Idempotency-Key header solves this: it lets you retry a request any number of times with the guarantee that Therius will process it exactly once.
How It Works
All mutating endpoints accept anIdempotency-Key request header:
POST /payment/purchasePOST /payment/authorizationPOST /payment/{id}/capturePOST /payment/{id}/refundPOST /payment/{id}/cancelPOST /payment/{id}/cancel_or_refundPOST /payment/resumePOST /subscriptionPOST /subscription/usage— see the note below; the semantics differ slightly
- First request — Therius reserves the key, processes the payment, and stores the
2xxresponse against the key. - Retry with the same key — Therius detects the duplicate, skips processing, and returns the cached response immediately.
- Concurrent request with the same key — If a second request with the same key arrives while the first is still in flight, Therius returns
409 Conflictwith aRetry-After: 1header. Wait one second and retry. - Wrong endpoint, same key — Reusing a key on a different endpoint returns
422 Unprocessable Entity.
Only
2xx responses are cached. If a request fails with a 4xx or 5xx status, the key is not stored — you can retry with a new key (or the same key, if the error was transient and you want to re-attempt the same operation).POST /subscription/usage reads the Idempotency-Key header too, but it is deduplicated per (meterCode, Idempotency-Key) and never expires: a replay returns the original usage event with "duplicate": true rather than a cached HTTP response. The key is optional there — omit it and every call records a new event.Code Examples
Bash / cURL
$IDEM_KEY value. Therius will return the cached result if the original request succeeded.
JavaScript
fetch call throws a network error, retrieve the stored UUID and retry with it — do not generate a new one.
Best Practices
- Generate the key before the request, not after. Store it with the order record so you can retrieve it if you need to retry.
- One UUID per logical operation. A purchase and its subsequent refund are two separate operations — each gets its own UUID.
- Do not reuse keys across endpoints. A key used for
POST /payment/purchasecannot be used forPOST /payment/{id}/refund. - Do not share keys across customers or orders. Each key must be globally unique to a single operation.

