Skip to main content
GET
Get Market Details
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.
Mapping tokens.yes / tokens.no to human outcome labels. Every individual market’s token pair is always YES / NO in the API — there is no per-token label field for custom outcomes like “Up” / “Down” or “Norway” / “England”. The mapping to a human label depends on the market type:
  • Binary single market (e.g. “Will ETH close above $3,000?”): tokens.yes = the question resolves true, tokens.no = the question resolves false. The market’s title / proxyTitle carries the semantic meaning.
  • Directional AMM market (e.g. “BTC Up or Down - 5 Min”): each direction is a separate individual market. tokens.yes on the “Up” market = betting on Up; tokens.no on the same market = the opposite side of that bet. To find the “Down” side, fetch the sibling market from the group.
  • Negrisk group market (e.g. “Norway vs England: team to advance?”): the group response returns outcomeTokens: string[] (for example ["Norway", "England"]) and markets[], one submarket per outcome. To trade a specific outcome, call getMarket() on that submarket’s slug and use its tokens.yes — that YES token represents “this outcome resolves true”. See the Negrisk overview and the TypeScript Negrisk group markets walkthrough.
There is no separate tokens.up / tokens.down field — always resolve labels from the group’s outcomeTokens array or from the submarket title / proxyTitle.
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

id
number
required

Market ID

Example:

7494

conditionId
string
required

Condition ID

Example:

"0x947b8e6812bf8ac27687fa25b642d6a25bf5c7292068e5aef129d9d26e9780b8"

negRiskRequestId
string | null
required

NegRisk request ID

Example:

null

description
string
required

Market description

collateralToken
object
required
title
string
required

Market title

proxyTitle
string | null
required

Proxy title

expirationDate
string
required

Expiration date

expirationTimestamp
number
required

Expiration timestamp

createdAt
string
required

Created timestamp

updatedAt
string
required

Updated timestamp

categories
string[]
required

Categories

status
string
required

Market status

expired
boolean
required

Is expired

creator
object
required
tags
string[]
required

Tags

volume
string
required

Volume

volumeFormatted
string
required

Formatted volume

tokens
object
required
prices
number[]
required

Prices

tradePrices
object
required
isRewardable
boolean
required

Is rewardable

slug
string
required

Market slug

tradeType
string
required

Trade type

Example:

"clob"

marketType
string
required

Market type

Example:

"single"

priorityIndex
number
required

Priority index

winningOutcomeIndex
number | null
required

Winning outcome index

metadata
object
required
settings
object
required
logo
string | null
required

Market logo

source
string | null
required

Market source (e.g. ugm:crypto, ugm:sports)

frequency
string

Schedule frequency for timeline

Example:

"minutely"

subFrequency
string | null

Schedule sub-frequency for timeline

Example:

"minutes_5"

feedEvents
object[]

Feed events