Tracking API reference
How the Tracking reference is organized: one page per concept for live state, state streams, readings and the field dictionary, and trips and stops.
The Tracking API reference documents every operation and type of Tracking, grouped into one page per concept. Each page covers its queries or subscriptions, its object and input types, and its enums, with a field table for every type.
The reference states what each operation and field is. For how to use them together, see the Tracking guides, and for the GraphQL fundamentals behind the notation, see GraphQL basics, including the type syntax that the field tables use.
Where the operations live
All Tracking queries are nested under the tracking field of the Query type. The state stream is a field of the Subscription type, at the root, because a subscription cannot be nested. Business Data Repository owns the asset and device records that Tracking reports on, so an asset state names an asset from Business Data Repository and a device state names a device from it.
Pages
The last known position, connectivity, motion, readings, and events of a device (TrackingDeviceState), the per-device states of an asset (TrackingAssetState), and the queries that read them: deviceState, deviceStates, assetState, and assetStates with its filter and order inputs.
The subscription that pushes the full state of an asset, with every linked device, on every report, delivered in batches, with the opening-snapshot markers and the removal signals that each message can contain.
The value model of a reading (TrackingReading and its typed values), the unit rules, and the field dictionary with the query that returns it, fieldDefinitions.
The timelines that Tracking calculates from the message archive (deviceTimeline and assetTimeline), the segmentation policy that cuts them into trips and stops, and the options that shape the returned points.
Shared types
The scalars, interfaces, and pagination types that Tracking shares with the other products are on the Common resources page. The Core API reference indexes the reference pages of every product.
How the reference pages are structured
Every page follows the same order: queries or subscriptions, then the page's objects, inputs, and enums, with pagination types in a section of their own at the end. Field tables use the GraphQL type notation, where ! marks a value that is never null and [...] marks a list: see Type syntax.
Other ways to explore the API
GraphQL Sandbox: Run queries and mutations interactively.
Public GraphQL schema: The full type system split into several files.
Introspection: Explore the schema from your own GraphQL client.
See also
Tracking overview: What Tracking covers and how its concepts fit together
Tracking guides: A live fleet map and a vehicle trip history, built from these operations
Error handling: Understand error structure, codes, and common error scenarios
Last updated
Was this helpful?