What is a client order ID?

CoTrading editorial team 2026-09-23

Figures on this page are as of 2026-09. Fees, limits and margin tiers change — check the venue's own docs.

A client order ID is an identifier you choose and send with an order, so that you can refer to that order by your own name for it — including in the moments before, or instead of, receiving the ID the exchange assigns.

Venues call it different things. On Binance spot the field is newClientOrderId; on Hyperliquid it is cloid. This page covers what the ID is for, the one property of it that matters most — what it is unique against — how to use it to find an order, and why it does not make a retry safe.

Why this matters now

The exchange’s own order ID is created when the exchange accepts your order, and you learn it from the response. That is fine until the response does not arrive. After a timeout on an order call you do not have the exchange’s ID, and you do not know whether the order exists. The only name for that order you are guaranteed to hold is the one you sent.

That is the purpose of a client order ID: it is the handle you have before the exchange has told you anything. Every other use — tagging orders by strategy, matching fills in a stream, cancelling by your own reference — is secondary to that one.

How it actually works

You generate the ID and include it in the order request. On Binance spot, if you do not send one, one is “automatically generated if not sent”.
The venue stores it with the order, alongside its own order ID.
It comes back to you in order responses and order-status records, so you can match what the exchange reports to what you sent.
You can look orders up by it where the venue supports that. Hyperliquid’s info endpoint documents querying order status “by oid or cloid” — by its own ID or by yours.
The venue enforces uniqueness over some scope and refuses a duplicate within it. CCXT’s unified hierarchy has a class for that refusal, DuplicateOrderId, under InvalidOrder.

Step 5 is where the confusion lives, because “unique” always means “unique among some set of orders”, and the set differs.

Unique against what?

Binance documents its scope precisely, in the trading endpoints documentation:

“A unique id among open orders. Automatically generated if not sent. Orders with the same newClientOrderID can be accepted only when the previous one is filled, otherwise the order will be rejected.”

So on Binance spot, the ID is unique among open orders. While an order with that ID is resting, a second one is refused. Once the first has filled, the ID is free again.

That is one possible scope among several. When you read another venue’s documentation, the questions to answer are:

Question	Why it matters
Unique among open orders, or among all orders ever?	Decides whether an ID can be reused once an order finishes
Over what time window?	A window-bounded scope frees the ID after a period
Per account, per sub-account, or per symbol?	Decides whether two strategies can collide
What format is allowed?	Length and character limits differ, and a rejected format is a rejected order

If the documentation does not answer a question, you do not have the property — treat it as unknown rather than as the answer you would prefer.

Client order ID vs exchange order ID

	Client order ID	Exchange order ID
Who assigns it	You	The venue
When you know it	Before sending	After a response arrives
Uniqueness	Over a venue-defined scope	Unique to that order
What it is for	Finding your order when you have nothing else; tagging	Referring to an order the venue has confirmed

Store both once you have both. The exchange ID is the unambiguous reference; the client ID is the one that survives a lost response.

Client order ID vs idempotency key

An idempotency key is a promise from the server: send the same request with the same key again and you get the original result back, with no second effect. A client order ID, as Binance documents it, promises something narrower — a duplicate is refused only while the original is still open. If the original filled instantly and the response was lost, a retry with the same ID is accepted and becomes a second order.

The full failure story, and what to do instead, is in retrying a failed order is not safe. The short version for this page: send a client order ID so you can find out what happened, not so you can skip finding out. Whether any other venue’s scope is wider is something to verify per venue.

Designing the IDs

Unique per attempt, not just per intent. If you retry after reconciling, give the new attempt a new ID that references the intent — for example an intent identifier plus an attempt number. You can then tell attempts apart in order history instead of seeing two orders under one name.
Write it down before you send. Record the ID, symbol and timestamp before the request goes out. If the process dies between sending and receiving, your own log still has the name to search for.
Keep it inside the venue’s format rules. Look up the length and character constraints once and validate locally.
Treat it as non-secret. The venue stores it and returns it in responses and order records. Do not encode anything in it you would not put in a log.

Using it to find an order

After an ambiguous outcome, the client order ID is the most direct question you can ask: does an order with this name exist, and what state is it in? Ask it first. Then check fills and the position anyway, because an order lookup does not show you a duplicate placed under a different ID, and an order that partially filled and was cancelled still changed your position. Position reconciliation covers the full check.

If a model is drafting orders, the ID should be generated by your code, not the model. A model-invented ID is unpredictable, may collide, and may not survive the venue’s format rules; a code-generated one is the key that ties an approved plan to the order that was actually sent.

FAQ

What is a client order ID used for?

It lets you name an order yourself, so you can find, match or cancel it using your own reference. Its most important use is after a lost response: without the exchange’s order ID, the client order ID is the only handle you have for asking whether the order exists and what state it is in.

Is a client order ID unique?

Only within a scope the venue defines. Binance spot documents newClientOrderId as unique among open orders, so the same ID can be accepted again once the earlier order has filled. Other venues may use different scopes; check each venue’s documentation for exactly what uniqueness covers.

Does a client order ID prevent duplicate orders on retry?

Not reliably. On Binance spot a retry with the same ID is refused while the original is still open but accepted once it has filled — the case where a duplicate costs you most. Reconcile open orders, fills and position before retrying, and use the ID to make that reconciliation easier.

Can I query an order by its client order ID?

Where the venue supports it, yes, and it is the fastest way to check an order whose response you lost. Hyperliquid documents order-status queries by either its own order ID or the client ID (cloid). Check your venue’s order-query endpoint for the parameter it expects.