Skip to main content
This walks the full path: find an event, pick an outcome, submit an order, and read it back. Resource methods return the typed payload directly and throw a RequestError on any non-2xx response.
submitOrder attaches a fresh idempotency key to every call, which protects you from the API replaying one request twice. It does not make your retry safe: a second call without a key of your own carries a new one, and the API treats it as a new order. To make a retry safe, generate the key yourself, keep it for as long as you might retry, and send the same one every time:
Re-sending a key with the same body returns the original order and creates no duplicate. Re-sending it with a different body is rejected. If a submit fails in a way that leaves the outcome unknown, you get ORDER_RECONCILIATION_REQUIRED: read the order back rather than submitting again.

Venue namespaces

Orders, positions and balances are venue-scoped, because the venues address markets differently: Kalshi by ticker with a YES/NO side and integer priceCents, Polymarket by tokenId with BUY/SELL and decimal prices.
Each namespace carries the same seven methods: submitOrder, listOrders, getOrder, cancelOrder, getOrderFills, listPositions and getBalance.

Identity and clock

client.whoami() returns the actor and pod your key acts for, plus its scope and capabilities, which is useful for confirming a key is wired to the pod you expect. client.getTime() returns the server clock; see Authentication on why that matters.