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. Ticker data is for research, pricing and market analysis only, never for directly purchasing tickets.

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 a listed price: what a seller listed a ticket at on resale, or what the primary market lists on the primary market, at the moment Ticker read the marketplace.

Prices are in US dollars. A route that takes currency answers an event at a Canadian venue in Canadian dollars when you pass currency=venue, at one exchange rate for the whole event, and names currency, venue_currency, fx_rate and fx_rate_date beside the prices. An event in the US is always in US dollars.

When a seat stops being open on the primary market the API calls it taken: bought, held or not yet released. When a listing leaves resale, a buyer took it or its seller withdrew it, and a count of listings that left, such as sold_or_pulled, counts both.

Completed resale sales are a separate record. GET /api/feed/v1/events/{eventId}/sales lists an event's sales, newest first: each with its sold_at, matched to the listing it sold from, with its section, row, tickets and listed price before and after fees.

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 to ids. A q that is a single character or a wildcard returns 400.

A screen reaches events by rule: date, city, price or demand. Every match it returns costs a unit against the same unit budget.

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

interest is the most people viewing the event in an hour, and sales the tickets bought.

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 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, the Matches it recorded, and the account's Watchlist. 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. A screen spends one screener run from the account's plan and the rows spend budget units, so a question that matches fifty events costs fifty units and one screener run. The compile spends nothing of its own.

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. History runs from the first reading to today, and no reading is overwritten.

Rate limits

A unit budget for each billing cycle, and a ceiling of requests per minute and per hour, belong to the account, not to a key, so five keys share one allowance and rotating a key does not buy more calls. The billing cycle is the account's 30 days, the same days its plan counts; /v1/usage names its first day and the day it renews.

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 the budget or a ceiling is used up, the call returns 429 with Retry-After in seconds: seconds until the minute or the hour clears for a ceiling, seconds until the cycle renews for the budget. Every 200 also carries X-Feed-Cost, the units that call spent.

An admitted request answered 404 or 5xx costs nothing: an unknown id, or our own failure. A 400, 401, 403 or 429 on an admitted request costs one unit, so a client that retries a bad request in a loop is still bounded. Every attempt counts toward the minute and hour ceilings. 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.

Heavy routes

These routes under /api/feed/v1/events/{eventId} read the live seat log: /sections/live, /seats/live, /seats/at, /seats/recent, /section-frames, /seat-history, /ga-history, /seller-series and /seller-market. An account runs two of them at a time. A third waits in line for up to 30 seconds; when it waited, the response carries X-Ticker-Queued-Ms, the milliseconds it waited, and the body is unchanged. Past 30 seconds it returns 429 with Retry-After and this body:

{
  "code": 429,
  "error": "busy",
  "message": "Ticker is busy with this account's earlier calls of this kind. Wait 6 seconds, then call again. Send these calls one at a time, not all at once.",
  "retry_after_seconds": 6
}

When Ticker as a whole is running as many heavy reads as it can, every caller waits in one shared line, and past 30 seconds the 429 carries "error": "busy_global" instead.

Send heavy reads one at a time per account. For bulk reads across hundreds of events, contact us.

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.