Which API should I use for search?

TomTom offers two APIs for searching places. If you are starting a new integration, use the Places Search API. If you already use the Search API, it is generally available and fully supported — there is no need to migrate to keep working.

Three reasons we recommend the Places Search API for new integrations:

• It is built on TomTom Orbis Maps, the new generation of our map data.
• Its session model matches how people actually search, typing and refining rather than issuing one isolated query.
• New search capability lands there.

The table below describes the Search API on TomTom Maps. There is also a Search API edition on TomTom Orbis Maps, which is in public preview and is documented separately.

At a glance

The difference in practice

The Places Search API models a search as a session. A session most often starts with suggest as the user types, then resolves to discover for deeper results or details for a single place. It does not have to start there: a session can begin at discover, bypassing suggest altogether — as an agentic or voice application would — and a favorite or a map pin can be resolved directly through details. The API keeps the context of the session, so later calls are informed by earlier ones rather than starting cold.

If your integration follows a typical flow such as suggestions-as-you-type, select a suggestion or hit the search button for deeper results, view details of a place, refine the search, and so on, then the session model of the Places Search API is the best choice.

The Search API gives you one endpoint per search type. You choose the endpoint that matches the job — fuzzy search, category search, nearby search, geometry search — and each call stands on its own.

Before you choose

Places Search API does not yet support along-route search. If your integration depends on it, the Search API remains the right choice for now.

Next steps

• Places Search API — Introduction
• Places Search API — Quick Start Guide
• Search API — Introduction