Skip to main content
Send an Idempotency-Key header on POST /v1/decisions to make retries safe. The header is optional, and the key must be 1 to 256 characters.

How it behaves

Keys are scoped to the account. Changing the model between tazo-large and tazo-small under the same key counts as different input.

Retry rules

1

Generate one key per operation

Create the key before your retry loop, not inside it.
2

Reuse it for every attempt

Send the same key and the same input on each retry.
3

Use a new key for new work

A different operation gets a different key.
If you resume an earlier operation later, let callers supply the key you retained for it.

Pending results

If processing outlasts the wait, you get 504 with the code decision_pending, an X-Tazo-Request-Id header, and a request_id in the body. Processing continues in the background. Check error.retryable before you retry:
  • With a key, it is true. Repeat the POST with the same key to get the result.
  • Without a key, it is false. Retrying would create a second request.

Uncertain submissions

A 503 durable_execution_unavailable means the API could not confirm the submission. The work may already have been accepted. With a key, retrying is safe. Without one, retrying can create another request, so the API does not recommend it.