Read the outcome identifier before the order book

An order-book response is only useful if it belongs to the outcome you meant to read. A market can expose a market ID, a slug, a condition ID, and separate identifiers for each outcome.

The title is for humans. The identifier map is what keeps the data attached to the right contract.

Start with the market version

Use the market's version to select the trading identifier: the CTF token ID for a v1 market or the Polymarket Protocol V2 position ID for a v2 market. Both fields can be present, so their presence alone does not choose the protocol.

If the required identifier is missing, stop the calculation. Do not substitute a nearby field just because it looks like a long hexadecimal string.

Keep the outcome mapping visible

Store the label, price, and selected asset ID together. For a binary market, the documentation maps the parsed outcome entries by index; keep the mapping in your note rather than relying on the order of a later response.

This is especially useful when a dashboard shows several related outcomes and the same title appears in more than one place.

Separate analytics identifiers

Use the market ID for market lookups, the slug for a human-readable page, and the condition ID for analytics or lifecycle work where required. Do not join records by title alone.

A correct price attached to the wrong condition is still the wrong input.

Snapshot the mapping with the book

Save the selected identifier, timestamp, best prices, and book hash together. When the book changes, you can tell whether the data changed or whether your code or note pointed at a different outcome.

The useful question is not whether the API returned a price. It is whether the price is tied to the exact outcome and market version you intended to analyze.

Further reading: Market details · Prices and order books · Order lifecycle.

Explore the markets: Open Polymarket (referral link).