Trading API v1

An external platform can integrate through the documented HTTP, EIP-712, HMAC, and WebSocket contracts without a Reso web session.

Use this order for a wallet-native integration. Every write is idempotent or one-time; preserve exact request bytes and identifiers until the final state is known.

Before you start

• An EVM funding-wallet signer controlled by the caller; Reso never receives the private key and provisions a separate managed owner.
• A secret store for the one-time Reso Credential and any Provider Credential.
• An ADI integrator API key for Sports, or access to the official Gamma/CLOB and deposit-wallet relayer clients for Crypto. Direct relayer users also need their own Polymarket Builder Credential.
• A supported source asset returned by GET /api/funding/assets; never hard-code the asset catalog or minimum amount.

1. Create or read the Trading Account with CREATE_OR_READ_ACCOUNT and the external funding wallet; Reso provisions a separate managed owner.
2. Create a Reso Credential with CREATE_CREDENTIAL; store the secret and passphrase returned once.
3. Discover the product market from the product-specific public API.
4. Read funding assets and create a deposit intent with Reso L2. For Crypto, wait until GET /api/trading/account returns polymarketFunderWallet before transferring funds.
5. For Crypto, register the managed owner's Polymarket CLOB Credential through a challenge signed by the funding wallet, then prepare polymarketFunderWallet.
6. Transfer the selected source asset to the intent depositAddress, then poll statusAddress.
7. Build and managed-owner-sign the product-native order, then submit it with Reso L2 and an Idempotency-Key.
8. Read the order and private portfolio; public wallet positions and activity need no authentication. Redeem remains a separate Provider wallet action when returned by the API.
9. Create withdrawals through a WITHDRAW challenge signed by the bound funding wallet. Reso fixes the destination and executes Provider actions; poll until DONE.

Where product signing data comes from

This page and the OpenAPI fully define the Reso account, authentication, funding, submission, and query contracts. ADI and Polymarket payload signing remains a caller-side Provider prerequisite; Reso validates and forwards it but never fabricates an owner signature.

• BTC 3m: GET /api/trading/markets/{marketId}/config returns the complete Reso signing domain and market rules.
• ADI Sports: use the public Reso market id, then use your own ADI integrator API key to obtain vault, token, exchange domain, fee, and order parameters from the ADI official API. Reso intentionally does not expose Provider metadata in public market DTOs.
• Polymarket Crypto: use id/slug/eventId/eventSlug/conditionId from /api/crypto/markets, then use the official Gamma/CLOB APIs or client to resolve token ids, derive the CLOB Credential, and create the exact owner-signed FAK rawBody.

• Polymarket quickstart
• ADI integration quickstart
• ADI EIP-712 signing
• ADI withdrawal
• Polymarket authentication
• Polymarket deposit wallets
• Polymarket market discovery
• Polymarket order signing
• Polymarket order lifecycle
• Polymarket rate limits
• Polymarket bridge assets
• Polymarket bridge withdrawal
• Polymarket error codes

Production: https://reso.market

HTTP base path: /api/trading. WebSocket: wss://<host>/api/trading/ws. Production settlement and Settlement Root use ADI Mainnet chain ID 36900; the Trading EIP-712 signing domain also uses chain ID 36900.

Reso has no dedicated SDK. Node.js clients use viem for owner EIP-712 signatures; add the official Polymarket CLOB and relayer clients only for Crypto.

Where JavaScript Demo environment values come from

# Reso wallet signing and HTTP clientnpm install viem# Crypto only: official Polymarket order and deposit-wallet clientsnpm install @polymarket/clob-client-v2 @polymarket/builder-relayer-client

curl --fail --silent https://reso.market/api/trading/time# {"serverTimeMs": 1783958400123, "maxRequestSkewMs": 30000}