Ticker API

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

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 and refresh with each pipeline run. The shopping series is daily.

{
  "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"]
  }
}

Send the key in the Authorization header. Every secret starts with 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 tier 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 tier is there and API access has not been granted.

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.

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 daily budget. Nothing hands back ids for free.

Ten reads in total, each priced in budget units. The two below are the shopping pair. They answer with current, the latest reading, and series, one point per UTC day. Values are as of computed_at and refresh with each pipeline run. The shopping series is daily. 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 applies to the two shopping routes above and to no other route on this page. It narrows a shopping response tointerest 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 daily flows. sales is how briskly the event is selling over the window, not a count of tickets sold that day.

Analytics

The analytics pair returns this set on every call. It does not take columns. Values are as of computed_at and refresh with each pipeline run. 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.

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

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 }
}

A shared daily unit budget 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.

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 digest 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.

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.