Skip to main content
PolymarketService is a direct HTTP client for the Polymarket CLOB endpoints exposed by the ILLA gateway. Reach it through the sdk.polymarket getter when you want to place, cancel, read, redeem, or withdraw imperatively — without going through the agent and the chat/tool loop. The instance is created lazily on first access and reused for the lifetime of the SDK instance.
You can pass a polymarket block to the IllaSDK constructor config to override the base URL, timeout, headers, or route paths for this service.

Authentication model

At the ILLA edge these routes pass the same gateway authentication as every other endpoint — an OAuth session bearer or an x-api-key (the SDK supplies the apiKey you configured). Inside the API there is no additional user-session binding for these routes; Polymarket-level authentication happens at the protocol level via a signed authData object passed in the request body — obtain it (and the order signature) beforehand by signing with POST /api/v1/signatures/sign.
authData is { signature, timestamp, nonce, address } (all strings); getOrders in particular requires auth data signed immediately before the call.

Methods

options is { signal?: AbortSignal }. postRedeem and postWithdraw submit signed Safe or deposit-wallet operations to the Polymarket relayer; both resolve to a PolymarketSafeExecuteSuccessResponse.

PolymarketResult envelope

Every method resolves to a discriminated result rather than throwing on request failure:
PolymarketErrorResponse is a union of a validation error ({ name: 'PolymarketInvalidParams', statusCode: 400, details.validationErrors[] }) and an action error ({ success: false, error: string }).

Routing by action

routePolymarketAction dispatches a single tagged request to the matching PolymarketService method. sdk.postPolymarketAction(request, options) is the built-in facade shortcut that routes against sdk.polymarket.
PolymarketActionRequest is a discriminated union on action: The polymarketAuth action is intentionally excluded — it is handled client-side and has no server endpoint.

PolymarketService vs the tool-execution path

Every Polymarket order reaches the CLOB the same way — a POST to the Polymarket routes this service wraps. What differs between the two paths is who builds the order, not how it is submitted:
  • Agent-assisted build. You send a natural-language message; the model emits a predictionMarketsBet tool call that arrives in pendingTools with the signature requests for the order. Your executor signs and reports back with sendToolResults — but the LLM is not in the loop for submission: your app still posts the signed order to /api/v1/polymarket/post-order (i.e. sdk.polymarket.postOrder(...)) itself. See Handling Tool Execution.
  • Fully imperative. Your app builds and signs the order and authData without involving the agent, then calls sdk.polymarket.postOrder(...) (or routes by action) directly.
Either way PolymarketService is the submission surface; the agent path just derives a built, ready-to-sign order from natural language first.