Skip to main content
Notable changes to the Polymarket Perps API.
​
Deposit and withdrawal history amounts are always decimal token units
GET /v1/account/deposits and GET /v1/account/withdrawals now serialize every amount (and withdrawal fee) in decimal token units, e.g. "10" for 10 pUSD. Previously, deposit rows in pending or removed status reported raw on-chain base units ("10000000" for the same 10 pUSD), and pending withdrawal rows could serve base-unit amounts and fees as well, so rows for the same transfer disagreed on units across statuses. Clients that divided pending amounts by 10^decimals to compensate must drop that conversion. Confirmed rows and the WebSocket deposits and withdrawals channels are unchanged — they were already decimal. Signed operation inputs (POST /v1/account/withdraw) still take base-unit amounts matching the EIP-712 signature.
​
Fill history flags maker fills executed under liquidation
GET /v1/account/fills and account trade history previously reported liquidation: false on every maker fill, even when the maker’s own account was under liquidation on the instrument — while the WebSocket fills channel already reported liq: true for the same fill. The two surfaces now agree: any maker or taker fill on an instrument in the account’s active liquidation scope reports liquidation: true. Rows written before the change are unaffected. Such maker legs are also excluded from leaderboard win counts.
​
Fills gain an adl flag; liq no longer set on ADL counterparty legs
Fill entries now carry a required boolean adl field on both the WebSocket fills channel and GET /v1/account/fills, set on both legs of an auto-deleveraging match. Behavior change: the counterparty leg of an ADL match previously reported liq: true on the WebSocket fills channel; it now reports liq: false. liq marks only the leg whose own position is being liquidated. Clients that detect forced closes via liq alone will no longer see ADL counterparty fills — check adl as well.
​
Position deleveraged notification added
Added the position_deleveraged notification, sent to the counterparty of an auto-deleveraging match when its profitable position is closed or reduced to settle a liquidation on the other side. Delivered on the WebSocket notifications channel and in the notifications history.
​
Exchange info reports engine version and cancel-only state
GET /v1/info/exchange now includes engine_version, the engine release version of the build serving the response. The response also documents cancel_only, which reports whether the exchange is in cancel-only (maintenance) mode; the flag has been returned since maintenance mode shipped on Jul 15.
​
Portfolio margin summary includes available order margin
The portfolio response and portfolio WebSocket channel now include margin.available_order_margin: the collateral available for additional order initial margin after existing exposure, open orders, orders and isolated-margin additions awaiting risk processing, and pending withdrawals or transfers.
​
Cancel all orders added
Added DELETE /v1/trade/orders/all to cancel all open orders in one request, optionally scoped to a single instrument. Available in the SDKs as cancelAllOrders (TypeScript) and cancel_all_orders (Python).
​
Cancel responses include order IDs
Cancel responses now include oid and coid fields.
​
Taker delay added for immediately matching orders
Added a 20ms taker delay for orders that immediately match on entry.
​
Reduce-only orders added
Added the reduce-only field to order submission and order updates.
​
Auto-cancel and rate-limit updates
  • Added PATCH /v1/trade/auto-cancel to arm or clear a dead man’s switch that cancels all open orders at a specified time.
  • Added GET /v1/account/auto-cancel to check the current auto-cancel status, trigger count, and daily reset time.
  • Auto-cancel is limited to 1000 triggers per UTC day per account.
  • Added updateLeverage and autoCancel WebSocket post messages.
  • portfolio and balances WebSocket channels no longer push updates on every order or fill, only periodically.
  • Rate limit error messages now distinguish between ip_rate_limited, action_rate_limited, and message_rate_limited.