Limitless Exchange API (2026): Endpoints, Keys, Limits
The Short Answer
The Limitless Exchange REST API lives at https://api.limitless.exchange and the websocket at wss://ws.limitless.exchange. Reading is open: markets, search, order books, price history and public portfolio lookups need no credentials. Anything touching an account needs a scoped API token plus an HMAC-SHA256 signature in three headers, lmts-api-key, lmts-timestamp and lmts-signature, with the timestamp inside a 30 second window. Orders carry a second signature, EIP-712, over the market's venue exchange address. No numeric rate limit is published.
Most prediction market APIs are one thing: a web service you call with a key. Limitless is two things stacked, because it settles onchain on Base. The read layer behaves like any REST API. The write layer is a signing pipeline, where your token proves who is calling and a separate wallet signature proves the order is valid. Here is the map.
Key Takeaways
- The entire read surface is public. Markets, search, order books, price history and any address's positions come back with no key.
- Authentication is a scoped token plus an HMAC signature over timestamp, method, path and body. The secret is shown once and cannot be recovered.
- Placing an order needs two credentials: HMAC headers to authenticate the request, and an EIP-712 signature to authorize the trade against the venue contract.
- No requests-per-second figure is published. Plan for 429s, respect
Retry-After, back off from one second, and queue rather than fan out.
Base URLs and the Endpoint Map
Two hosts cover everything: the REST base at https://api.limitless.exchange and a Socket.IO server at wss://ws.limitless.exchange. The reference groups endpoints into eight families, from markets and trading through portfolio and partner accounts. An OpenAPI spec sits at docs.limitless.exchange/openapi.json, so you can generate a client.
| Endpoint | Auth | Notes |
|---|---|---|
GET /markets/active | None | Paged browse, limit must not exceed 25 |
GET /markets/search | None | query required, limit defaults to 10 |
GET /markets/:slug | None | Market detail plus venue addresses |
GET /markets/:slug/orderbook | None | Live book only, Yes side, no history |
GET /markets/:slug/historical-price | None | Intervals 1h, 6h, 1d, 1w, 1m, all |
GET /portfolio/:account/positions | None | Any wallet address, public |
GET /maintenance/status | None | Trading mode before you submit |
POST /orders | HMAC, trading scope | GTC, FAK and FOK order types |
POST /auth/api-tokens/derive | Privy identity bearer | Secret returned once only |
GET /auth/api-tokens | HMAC | List active tokens |
DELETE /auth/api-tokens/:tokenId | HMAC | Revoke a token |
The Public Half: What Works With No Key
The read side is genuinely open: in the OpenAPI spec the market endpoints carry an empty security array, so no credential is expected. You can page active markets, filter by tradeType for amm, clob or group, run a fuzzy search with a similarity threshold, pull a market's detail record, read its live order book and fetch price history. Public portfolio goes further than most venues: hand GET /portfolio/:account/positions any Ethereum address and you get that trader's positions, rewards and points back.
Two limits shape the design. Market browsing caps limit at 25 per page, so a full index means paging. And the order book endpoint returns the live Yes side only: there is no historical book, and the No side is derived by inverting prices and flipping bids against asks.
Authentication: Scoped Tokens and HMAC Signing
Limitless does not hand out a static bearer key. You derive a scoped token, a token ID plus a secret, either from the app's profile menu under Api keys or headlessly by posting to /auth/api-tokens/derive with a Privy identity token in the identity header. The secret is returned exactly once and cannot be retrieved again, so it goes straight into your secret store.
Every authenticated request is then signed. The canonical message is four lines: ISO-8601 timestamp, HTTP method, request path including query string, and request body, left empty for GET. Sign it with HMAC-SHA256 using the base64-decoded secret, then send lmts-api-key, lmts-timestamp and lmts-signature. The timestamp has to sit within 30 seconds of server time, so a drifting clock will fail authentication in confusing ways.
Tokens are scoped rather than all-powerful. trading covers placing and canceling orders, account_creation covers sub-account profiles, delegated_signing lets the server sign for sub-accounts and requires trading alongside it, and withdrawal moves ERC20 balances out of server wallets. Those four are self-service.
Placing an Order Takes Two Signatures
This trips up developers coming from centralized venues. Your HMAC headers authenticate the HTTP request, but they do not authorize the trade. The order object inside the body has to be signed with EIP-712 using the market's venue exchange address as the verifyingContract, which means fetching GET /markets/:slug first to read the venue. Venue data is static per market, so fetch once and cache it.
The same lookup tells you how to set approvals. Buys approve USDC to the exchange. Sells on a simple CLOB market approve tokens to the exchange only, while sells on NegRisk or grouped markets need approval to both the exchange and the adapter. Posting to /orders takes the signed order, an ownerId, an orderType and the marketSlug. Optional extras include postOnly for GTC orders, a clientOrderId up to 128 characters for idempotency, a recvWindow between 1 and 10,000 milliseconds, and a self-trade prevention policy. A 400 covers bad order data or insufficient balance, a 201 means it landed.
The WebSocket Is Socket.IO, Not Raw WS
The realtime feed is a Socket.IO server, websocket transport only, on the /markets namespace at wss://ws.limitless.exchange. That matters: a bare websocket client will not speak the protocol. Heartbeats are server-driven, so no client ping is needed.
Three subscriptions are public and need no credentials: subscribe_market_prices for AMM prices and CLOB order book updates, subscribe_market_lifecycle for creation and resolution events, and subscribe_unrealized_pnl for leaderboard invalidation hints. Two more require the same HMAC headers passed as connection extraHeaders: subscribe_positions and subscribe_order_events.
Three behaviors will bite you. Subscriptions replace each other rather than stacking, so a client wanting both AMM prices and CLOB books must send market addresses and slugs together in one call. They do not survive a disconnect, so resubscribe on reconnect. And order events arrive from two sources, the off-chain matching engine and settlement, with no guaranteed ordering, so a provisional MATCHED can land before or after its terminal MINED or FAILED. Correlate on tradeEventId plus orderId, not arrival order. A 60 second deduplication window means retries will not double-deliver.
Rate Limits and Maintenance Mode
Limitless publishes no numeric rate limit. No per-second figure, no per-minute quota, no burst allowance. What the docs give you instead is behavior: exceeding a limit returns HTTP 429, respect a Retry-After header when one is present, otherwise back off exponentially starting at one second, queue high-frequency requests rather than firing them concurrently, and never retry a 400 or a 401. Teams needing more are told to contact help@limitless.network. The official SDKs ship a retry wrapper and a throttling order queue.
Budget for one more failure mode. Limitless runs a maintenance system with four trading modes: normal, post_only, cancel_only and disabled. When a mode blocks your action the API returns 425 with a code field naming the mode. Check GET /maintenance/status at startup and refresh it before trading actions, and do not retry a blocked action in a tight loop.
Partner Accounts and Delegated Signing
Beyond a single trader's bot there is a programmatic tier. Partners create sub-accounts in two shapes. A server wallet sub-account gets a managed Privy wallet, and the partner submits unsigned orders that the server signs, which needs account_creation plus delegated_signing. An EOA sub-account leaves the private key with the end user, who signs their own EIP-712 orders, and needs only trading and account_creation. Partners read sub-account data with an x-on-behalf-of header on supported endpoints. HMAC secrets belong in a backend, never in browser code.
Watching Limitless Alongside Every Other Venue
An API is only as useful as the comparison it enables. A Limitless quote means one thing alone and something different beside the same question elsewhere. That is what Predictefy does: it covers 15+ prediction market venues and matches the same event across all of them, so one lookup tells you whether the Limitless quote is the cheap side or the expensive one. Predictefy's arbitrage API is free to use, so adding that comparison to your Limitless bot costs nothing.
Frequently Asked Questions
Is the Limitless Exchange API free to use?
Yes. Limitless publishes no fee for API access, and reading market data needs no key at all. You pay trading fees when orders fill, nothing for the requests themselves. Predictefy's arbitrage API is also free to use, so you can compare Limitless prices against 15+ venues without adding a second bill.
Do I need an API key to read Limitless market data?
No. Market browsing, search, order books, historical prices and public portfolio lookups all run without credentials. Keys are only required once a request touches your own account: placing orders, reading positions, or managing tokens. That public tier is what lets aggregators like Predictefy pull Limitless prices alongside 15+ other venues.
How do I authenticate with the Limitless API?
Derive a scoped token from the profile menu in the app or through POST /auth/api-tokens/derive, then sign every request with HMAC-SHA256. Send three headers: lmts-api-key, lmts-timestamp and lmts-signature. The timestamp must sit within 30 seconds of server time. The secret is shown once and cannot be retrieved again.
Does Limitless publish API rate limits?
No. The documentation describes how to handle HTTP 429, respect a Retry-After header and back off exponentially from one second, but it publishes no requests-per-second number. Heavy users are told to email help@limitless.network for elevated limits. Queue high-frequency calls rather than firing them concurrently.
Can I trade Limitless markets alongside Polymarket and Kalshi?
Yes. Limitless runs its own REST and websocket stack, so a cross-venue bot needs one adapter per exchange. Predictefy covers 15+ venues and matches the same event across all of them, which handles the hard part, deciding that two differently worded markets are the same question. Its arbitrage API is free.
Conclusion
The Limitless API is generous on the read side and strict on the write side. Everything a researcher or an aggregator needs is public. Everything that moves money needs a scoped token, a fresh HMAC signature inside a 30 second window, and a wallet signature bound to the right venue contract. Build the read integration first and treat the websocket as the primary feed rather than polling. Official SDKs in TypeScript, Python, Go and Rust handle the signing.
One housekeeping note: this is information, not financial, tax or legal advice. API surfaces, scopes and limits change without warning, and the docs at docs.limitless.exchange are the binding source. Verify there before you ship anything that trades real money.