orderId, customerId, and bankAccountId. Because you supply the ID, it doubles as an idempotency key: the API enforces uniqueness on it, so a retried create can’t silently produce a duplicate.
How it works
When you create an order with anorderId you’ve already used, the API rejects the second request with 409 Conflict rather than creating a duplicate:
orderId on retry. One of two things happens —
- the original request never landed → the retry creates the order, or
- the original request did land → the retry returns
409, telling you the order already exists.
Recommended retry pattern
- Generate the resource UUID once and persist it before the first attempt.
- Reuse that same UUID on every retry.
- Treat
409 Conflictas success — the resource already exists. - If you need the resource’s current state,
GETit by ID.
A second safety net for onramps
Beyond the per-ID check, onramps are also guarded against accidental duplicates by amount: only one pending onramp order can exist for a given(bank account, amount) pair. A second attempt returns: