Developer platform · Public beta
Idempotency, errors, and retention
Build retry-safe integrations and handle asynchronous operations predictably.
Idempotency
Every billable POST requires an Idempotency-Key. Repeating the same key, route, operation kind, requested options, and normalized client input returns the original operation. Reusing a key with different semantics returns 409.
Keep keys stable across transport retries. Do not use a random key for every attempt.
Error envelope
Errors include a stable code, human-readable message, and request ID. Authentication and ownership failures do not disclose whether another tenant's resource exists.
- 400
- Malformed or unsupported input
- 401/403
- Missing credential, scope, origin, ownership, suspension, or pause
- 402
- Spend limit or paid mode cannot be admitted
- 409
- Idempotency conflict
- 413
- Body too large
- 429
- Capacity exhausted; honor Retry-After
- 5xx
- Service failure; retry only with the same idempotency key
Retry-After and polling
For 429 or temporarily queued work, wait at least the Retry-After value and add jitter. Keep only one poll in flight. Stop at the terminal succeeded, failed, or cancelled state.
Retention and caching
Generated artifacts are retained for 30 days, then cleanup and bucket lifecycle policies remove them. Authenticated responses use Cache-Control: no-store. Do not place credentials or user plate text in URLs, analytics dimensions, or shared caches.