Ticket market data API

Ticker's market data over HTTP: price, inventory and demand for an event, the history of those readings, a name-to-id search, and performer rank. It authenticates with an API key. There is one Ticker API, and this is its reference.

Getting started

Create a key in Settings, under API, then send it as a bearer token against this base URL.

https://api.findticker.com

curl -s \
  -H "Authorization: Bearer $TICKER_API_KEY" \
  "https://api.findticker.com/api/feed/v1/events/ev7k3m9qp2xd/shopping?range=28d&columns=interest,sales"

Responses are JSON. A null means the reading was not observed, never that it was zero. Values are as of computed_at, the time the reading was computed. The shopping series is a list of points, each stamped with its snapshot_date.

{
  "event_id": "ev7k3m9qp2xd",
  "current": {
    "interest": 412,
    "sales": 9
  },
  "series": [
    {
      "snapshot_date": "2026-08-31",
      "interest": 412,
      "sales": 9
    }
  ],
  "meta": {
    "range": "28d",
    "coverage_start": "2026-08-04",
    "points": 28,
    "columns": ["interest", "sales"]
  }
}

Where the prices come from

Every price this API returns is an asking price: what a seller listed a ticket at on resale, or what the box office lists on the primary market, at the moment Ticker read the marketplace. None of them is the price a ticket changed hands at, and no field reports one.

When a seat stops being open on the primary market the API calls it taken. A sale, a hold and a seat not yet released look the same from outside, so taken is never a count of sales. When a listing leaves resale, a buyer may have taken it or its seller may have withdrawn it; the API does not tell those apart, and it reports the last asking price, not a clearing price.

Authentication

Send the key in the Authorization header. Every secret starts with tk_live_.

Authorization: Bearer tk_live_...

The key reaches the data routes and nothing else. The rest of the Ticker API is session-authenticated, so a key cannot read a watchlist, an alert, or an account, and it cannot create another key.

The account's plan is re-read on every request. A downgrade or a cancellation stops the reads at the next call with a 402, without touching the key. A 403 is the other refusal: the plan is there and API access has not been granted.

Ids

Every route takes Ticker ids. An event id is ev plus ten characters, a performer id is pf plus ten characters, and every id the API returns is in that form.

A marketplace id resolves in the same slot when it carries its source prefix, vs:, tm: or tp:. That form does not expire. A bare marketplace id is read as vs: until 2027-09-13 and answers 404 after that date, so nothing you already hold breaks today and nothing stays tied to a marketplace for ever. A whole url segment with its slug is a 400: send the id alone.

Resolve an id by name with the same key:

curl -s \
  -H "Authorization: Bearer $TICKER_API_KEY" \
  "https://api.findticker.com/api/feed/v1/search?q=morgan%20wallen&limit=5"

Each match carries an event_id, the value every route below takes, and a performer_id for the performer route.

Enumeration

Search resolves a name. It does not page a catalog: there is no list-by-date, list-by-city or list-by-performer route, no cursor on the search response, and a q that is a single character or a wildcard returns 400. Arrive with a name or with ids you already hold.

A screen is the one way to reach events you cannot name, and it is bounded by price rather than by shape: a filter returns matches, and every match returned costs a unit against the same unit budget. Nothing hands back ids for free.

Shopping routes

Every read is priced in budget units. The two below are the shopping pair. They answer with current, the latest reading, and series, a list of points each stamped with its snapshot_date. Values are as of computed_at. They are the only routes that take columns.

A batch carries up to 200 ids. Every batch response echoes the bound in force as meta.batch_max, so a client can size its pages from the answer rather than from this page.

curl -s -X POST "https://api.findticker.com/api/feed/v1/events/shopping" \
  -H "Authorization: Bearer $TICKER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "event_ids": ["ev7k3m9qp2xd", "ev2p5w8xd4mq"],
    "range": "7d",
    "include_series": true,
    "columns": ["interest", "sales"]
  }'

{
  "data": [ /* one entry per known id, in the order asked for */ ],
  "meta": {
    "requested": 2,
    "returned": 1,
    "missing": ["ev2p5w8xd4mq"],
    "batch_max": 200
  }
}

Columns

columns applies to the two shopping routes above and to no other route on this page. It narrows a shopping response to interest and sales. An unknown name is a 400 whose message lists the valid set.

A missing key and a null value mean different things. Absent means the request did not select it. Null means it was selected and not observed.

Shopping

Both metrics are rolling-window levels, not flows. sales is how briskly the event is selling over the window, not a count of tickets that changed hands.

Analytics

The analytics pair returns this set on every call. It does not take columns. Values are as of computed_at. prediction_markets is present only when at least one Kalshi market maps to the event; the same array appears on the performer route, alongside its raw X counts and Kalshi probability.

Other routes

None of these take columns. The analytics pair answers one flat reading per event, history answers a list of points stamped as_of_date, search answers ids only, and the performer route answers a rank position and its series.

Views and screens

These three answer with a set of events rather than a reading for an id. A saved View is one you built in the product and the key reads back its current matches. A screen takes the question in plain language, compiles it with the same model the product's own screener uses, and returns the matching list together with the filter that ran, so nothing about the answer is opaque.

Rows carry the analytics reading, the same set the analytics route serves. The compile spends one request from the account's assist allowance and the rows spend budget units, so a question that matches fifty events costs fifty units and one assist request.

curl -s -X POST \
  -H "Authorization: Bearer $TICKER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"query":"events under $80 with more than 200 listings"}' \
  "https://api.findticker.com/api/feed/v1/screen"

{
  "query": "events under $80 with more than 200 listings",
  "predicate": {
    "all": [
      { "col": "ea.median_price_current", "op": "<", "val": 80 },
      { "col": "ea.listings_current", "op": ">", "val": 200 }
    ]
  },
  "sort": null,
  "note": null,
  "total": 143,
  "rows": [ { "event_id": "...", "median_price_current": 62, "listings_current": 318 } ],
  "meta": { "page": 1, "limit": 50, "returned": 50, "units_charged": 50 }
}

Freshness

How current each route's answer is, and the field that says so. A reading carries the time it was computed; read that field rather than assuming an age. No route promises a schedule: history runs from the first reading to today, and no reading is overwritten.

Rate limits

A shared unit budget for each UTC date and a per-minute request budget belong to the account, not to a key, so five keys share one allowance and rotating a key does not buy more calls.

A read costs one unit per event id it returns. A single read costs one. A batch of known ids costs one unit per id returned. Ids the catalog does not know cost nothing and come back under meta.missing. A history read costs one whatever its days value, and a search costs one because it returns ids rather than readings.

Every 200 carries X-Feed-Limit and X-Feed-Remaining. When either budget is exhausted the call returns 429 with Retry-After in seconds: seconds until the minute clears for the burst ceiling, seconds until midnight UTC for the day. Every 200 also carries X-Feed-Cost, the units that call spent.

An admitted request counts on the attempt, so a client that retries an error in a loop is still bounded. A call refused on authentication or entitlement is never admitted, so it costs nothing and carries no X-Feed header at all. These are current limits, not an SLA.

Key lifecycle

Keys live in Settings, under API. An account can hold five at once, which is what makes rotation possible: create the replacement, move your integration over, then revoke the old one.

The secret appears once, in the dialog that creates it. Ticker stores a SHA-256 hash of it and the non-secret prefix, so no route can return the secret a second time and nobody at Ticker can read it back. Copy it into your secret store before you close that dialog. If you lose it, revoke the key and create another.

After creation a key is identified by its prefix, tk_live_ plus eight characters, next to its name, creation date and last use. Revoking is immediate: requests carrying that key return 401 from the next call on.

Treat a key like a password. Keep it server-side, out of source control and out of browser code, and revoke it the moment you think it has leaked.

Errors

Every error is JSON in one shape:

{ "code": 401, "message": "…" }

A known event that has no reading yet is not an error. The shopping routes return 200 with current set to null and an empty series; the analytics and history routes return 200 with null readings.

Prefer an AI client?

Everything the API exposes is also reachable through the MCP server: no key, OAuth sign-in, and the same readings as tools. Use the API when you want raw HTTP from your own code; use MCP when an assistant is doing the reading.