June 1, 2026 · 8 min read

Travel data isn't places data: 5 axes where general-purpose POI APIs miss

Google Places is a great places API. So is Foursquare's premium product, and Mapbox, and Apple's. They are not travel APIs. The distinction matters because the things travelers ask are exactly the things places APIs aren't shaped to answer.

1. Sequence

A places API returns a set. The world's pizza places, ranked by distance. Twenty hotels near a hotel. A travel itinerary is the opposite — an ordered list. Day 1 here, Day 2 there, with the transition between them mattering as much as the stops.

"Show me the Buddhist Circuit" is not a set query. It's a path query. The order is the thing. Places APIs that paper over this with tags ("buddhist", "pilgrimage") lose the structure of the journey. The user's chatbot then invents the order, badly.

2. Admin context

Travelers care about administrative geography in ways that locals don't. A San Franciscan ordering coffee doesn't think about which county they're in. A traveler planning a week in Rajasthan wants to know which state, which district, which region — because permits, transport, food, language, and weather change at those boundaries.

Places APIs typically expose a flat city + country pair, sometimes a state. They rarely expose district, sub-region, or the gazetteer relationships that travelers actually use to make decisions. A travel-shaped API treats admin hierarchy as a first-class join.

3. Regulatory layer

Travel is regulated in ways places aren't. Some destinations require inner-line permits. Some are restricted to nationals of certain countries. Some are e-visa-eligible from one country and not from another. Some have transit rules that change seasonally.

None of this surfaces in a POI API. A traveler asking "can I visit Tawang next week" needs answers to questions a coffee-shop API has no reason to model. A travel API that doesn't model the regulatory layer is going to send your chatbot's users to places they can't legally enter.

4. Heritage status

A monument is not just a location. Its status — UNESCO inscribed, nationally protected, state-listed, locally maintained — changes how travelers should plan around it. A UNESCO site has stricter visitor rules, often longer queues, often a ticketing infrastructure that a nationally-protected monument doesn't.

Heritage flags also drive itinerary logic. "Top-tier monuments first, secondary sites in the gaps" is a standard tour-operator heuristic. Without structured heritage status, your chatbot collapses everything into "old building" and ranks them by review count, which is not how cultural travel works.

5. Circuit membership

The most under-modeled axis. Circuits — pilgrimage routes, food trails, hill-station belts, themed clusters — are real graph relationships in travel. The Krishna Circuit, the Sufi Circuit, the Jain Circuit are not loose collections. They have membership, they have ordering, they have narrative.

A places API has no concept of circuit membership because places are not in circuits — POIs are in cities, and cities are in countries. A travel API that doesn't model thematic relationships ends up answering "best food cities in India" with a global popularity rank instead of a regional cluster, which is what the user actually wanted.

What a travel-shaped API looks like

A travel-shaped API returns rows that already encode these axes. Each city carries admin attribution down to district. Each monument carries its heritage flag and inscription year. Each circuit returns a sequenced list of stops with notes. Each row carries license metadata. The endpoints are organized by what travelers ask, not what database tables exist: /v1/cities, /v1/monuments, /v1/circuits, /v1/stations.

None of this requires a fancy graph database or a novel data model. It requires somebody to decide that travel queries deserve their own shape rather than being squeezed into a places-shaped hole.

Why we focus on the five

These are the gaps where general POI APIs consistently fail travel-AI products. Sequence, admin context, regulatory layer, heritage status, circuit membership. Fix all five and your chatbot's accuracy on real travel queries jumps to a place where you can ship it. Fix none and you're back to apologizing to users for sending them to closed airports.

The right substrate is travel-shaped from row one.