Requests

Serverless › Requests tracks every async request in the workspace (async images, image edits, all videos) — including the exact failure cause, which the sync path can’t always give you. Sync calls return their result directly and don’t appear here.

Request lifecycle

queued ──▶ running ──▶ succeeded
   │                 ├▶ failed
   └──────────────── ▶ canceled

Every accepted request terminates. Even if a worker dies mid-job, a sweeper resolves it to failed/canceled — nothing stays stuck.
Execution timeouts: image > 5 min, video > 30 min → model_timeout.
The three terminal states map 1:1 to webhook events.

The list

Newest first; filters: status × modality; rows show id, status, modality, model, created/finished time.
Same data over the API: GET /v1/requests?status=...&limit=... (reference).

Request detail

Field	Notes
`status`	See lifecycle above
`output_object_key` / `output_bucket`	Where the result landed (storage)
`output_urls`	Presigned links — only when `succeeded`, valid ~1 hour; re-open for fresh ones
`error_code` / `error_message`	Set when `failed` — table below
`queued_at` / `started_at` / `completed_at`	Timestamps

Error codes

`error_code`	Meaning	What to do
`vram_exceeded`	Job exceeded GPU memory	Smaller size/steps, a more quantized model, or raise the deployment’s price cap
`model_timeout`	No result within budget (image 5 min / video 30 min)	Retry; reduce job size if persistent
`pod_crash`	Worker ran out of host memory	Contact support
`storage_upload_failed`	Couldn’t write to your output bucket	Re-verify the credential under Settings → Integrations

Canceling

Only queued requests can be canceled — row button or POST /v1/requests/{id}/cancel.
Once running, the GPU is committed: cancel attempts return 409 with the current status.
A successful cancel is terminal (canceled) and fires request.canceled.
Nothing to refund either way — billing is the deployment’s GPU-hours, not request counts.

Access

Workspace members only — other workspaces’ request ids return 403/404.