Skip to main content
Every order creation and position-close request must include an Idempotency-Key header. This includes POST /v1/orders, POST /v1/twap-orders, POST /v1/scaled-orders, and POST /v1/positions/{position_id}/close. Use a unique value for each intended operation and reuse that same value only when retrying the identical request on the same endpoint. Standard orders and position closes also accept an optional client_order_id in the JSON body. The two values serve different purposes:
  • Idempotency-Key identifies one HTTP operation and prevents duplicate placement when that operation is retried.
  • client_order_id identifies the resulting order in your own system. It is returned with the order and can be used to retrieve that order without its server-assigned id.
The key may contain printable ASCII characters and may be up to 128 characters. MyFundedPerps binds it to the API key, endpoint, and a hash of the request. The binding is written in the same database transaction as the order, so two concurrent retries cannot create two accepted orders. The first accepted request returns 201 Created. A retry with the same key and payload returns 200 OK with the order’s current state. That state may have advanced since the first response, for example from pending to filled, so use the status returned by the retry. A trading-rule rejection returns 422 on both the original request and every matching retry. The error keeps the original order_id, rule code, and details, so a lost response cannot turn a rejected placement into an apparent success. Reusing an idempotency key with a different account, market, side, size, or other order field is rejected. Generate keys with enough entropy, such as a UUIDv4 or ULID, and retain them alongside your local order record.

​
Reconcile by client order ID

Set client_order_id before sending an order, then persist it with your local order intent. It may contain non-space printable ASCII characters and may be up to 128 characters. IDs are unique across your MyFundedPerps user, including orders submitted with a different API key.
If a response is lost, retrieve the order directly:
The response uses the normal order-page shape with either one matching order or an empty data array. You may also send account_id to require the match to belong to a particular account. Do not combine client_order_id with status, limit, or cursor. Reusing a client order ID with the identical placement returns the existing order, even after API key rotation. Reusing it for a different payload returns 409 client_order_id_conflict.