AGG is currently in alpha. APIs, components, and docs may change.
Agg.market — Prediction Market Aggregator logo

Look up markets by venue identifier

Resolve a Kalshi ticker or Polymarket token_id to the full cross-venue cluster.

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

curl "https://api.agg.market/venue-events?venue=kalshi\
&externalIdentifier=KXNBAGAME-26MAR15BOSLAL" \
  -H "x-app-id: $AGG_APP_ID"

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

Markets

curl "https://api.agg.market/venue-markets?venue=polymarket\
&externalIdentifier=512345" \
  -H "x-app-id: $AGG_APP_ID"

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

Outcomes

curl "https://api.agg.market/venue-market-outcomes?externalIdentifier=$TOKEN_ID" \
  -H "x-app-id: $AGG_APP_ID"

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.