> For the complete documentation index, see [llms.txt](https://navixy.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://navixy.com/docs/navixy-graphql-api/tracking/api-reference.md).

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

{% hint style="warning" %}
**Navixy GraphQL API is a work in progress.** This documentation is published for preview purposes only and doesn't reflect a stable release. Structure, field names, and behaviors are subject to change.
{% endhint %}

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](/docs/navixy-graphql-api/tracking/guides.md), and for the GraphQL fundamentals behind the notation, see [GraphQL basics](/docs/navixy-graphql-api/graphql-basics.md), including the [type syntax](/docs/navixy-graphql-api/graphql-basics.md#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 two state streams are fields 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

<table><thead><tr><th width="240">Page</th><th>Covers</th></tr></thead><tbody><tr><td><a href="/docs/navixy-graphql-api/tracking/api-reference/state.md">Live state</a></td><td>The last known position, connectivity, motion, readings, and events of a device (<code>TrackingDeviceState</code>), the per-device states of an asset (<code>TrackingAssetState</code>), and the queries that read them: <code>deviceState</code>, <code>deviceStates</code>, <code>assetState</code>, and <code>assetStates</code> with its filter and order inputs.</td></tr><tr><td><a href="/docs/navixy-graphql-api/tracking/api-reference/state/streams.md">State streams</a></td><td>The subscriptions that push the full state of an asset or a device on every report, delivered in batches, with the opening-snapshot markers and the removal signals that each message can contain.</td></tr><tr><td><a href="/docs/navixy-graphql-api/tracking/api-reference/readings.md">Readings and the field dictionary</a></td><td>The value model of a reading (<code>TrackingReading</code> and its typed values), the unit rules, and the field dictionary with the queries that return it: <code>hotFieldCodes</code> and <code>fieldDefinitions</code>.</td></tr><tr><td><a href="/docs/navixy-graphql-api/tracking/api-reference/trips.md">Trips and stops</a></td><td>The timelines that Tracking calculates from the message archive (<code>deviceTimeline</code> and <code>assetTimeline</code>), the segmentation policy that cuts them into trips and stops, and the options that shape the returned points.</td></tr></tbody></table>

## Shared types

The scalars, interfaces, and pagination types that Tracking shares with the other products are on the [Common resources](/docs/navixy-graphql-api/core-api-reference/common.md) page. The [Core API reference](/docs/navixy-graphql-api/core-api-reference.md) 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](/docs/navixy-graphql-api/graphql-basics.md#type-syntax).

## Other ways to explore the API

* [GraphQL Sandbox](https://api.navixy.dev/v4/graphql/sandbox): Run queries and mutations interactively.
* [Public GraphQL schema](/docs/navixy-graphql-api/developer-resources/public-graphql-schema.md): The full type system split into several files.
* [Introspection](/docs/navixy-graphql-api/graphql-basics.md#introspection): Explore the schema from your own GraphQL client.

## See also

* [Tracking overview](/docs/navixy-graphql-api/tracking/overview.md): What Tracking covers and how its concepts fit together
* [Tracking guides](/docs/navixy-graphql-api/tracking/guides.md): A live fleet map and a vehicle trip history, built from these operations
* [Error handling](/docs/navixy-graphql-api/error-handling.md): Understand error structure, codes, and common error scenarios


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://navixy.com/docs/navixy-graphql-api/tracking/api-reference.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.