Skip to main content

​
New endpoints

​
Batch place orders — POST /v1/pm/orders/batch

Submit up to 50 CLOB orders in a single round-trip. Orders may span multiple markets and events — each item carries only outcomeId, and the server resolves market and event from the outcome. Per-order best-effort: a bad item does not abort the rest of the batch.
See Batch place orders for the full schema.

​
Batch cancel orders — DELETE /v1/pm/orders/batch

Cancel up to 100 CLOB orders in a single round-trip. Order IDs may belong to different markets and events. IDs the caller does not own return ORDER_NOT_FOUND.
See Batch cancel orders for the full schema.

​
New features

​
Self-trade prevention — stpMode on CLOB orders

CLOB order placement now accepts an optional stpMode field that controls how the matching engine resolves a match against another resting order from the same user. Previously, both same-user orders sat on the book until one was manually cancelled — a sharp edge for market makers replacing quotes.
Valid values:
  • SKIP (default) — the match is silently skipped and both orders remain on the book. Backward-compatible behavior.
  • CANCEL_OLDEST — the resting same-user maker is cancelled and refunded; the taker continues matching against other counterparties.
  • CANCEL_NEWEST — the incoming taker stops at the same-user match. If it had already filled against other users, those fills stand and the taker comes back as cancelled; otherwise it is rejected.
  • CANCEL_BOTH — the resting maker is cancelled and the taker is cancelled or rejected under the same rule as CANCEL_NEWEST.
Unknown values fall back to SKIP. The applied stpMode is echoed back on OrderDto / OrderResponse, so the client can confirm what the server applied without round-tripping through the request body. AMM orders ignore stpMode.

​
Behavior to know

  • CLOB-only. Both batch endpoints and stpMode apply only to CLOB markets. AMM orders in a batch are rejected per-item with UNSUPPORTED_ENGINE; AMM orders ignore stpMode entirely.
  • Per-order best-effort. Batch HTTP responses are 200 OK whenever the batch was processed. Inspect the per-item success flag and the summary to see what landed.
  • Weighted rate limiting. Batches are charged per item against your write rate-limit bucket — a 50-order batch costs 50 tokens, not 1. Over-budget batches are rejected with 429 before any orders reach the matching engine.
  • Idempotent retries. Both batch endpoints accept an optional Idempotency-Key header. Retries within 24 hours that share the same key, body, and route replay the original response with Idempotent-Replayed: true. Reusing a key with a different body returns 422; a concurrent retry (sent before the first is finished) returns 409. Transient responses (5xx, 429, 408) are not cached so you can recover by retrying.

​
Documentation