# Media retention

How long result URLs live, what the API keeps of your requests, and the two headers that set both.

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:

- `X-Veed-Media-Expiration-Seconds` · integer · optional — Number of seconds before the media URLs returned for this request expire. A value above the maximum is capped rather than rejected. At most 2592000. Defaults to `86400`.

```bash
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.

**Warning** — An expired URL is not renewable: polling the job again returns the same URL,
and it stays expired. Copy anything you need to your own storage while the
link still works.

## 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:

- `X-Veed-Store-IO` · enum · optional — Set to `0` to not store this request's and response's bodies. They are then not available in your request logs for debugging. Accepts `0`, `1`. Defaults to `"1"`.

```bash
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.

**Note** — This governs the stored JSON only. The result URLs from those calls are
unaffected: their lifetime is the media header above.

### 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

| Data | Default retention | Control |
| --- | --- | --- |
| Generated media (result URLs) | `86400` seconds, up to `2592000` | `X-Veed-Media-Expiration-Seconds` |
| Request and response bodies | 7 days | `X-Veed-Store-IO: 0` to opt out |

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](https://api.veed.io/docs/api) lists both on every endpoint.