Skip to content
Guides/Idempotency & retries
Guides

Idempotency & retries

Retry requests safely without paying for the same analysis twice.

Protect an analysis

Send an Idempotency-Key header to identify one logical analysis. Generate the key before the first attempt and keep it with the request payload so you can reuse both after a network failure.

http
Idempotency-Key: 7c279d2e-9b37-4af7-9f61-67dfeb4718e2

Keys are optional, nonempty, at most 256 bytes, and must not have surrounding whitespace. A UUID is a useful choice. Without a key, every request is a new analysis and can incur a separate charge.

How retries behave

SituationResult
Same key and same payload, analysis completeOriginal result with credits_charged: 0 and a fresh X-Request-ID.
Same key, analysis still processing409 request_in_progress with Retry-After.
Same key and different payload409 idempotency_conflict.
Same key, previous operation failed without a charge409 previous_request_failed. Start new work with a new key.
Key reused after the retention window expiresStarts a new analysis and may incur a new charge.

Keys are scoped to your account and endpoint, not a particular API key. Rotating an API key does not create a new idempotency scope.

Retry window

Retry protection lasts 24 hours from first acceptance. Additional retries do not extend this window. Treat a retry after expiration as potentially billable new work.

Keep the payload unchanged, including image URLs and image order. If you intentionally change an image or hint, use a new key. Surrounding hint whitespace is normalized, and an omitted currency defaults to USD; do not rely on modifying a request during recovery.

Recover an uncertain result

  1. Keep the original idempotency key and request payload.
  2. Retry with the same key if the connection drops, your client times out, or you receive 503 analysis_unavailable.
  3. For 409 request_in_progress, 429 rate_limited, or 503 rate_limit_unavailable, wait for the Retry-After interval before retrying with the same key and payload.
  4. Apply bounded exponential backoff with jitter to transient failures. Stop after a reasonable number of attempts and preserve the key for later recovery within the window.
  5. Save the latest X-Request-ID for support if the result stays uncertain.

Start again after a known failure

502 analysis_failed means a complete result could not be produced and no analysis credit was consumed. A subsequent request using that failed operation’s key returns 409 previous_request_failed.

After correcting the cause, use a new key to start a new analysis. A successful new analysis costs one credit.