Media retention

Every request leaves two kinds of data behind: the media the model generates, which we host and hand back as a URL, and the JSON bodies of the call itself, which power the request log in your dashboard. This page says how long each one lives and how to change it.

Each has its own default and its own header, and both are read per request — retention is something you decide at the call site, not a workspace setting.

Generated media

A completed job's result carries URLs that expire. The window starts when the result is ready rather than when you read it, so a job you poll slowly has already spent part of it. After that the URL stops serving the file and answers 410 Gone.

Per-request expiration

X-Veed-Media-Expiration-Seconds sets the window, in seconds:

curl https://api.veed.io/v1/fabric-1.0 \
-H "Authorization: Bearer $VEED_API_KEY" \
-H "X-Veed-Media-Expiration-Seconds: 3600" \
-H "Content-Type: application/json" \
-d '{ "image_url": "https://example.com/face.jpg", "audio_url": "https://example.com/line.mp3" }'

Left unset it is 86400 seconds, one day. The ceiling is 2592000 seconds, thirty days: ask for longer and you get thirty days rather than an error, so read back what you asked for if it matters.

Shorten it when the link passes somewhere you do not control — an email, a webhook payload, a log line. Anyone with the link can fetch the file until the window closes. Lengthen it when a human has to act on the result.

Request payloads

Each call's request and response body is stored for 7 days, which is what makes the request log worth reading — it is where you see the exact payload that produced a result, or the one that produced an error. Past 7 days the bodies are dropped and the log marks them expired.

Preventing payload storage

X-Veed-Store-IO governs whether the bodies are kept at all:

curl https://api.veed.io/v1/fabric-1.0 \
-H "Authorization: Bearer $VEED_API_KEY" \
-H "X-Veed-Store-IO: 0" \
-H "Content-Type: application/json" \
-d '{ "image_url": "https://example.com/face.jpg", "audio_url": "https://example.com/line.mp3" }'

It is 1 unless you send otherwise, and opting out is per call — keep it on everywhere and turn it off for the requests carrying something you would rather we did not hold, like a customer's name in a prompt.

What is kept either way

Turning payload storage off does not make a request invisible to you. Its metadata is recorded regardless — when the call was made, which model, which status, how long it took and what it cost — because that is what your usage and billing are counted from. A request whose bodies are gone still shows what it did; it no longer shows what it said.

Summary

There is no workspace-level default for either header yet, so a policy you want applied everywhere belongs in the client your services share — set the headers once in whatever wraps the SDK rather than at each call site. The API reference lists both on every endpoint.