Chain v3 generations with asset_id

Every job that completes in the v3 API returns an outputs[] array. Each item carries an asset_id you can pass straight into a later submit’s media inputs, so you can chain generations — for example, generate an image, then animate it into a video — without downloading and re-uploading the file in between.

Reference an output in the next submit

Submit the first job and poll GET /v3/jobs/{job_id} until every item in outputs[] reports status: "COMPLETED".
Read outputs[0].asset_id (or whichever output you want to chain from) — it looks like asset_<uuid>.
Pass it in the next submit as an asset reference:

{
  "input": {
    "start_keyframe": { "source": "asset", "asset_id": "asset_..." },
    "prompt": "the character waves at the camera"
  }
}

asset_id is the only supported way to name a previous job’s output. If you pass a job_<uuid> in an asset field the API returns a 400 pointing you back at outputs[].asset_id.

Earlier drafts of the API described a workaround where you replaced the job_ prefix of a job id with asset_ to obtain the asset id. That derivation is no longer supported — read outputs[].asset_id instead.

Example: image, then video

# 1. Generate an image and capture the job id.
JOB_ID=$(curl -sS -X POST https://api.hedra.com/v3/models/gpt-image-2 \
  -H "Authorization: Key $HEDRA_KEY" \
  -H "Content-Type: application/json" \
  -d '{"input": {"prompt": "a golden retriever in a sunflower field", "aspect_ratio": "16:9", "resolution": "1K"}}' \
  | jq -r .job_id)

# 2. Poll until COMPLETED, then pull the output asset id.
ASSET_ID=$(curl -sS https://api.hedra.com/v3/jobs/$JOB_ID \
  -H "Authorization: Key $HEDRA_KEY" | jq -r '.outputs[0].asset_id')

# 3. Use that asset id as a keyframe for a video generation.
curl -X POST https://api.hedra.com/v3/models/veo-3 \
  -H "Authorization: Key $HEDRA_KEY" \
  -H "Content-Type: application/json" \
  -d "{\"input\": {\"start_keyframe\": {\"source\": \"asset\", \"asset_id\": \"$ASSET_ID\"}, \"prompt\": \"the dog runs through the field\"}}"

Output status and the 48-hour retention window

Each item in outputs[] carries a status:

Status	Meaning
`COMPLETED`	The output produced media. `url` and `asset_id` are populated.
`FAILED`	The output failed. `error` describes the failure; `url` and `asset_id` are null.
`EXPIRED`	The generated media has been garbage-collected. Metadata is retained, but `url` and `asset_id` are null.

Generated media is retained for 48 hours after a job completes. After that window the underlying files are deleted and the output flips to EXPIRED. The job record itself remains — you can still read its metadata (dimensions, duration, timing, error envelope) — but you cannot download the bytes or reference the output as an asset in a new submit. This affects two kinds of callers in particular:

Long-lived polling loops. If a client polls a job more than 48 hours after it completed, expect outputs[].status = "EXPIRED" with url: null and asset_id: null.
Webhook replays. A webhook delivery that is replayed after the retention window carries the same EXPIRED payload as a poll would — the retention window is measured from the original completion time, not from delivery.

If you need the output beyond 48 hours, download it to your own storage soon after the job completes.

import time
import httpx

def wait_for_result(job_id: str, key: str) -> dict:
    headers = {"Authorization": f"Key {key}"}
    while True:
        job = httpx.get(f"https://api.hedra.com/v3/jobs/{job_id}", headers=headers).json()
        outputs = job["outputs"]
        if all(o["status"] in ("COMPLETED", "FAILED", "EXPIRED") for o in outputs):
            return job
        time.sleep(2)

job = wait_for_result(job_id, api_key)
for output in job["outputs"]:
    if output["status"] == "EXPIRED":
        raise RuntimeError("Output expired — media is no longer retrievable.")
    if output["status"] == "FAILED":
        raise RuntimeError(f"Output failed: {output['error']}")
    # COMPLETED — download output["url"] or chain output["asset_id"].

Per-output errors

error is now published on every kind of output — image, video, and audio — as an error envelope. It is null on a COMPLETED output and populated on a FAILED output, so you can inspect the failure per-item when a job produces multiple outputs.

Measured frame rate on video outputs

Video outputs now report the real measured frame rate in fps. Older jobs whose output was probed before this change may still return fps: null — treat null as “unmeasured” rather than “no frame rate”.

Getting Started

Guides

Concepts

API Reference

Chain v3 generations with asset_id

Reference an output in the next submit

Example: image, then video

Output status and the 48-hour retention window

Per-output errors

Measured frame rate on video outputs

​Reference an output in the next submit

​Example: image, then video

​Output status and the 48-hour retention window

​Per-output errors

​Measured frame rate on video outputs

Reference an output in the next submit

Example: image, then video

Output status and the 48-hour retention window

Per-output errors

Measured frame rate on video outputs