TomTom Orbis APIs are now in general availability

Six newly built APIs on Orbis Maps, designed for API-first use and agent-based access.

[Co-authored by: Alice Rouquette, Ruben Woelders, and Ashay Vishnoi]

Developers today are building for two consumers of APIs: applications and AI agents. Both need location intelligence, yet working with location data presents a familiar set of challenges:

• Multiple services with inconsistent schemas and authentication models

• Proprietary rendering stacks that limit flexibility

• AI agents struggling to reliably discover and call geospatial services

Today, six new APIs built on Orbis Maps are generally available, giving developers direct access to core mapping, routing, traffic, search and geocoding capabilities through a unified platform. They are Map Display, Traffic, Routing, Places Search, Geocoding and Reverse Geocoding APIs. Orbis is TomTom's modular map built for incremental updates and extensibility, and it is a location platform built from the ground up for modern application development and agentic workflows.

The rise of AI-native applications changes how APIs are consumed. Increasingly, developers are not only integrating services directly, they are exposing them to agents that discover, reason over and invoke APIs autonomously. That requires consistent schemas, machine-readable specifications and predictable interfaces. Orbis APIs are designed with those requirements from the start.

The six APIs share one foundation, Orbis Maps, one set of conventions, and come with a Maps SDK for JavaScript and a TomTom MCP Server.

What's in general availability today

Routing API. Traffic-aware car routes with up to 150 waypoints per request (more than any other provider). Fastest, shortest, thrilling and most efficient route types, alternatives, avoidances, and time-based planning .

Map Display API. Vector and satellite tiles for web and mobile, with multi-language labels and multiple styles. 23 zoom levels (0 to 22), and MapLibre compatibility out of the box.

Traffic API. Real-time flow and incident tiles plus per-incident detail, refreshed every 30 seconds from more than 5 billion kilometers of driving data processed each day, across 80+ countries. Overlay it on Map Display tiles or use it on its own.

Geocoding API. Turns full or partial addresses into coordinates, tolerant of typos and incomplete input, with structured JSON output.

Reverse Geocoding API. Turns coordinates into structured, human-readable addresses.

Places Search API. Built on three endpoints: discover (fully resolved results from complete input), suggest (as-you-type suggestions) and details (full information for a POI).

All six APIs run on Orbis Maps and share the same conventions: Orbis map data, OpenStreetMap and MapLibre compatibility, REST delivery, JSON responses, and GeoJSON-compatible geometry. Each API works on its own, and they are built to work together.

A note on scope: this first GA wave covers car routing and consumer and analytics use cases. Truck and other vehicle modes, batch routing and a few advanced capabilities are not in General Availability scope yet. Where you need them today, the existing TomTom Maps APIs stay available until the Orbis APIs reach parity, with migration guides available in the docs for each API product.

What actually changed

These are not the existing TomTom APIs pointed at a fresher map. They are a new API surface built on Orbis Maps, and three things changed underneath.

New endpoints and schema: Apart from moving the APIs to new paths, we restructured them completely, so each URL reflects the resource being retrieved, which keeps the logic easy to follow for developers and AI agents alike.

Map Display now treats vector and raster as separate resources rather than variants of one, with tile at the end as the resource and {zoom}/{x}/{y} as its identifier:

GET /maps/orbis/display/raster/tile/4/33/82
GET /maps/orbis/display/vector/tile/4/33/82

Places Search replaced a constellation of mode-specific endpoints (fuzzy search, POI search, nearby search and more, each forcing you to pick the right one up front) with three actions that follow how people actually search:

GET /maps/orbis/places/suggest   # autocomplete as the user types 
GET /maps/orbis/places/discover  # find places matching criteria 
GET /maps/orbis/places/details   # retrieve details for a specific place 

Each action maps to a step in the search flow, organized around the user journey instead of our internal taxonomy. The underlying data model is new as well, different from the previous TomTom schema. If you are migrating from previous TomTom APIs, start with the migration guides in the docs.

Open data at the core: Orbis combines open data with TomTom's proprietary content (address points, speed limits, traffic restrictions, speed profiles and traffic signs) across 235+ countries and territories. Its data model follows the schema from the Overture Maps Foundation, an open mapping standard co-developed by TomTom, Amazon, Meta and Microsoft under the Linux Foundation, together with OpenStreetMap data. For you, that means the schema is open and shared across the industry, so the integration patterns and tooling you build stay portable and work with common open-source GIS tools, rather than being tied to a proprietary format.

Fresh data as the differentiator: Open map data provides the foundation. Fresh proprietary content, traffic intelligence and real-time updates provide the operational advantage:

• Map content updated weekly

• Traffic flow and incidents refreshed every 30 seconds

• More than 5 billion kilometers of driving data processed each day

Two design decisions that matter

Beyond the map underneath, two decisions shape what it is like to build on the portfolio.

Every Orbis API shares one surface, so the patterns you learn on your first call carry to the rest. All APIs live under the same base path and take the same two headers, TomTom-Api-Key and TomTom-Api-Version. The key moves out of the URL because a query string is an unsafe place for credentials, where they leak into logs, history and referrers. The version, which previously lived in the path, moves to a header to separate a resource's identifier (its URL) from its representation (the API version): version changes no longer break permalinks, and the format stops drifting across APIs (1 versus v1 versus 1.0).. Two different APIs end up looking almost identical to call:

# Geocoding — address to coordinates 

curl "https://api.tomtom.com/maps/orbis/places/geocode?query=Rembrandtplein,Amsterdam" \ 

  -H "TomTom-Api-Key: YOUR_API_KEY" \ 

  -H "TomTom-Api-Version: 2" 

  

# Reverse Geocoding — coordinates to address 

curl "https://api.tomtom.com/maps/orbis/places/reverseGeocode?position=4.8952,52.3702" \ 

  -H "TomTom-Api-Key: YOUR_API_KEY" \ 

  -H "TomTom-Api-Version: 2"

The same conventions repeat everywhere:

a. An Attributes (and Attributes-Exclude) header lets you declare exactly which fields come back, with identical syntax across every API. That is a deliberate design choice with two payoffs: integrations stay stable, because you receive only the fields you asked for and never inherit fields added in a later release. Both computation and payload shrink, since the service only builds and returns what you requested. On Routing, that can be the difference between a response of a few hundred kilobytes and one of a few hundred bytes.

b. Errors follow one contract too: 400, 403 and 429 carry the same meaning and return the same detailedError object, so the error handling you write once works portfolio-wide.

c. Content negotiation follows the HTTP standard rather than a custom scheme: you ask for a representation with the Accept header and the API answers with a matching Content-Type. It's the same mechanism your HTTP tooling already speaks, so there are no format flags in the query string and nothing per-API to memorize.

d. Field names also carry their units. A distance is distanceInMeters, not distance; a duration is durationInSeconds, not time. The unit lives in the name, so there's no cross-referencing the docs and no unit-mismatch bugs surfacing in production, and it's less context for an AI agent to load, since the field tells the model what it holds without a lookup.

e. Geometry is shared too. Coordinates are always GeoJSON, longitude first, in requests and responses, so nothing gets reordered as data moves between services. That is what lets the APIs compose without glue code:

• Geocoding returns a position you hand straight to Routing as a waypoint.

• A Places Suggest result carries a place id that drops directly into Details — the response even embeds the follow-up request for you.

• Reverse Geocoding takes the same [longitude, latitude] your tracking feed already emits and returns a structured address.

f. Each API publishes an OpenAPI spec in the API Explorer section of its docs (for example, the Map Display spec), with the equivalent for every other product. Generate a typed client for one API and the same tooling works for the next, and automated checks against those specs keep naming, parameters and errors aligned as the platform evolves. Learn one API and the others follow the same patterns, which cuts the integration and debugging time that usually comes from reconciling mismatched formats.

2. Fast integration through a shared SDK. The Maps SDK for JavaScript wraps the portfolio behind one TypeScript-first interface. It runs in the browser, on Node.js and in React Native, and is built on MapLibre and GeoJSON, so rendering stays open and you are not locked to an engine you don't control.

Displaying an Orbis map takes a few lines:

import { TomTomConfig } from '@tomtom-org/maps-sdk/core'; 

import { TomTomMap } from '@tomtom-org/maps-sdk/map'; 

  

TomTomConfig.instance.put({ apiKey: YOUR_API_KEY }); 

  

const map = new TomTomMap({ 

  mapLibre: { container: 'map', center: [4.8952, 52.3702], zoom: 12 }, // Amsterdam 

});

From there, Search, routing and live traffic return the same SDK:

import { PlacesModule, RoutingModule } from '@tomtom-org/maps-sdk/map'; 

import { search, calculateRoute } from '@tomtom-org/maps-sdk/services'; 

  

const places = await PlacesModule.get(map); 

places.show(await search({ query: 'coffee' })); 

  

const routing = await RoutingModule.get(map); 

routing.showRoutes(await calculateRoute({ 

  locations: [[4.8952, 52.3702], [4.9, 52.35]], 

})); 

The SDK is free to download and use (currently in public preview); MapLibre stays a peer dependency, and you pay only for the API usage underneath. Routing now returns GeoJSON rather than encoded polylines, so route geometries render natively in MapLibre, Leaflet or any GeoJSON-aware library, with no decoding step. For teams that already buy TomTom routing, traffic or geocoding but render the map with a second vendor, the SDK lets you consolidate on data you already trust.

Agentic access

More and more, what calls these services is an AI agent alongside integrations that developers build. An agent decides at runtime which service to call, and it reasons from the specification instead of asking a teammate what a parameter means. We made extensively documented OpenAPI Specs so it can be used by toolings, including AI agents, to ease integration with our APIs.

On top of that, Model Context Protocol servers expose the platform to any MCP-compatible agent:

The TomTom Maps MCP Server exposes the full Orbis portfolio (map display, routing, search, geocoding and traffic) through a single integration, so an agent reaches routing, search, traffic and geocoding without a separate connector for each.

In an MCP-enabled host, a request looks like this:

"Show me coffee shops within a 10-minute drive of Piccadilly Circus, and avoid any congestion."

The agent resolves the location, calls Routing for drive-time reachability, searches POIs inside that area and checks live traffic, across multiple Orbis APIs, through one integration, with no glue code.

MCP suits end-user-facing AI surfaces that answer natural-language queries, such as a chat assistant or an in-app copilot that picks and calls services for the user., However, if you are integrating a single API into your own code, often with a coding agent, the better tool is the OpenAPI specification. We publish the full spec for each API in the API Explorer section of its documentation, so you can point your model straight at it. That gives the model the complete contract (endpoints, parameters and response shapes) instead of leaving it to infer behavior from documentation.

What you can build with it

A few things our teams have built on the portfolio:

• API playgrounds. Try the Routing playground. No key, no setup. More playgrounds based on Traffic and Places Search are coming soon.

• Demo: Routing API playground
  

• Site selection agent. Feed in a GeoJSON area and ask where to open next. The agent pulls POIs to assess competition and uses drive-time reachability to score locations.

Each uses the latest Orbis APIs, reached through the SDK and MCP.

What's next

This is a starting point. Over the rest of 2026 we will continue to add more capabilities and expanding the agent tooling. The changelog in the docs tracks each release.

Get started