Skip to main content
Welcome to the Limitless Changelog. Here you’ll find important changes to the Limitless Exchange platform including API updates, SDK releases, and new features.

Jul 1, 2026

Predictable, Second-Precision Slugs for Scheduled & Recurring Markets

Going live Wednesday, July 1. Recurring and upfront-scheduled CLOB market slugs become predictable, so market makers can precompute a slug before its market exists. This aligns the slug timestamp with Polymarket’s convention and was driven by multiple MM requests.
  • Format change: on recurring and scheduled markets, the slug timestamp suffix moves from a 13-digit millisecond value (set at creation time, carrying no real information) to a 10-digit Unix-second value taken from the slot’s scheduled open time.
    • Before: eth-up-or-down-5-min-1782716420095
    • After: eth-up-or-down-5-min-1782717300 (Polymarket parity: eth-updown-5m-1782717300)
  • Cadences: applies to every recurring up/down series — 5-min, 15-min, hourly, daily, and weekly — plus upfront-scheduled markets. The suffix is the slot start in Unix seconds, so it aligns to the slot boundary (e.g. a multiple of 300 for 5-min, 3600 for hourly, 86400 for daily).
  • Ladder markets: same second-precision suffix, taken from the market’s start point (openPriceAt).
  • UGM markets: still use a full millisecond timestamp (not precomputable), but now carry a dedicated -ugm- marker so they can be identified, e.g. btc-above-dollar6024331-on-jun-28-1218-utc-ugm-1782648136065.
  • Unchanged: manually-launched markets and AMM markets keep the millisecond suffix.
  • Action: if you parse or hardcode slug timestamps, switch to the seconds-based format. To fetch upcoming slot slugs without computing them, use the timeline endpoints.
Documentation: Market Timeline | Get Active Market Slugs

Jun 29, 2026

Market Status Values & orderbookUpdate Payload Documented

Two reference gaps closed for integrators reading market state and realtime orderbooks.
  • GET /markets/{slug}: the market status enum is now documented — FUNDED (live and tradeable), LOCKED (trading paused, existing positions retained; typically just before resolution or an operator halt), RESOLVED (outcome known, winners can redeem), FUNDED_FLAGGED (live but flagged for review, treat as tradeable), and DRAFT (not yet funded, not tradeable). Treat any unrecognized future value defensively rather than assuming the market is tradeable.
  • WebSocket orderbookUpdate: the payload is now spelled out with the concrete bids/asks schema and a field table, plus a precision/snapshot note pointing at GET /markets/{slug}/orderbook.
Documentation: Get Market | WebSocket Events

Jun 25, 2026

Maintenance Mode: Detecting Trading Pauses

Production integrations can now detect and handle platform maintenance windows. During maintenance, trading can become post-only, cancel-only, or fully disabled, and trading endpoints may return 503 Service Unavailable.
  • New GET /maintenance/status endpoint to check whether trading is currently restricted or a future maintenance notice is scheduled
  • New Maintenance Mode developer guide covering when to check status, the trading modes, and 503 handling (do not retry a blocked action in a tight loop — refresh status and wait until the mode allows it)
Documentation: Maintenance Mode | Maintenance Status

Public Portfolio: PnL Chart Endpoint

A public, read-only endpoint exposes an account’s realized PnL over a timeframe — no authentication required for the read.
  • GET /portfolio/{account}/pnl-chart returns a realized PnL series plus the current realized snapshot for the given account address, selected by a timeframe query (e.g. 1w)
  • Part of the public-portfolio read surface (alongside public positions and traded-volume); served read-only with caching, and the account address is normalized
Documentation: Get PnL Chart (Public)

/portfolio/orders: Cursor Pagination

The authenticated /portfolio/orders read now supports keyset (cursor) pagination.
  • Responses carry nextCursor (null on the last page) and an exact total
  • Pass the returned cursor back along with limit to page forward — the cursor is opaque and resumes exactly where the previous page ended, with no duplicates across pages even when many orders share the same timestamp
  • The legacy non-projection fallback is not paginated (returns the first limit orders with nextCursor: null) and is being retired

Market Creator: username and Trade Wallet

The creator object on market and group responses now includes the creator’s username (alongside display name, image, and social link), and the creator address resolves to the creator’s trade wallet (their smart wallet, or the signer EOA when the trade wallet is set to EOA). Documentation: Get Market

Jun 24, 2026

Packs: On-Chain Mechanics Documented

The Packs guide now explains how a pack works on-chain. Each pack is a single Conditional Token (CTF) held in the user’s own wallet, redeemable only if every leg resolves their way (otherwise it expires worthless). Buying a pack signs an EIP-712 intent covering the chosen pack, stake, and deadline, and winners claim permissionlessly on Base — there is no dependency on Limitless to release winnings. Risk is fixed to the stake. Documentation: Packs

Jun 22, 2026

Market Data Clarifications & Market Pages Discoverability

  • Confirmed there is no testnet or sandbox — all integrations run against Base mainnet with real USDC. Rehearse a flow with small live orders on a low-volume market.
  • Clarified that reported user volume is lifetime volume, and the fee difference between claiming a resolved win and selling a position before resolution.
  • The Market Pages endpoints (category- and property-based filtering) are now surfaced in the API Reference navigation, and GET /markets/active points to them for structured filtering.
Documentation: For Developers | Market Resolution

Jun 17, 2026

Orderbook: Deriving the NO Book

GET /markets/{slug}/orderbook returns a single, YES-side book. The reference now documents the complementary-pricing identity — price(YES) + price(NO) = 1 — so integrators can mirror the YES book into the NO book (flip bids and asks, replace each price p with 1 - p) instead of assuming NO liquidity is missing. Native NO orders are already merged into the returned YES book. Multi-outcome (NegRisk) markets are covered too: each outcome has its own book and is derived independently. Documentation: Get Orderbook

Jun 14, 2026

SDK WebSocket: Authenticated Subscriptions on HMAC

All four SDK WebSocket pages (TypeScript, Python, Go, Rust) now document authenticated subscriptions — positions, order events, and transactions — via hmacCredentials passed to the WebSocket client, which signs the handshake automatically. The Python page gained full authenticated-subscription examples to match the others. No X-API-Key is used on the WebSocket handshake. Documentation: TypeScript | Python | Go | Rust

Jun 12, 2026

Authentication Docs Standardized on HMAC

Active code examples across the developer docs now standardize on scoped API tokens with HMAC-SHA256 request signing (lmts-api-key, lmts-timestamp, lmts-signature). The legacy X-API-Key header has been removed from active examples. Existing API-key integrations continue to work, but new integrations should use HMAC scoped tokens. Documentation: Authentication

Jun 10, 2026

Documentation Accuracy Pass

A sweep fixed copy-paste-breaking inaccuracies across the API and SDK references: scoped-token field names, SDK retry-timing units, WebSocket symbol and event names, and signing-payload details. It also clarified that expiration and nonce must both be 0 for standard CTF orders. Documentation: EIP-712 Signing | Authentication

Jun 9, 2026

Self-Trade Prevention on POST /orders

POST /orders now accepts an optional top-level stpPolicy for clients that want explicit self-trade handling. Available across the TypeScript, Python, Rust, and Go SDKs.
  • Existing integrations keep the default cancel_maker behavior when stpPolicy is omitted.
  • Supported values: cancel_maker, cancel_taker, cancel_both.
  • stpPolicy sits outside the EIP-712 signed order payload (top-level request field).
  • cancel_taker / cancel_both reject the incoming order with execution.settlementStatus: "CANCELED" and execution.reason: "STP_TAKER_REJECTED" on the POST /orders response.
  • cancel_maker / cancel_both list the cancelled resting order ids in execution.stpMakerCancels; each cancelled maker emits a CANCELLATION order-event with reason: "STP_MAKER_CANCELLED".
  • Scope: blocks same-profile self-matches on the same token only; cross-token orders on the same profile are unaffected.
Documentation: Create Order — Self-Trade Prevention

Jun 8, 2026

Taker Delay: Async Submission for Marketable Orders

Markets can now apply a taker delay — a short, per-market hold on marketable (taker) orders before the matching engine fills them. When a market has it enabled, order submission becomes asynchronous. What changes for integrators on a delay-enabled market:
  • A marketable order’s POST /orders returns immediately with execution.settlementStatus: "DELAYED" and an eligibleAt timestamp — it no longer blocks until the trade is mined. Track the fill asynchronously over subscribe_order_events (provisional MATCHED → terminal MINED / FAILED), correlating by clientOrderId / tradeEventId.
  • postOnly orders are not affected — maker quotes rest immediately, as today.
  • Read a market’s current delay from settings.takerDelayMs (milliseconds; 0 = none) on the market response.
Documentation: WebSocket Events

Jun 7, 2026

Packs

A new product on Limitless. Packs are curated bundles of 2 to 3 predictions from different markets, presented as ready-made offers with a clear multiplier and a single buy-in window. A user wins only if every leg lands. What’s live:
  • USDC collateral on Base, stake range $1 to $10, multiplier capped at 15x before vig
  • 4% vig on crypto and sports packs, already baked into the displayed multiplier
  • Pack listing states: Active, Hidden (no new buys; existing positions continue to resolve), Closed (terminal)
  • User-held pack status: Active, Won, Lost; Won packs expose a Claim button until winnings are collected
  • External wallets sign a one-time USDC approval for $100 (covers up to 10 max-stake packs); each pack purchase needs a confirmation
  • Limitless Safe wallets do not need ETH for gas; external EOA wallets need a small Base ETH balance when claiming
Documentation: Packs

Jun 5, 2026

WebSocket Order Events: FAK/FOK Terminal (EXECUTION) Frame

Authenticated subscribe_order_events clients now receive a terminal EXECUTION frame the moment an immediate-or-cancel (FAK/FOK) order reaches its final state — no polling needed. What changed:
  • source: "OME" now carries a fourth type, EXECUTION, with a status of FILLED, PARTIALLY_FILLED, or KILLED
  • eventId uses the string form terminal:<orderId>
  • Delivered once, to the order owner; it carries no fee fields — read the MINED settlement frame or the POST /orders response for the realized fee
  • A FOK that cannot fill is rejected with HTTP 400 and emits no terminal frame, so a FOK only ever appears as FILLED
Documentation: WebSocket Events

Jun 3, 2026

WebSocket Order Events: Pre-Settlement MATCHED Frame

Authenticated subscribe_order_events clients now receive a provisional MATCHED settlement frame the moment the matching engine fills an order — before the on-chain settlement transaction. This is the earliest “your order will be matched for N” signal. It is emitted per participant (the taker and each maker), each carrying its own side, token, fill size, and a fee estimate (isEstimate: true). What changed:
  • source: "SETTLEMENT" now carries three types: provisional MATCHED, then terminal MINED or FAILED
  • MATCHED uses its own eventId namespace matched:<tradeEventId>:<orderId>, distinct from the terminal settlement:<tradeEventId>:<orderId>, so the two never dedup-collide
  • Correlate provisional → terminal by tradeEventId + orderId; settle accounting on MINED (realized fee + txHash), never on the MATCHED estimate
Documentation: WebSocket Events

Polymarket Migration Guide: Updated for CLOB V2

Polymarket cut over to CLOB V2 around May 2026, deprecating the V1 SDKs and endpoints the original migration guide was built on. The entire Migrate from Polymarket page has been reframed against V2. What changed in the guide:
  • Polymarket collateral updated from USDC.e to pUSD
  • New host data-api.polymarket.com documented for positions, trades, activity, and price history
  • Cancel semantics, /data/* order endpoints, public search, and slug paths corrected to V2 conventions
  • The Limitless side of every comparison table remains classic CTF (taker, expiration, nonce, feeRateBps)
  • Getting Started navigation reordered to surface the migration guide earlier
Documentation: Migrate from Polymarket

Jun 2, 2026

User-Generated Markets

Limitless now lets users propose and fund their own markets. A new user-guide page covers the flow end-to-end, and the Maker Rebates page has been updated alongside to reflect the current rebate eligibility surface. Documentation: User-Generated Markets | Maker Rebates

Authentication: UI Flow for Scoped API Tokens

The “Getting a Scoped API Token” section now documents the UI derivation flow (connect wallet, open the API token modal, derive) alongside the existing programmatic POST /auth/api-tokens/derive path. Most builders should use the UI; the programmatic path is for fully automated partner integrations that need to mint tokens on behalf of end users. Documentation: Authentication

Jun 1, 2026

Markets: winningOutcomeIndex Outcome Mapping

The winningOutcomeIndex field on resolved markets is now explicitly documented as 0 = YES, 1 = NO. Integrators previously had to verify this convention empirically. The mapping is added to the GET /markets/{slug} reference, the Programmatic API guide, and the OpenAPI description for winning_index. Documentation: Get Market | Programmatic API

May 29, 2026

Cross-Market Market Making Quickstart

A new dedicated quickstart for the agents-starter cross-market-mm strategy: quote on Limitless, hedge fills on Polymarket to stay delta-neutral. The page covers the one-key wallet model (EOA plus key-less ERC-1271 deposit wallet, pUSD held in it), a no-money dry-run flow that takes under 10 minutes, an honest 20 to 30 minute go-live path, the lifecycle commands, safety rails, and the economics. Economics callout: Limitless charges takers only, so the maker bot pays no Limitless fee. Revenue is the cross-venue spread plus maker rebates (100% of eligible taker fees on Daily/Hourly Crypto and 15-min Crypto, fill-gated) plus LP rewards for resting orders near midpoint. Cost is the Polymarket hedge taker fee. Documentation: Cross-Market Market Making | Build a Trading Agent

SDK Retirement: Java Quickstart Removed

The Java quickstart has been removed from the developer documentation. It was unmaintained and out of line with current API behavior. The four supported developer quickstarts are now TypeScript, Python, Go, and WebSocket.

Small Audit Fixes

  • GET /auth/api-tokens/capabilities: profiles with no capability row return tokenManagementEnabled: true and allowedScopes: ["trading"], not false and an empty array. The docs now match the backend handler.
  • TypeScript SDK markets reference: group.submarkets corrected to group.markets (the field is markets?: Market[]). The previous samples would throw at runtime.

May 28, 2026

Market Timeline Endpoints

Two new endpoints let integrators pre-fetch upcoming recurring-market slots (5-minute crypto, hourly, etc.) before they open:
  • GET /markets/{slug}/timeline for the schedule on a single recurring market
  • GET /markets/timeline for the global upcoming schedule
Documentation: Market Timeline

Cancel Authentication Clarifications

POST /orders/cancel is not EIP-712 signed. It requires the trading scope. Cancels on behalf of sub-accounts via onBehalfOf additionally require the delegated_signing scope. The reference page now spells this out so partner integrations can scope their tokens correctly the first time. Documentation: Cancel Order

May 27, 2026

SDK Update: Current Profile and Partner Account Listing

All four official SDKs now expose helpers for authenticated current-profile reads and partner-owned sub-account listing/recovery. Current profile:
  • GET /profiles/me returns the authenticated caller’s private profile without passing a wallet address
  • SDK helpers:
    • TypeScript: client.portfolio.getProfile()
    • Python: client.portfolio.get_current_profile()
    • Go: client.Portfolio.GetCurrentProfile(ctx)
    • Rust: client.portfolio.get_current_profile()
Partner account listing:
  • GET /profiles/partner-accounts lists child accounts owned by the authenticated partner or recovers one by account
  • Requires HMAC authentication with the account_creation scope
  • Do not send x-on-behalf-of; results are always scoped to the partner behind the HMAC token
  • SDK helpers:
    • TypeScript: client.partnerAccounts.listAccounts()
    • Python: client.partner_accounts.list_accounts()
    • Go: client.PartnerAccounts.ListAccounts(ctx, ...)
    • Rust: client.partner_accounts.list_accounts(...)
Documentation: Get Current Profile | List Partner Sub-Accounts | Programmatic API | TypeScript SDK | Python SDK | Go SDK | Rust SDK

May 25, 2026

Pyth Markets: Full-Precision Open Price and Descriptions

New Pyth-resolved markets now expose the full oracle precision in metadata.openPrice and the auto-generated market description text. Chainlink-resolved markets are not affected.
  • metadata.openPrice for new Pyth markets returns the full decimal value (e.g. 2132.21000000 instead of 2132.21). Pyth crypto feeds typically use 8 decimal places.
  • The strike price quoted inside the auto-generated market description text uses the same full-precision value.
  • Chainlink markets continue to return the 18-decimal padded string in both metadata.openPrice and the description.
  • No backfill — only Pyth markets created or activated after the cutover get the new shape. Existing markets remain as-is.
Action for partners: if you parse openPrice as a number, no change is needed. If you display it verbatim or regex-match against the rounded value inside descriptions, expect longer strings for new Pyth markets. Documentation: Market Resolution

Sports Markets: Updated Titles and Resolution Wording

Football match markets get cleaner titles and more explicit resolution language. Existing markets are not affected; the changes apply to newly created markets.
  • Group titles no longer include the match date. The scheduled date and time appears in the description body.
  • Solo market titles are reformatted (e.g. “Both Home and Away score on Feb 17?” → “Home and Away both to score?”). Affects BTTS, TOTAL_GOALS, CORNERS_MATCH, CARDS_MATCH, and SPREADS.
  • Descriptions are expanded to a 3-paragraph format with explicit branches for: match completed on the pitch, match abandoned after kickoff (solo markets resolve based on official data recorded up to that point), and match canceled before kickoff or postponed beyond the resolution window.
  • Team-outcome markets now explicitly recognize wins awarded by the competition authority when the match itself is not completed.
Action for partners: if you parse market titles for the match date, switch to the deadline field on the market object. If you regex-match descriptions for resolution wording, expect the new 3-paragraph format on newly created markets.

May 20, 2026

Receive Window on POST /orders

POST /orders now accepts optional top-level timestamp (Unix ms) and recvWindow (ms) fields for clients that want order freshness checks. Both fields sit outside the EIP-712 signed order payload.
  • Existing integrations are unchanged unless they send recvWindow.
  • recvWindow must be between 1 and 10000 ms.
  • A stale or future-dated timestamp returns HTTP 425 Too Early. Build and sign a fresh order before retrying.
Documentation: Create Order — Receive Window

May 7, 2026

SDK Update: Partner Withdrawal Allowlist & Expanded WebSocket Coverage

All four official SDKs (TypeScript, Python, Go, Rust) now expose helpers for the partner withdrawal-address allowlist and a typed WebSocket subscription surface for the public realtime channels. Partner withdrawal-address allowlist:
  • PartnerAccountService.addWithdrawalAddress()POST /portfolio/withdrawal-addresses
  • PartnerAccountService.deleteWithdrawalAddress()DELETE /portfolio/withdrawal-addresses/:address
  • Both use a Privy identity token (identity: Bearer <token>), not API-token/HMAC auth
  • HttpClient.deleteWithIdentity() exposed for identity-token authenticated DELETE requests
  • POST /portfolio/withdraw continues to use HMAC auth with the withdrawal scope; destination is optional for child server-wallet withdrawals and defaults to the partner smart wallet (or partner account)
  • Unit coverage added for identity-auth allowlist calls and explicit server-wallet withdrawal destinations
WebSocket subscription / event surface:
  • Typed subscriptions for order events, live sports/esports, market lifecycle, oracle price data, and system messages
  • Mirrors the subscribe_* channels documented on the WebSocket reference
Documentation: TypeScript Partner Accounts | Python Partner Accounts | Go Partner Accounts | Rust Partner Accounts | Add Withdrawal Address | Delete Withdrawal Address | WebSocket Events

May 5, 2026

Combined Cancel Endpoints (orderIds + clientOrderIds)

A new POST /orders/batch-cancel endpoint accepts either internal orderIds or clientOrderIds (the value supplied at order creation time) in a single call. Provide exactly one identifier array — requests with both, or with neither, return 400 Bad Request.
  • POST /orders/cancel-batch remains supported for existing integrations and continues to accept orderIds only
  • clientOrderId is also surfaced on the subscribe_order_events payload so partners can correlate WebSocket events to their own client-side IDs
Documentation: Batch Cancel Orders (Combined) | Cancel Orders (Batch) | WebSocket Events

May 4, 2026

Withdrawal Address Whitelisting

Explicit treasury destinations for server-wallet withdrawals must now be allowlisted on the authenticated partner profile. Withdrawals to the partner account or partner smart wallet do not require allowlisting.
  • POST /portfolio/withdrawal-addresses — add an allowlisted destination (Privy identity token)
  • DELETE /portfolio/withdrawal-addresses/:address — remove an allowlisted destination (Privy identity token)
  • POST /portfolio/withdrawdestination field now references allowlisted addresses for child server-wallet withdrawals; HMAC auth with the withdrawal scope unchanged
Documentation: Add Withdrawal Address | Delete Withdrawal Address | Withdraw

Apr 30, 2026

Partner Account Allowance Helpers

Server-wallet sub-accounts need delegated-trading approvals before they can trade. Two new endpoints (and matching helpers across all four SDKs) make the recovery flow explicit:
  • GET /profiles/partner-accounts/:profileId/allowances — inspect approval state per target
  • POST /profiles/partner-accounts/:profileId/allowances/retry — re-run any missing or failed retryable targets
  • Both require HMAC credentials with account_creation and delegated_signing
  • 409 Conflict indicates a retry is already running; 429 returns retryAfterSeconds
Recommended flow: poll checkAllowances → if not ready and any target is retryable, call retryAllowances → on submitted, poll again after a short delay. Documentation: Check Allowances | Retry Allowances | Programmatic API

Restricted Regions Update

Russia and Belarus added to the list of restricted jurisdictions in the Terms of Service. Documentation: Terms of Service

Apr 27, 2026

Rust SDK v1.0.7: Initial Stable Release

The official Rust SDK is now documented with full coverage for individual traders, bot builders, and partner integrations. Highlights:
  • Typed async client for CLOB and NegRisk markets
  • Root Client entrypoint for markets, portfolio, market pages, API tokens, partner accounts, delegated orders, server wallets, and WebSockets
  • Built-in EIP-712 order building and signing on Base
  • API key and HMAC authentication support
  • Async WebSocket streaming with reconnect handling
  • Pluggable logging, retry helpers, and builder-style HTTP configuration
Documentation: Rust SDK

Order Execution: FAK Orders Added to Signing and SDK Docs

Fill-and-kill (FAK) orders are now documented across the developer guides. FAK orders use the same price and size inputs as GTC limit orders, match immediately against available liquidity, and cancel any unmatched remainder instead of resting on the book. Updated docs:
  • EIP-712 signing now includes FAK in the order type reference and amount-calculation guidance
  • TypeScript SDK order docs include FAK examples and parameter reference
  • Programmatic API delegated orders now show GTC, FAK, and FOK flows
Documentation: EIP-712 Signing | TypeScript SDK Orders | Programmatic API

WebSocket Order Events

Authenticated WebSocket clients can now subscribe to the CLOB order lifecycle with subscribe_order_events. New realtime stream:
  • Emits orderEvent messages for both off-chain matching-engine updates and on-chain settlement results
  • OME events cover placement, updates, and cancellations
  • Settlement events cover mined and failed transaction outcomes
  • Auth failures are surfaced on the exception channel
  • Clients should resubscribe on reconnect and treat OME and settlement events as independent streams
Documentation: WebSocket Events

Portfolio History Cursor Contract and Partner Position Headers

Portfolio and partner account docs were updated for integrations that page through account activity or query positions on behalf of managed accounts. API documentation updates:
  • GET /portfolio/history now reflects the cursor-based pagination contract
  • Position reads now document partner onBehalfOf usage for managed account flows
  • Server-wallet redemption docs clarify the difference between API resolution state and on-chain conditional-token settlement
Documentation: Portfolio History | Get Positions | Programmatic API

Developer Onboarding and Partner Flow Updates

Developer onboarding now more clearly separates the individual trader/bot path from the platform/partner path. Updated guidance:
  • Individual traders and bot builders can use API keys or self-service scoped trading tokens without applying for partner access
  • Platform partners should use backend-held HMAC credentials, sub-accounts, and delegated signing
  • Programmatic API docs now include the partner application link and updated signing guidance
Documentation: For Developers | Authentication | Programmatic API

Brand Assets and Support Contact

Brand assets were refreshed and the docs support link now points to help@limitless.network.

Apr 14, 2026

SDK v1.0.6: Server Wallet Claim & 100% Maker Rebates

Server wallet claim (all SDKs):
  • All three SDKs (TypeScript, Python, Go) now include helper methods for server wallet redemption and withdrawal
  • redeem — claim resolved conditional-token positions from managed sub-accounts
  • withdraw — transfer ERC20 funds from managed sub-accounts to partner wallets
  • Previously these operations required direct REST calls; now fully supported in the SDK
Maker Rebates program update:
  • Rebate rate increased to 100% across all market types (daily, hourly crypto, 15-minute crypto)
Documentation: Programmatic API | TypeScript SDK | Python SDK | Go SDK | Maker Rebates

Apr 2, 2026

Programmatic API: Partner Integrations, Delegated Signing & FOK Orders

Major new capability for partners building on Limitless. The Programmatic API enables platform integrations with sub-account management, server-side order signing, and both GTC and FOK order types — all through HMAC-authenticated scoped tokens. New API endpoints:
  • POST /auth/api-tokens/derive — Create scoped HMAC tokens with granular permissions (trading, account_creation, delegated_signing)
  • GET /auth/api-tokens/capabilities — Check partner capability configuration
  • GET /auth/api-tokens — List active tokens
  • DELETE /auth/api-tokens/:tokenId — Revoke a token
  • POST /profiles/partner-accounts — Create sub-accounts with server-managed wallets or EOA verification
Delegated signing:
  • Partners with the delegated_signing scope can submit unsigned orders on behalf of sub-accounts
  • The server signs orders using Privy-managed wallets — no private key management needed on the partner side
  • Both GTC (limit) and FOK (market) order types are supported for delegated orders
  • FOK orders use makerAmount (USDC to spend for BUY, shares to sell for SELL) instead of price + size
Recommended architecture:
  • Store HMAC credentials on your backend — never expose them to frontends
  • Use the SDK server-side to sign partner-authenticated requests
  • Expose only your own app-specific endpoints to the frontend
Documentation: Programmatic API guide | Authentication | API Tokens reference

SDK v1.0.4–1.0.5: Programmatic API Support (TypeScript, Python, Go)

All three official SDKs now include full support for the Programmatic API: New services across all SDKs:
  • ApiTokenService — Derive, list, and revoke scoped HMAC tokens
  • PartnerAccountService — Create sub-accounts with server wallets or EOA verification
  • DelegatedOrderService — Place GTC and FOK orders on behalf of sub-accounts, cancel orders
New root Client entrypoint:
  • Composes all domain services (markets, portfolio, orders, API tokens, partner accounts, delegated orders) behind a single constructor
  • HMAC credentials are configured once and applied to all requests automatically
TypeScript SDK:
  • Client with hmacCredentials option
  • client.apiTokens, client.partnerAccounts, client.delegatedOrders
  • WebSocket HMAC authentication support
  • TypeScript SDK docs
Python SDK:
  • Client with hmac_credentials option
  • client.api_tokens, client.partner_accounts, client.delegated_orders
  • WebSocket HMAC handshake support
  • Python SDK docs
Go SDK:
  • NewClient(limitless.WithHMACCredentials(...))
  • client.ApiTokens, client.PartnerAccounts, client.DelegatedOrders
  • WebSocket HMAC authentication support
  • Go SDK docs

Mar 23, 2026

SDK v1.0.3: Market Pages Navigation

All three SDKs now support the market pages navigation API for browsing markets by category. New capabilities:
  • Navigation tree discovery
  • Market page resolution by path with automatic redirect handling
  • Market listing with filters, pagination, and cursor support
  • Property keys and options for dynamic filtering
TypeScript: Market Pages | Python: Market Pages | Go: Market Pages

Go SDK v1.0.3: Initial Stable Release

First stable, production-ready release of the Go SDK with full feature parity. Highlights:
  • EIP-712 order signing with private key (Base mainnet)
  • GTC and FOK order support
  • WebSocket streaming with Socket.IO protocol, auto-reconnect, and typed event handlers
  • Configurable retry with exponential backoff
  • Functional options pattern throughout (WithBaseURL, WithAPIKey, WithLogger, etc.)
  • Zero external dependencies beyond go-ethereum and gorilla/websocket
Documentation: Go SDK

Mar 2026

WebSocket Market Lifecycle Events

New WebSocket events for market creation and resolution, enabling real-time monitoring of market lifecycle changes.
  • market.created — Fires when a new market is created
  • market.resolved — Fires when a market resolves
Documentation: WebSocket Events

Feb 2026

SDK v1.0.2: Stable LTS Release (TypeScript & Python)

First stable, long-term support releases of the TypeScript and Python SDKs. Core features across both SDKs:
  • API key authentication with X-API-Key header
  • EIP-712 order signing with venue-aware contract resolution
  • GTC and FOK order creation with automatic signing
  • Market data fetching with intelligent venue caching
  • Portfolio and position tracking
  • WebSocket streaming with auto-reconnect
  • Retry mechanisms with configurable backoff strategies
  • NegRisk market support with dual approval system
TypeScript SDK highlights:
  • Full TypeScript type safety with comprehensive type definitions
  • 17 production-ready code samples
  • @retryOnErrors decorator and withRetry wrapper
  • TypeScript SDK docs
Python SDK highlights:
  • Async-first architecture built on aiohttp
  • Pydantic models for type-safe request/response handling
  • @retry_on_errors decorator
  • Python SDK docs

Python SDK v1.0.2: Float Precision Fix

Fixed IEEE 754 float precision issues in order pricing that could cause incorrect makerAmount/takerAmount calculations (e.g., 0.95 scaling to 949999 instead of 950000).

Dec 2025

Cookie-based session authentication has been removed. All programmatic access now requires API keys (X-API-Key header) or scoped API tokens (HMAC). Action required: If you were using cookie-based authentication, migrate to API key authentication. Generate keys at limitless.exchange under profile menu → Api keys. Documentation: Authentication

Nov 2025

Initial SDK Releases (Pre-release)

Pre-release versions of the TypeScript (v0.0.1) and Python (v0.1.0) SDKs launched with core trading functionality including market data access, GTC/FOK order creation, and portfolio tracking.