Skip to main content
GET
/
markets
/
{addressOrSlug}
Get Market Details
curl --request GET \
  --url https://api.limitless.exchange/markets/{addressOrSlug}
"<unknown>"
This endpoint returns venue data (venue.exchange and venue.adapter) needed for EIP-712 order signing. Fetch once per market and cache — venue data is static.
Outcome index convention. On a resolved market the response carries winningOutcomeIndex, an index into the fixed outcomeTokens: ['Yes', 'No'] array:
  • winningOutcomeIndex: 0YES resolved
  • winningOutcomeIndex: 1NO resolved
  • null — not yet resolved
The same mapping applies anywhere this field appears (portfolio positions, feed events). For negrisk groups, the winning index lives on the individual sub-market that resolved YES, not on the group object.
Market volume. The response includes lifetime trading volume in the volume field (raw, base units) and volumeFormatted (human-readable USDC). The API does not expose a rolling 24-hour volume field; for time-windowed activity, derive it client-side from Get Feed Events (filter trade events by timestamp).
Market status values. The response’s status field is one of:
  • FUNDED — the market is live and accepting trades. The default for active markets.
  • LOCKED — trading is paused on the market: orders cannot be placed or filled, but existing positions remain. A market typically enters LOCKED shortly before resolution (after the deadline, while the winning outcome is being determined) or when an operator manually halts it. The market resumes as FUNDED if unlocked, or transitions to RESOLVED once the outcome is set.
  • RESOLVED — the winning outcome is known. winningOutcomeIndex is populated and winners can redeem their CTF positions. See Lifecycle after a trade.
  • FUNDED_FLAGGED — the market is live but flagged for review (for example, pending resolution clarification). Treat it as FUNDED for trading purposes unless your integration wants to surface the flag to users.
  • DRAFT — the market exists but has not been funded yet and is not tradeable.
Treat any unrecognized future value defensively rather than assuming the market is tradeable.
Taker delay. A CLOB market’s settings object carries takerDelayMs — the market’s taker delay in milliseconds (0 = none, the default). When it is greater than 0, marketable (taker) orders on this market are briefly held before the matching engine fills them and order submission becomes asynchronous (the create-order response returns settlementStatus: "DELAYED" with an eligibleAt; track the fill over subscribe_order_events). Read settings.takerDelayMs to detect delay-enabled markets before placing taker orders. postOnly (maker) orders are never delayed.

Path Parameters

Response

Market or group details with pricing and volume data

CLOB market with position IDs and trading data