> ## Documentation Index
> Fetch the complete documentation index at: https://docs.myfundedperpetuals.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Idempotency

> Retry order creation without accidentally placing a duplicate order.

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`.

```http theme={null}
Idempotency-Key: 01J6Y6K4ZKQ9R0M3YQ59P8M0PC
```

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.

```json theme={null}
{
  "client_order_id": "strategy-7:entry-42",
  "account_id": "YOUR_ACCOUNT_ID",
  "market_id": "binance|BTCUSDT"
}
```

If a response is lost, retrieve the order directly:

```bash theme={null}
curl --get "https://developers.myfundedperpetuals.com/v1/orders" \
  -H "Authorization: Bearer $FP_API_KEY" \
  --data-urlencode "client_order_id=strategy-7:entry-42"
```

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`.