Data freshness

This page covers when each kind of data is recorded, how long each endpoint’s response is cached on the server, and which timestamp to read to know how old a figure is. You need it to choose a polling pace and to interpret any price or count.

Cadences

Routeur’s jobs run on fixed schedules (all times UTC). Each response tells you what it was built from.

Data	Recorded	Where to check
Kalshi listings, rule text, top-of-book asks and bids	Every 15 minutes (`:00`, `:15`, `:30`, `:45`); a crawl takes a few minutes	`observed_at` on each quote; `latest_crawls` in `GET /v1/status`
Polymarket listings, rule text, top-of-book asks and bids	Every 30 minutes (`:00`, `:30`)	same
Trades on both venues	Every minute	`executed_at` on each trade (the venue’s time); `recorded_at` on stream events
Order books	Live from the venues’ feeds; full-tier markets get every level change, other markets are polled a few levels at a time	`as_of`, `venue_ts` and `snapshot_at` on a book; `book_at` on market objects; `GET /v1/books/health`
The graph: relations, events, leads, cross-venue pairs	Hourly, starting 10 minutes past the hour, from the latest complete crawls	`graph_run` on the response; `graph_run.started_at`, `finished_at` and `listings[].since` in `GET /v1/status`
Flow signals (bursts, large fills, one-sided flow)	Every 5 minutes	`first_detected_at`, `last_detected_at`
Topic labels and search embeddings	Every 15 minutes	`graph_run`
Settled history, calibration, strategies	Twice an hour (`:07`, `:37`)	`refreshed_at` on calibration
Rulebooks and contract terms documents	Every 6 hours; rule text itself is recorded on every crawl	`first_seen_at`, `last_seen_at` on versions; `fetched_at` on documents
Webhook deliveries	Queued after each graph run, delivered every 2 minutes	`created_at` on the event

A graph run reads only complete crawls. If a venue’s latest crawl did not finish, the run keeps the previous complete one and its markets stay listed. Observed on 17 September 2026: graph run 74 started at 12:10:17 from the crawls that began at 12:00, and finished 20 seconds later; the next crawls started at 12:30 and finished at 12:33 (Kalshi) and 12:36 (Polymarket).

Server-side cache

Many endpoints keep a recent response for the same path and query, per API instance. A cached response is still counted against your key. Cached or not, JSON responses carry Cache-Control: private, max-age=30; errors and the stream carry no-store.

Cache time	Endpoints
5 seconds	`GET /v1/books/health`
10 seconds	`GET /v1/markets/{venue}/{id}/book/history`
30 seconds	`GET /v1/events`, `GET /v1/events/{venue}/{id}`, `GET /v1/search`, `GET /v1/insights/tape`
1 minute	`GET /v1/insights`, `/insights/moves`, `/insights/flows`, `/insights/ticker`, `/insights/strategies/{id}`, `GET /v1/opportunities`, `GET /v1/flow`, `GET /v1/markets/{venue}/{id}/rules`, `GET /v1/rulebooks/{venue}/{kind}/{id}`, `GET /v1/relations/{left_venue}/{left_id}/{right_venue}/{right_id}`
2 minutes	`GET /v1/topics/{slug}`, `GET /v1/events/{venue}/{id}/related`, `GET /v1/markets/{venue}/{id}/related`
5 minutes	`GET /v1/categories`, `GET /v1/insights/closing`, `GET /v1/insights/strategies`
10 minutes	`GET /v1/topics`, `GET /v1/insights/calibration`
Not cached	`GET /v1/status`, `GET /v1/markets`, `GET /v1/markets/{venue}/{id}`, `/relations`, `/quotes`, `/trades`, `/book`, `GET /v1/cross-venue`, `GET /v1/stream`, `GET /v1/openapi.json`

Polling an endpoint faster than its cache time returns the same body and spends quota. Poll at the cadence of the data behind it instead, or use the live stream.

Which timestamp to read

Field	On	Meaning
`observed_at`	quotes, `quote` on markets, `depth` on leads	When Routeur read the venue’s top of book. A quote is what the venue was asking at that moment, not a live price.
`executed_at`	trades	When the fill happened, as the venue reports it.
`recorded_at`	stream `trade`, `book` and `rule_change` events	When Routeur wrote the event. A recording backlog can deliver older fills; compare with `executed_at`.
`as_of`	order book	When the last level change the book includes was received.
`venue_ts`	order book, stream `book` events	The venue’s own timestamp on that change, where the venue sends one.
`snapshot_at`	order book	The full snapshot the book was rebuilt from; `events_applied` says how many changes were applied since.
`book_at`	every market object with a recorded book	When the recorded top of book last changed.
`graph_run`	envelopes of graph-derived responses	The hourly run the response was read from. `GET /v1/status` gives its `started_at` and `finished_at`.
`listings[].since`	`GET /v1/status`	When the crawl each venue’s markets were read from started.
`first_seen_at`, `last_seen_at`	rule versions, rulebook versions	When a version of the terms was first and last observed in a crawl.
`changed_at`	rule changes	When the terms changed, from the crawl that first saw the new version.
`fetched_at`	contract terms documents	When the document was last fetched.
`first_detected_at`, `last_detected_at`	flow signals	The first and latest 5-minute pass that detected the signal.
`first_seen_at`, `last_confirmed_at`	proof trail	When the relation was first proven and the latest run that confirmed it.
`refreshed_at`	calibration	When settled history was last recomputed.

Observed on one Kalshi market on 17 September 2026: quote.observed_at was 12:33:03 (the 12:30 crawl), the order book’s as_of was 12:40:56 with venue_ts 12:40:56.573, and the latest trade’s executed_at was 12:38:23.

Prices are observations

Quotes are the venues’ top-of-book asks and bids as recorded on a crawl, up to 15 minutes old on Kalshi and 30 on Polymarket. Between crawls the book moves, and a venue can hold more size at worse prices behind the top level. For a live view, read GET /v1/markets/{venue}/{id}/book, which is rebuilt from the venue feed; for sizing a lead, read its depth, which walks both books with fees and minimum sizes.

Checking the service

curl -s https://api.routeur.app/v1/status -H "X-API-Key: $ROUTEUR_API_KEY"

{
  "data": {
    "graph_run": {
      "id": 74,
      "started_at": "2026-09-17T12:10:17.023795Z",
      "finished_at": "2026-09-17T12:10:36.937979Z",
      "listings": [
        { "venue": "kalshi", "crawl_run": 405, "since": "2026-09-17T12:00:19.066598Z" },
        { "venue": "polymarket", "crawl_run": 404, "since": "2026-09-17T12:00:18.890952Z" }
      ],
      "markets": 304955,
      "new_edges": 59380,
      "conflicts": 0,
      "opportunities": 36
    },
    "latest_crawls": [
      { "venue": "kalshi", "started_at": "2026-09-17T12:30:14.362718Z", "finished_at": "2026-09-17T12:33:23.889705Z", "complete": true, "markets": 130310 },
      { "venue": "polymarket", "started_at": "2026-09-17T12:30:14.364144Z", "finished_at": "2026-09-17T12:36:04.079904Z", "complete": true, "markets": 174810 }
    ],
    "latest_complete_crawls": [ "..." ]
  },
  "graph_run": 74
}

Field	Meaning
`graph_run.id`	The latest finished run; the same number appears as `graph_run` on graph-derived responses.
`graph_run.listings`	The crawl each venue’s markets were read from, and when it started.
`graph_run.conflicts`	Relations withheld because the evidence disagreed.
`latest_crawls`	The most recent crawl per venue, complete or not.
`latest_complete_crawls`	The most recent complete crawl per venue; the next graph run reads these.

GET /v1/books/health reports each venue’s order-book feed: status (up, degraded, down), connected, last_message_at, stale_seconds, message and event rates, and feed latency (latency_ms_p50, latency_ms_p99).

Get started

Concepts

Agents & MCP

Webhooks

Reference

Cadences

Server-side cache

Which timestamp to read

Prices are observations

Checking the service

Cadences

Server-side cache

Which timestamp to read

Prices are observations

Checking the service

Related