> ## Documentation Index > Fetch the complete documentation index at: https://docs.rook.pm/llms.txt > Use this file to discover all available pages before exploring further. # Market identity > One settlement identity, explicit outcome sides, preserved venue provenance. ## Market, outcome, listing | Reference | Meaning | | - | - | | Family | Rook's grouping of related markets across original venue events | | Event | An original venue-maintained event, identified by venue and native event ID | | Market | A versioned settlement obligation with a readable explanation | | Outcome | A specific side of that obligation: YES, NO or a named outcome | | Listing | A venue-specific representation with native identifiers and trading metadata | Settlement-equivalent venue listings share canonical market and outcome identities. Prices, position attribution and execution provenance remain listing-specific. ## Family, venue event, market The navigation structure is **Family → original venue events → markets**. Rook preserves each venue event's ID, title and market membership. Related markets in different events share family references; Rook does not merge those events or manufacture an event to group the markets. Both event and market responses return `family_ids`. A family returns its `event_ids` and `market_ids`, so you can follow the group in either direction. Membership can overlap and does not imply that every market in an event has supported payout analysis. Coverage reports that separately. ## Start with native IDs Specify the venue together with the event or market ID you already have: ```http theme={null} GET /v1/events?venue=polymarket&venue_event_id=900001 GET /v1/markets?venue=polymarket&venue_market_id=1000001 ``` The first response returns a Rook `event_id`, the original `venue_event_id`, its market IDs and family IDs. The second returns a Rook `market_id`, its original event references, family IDs and outcome/listing IDs. The numbers here are illustrative fixtures, not live venue records. Polymarket event and market IDs are numeric. JSON encodes their exact decimal digits as strings, such as `"venue_market_id": "1000001"`. Event IDs, market IDs, condition IDs and CLOB token IDs are separate identifiers. Rook IDs are opaque strings; use the returned value unchanged. For several markets, use [`POST /markets:resolve`](/api-reference/resolve-markets) with `venue` and `venue_market_id` on each input. A market ID alone resolves the market and returns its outcomes; add an outcome selector when resolving a specific side. The connected examples show two original events, `evt_pm_900001` and `evt_pm_900002`, sharing `fam_fed_dec_2026`. Their cut and hold markets retain their separate event memberships. Follow the returned family with `GET /families?family_id=fam_fed_dec_2026`, or browse its original events with `GET /events?family_id=fam_fed_dec_2026`. ## Equivalence requires matching rules Matching titles are insufficient. Measurement, source, observation window, boundary conditions and exceptional settlements must agree. A difference in any settlement-relevant rule preserves separate canonical identities. Amendments retain historical mapping and settlement versions. `GET /markets?market_id=mkt_fed_dec_2026_cut` returns the market's settlement summary, payout conditions, outcome IDs, listings and family references in `items`. Add `include=EVIDENCE` for the supporting settlement evidence. Omit `market_id` to browse or search markets through the same endpoint. ## Select a side explicitly An analytical instrument reference supplies exactly one of: ```json theme={null} {"outcome_id": "out_fed_dec_2026_cut_yes"} ``` ```json theme={null} {"listing_id": "lst_pm_fed_dec_2026_cut_yes"} ``` A listing reference also preserves venue identity. An event or market alone cannot silently select YES. NO has its own payout vector; it is not a negative YES holding. Native IDs remain exact text, including long numeric token identifiers. Resolve supported native identity tuples through [`POST /markets:resolve`](/api-reference/resolve-markets). Search by event, family, venue, category or explicit market IDs. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.