Skip to main content
After submitting an order, use authenticated account reads to check its current state, reconcile open orders and resulting trades, and cancel liquidity you no longer want resting on the book.
Clients authenticated with Session Keys can only fetch orders and trades associated with those Session Keys. Deposit Wallet Owners cannot fetch orders from authorized Session Keys.

​
Fetch an Order

Look up a single order by its ID. Use this to check the current status of an order you already know about, rather than scanning the full list of open orders.
Call fetchOrder() on a SecureClient to fetch an order by ID:
The method returns an OpenOrder with normalized asset, decimal, and date values:
The unified SDK uses assetId for an outcome’s trading identifier: a token ID for a CTF market or a position ID for a Polymarket Protocol V2 market. Use the identifier exposed for that outcome.expiresAt is present when the response includes an expiration. Otherwise, the field is omitted.
See the order response reference for quantity units and statuses.

​
List Open Orders

Retrieve every resting order on the account, optionally narrowed to one outcome or market. Filtering by a specific order ID can also return a canceled or fully matched order.
Call listOpenOrders() on a SecureClient to iterate over the account’s open orders:
Pass a filter to narrow the results. Despite its name, market takes the market’s condition ID:
Each page contains OpenOrder items:
See the order response reference for quantity units and statuses.

​
List Account Trades

Retrieve executed fills for the account, as opposed to orders that are still resting on the book. Use this to reconstruct fill history, compute realized position size, or audit what actually matched.
Call listAccountTrades() on a SecureClient to iterate over the account’s trades:
Pass a filter to narrow the results. Despite its name, market takes the market’s condition ID:
Each page contains ClobTrade items:
See Trade Statuses to follow each trade’s status through settlement.

​
List Builder Trades

Retrieve matched trades attributed to a builder code across the accounts your application serves. Use this instead of an account trade read when you need to reconcile fills or measure activity for the builder integration as a whole. Orders do not appear here until they match.
Call listBuilderTrades() on a PublicClient or SecureClient to iterate over trades attributed to your builder code:
Pass a filter to narrow the results:
Each page contains BuilderTrade items:
See Builder Programs to learn how attribution works.

​
Cancel Orders

Cancel only as broadly as needed. Start with known order IDs, use a market or asset filter when withdrawing a set of quotes, and reserve account-wide cancellation for exceptional situations. Cancellation remains available while the exchange is in cancel-only mode, when new orders are rejected. For a partially filled order, cancellation removes only its unfilled remainder, including when the market resolves. It preserves the original and matched sizes and does not undo settled fills.

​
Cancel Orders by ID

Cancel one order when you know its ID. To cancel a known set of orders in one request, submit a batch of up to 3,000 IDs. Duplicate IDs in the batch are ignored.
Call cancelOrder() on a SecureClient to cancel one order:
Call cancelOrders() to cancel several known orders in one request:

​
Cancel Market Orders

Cancel by outcome to withdraw orders for one outcome, or by market to withdraw orders for every outcome in the condition. At least one filter is required.
Call cancelMarketOrders() on a SecureClient with an asset ID or condition ID:
The market field takes the market’s condition ID.

​
Cancel All Orders

Use account-wide cancellation when you need to remove every resting order, such as during an emergency shutdown.
This action cancels every open order associated with the authenticated CLOB API credentials.
Call cancelAll() on a SecureClient:

​
Cancellation Results

A cancellation can succeed for only some of the requested orders. Reconcile the result before retrying: it identifies the orders that were canceled and gives a reason for each order that could not be canceled.
The TypeScript SDK returns a CancelOrdersResponse:
Type
In this example, one order was canceled and another could not be canceled because it had already matched:
Example

​
Order Heartbeats

Use order heartbeats to request cancellation of your API key’s open orders if its trading process stops responding. Each SDK call sends one request. Your application owns the ongoing heartbeat loop and failure handling.
The first accepted heartbeat enables timeout cancellation for all open orders owned by the same API key, across markets and processes. Start only when you can keep sending accepted heartbeats every 5 seconds. There is no disarm endpoint: stopping the loop or closing the SDK client leaves the deadline active. A single test call with production credentials can put existing orders at risk of cancellation.
After 10 seconds without an accepted heartbeat, the server detects expiry on its five-second scan and queues a cancel-all attempt. Cancellation is best effort: queue delays, service failures, or orders that cannot be canceled can prevent or delay completion. Ten seconds is the expiry threshold, not a guaranteed cancellation time. WebSocket keepalive does not refresh this deadline.
Call sendOrderHeartbeat() on a SecureClient with the same API key that owns your orders. The first call uses an empty ID by default.
Await every send before the next one and retain the latest returned heartbeatId. A mismatch error contains the expected ID. The explicit retry above uses it to recover. A rejected send does not refresh the deadline. The SDK provides a single request per call. The loop owns scheduling and recovery.

​
Heartbeat FAQ

Use one coordinated sender per API key and wait for each send to finish before sending the next. Concurrent sends can race over the rotating heartbeat ID. Every accepted heartbeat covers all open orders owned by that key, across markets and processes.
A rejected request does not refresh the deadline. Retry with the expected ID from the mismatch response, then save the ID returned by the successful retry. The expected ID can be empty if another integration sent a legacy heartbeat request.The SDK examples above retry the first mismatch once. A second mismatch raises an error for your application to handle.
Stop placing new orders and check your outstanding orders. The examples above propagate authentication, payload, rate-limit, transport, and response errors to your application.A request can succeed even if its response is lost. An SDK exception does not tell you whether the heartbeat registration is active or whether the server has rotated the ID.
Stop placing orders, cancel the orders you want to remove, and verify the cancellations before stopping the heartbeat loop.Stopping the loop or closing the client leaves the server’s deadline active. There is no disarm operation that lets you immediately disable the timeout while keeping existing orders live.
The server removes the heartbeat registration, then attempts to cancel the orders. Cancellation is best effort. Check the cancellation results and outstanding orders rather than assuming every order is gone. The server does not keep canceling later orders indefinitely.A later accepted heartbeat registers the API key again. Before resuming quoting, reconcile open orders. A successful heartbeat does not tell you whether orders placed before the outage survived or were canceled.

​
Check Closed-Only Mode

Closed-only mode is an account-level circuit breaker for a market. When it’s on, the account can only place orders that reduce an existing position, not new opening orders. Check this before placing an order if you want to fail fast instead of waiting for a rejection.
Call fetchClosedOnlyMode() on a SecureClient:
The method returns the account’s closed-only state as a boolean:

​
Check Order Scoring

An order scores when it is live on a market with liquidity rewards and meets the market’s minimum qualifying size, maximum qualifying spread, and required live duration. Because eligibility changes as the order book moves, treat the result as a point-in-time check.
Call fetchOrderScoring() on a SecureClient with the order ID:
To check the scoring status of several orders in one request, call fetchOrdersScoring() with their IDs:
The response maps each order ID to its scoring status: