📚 Glossary

A unique identifier that authenticates your requests to Trackser Live. Treat it like a password—keep it secure and never share it. Used as a query parameter: ?key=YOUR_API_KEY

The ISO 8601 timestamp indicating when the response data was generated. Use this to verify data freshness. For real-time data, it should be within the last minute.

TfL's legacy real-time train tracking system. Provides detailed XML feeds with track codes, platform information, and vehicle IDs. Our primary data source for Underground lines. See Data Sources for more.

TfL's modern JSON-based API covering all TfL services. Less detailed than TrackerNet but provides broader network coverage. Used as a secondary source or fallback. See Data Sources for more.

A method of compressing responses to reduce bandwidth. Most API responses use gzip compression, typically reducing size by 70-80%. Most HTTP clients handle this automatically.

The unique identifier of a train's booked working throughout the day. Internally this is called a "Train Number" or "Train Running Number" and a physical train will be allocated to this for the day, although they can be swapped around for operational reasons. This is different from leading car number. You can use the Working Timetables to follow a trains scheduled working throughout the day.

This is the same as "vehicleId"—it refers to the unique identifier for a train's booked working throughout the day. TrackerNet uses "SetNo" while Unified API uses "vehicleId", but they represent the same concept. We normalize both to "vehicleId".

The physical identification number of the first car in a train set. Used by operational staff to identify specific trains. It will change as a train reverses direction. Different from "vehicleId"/"setNo" which is the booked working identifier.

A code indicating a physical track section where a train is located. This code is derived from the track circuits of the signalling system. Trackser Live uses track codes to infer precise locations when direct station information is unavailable. Example: TF80251

The descriptive name of a platform at a station, typically including direction. Example: "Northbound Fast - Platform 3" or "Eastbound - Platform 2".

Used in TrackerNet data, LCID is an internal identifier for the local computer system reporting the train's location. It helps correlate data from different reporting systems but is not directly meaningful for end users.

A train that has remained at the same location longer than historical norms. Detected by comparing current location duration against locationAvgSeconds. Not necessarily a problem—some waits are expected (driver changes, booked dwell times, etc.). Flagged by isMaybeStalled field.

When a trains booked working (vehicleId) has recently changed due to operational needs, such as late running or maintenance. This isn't persisted throughout the day, so a train may reform multiple times. Indicated by isReformed field.

The service pattern for a particular trip. "All Stations" means the train stops at every station on its route. "Fast" means it skips certain stations. "~ All Stations" (with tilde) indicates a timetabled pattern and is derived from cached data collected over time.

A short code indicating the final destination and route, used on newer CBTC signalled lines. Example: "WAT1 (WAT1/M-W-XX-NPNN-M/WAT1)" for Watford Platform 1. In this example, "M-W-XX-NPNN-M" indicates the stopping pattern which is a Semi-Fast service, not stopping at Northwick Park or Preston Road. An All Stations service to the same destination would have a destination code of "WAT1 (WAT1/M-W-NP-NPNN-M/WAT1)". Provides a consistent way to identify service patterns that may have the same destination name but different stopping patterns. We use this code to also infer the destBookedPlatNo field.

An identifier for a specific service run assigned by TfL's scheduling system. Helps track the journey of a particular train set throughout its operating day. A Train Number and Trip Number together uniquely identify a service in the Working Timetables.

The scheduled departure time from the line's origin or first stop. Format is HH:MM:SS. Helps identify the planned schedule and understand delays.

The process of standardizing station names and location descriptions. TfL's raw data includes inconsistent naming (abbreviations, variations, typos), so we normalize to consistent, human-readable station names.

Removal of duplicate train records. The same physical train can sometimes appear multiple times in raw data. We identify duplicates by matching vehicle ID, location, and timestamp, keeping only the most accurate record.

Adding computed or enhanced fields to raw data. Examples: inferring locations from track codes, calculating destination codes, computing stall status. Makes data more useful without changing its core facts.

Historical average time trains spend at a particular location. Calculated from months of data. Used to detect stalls—if a train's currentLocationDurationSeconds exceeds this average significantly, it's likely stalled.

Boolean flag indicating whether a train is moving slower than historically normal for its current location. Useful for identifying delays without assuming all slow movement is a problem.

Flag indicating the vehicle ID was not directly provided by TfL but was inferred from other data (like leading car number). These are usually accurate but slightly less reliable than directly reported IDs.

The serverless platform on which Trackser Live runs. Allows us to execute code globally with minimal latency, automatic scaling, and built-in security. See Architecture for details.

Cloudflare's storage service where we keep processed train snapshots and historical data. Allows us to serve cached responses quickly and maintain historical records for replay and analysis.

A distributed network of servers that cache and serve content from locations near users. Reduces latency and bandwidth costs. Trackser Live uses Cloudflare's edge network globally.

A mechanism to control how many requests can be made per time period. Protects the system from abuse and ensures fair resource allocation. Trackser Live enforces per-key rate limits.