preview_creative renders an existing creative manifest into viewable output. It does not generate or modify the input manifest — use build_creative for that. Supports both single creative preview and batch preview (5-10x faster for multiple creatives).
Request Schema: /schemas/3.2.0-beta.0/creative/preview-creative-request.json
Response Schema: /schemas/3.2.0-beta.0/creative/preview-creative-response.json
Quick Start
Single Creative Preview
Direct HTML Embedding
For faster rendering without iframe overhead, request HTML directly:Batch Preview (Multiple Creatives)
Preview multiple creatives in one API call (5-10x faster):Variant Preview (Post-Flight)
Preview what a specific variant looked like when served. Usevariant_id from get_creative_delivery response:
get_creative_delivery includes its full manifest, you can also pass the manifest directly to preview_creative as a standard single request to re-render it.
Request Parameters
All modes use a single flat object withrequest_type as the discriminant.
Required column values: Conditional = single requests and batch items require one of
creative_manifest or creative_id; Batch = required when request_type is "batch"; Variant = required when "variant".
Discover renderers from get_adcp_capabilities.creative.supported_formats[] by selecting entries whose operations contains preview and whose canonical format satisfies the manifest. capability_id is an agent-local renderer route; it never belongs in the portable manifest. If multiple renderers match, the caller must select one explicitly.
Opt-in asynchronous preview
preview_creative is synchronous by default. A buyer that can poll task results MAY set allow_async: true. Only then may an agent hand rendering to a queue or external renderer, release the request connection, and return:
get_task_status with task_id; the completed task result contains the normal single, batch, or variant preview response. If the request also supplies push_notification_config, the agent sends at least the terminal completion/failure notification and the same task remains pollable. response_type: "submitted" keeps this fourth arm in the same discriminator family as the three synchronous preview arms; status: "submitted" is the task-lifecycle signal.
submitted is for work that continues after the request connection is released, including a queued upstream renderer. If the agent is actively rendering while keeping the connection open, it uses working progress and returns the normal response on that connection. When allow_async is false or absent, agents MUST NOT return the submitted shape. build_creative already has a separate async response contract and is unchanged by this field.
Preview remains read-only in every lifecycle state. Queuing a preview MUST NOT build or approve a creative, add it to a creative library, or modify the supplied or stored manifest.
Input Sets
Generate multiple preview variants by providing different contexts:DEVICE_TYPE, COUNTRY, CITY, DMA, GDPR, US_PRIVACY, CONTENT_GENRE, etc.
Context descriptions: For AI-generated content like host-read audio ads.
Response Format
Single Mode Response
Batch Mode Response
Preview Structure
render_id and role.
Previewing generative creative
For generative formats — contextual display, AI-generated native, conversational ads — the creative doesn’t exist until serve time. Preview serves two distinct purposes:Pre-flight: representative samples
Before the campaign runs, use single or batch mode to preview what the agent could generate given different contexts. Passinputs with context_description to simulate serve-time conditions:
Post-flight: exact replay
After the campaign runs, use variant mode to see exactly what was served. Pass avariant_id from get_creative_delivery:
Setting expectations
For generative formats where every impression produces a different creative (like AI chat or real-time contextual), pre-flight previews are best understood as samples from a distribution rather than the ad. The brief and brand identity constrain the distribution; previews let you verify the agent interprets those constraints correctly.
Conversational and interactive formats
For formats where the ad is stateful — AI chat, interactive experiences, conversational native — preview takes on additional meaning:- Pre-flight renders a representative first interaction or simulated conversation. The
interactive_urlfield in the preview response (when present) provides a sandbox where reviewers can interact with the experience directly. Usecontext_descriptionto simulate different conversation entry points. - Post-flight variant replay shows the actual exchange that occurred. For multi-turn formats, the variant manifest captures the full content the agent produced (message sequence, responses, media assets shown). The level of detail depends on the agent — some provide full transcripts, others provide summarized content with anonymized user signals.
Quality levels
The preview quality tier describes render fidelity, not merely the renderer’s relative cost or speed. It is not a validation result, compliance or brand-safety clearance, seller acceptance, or authorization to serve. Buyers use the applicable validation, governance, and seller creative-review workflows for those decisions.draftis an iteration render for reviewing creative direction. It MUST preserve the supplied manifest or brief’s core concept, content, and non-fidelity constraints, but it MAY use lower-resolution or placeholder assets; approximate layout, typography, color, motion, audio, or interactive behavior; and omit final polish. The protocol does not guarantee that any of those listed fidelity dimensions is final in a draft preview.productionis a fidelity-accurate review render. For standard or otherwise deterministic creative, it MUST faithfully render the supplied manifest—or the stored manifest resolved fromcreative_id—and its assets using the serve-time presentation controlled by the selected renderer. Inpreview_creative, material asset substitution or approximation requiresquality_used: "draft". It MUST include disclosure and compliance elements required by the manifest and those owned by that rendering layer for the supplied context.
production means that the sample uses the serve-equivalent generation pipeline and configuration, honors the same declared constraints, and uses the same full-fidelity presentation rules as serve-time generation. It does not promise that the same content will be generated for every impression. Final assets and layout MAY vary where the format varies them at serve time.
For stateful or interactive creative, a production preview MUST render the sampled state or path with serve-time visual and control fidelity. The tier makes no behavioral-coverage guarantee beyond that sample. Buyers assessing guardrails, disclosure persistence, error states, or multi-turn behavior SHOULD use interactive_url, when present, and exercise a scenario suite appropriate to the format.
These definitions also apply to preview_quality on an inline build_creative preview. In 3.x, that inline response does not echo quality_used, so an agent MUST either meet the requested preview_quality or return preview_error; it cannot silently substitute another tier. Buyers that need a successful response to echo the rendered tier use preview_creative.
Quality mismatch
If the requested quality level is not supported, the agent renders at the best quality it can provide and reports that tier inquality_used. When a single request supplies quality, the response MUST include quality_used. For batch mode, each successful result whose effective request supplied quality—either on the item or through the batch-level default—MUST include quality_used. Agents SHOULD report quality_used even when the request omitted quality, so buyers can record the renderer’s default tier.
Buyers MUST compare quality_used with the requested value before treating a preview as a production-fidelity review artifact. A mismatch means the agent applied a different tier; specifically, requested production with quality_used: "draft" is an explicit downgrade. quality_used does not appear on variant-mode replay because that mode reproduces a historical execution rather than selecting a new render-quality tier. Agents are not required to support both quality levels or advertise per-capability quality discovery.
In 3.x, quality_used is a binary fidelity gate: it does not identify which dimensions caused a downgrade. Buyers that receive a mismatch need agent-specific or out-of-band diagnostics before deciding whether to retry, select another renderer, or revise the creative.
Preview expiration and variant retention
Preview responses may include anexpires_at timestamp. When present, consumers should treat preview URLs as invalid after that time and re-generate them before reuse. When expires_at is omitted, the preview URLs do not expire. For generative creative, re-generating a pre-flight preview may produce different output — the same brief and context can yield different creative each time.
Preview URL durability
preview_url is the protocol resource buyers and MCPUI hosts render. AdCP does not define a separate durable asset pointer for preview renders in 3.x; if a creative agent needs an internal asset key, resource URI, or storage object ID, it remains agent-internal unless the schema adds a future field for it.
Creative agents MUST keep each preview_url dereferenceable until the response’s expires_at timestamp. When expires_at is omitted, the URL has no protocol-level expiration and must remain dereferenceable until the agent explicitly revokes or purges it out of band. Do not back preview URLs only with pod-local Map/LRU state in multi-process or multi-pod deployments, because a browser fetch, later refinement call, or reviewer session may land on a different process than the one that created the preview.
Durable storage does not require permanent public CDN hosting. A preview URL can resolve through the creative agent’s authenticated preview route as long as the route can recover the render from shared storage, such as a database row, object store key, or shared cache tier, for the advertised lifetime.
Variant previews (post-flight) depend on the agent retaining variant data. Agents are not required to retain variant data indefinitely. If you request a variant preview for a variant the agent has purged, expect a standard error response. For long-running campaigns, retrieve and archive variant previews periodically rather than assuming they will remain available.
Examples
Device Variants
Batch with HTML Output
Preview multiple creatives for a grid layout:AI-Generated Audio Preview
HTTP Status Codes
Single mode:- 200 OK - Preview generated successfully
- 400 Bad Request - Invalid canonical manifest
- 404 Not Found - Format not supported
- 200 OK - Batch processed (check individual
successfields) - 400 Bad Request - Invalid batch structure
Key Points
- Every render’s
preview_urlreturns an HTML page for iframe embedding - Use
output_format: "html"for grids of 10+ previews (no iframe overhead) - Batch mode is 5-10x faster than individual requests
- Preview URLs expire only when
expires_atis present; omittedexpires_atmeans no protocol-level expiration - Back preview URLs with storage that survives the URL’s advertised lifetime; process-local maps are only appropriate for single-process demos or shorter-than-process-lifetime URLs
- Handle partial batch failures by checking each result’s
successfield
Related Documentation
- Advanced Preview Patterns - Caching, workflows, implementation notes
- Creative Manifests - Manifest structure
- Creative Formats - Format specifications