Problem
expires_at is required in both the single and batch preview responses (preview-creative-response.json). However, some creative agents produce preview URLs that do not expire. The spec defines no convention for this case — implementers must either:
- Advertise a far-future timestamp (e.g. 30 days out), misrepresenting actual expiry behaviour
- Omit the field (schema violation)
- Use a sentinel value (no such value is defined)
Proposed fix
Two options — requesting spec authors pick one:
Option A: Make expires_at optional. Omission signals non-expiring. Add a note: "Omit expires_at if preview URLs do not expire. When present, consumers MUST treat URLs as invalid after this timestamp."
Option B: Define a sentinel value (e.g. "9999-12-31T23:59:59Z") for non-expiring URLs, with a note in the schema description.
Option A is cleaner and avoids a magic value.
Affected files
schemas/v3/creative/preview-creative-response.json (both single and batch branches — expires_at required field)docs/creative/task-reference/preview_creative.mdx
Problem
expires_atis required in both the single and batch preview responses (preview-creative-response.json). However, some creative agents produce preview URLs that do not expire. The spec defines no convention for this case — implementers must either:Proposed fix
Two options — requesting spec authors pick one:
Option A: Make
expires_atoptional. Omission signals non-expiring. Add a note: "Omitexpires_atif preview URLs do not expire. When present, consumers MUST treat URLs as invalid after this timestamp."Option B: Define a sentinel value (e.g.
"9999-12-31T23:59:59Z") for non-expiring URLs, with a note in the schema description.Option A is cleaner and avoids a magic value.
Affected files
schemas/v3/creative/preview-creative-response.json(both single and batch branches —expires_atrequired field)docs/creative/task-reference/preview_creative.mdx