Idempotency
The Flowlix API supports idempotency for safely retrying requests without performing the same operation twice. This is critical for payment processing, where network issues or timeouts can leave you unsure whether a request succeeded.How it works
Include anIdempotency-Key header with a unique value on any POST request:
Behavior
- First request — Flowlix processes the request normally and stores the response against the idempotency key.
- Subsequent requests with the same key and same parameters — Flowlix returns the stored response without reprocessing. The response is byte-for-byte identical.
- Same key but different parameters — Flowlix returns a
409 Conflicterror. You cannot reuse a key with different request bodies.
Key requirements
| Rule | Detail |
|---|---|
| Format | Any string up to 255 characters. We recommend UUIDv4. |
| Scope | Keys are scoped to your API key. Different API keys can use the same idempotency key without conflict. |
| Expiration | Keys expire after 24 hours. After expiration, the same key can be reused as if it were new. |
| Applicable methods | Only POST requests. GET requests are naturally idempotent. |
Generating keys
We recommend using UUIDv4 for idempotency keys:Conflict errors
If you reuse an idempotency key with different request parameters, you get a409 Conflict:
Best practices
- Always use idempotency keys for payment creation and refund requests.
- Generate a new key for each distinct operation — do not reuse keys across different payments.
- Store the key alongside the order in your database so you can retry with the same key if needed.
- Use deterministic keys for retries — if retrying a failed request, use the same key as the original attempt.
- Do not generate keys randomly on each retry — that defeats the purpose. The key must be the same across all attempts of the same operation.
Retry strategy
A recommended retry strategy for payment requests:- Generate an idempotency key for the operation.
- Send the request.
- If you get a network timeout or
5xxerror, wait and retry with the same idempotency key. - Use exponential backoff: wait 1s, 2s, 4s, 8s, up to a maximum of 30s.
- After 3-5 retries, stop and alert your operations team.