Idempotency

Send Idempotency-Key on every order. Any string up to 128 characters; a UUID is fine.

curl -X POST ".../accounts/$ID/orders" \
  -H "idempotency-key: 8f14e45f-ea8f-4b12-9c1a-3d7bbb1c2e01" \
  -d '{"symbol":"XAUUSD","side":"buy","volume":0.1}'

Why it matters more here than in most APIs

Your connection drops just after the order left your process. You do not know whether it executed. Retrying risks a second position; not retrying risks no position at all. With an idempotency key there is no dilemma — the retry returns the first result.

Our SDKs generate a key for every order automatically, so this is handled for you unless you are calling the API directly. If you retry across process restarts, pass your own stable key instead of letting the client invent one.

The three cases

State of that key	What you get
Never seen	The order executes. The result is stored for 24 hours.
Seen and finished	The stored result, identical to the first response. Nothing executes.
Seen and still running	409 conflict. Nothing executes.

The third case is refused rather than queued on purpose. If a request with that key is in flight, the honest answer is "one is already going out", not a second one. Wait for the first response.

Keys are scoped to your team, so picking order-1 cannot collide with another customer's, and nobody can read your result by guessing a key.

A request that fails releases its key, so you can retry the same order with the same key after fixing whatever was wrong.

What can go wrong

You see	It means
conflict — "still in flight"	You retried too fast. Wait for the first response.
An identical response you did not expect	You reused a key from a previous order. Use a new key per intent.
A second position despite retrying	You did not send the header, or you sent a different key.