Why
You send a request, but the network drops the response before it reaches you. Did it go through? With an idempotency key you can just retry: the same key returns the original result instead of doing the work a second time.How it works
The operations that create money movement take anidempotencyKey — a UUID you generate — in the request body:
- The first call with a key runs the operation.
- The same key with the same body returns that original result — the operation runs once, however many times you retry.
What a replay actually returns
A retry only replays cleanly when the original succeeded. Every other case is an error, and one of them surprises people:
Treat
409 as “wait and re-read” rather than an error to surface: the original is still running, and
retrying the same key once it settles gives you the result.
Keys are unique per company across all idempotent endpoints, not per endpoint — so a key used on a
transfer cannot be reused on a pay-out.
Two rules
- Generate one new key per operation — each transfer, pay-in, pay-out, and virtual bank account gets its own.
- Reuse a key only to retry that exact call. For a genuinely new operation, generate a new key.
Every other endpoint ignores the field. Reads are naturally safe to repeat, and the remaining writes are
either idempotent by construction or keyed on a resource you already name in the path.
Next steps
API conventions
Pagination, versioning, and the shared idempotency rules.
Transfers
Fiat and crypto transfers — each with its own key.

