Idempotency-Key header when a network retry must refer to the original capture.
Retry the same request
Use the same API key, idempotency key, capture options, execution mode, and webhook configuration. Matching retries reuse the original job and its reservation. If the job is still pending, the response can be 202; after success, it can be 200 with the existing artifact. Reusing an account’s idempotency key with a different API key or conflicting configuration returns409 idempotency_conflict. Defaults are normalized before fingerprinting. Keep the whole original request stable, including webhook secrets and mode, instead of relying on hand-edited equivalence.
An idempotency key identifies a logical submission. It is different from X-Request-ID, which identifies an HTTP request for tracing.
Recover after losing the response
GET /v1/jobs/{id}. You need jobs:read and the submitting API key.
If the job is pending or unknown, continue tracking it. If it is complete, use its artifact. If it failed, decide whether the underlying cause warrants a new capture with a new key. Reusing the old key does not request a new render after terminal failure.
Avoid duplicate work
- Save your idempotency key together with the original request.
- Submit the capture.
- Persist the returned job ID or artifact URL.
- After a network error, recover by key or replay the identical request with that key.
- Create a new key only when you intentionally want another capture.
unsupported_option for idempotency, it does not have the durable submission capability configured. Correct deployment configuration before relying on retry deduplication.