Data sources
Headcode sits on top of open and licensed UK rail datasets. These sources overlap, disagree and change at different speeds. Headcode ingests them into a unified model so clients can work with consistent station, service, board and disruption objects.
Source categories
Section titled “Source categories”| Category | Examples | What Headcode uses it for |
|---|---|---|
| Timetable and planning data | Industry timetable feeds, location reference data, CIF-style schedule records | Base schedules, calling patterns, operational locations, UIDs and planned times |
| Real-time running data | Darwin real-time train running data | Estimates, actual times, cancellations, platforms, formations and alerts |
| Station and stop geography | NaPTAN stop areas and stop points | Coordinates, stop relationships and ATCO identifiers |
| Network and operational references | Network Rail Open Data, TIPLOC/STANOX mappings | Operational identifiers, timing locations and infrastructure references |
| Usage and passenger context | ORR usage and footfall statistics | Enrichment, ranking and future passenger-flow products |
| Commercial rail data | Rail Data Marketplace feeds and licensed datasets | Additional coverage where open feeds are incomplete |
How data is normalised
Section titled “How data is normalised”Headcode does more than proxy upstream APIs. It reconciles identifiers across systems (CRS, TIPLOC, STANOX, NLC, ATCO, UIC), links operational locations to passenger stations, merges static timetable data with live updates, and applies consistent naming, nullability and JSON field conventions across all responses.
This means clients can usually start with whichever identifier they already have, then follow links or returned identifier fields to move between stations, boards and services.
Static, live and enriched data
Section titled “Static, live and enriched data”Headcode responses commonly combine three types of data:
- Static data changes slowly. Examples include station names, coordinates, platform lists and identifier mappings.
- Planned data changes with timetable publications and short-term planning updates. Examples include calling patterns, UIDs and scheduled public times.
- Live data changes continuously. Examples include estimated times, actual times, cancellations, platform changes and disruption messages.
When these layers disagree, Headcode favours the best current operational view for live-running endpoints while preserving stable identifiers and schedule context.
Currently exposed products
Section titled “Currently exposed products”- Stations, station search and identifier resolution.
- Station departure and arrival boards, including combined boards and next departures to multiple destinations.
- Station footfall data.
- Service detail, calling points, formations and live status.
- Service lookup by UID and scheduled start date.
- Platform train order.
- Disruptions from station messages and train alerts.
- Non-station operational locations (junctions, sidings, depots).
- Operator reference data.
- Delay and cancellation reason code reference data.
- Feed health monitoring (alarms and heartbeat status).
For details on the response shapes exposed by these products, see Data structures.