Skip to main content
If you already hold a venue’s own identifier, you can resolve it directly instead of searching. Every lookup returns the full cross-venue cluster, and it works the same whether the identifier belongs to the cluster anchor or to one of its members.

​
Events

matchedVenueEvents[] on each result lists the same event on every other venue.

​
Markets

matchedVenueMarkets[] lists the same market on every other venue.

​
Outcomes

matchedVenueMarketOutcomes[] gives a { venueMarketId, venueMarketOutcomeId } reference pair for the counterpart outcome on each matched venue — IDs only, correctly aligned even where the two venues frame the question in opposite directions. This endpoint does not return the counterpart objects themselves: fetch them from /venue-markets using the returned venueMarketId if you need labels, prices, or venue metadata.

​
Rules

  • venue is required for /venue-events and /venue-markets. It is optional for /venue-market-outcomes, where identifiers are globally unique.
  • Batch up to 20 identifiers per request by repeating the parameter. Over 20 returns 400.
  • Unknown identifiers are omitted from data rather than returned as nulls. Match responses back to your input by reading externalIdentifier on each item.

​
Two limits worth knowing

Kalshi outcome identifiers cover one side only. Kalshi puts its ticker on the Yes-side outcome; the No side has no identifier and cannot be looked up directly. Fetch the market instead and read both outcomes from venueMarketOutcomes[]. Do not persist cluster ids as permanent keys. When two clusters merge, members are re-pointed onto the surviving anchor. The old id stays a valid event, but it is no longer the cluster head. Re-resolve from discovery, or key your own storage on the venue identifier you already hold — that one is stable.