At a glance

Generated images and videos are copied into our storage so we can hand you a stable link, and that copy is deleted automatically after 30 days. You can shorten that per request with store: false or output_ttl_secs on images and videos, and delete a video yourself through the API. A scheduled lifetime is never shorter than 24 hours, and a video can't be deleted by hand sooner than 24 hours after it was generated.

Deletion applies to our copy only. It does not reach the model provider that generated the output, see what deletion does not cover.

Controlling how long a video is kept

Three controls. store and output_ttl_secs work on both POST /v1/videos and POST /v1/images; deleting a finished video by id is videos only. Each needs an API key with the matching scope.

Delete a video

curl -X DELETE https://videorouter.sh/v1/videos/$VIDEO_ID \
  -H "Authorization: Bearer $VIDEOROUTER_API_KEY"

# 200
{
  "id": "video_...",
  "object": "video.deleted",
  "deleted": true,
  "files_deleted": 1
}

Deleting is permanent and cannot be undone. Calling it again, or fetching the video afterwards, returns 404. It only works on a video that has finished, and only once the video is 24 hours old.

Give a video a shorter lifetime

curl https://videorouter.sh/v1/videos \
  -H "Authorization: Bearer $VIDEOROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "bytedance/seedance-2.0/fal",
    "prompt": "A paper boat drifting down a rainy street",
    "output_ttl_secs": 172800
  }'

The timer starts when the job completes, not when you submit it. Once it has completed, the job reports the deletion time as output_expires_at (Unix seconds):

{
  "id": "video_...",
  "status": "completed",
  "data": [{ "url": "https://..." }],
  "cost_usd": 0.42,
  "output_expires_at": 1760745600
}

• store: false does not mean the output is never stored. A result has to be stored so we can deliver it to you, so it means the shortest lifetime we offer: 24 hours after completion.
• A value of output_ttl_secs below 24 hours is raised to 24 hours, not rejected. A value that is not an integer, or above 30 days, is a 400.
• "Completes" means the moment we first see the job finished, either on your poll or on our background check of unattended jobs. A job nobody polls still expires, at the latest on the 30-day default.

Why 24 hours?

A finished video or image has already been paid for upstream, so we do not let it be generated, viewed and removed within the same hour. Every way of deleting an output, whether by hand or by a requested lifetime, waits until it is 24 hours old.

What each call returns

Webhooks are not sent for a job whose output was deleted before it finished.

Generated images

Images are kept for the same 30 days. Send "store": false (24 hours) or "output_ttl_secs" (24 hours to 30 days) with the POST /v1/images request and the response reports output_expires_at. There is no per-image delete call yet. To remove images by hand, open the request log, tick the image rows, and choose Delete outputs. The same button handles videos, and skips any image or video generated in the last 24 hours. Each image is billed when it is submitted, so deleting one never changes what you were charged.

Other files we hold

• Audio on /v1/audio/* (speech-to-text input, text-to-speech, music and sound-effect output): kept 30 days for debugging, then deleted. Send "store": false (a form field on transcriptions) to keep it 24 hours instead. Like videos, it is never deleted sooner than 24 hours, and it is not skipped entirely: a copy has to exist briefly so we can look into a billing or quality dispute.
• Image- and video-request input references: kept 30 days for debugging, then deleted. store: false and output_ttl_secs apply to generated outputs only, not to these copies.
• Reference files you upload for a generation call (the upload endpoint): the uploaded file is deleted after 30 minutes. Using it in an image or video request also leaves the 30-day debugging copy above.
• Assets you save in Studio (uploads, elements, voices), review attachments and community posts: kept until you delete them or delete your account.

The request log

Every request writes a log row: model, routing decision, token counts, cost, timing, status, and a copy of what you sent (the chat messages and reply, or the parameters and prompt of an image, video or audio request, with very long values truncated). It backs /logs and /usage, and is visible to your own account and to our staff for support, billing and safety review.

These rows are kept while your account is active and are not removed when you delete a generated output. We keep the prompt, settings and cost of a job for billing. There is no automatic expiry yet; email contact@zeus.rocks to have them erased. What a log row contains is covered on Data privacy & logging.

What deletion does not cover

• The model provider's copy. Your request is sent to whichever provider serves it, and none of them offers us a delete call. Whatever they hold follows their own terms, not ours.
• Links you already shared. Until the file is deleted, anyone with the link can open it, so treat output links as secrets. After deletion the link stops working.
• The request-log row, as above.
• Copies you downloaded. Those are yours to manage.

To delete everything tied to your account, including log rows, email contact@zeus.rocks. The full policy is on the Privacy Policy page.