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.
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
predictionMarketsBettool call that arrives inpendingToolswith the signature requests for the order. Your executor signs and reports back withsendToolResults— 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
authDatawithout involving the agent, then callssdk.polymarket.postOrder(...)(or routes by action) directly.
PolymarketService is the submission surface; the agent path just derives a built,
ready-to-sign order from natural language first.