Problem
Creative-generation workflows commonly return MCPUI preview URLs for draft variants. If those preview URLs point at process-local state, they break in multi-pod deployments when a browser/MCPUI fetch lands on a different pod than the one that created the draft.
We hit this in staging with a generated Meta image creative: the creative session was created successfully, but the returned asset URL later 404ed because the API instance serving GET /creative-sessions/{sessionId}/variants/{variantId}/assets/{assetId} did not have that in-memory session.
Why this matters for the SDK
This is easy for implementers to get wrong because the SDK/MCPUI flow makes it natural to return a URL immediately, but it does not currently nudge the implementer toward a durable resource contract. Creative iterations also include draft variants, refinement lineage, evaluator notes, selected/finalized state, and sometimes inline bytes; those are workflow state, not just a transient cache.
Suggested SDK help
The SDK should provide guidance and/or helpers for durable preview resources in creative workflows:
- A documented pattern for preview asset URLs/resource URIs that are stable across process boundaries.
- A helper/type for returning either a durable hosted artifact URL or an opaque
asset_ref/resource URI that the host can resolve.
- Explicit distinction between inline draft bytes, hosted artifacts, and final campaign creative manifests.
- Guidance that MCPUI preview links must not depend on pod-local in-memory maps unless the server is single-process/dev-only.
- Optional serialization helpers for creative session variants, preview resources, and creative manifests, so implementations do not have to invent ad hoc JSON shapes.
Expected outcome
An SDK adopter building a creative-session or generated-asset workflow should have an obvious path to return MCPUI preview links that survive load balancing, pod restarts, and later refinement/finalization calls.
Related implementation note
In our API we are fixing this by persisting creative-session state in Postgres and using the local in-memory map only as a cache. Larger inline assets may move to object storage later, with Postgres remaining the metadata/session index.
Problem
Creative-generation workflows commonly return MCPUI preview URLs for draft variants. If those preview URLs point at process-local state, they break in multi-pod deployments when a browser/MCPUI fetch lands on a different pod than the one that created the draft.
We hit this in staging with a generated Meta image creative: the creative session was created successfully, but the returned asset URL later 404ed because the API instance serving
GET /creative-sessions/{sessionId}/variants/{variantId}/assets/{assetId}did not have that in-memory session.Why this matters for the SDK
This is easy for implementers to get wrong because the SDK/MCPUI flow makes it natural to return a URL immediately, but it does not currently nudge the implementer toward a durable resource contract. Creative iterations also include draft variants, refinement lineage, evaluator notes, selected/finalized state, and sometimes inline bytes; those are workflow state, not just a transient cache.
Suggested SDK help
The SDK should provide guidance and/or helpers for durable preview resources in creative workflows:
asset_ref/resource URI that the host can resolve.Expected outcome
An SDK adopter building a creative-session or generated-asset workflow should have an obvious path to return MCPUI preview links that survive load balancing, pod restarts, and later refinement/finalization calls.
Related implementation note
In our API we are fixing this by persisting creative-session state in Postgres and using the local in-memory map only as a cache. Larger inline assets may move to object storage later, with Postgres remaining the metadata/session index.