Architecture overview

Last edit: 2026.11.05

This page shows how TomTom’s NDS.Live services fit together: the Smart Layer Tile Services that deliver the content, the NDS.Live Registry that your map data component uses to find them, and the two setups your integration can run in. It ends with the essentials for your integration.

How the pieces fit together

Solid arrows are requests from your map data component, and dashed arrows are the responses.

Smart Layer Tile Services

Each service delivers one package as tiles. These are the services for map content and their update frequency as of October 2026:

ISA — weekly
ADAS Road Model — weekly
Navigation — weekly
Lane Model — monthly

Lane data isn’t only in Lane Model: ADAS Road Model and Navigation contain lane data too, which is updated with their roads. TomTom is working on shorter cycles for all packages.

TomTom provides a Smart Layer Tile Service for each supported map configuration. The service is described in the OpenAPI format and exposes methods for downloading tiles, such as getLayerByTileId and getHeaderOnlyByTileId, and metadata methods, such as getSpatialExtent and getServiceNodeLegalInfo.

NDS.Live Registry

The NDS.Live Registry is a discovery service. It holds the metadata describing which Smart Layer Tile Services exist and what each one contains.

Your entitlements decide which of these services your map data component can use, and the registry returns only those. In an automotive deployment, your vehicles don’t use a TomTom API key. Your authorization service issues a short-lived JWT token to each vehicle. TomTom’s access control system (ACS) reads the token’s entitlements and selects the API key for the right maps.

This affects how you design your integration:

Your map data component finds its services in the registry. It asks the registry which services are available and picks the ones that fit its use case, by the layers and module versions the registry lists for each service. Because the registry provides the endpoints, you don’t have to hardcode them, and they can change without an update to your map data component.
Your map data component can fail over to another endpoint. The registry lists alternative Smart Layer Tile Service endpoints, so when one fails, it can switch to another.

Map data component setup

Your map data component is the part of your integration that communicates with TomTom’s NDS.Live services and prepares the map data for your features. Drivers don’t interact with it directly. It runs in one of two setups:

Cloud-to-device setup — the map data component is part of the software on your devices, such as your vehicle software, which calls the services itself
Cloud-to-cloud setup — the map data component runs in your cloud backend, which calls the services and serves your vehicles

Map layer alignment

Your map data component has to place the layers it gets from other services, such as traffic, on the right roads of your map. This is called location referencing. A layer refers to roads in one of two ways:

Direct references point to a road by its feature ID in the same tile, for example from a road’s attribute to another road in the tile. Your map data component resolves them within the tile. They’re fast to process and always match.
Indirect references identify a road by its road location ID or by its geometry. A layer uses them for roads that aren’t features in its own tile, for example roads in another tile, or roads of a map compiled separately. Your map data component matches them to a road in your map.

If your map data component uses layers with indirect references, it implements the matching that these layers need: by road location ID, by geometry, or both.

Module updates

Your map data component decodes the responses from TomTom’s services using zserio code. This code is generated from a specific fixed version of each NDS.Live schema module. Vehicles stay on the road for years, so the code in your vehicle software can be several versions old. When the NDS Association releases new module versions, older map data components must still be able to read the data, so that they keep getting map updates without a software update.

If your map data component uses the TomTom Navigation SDK for Android or iOS, the Navigation SDK handles module versions for you, as described below. If your map data component doesn’t use the Navigation SDK, it has to do this itself.

On an existing endpoint, TomTom rolls out only compatible module versions. A breaking module version always comes with a new endpoint, which has a new node ID. So a map data component that works with an endpoint keeps working with it.

The Smart Layer module and each layer carry a module version label: the current version of their module and a minVersion. The minVersion value is the oldest version of that module whose zserio code can still read them. The Smart Layer module is the container that holds the layers, and the data of each layer follows a content module, such as ROAD or LANE.

Your map data component sees these module version labels in the NDS.Live Registry, before it calls any service. For each service, the registry response gives the label of the Smart Layer module and the labels of all the layers. Two methods return the same labels, so it can check them again after it selects a service:

getServiceModuleDefinition returns the label of the Smart Layer module.
getServiceDefinition lists the labels of all the layers of a service.

To ensure smooth operation as new versions come out, your map data component must:

Check the minimum version.
Your map data component checks the Smart Layer module first, then each layer. For each, it checks two conditions: the version of its zserio code is the same as the minVersion or later, and the version of the data is the same as the code’s own minimum version, MIN_VERSION in the generated code, or later. If both are true, your map data component can read it. If it can’t read the Smart Layer module of a service, it drops the service during selection. If it can’t read a layer, it skips the layer.
Handle several attribute layers of the same type.
A service can deliver more than one attribute layer of the same type, each with its own minVersion.
Merge the layers it can read.
Your map data component must combine all attribute layers of one type that pass the version check.

For example, version 2026.09 of a module adds an attribute. TomTom delivers it in an additional attribute layer with minVersion 2026.09, next to the existing layer. In a cloud-to-device setup, vehicle software built on an older version skips the new layer and keeps using the existing one. Newer vehicle software reads both layers and gets the new attribute too.

Integration essentials

Never hardcode an API key in a vehicle or a shipped map data component. You can only replace a hardcoded key with a software update to every copy of your map data component that has it, so you can’t rotate or revoke it quickly. Evaluation keys are fine to use from your own computer. For anything you ship, serve keys from a system that can issue, rotate and revoke them.

Put an account and API management layer in front of the services. Design it for security and scale, so that it prevents incorrect use of entitlements and licenses and protects API performance.
Keep your request rate reasonable. Endpoint capacity is shared. When the TomTom API gateway limits your requests, it returns 429: back off and retry.
Define a tile download strategy. Balance performance against over-the-air data use, based on how updates reach your map data component.
Use the NDS.Live Registry. It lets your map data component find its services and fail over between endpoints.
Call the methods at the service URL. The openapi.json file describes the methods of a service for you and your tools. Your map data component doesn’t read it at runtime: it replaces /openapi.json with the method name. Build it once, with code you generate from the NDS.Live schema, because generic OpenAPI client generators don’t support zserio.
Handle node ID changes. A node ID changes only when TomTom retires a service. From then on, the old service returns 410. Discard the data your map data component got from it, and ask the NDS.Live Registry for the new service.
Follow the module update strategy. NDS.Live modules get new versions as the specification evolves, and your map data component has to handle several module versions.