What is the TravelTime Data API?

Introducing the TravelTime Data API: the location data layer for AI, search and analytics

The TravelTime Data API seven layers of location data — places and points of interest, public transport, roads, open spaces and land cover, population, administrative boundaries, and neighbourhood environmental signals. And introduces two new endpoints dedicated to supporting smarter interpretation of your data: custom scoring and proximity.

The TravelTime Data API has full coverage in 33 countries and public transport in a further 95, all on the same H3 grid. It is a data layer built to be stored, joined and aggregated, and it is included with a TravelTime licence.

For existing customers, it’s already enabled. If you’re not a customer, create a free TravelTime account to get started.

What problem does the Data API solve?

Most location questions are not just "where is this address?" but "what is here, and who can reach it?". While the first can be achieved with geocoding, the second question means holding several different datasets — the places in an area, the transport serving it, the people living there, and the boundaries you have to report against.

For businesses, there are typically two problems when finding vendors to answer these questions:

Unscalable licensing and pricing models

Many places and POI APIs are built to answer one query at a time, and their terms typically restrict what you can cache, store or feed into a model.

That makes them hard to scale. If you can’t store results, the vendor makes a poor fit for jobs like scoring ten thousand catchments for nearby amenities, pre-computing journeys, and building the data into large-scale, repeatable analysis.

Per-request pricing breaks down in the same way. When every call carries a cost, the bill grows with every test, every backfill and every user. Experimenting gets expensive, and teams start rationing requests instead of building the feature properly.

The TravelTime Data API is included with a TravelTime licence, and the data is yours to store, join and reuse. You can build, test and scale without watching a meter.

Data silos

The second challenge is data silos. Too often, building a location product means stitching together POI feeds, transport files, census tables and boundary shapes, each with its own format, licence and refresh cycle.

Finding and downloading the right data is one challenge. But reconciling that data and doing it for every new market is often a much bigger one.

The Data API does that reconciliation. Every layer sits behind one API on the same H3 grid, so one cell ID works across all of them, and you can query and join the layers without new plumbing.

Pair it with other TravelTime APIs and those same cells describe a travel time catchment. That’s ready for catchment analysis and for scoring based on real accessibility, not a radius ring.

What data does it include?

The TravelTime Data API gives you access to several layers of data, each rebuilt per country from source on a fixed cadence. There are seven data layers that say what is in an area, and two pre-built to support better scoring and proximity analysis.

Discover the TravelTime Data API docs for a full overview.

Places

Points of interest matched across Foursquare, OpenStreetMap and Overture, plus national government registers, in a 16-group taxonomy. Read more on what a POI database is and how it can be used.

Public transport

Stations and stops, the lines that serve them, and service frequency, with counts per H3 cell by mode.

Roads

Major roads, one row per direction, and the entries and exits on each.

Boundaries

Administrative areas from the smallest local area up to the country, with the cells that make up each one. Browse the tree, ask any division for its H3 cells and feed those into any other layer — this is how you could get "population and pharmacy count for every ward in Greater London" without holding a shapefile.

Demographics

Population per H3 cell, plus census fields for residents, households, age, renting, cars and income.

Neighbourhood

Noise, air quality, flood risk, crime, deprivation and broadband per H3 cell, currently live in 6 countries — Australia, France, the Netherlands, Spain, the UK and the US.

Open spaces

Named parks and other open spaces, like beaches, playgrounds and green cover for each H3 cell.

Proximity

Walk, transit and drive ratings from 0 to 100, and travel times of up to 15 minutes to everyday places.

Custom scores

Score up to 1,000 locations, or find every cell that passes, against up to 50 checks you define.

Built for multiple industries and roles

By role

• Product and engineering teams building location features into apps, portals and marketplaces.
• Data and analytics teams who want a clean, joined location base.
• Search teams grounding answers about places in real data.
• AI teams that need smarter location reasoning and context.

By industry

• Property portals: what's nearby, transport, green space and area data on every listing.
• Site selection, retail and commercial real estate: catchment population, competition density, footfall drivers and access.
• Location intelligence and analytics: every layer on one grid.
• Travel and hotel search: places and parks within reach of a stay.
• Public sector and research: demand, deprivation and access by area.
• Logistics: territory planning and stop enrichment.
• Network adequacy: reporting that proves what share of a population can reach a provider inside a time standard.
• AI: grounded context for AI features, where a model describing a neighbourhood works from measured counts instead of a plausible guess.

How do you query every layer?

You can query the Data API in several access patterns, and the response envelope is the same for every layer.

• By coordinates: near with radius_m (up to 50 km), bbox for a box, or at for the H3 cell around a point.
• By H3 cell: cells, up to 100,000 cells, at resolution 9 unless set otherwise. One cell id works across every layer.
• By travel time: get the cells reachable in a set time from the TravelTime H3 API and send them as cells.
• By area: there is no polygon or borough parameter. Send an area as cells, a box or a radius, and use group_by to roll results up to a boundary type or one total.
• Geohash: grid=geohash (precision 6 or 7) returns places on a geohash grid instead of H3, on /v1/places and /v1/places/cells.
• Output: JSON or GeoJSON, with cursor-based paging of up to 10,000 rows.

How is the data quality assured?

Every check is visible in the data, so you can inspect it rather than take it on trust. Find out more on how we verify places here.

Matching across sources

Places are built from Foursquare OS Places, OpenStreetMap and Overture Maps, matched on name, location and category. Each place shows which sources list it in listed_by, and you set the bar with min_sources, from one source up to all three.

Verification against official registers

Where an official register exists, such as food hygiene inspections, health providers or schools, matched places are marked verified and the confirming registers are listed in verified_by. Add verified=true to return only confirmed places.

Published match accuracy

For each register, a random sample of matches is checked to confirm each pair is the same place. The share judged correct is published with a 95% interval on the coverage page.

Versioned, monthly updates

Each country’s data is updated about once a month and replaced in full, so old and new data never mix. Key your cache on the catalogue’s updated_at date. Place IDs change with each update, so re-resolve any you store, while other IDs stay stable.

Places data built differently, by design

We’ve built the Data API differently from many places or POI vendors. Our research with customers showed that most teams don’t need full business listings, so we’ve left some things out on purpose.

It’s worth knowing before you design around it:

• No business information: no phone numbers, opening hours or reviews. It is a places layer, not a business-information service.
• No real-time signals: nothing models "open now" or "busy right now".
• No address-level resolution: one point per place, a centroid or representative point, not unit-level granularity.
• No private or paywalled sources: everything traces to a publicly redistributable source, which is what keeps the licence position clean.
• No drift detection: if a café closes and a barber opens at the same address, the data reflects what the sources say at the next rebuild. Cross-validation proves that sources agree a place exists, not that it is trading today.

Working with other TravelTime APIs

This is the part that is hard to assemble from separate vendors. TravelTime's H3 API (POST /v4/h3/fast) returns a travel time catchment as a set of H3 cells. The Data API takes H3 cells. So the two compose directly:

1. Generate the area reachable in 30 minutes by public transport from a site
2. Take that catchment's cells
3. Ask each data layer what those cells contain — the population, the competing stores, the share of green space, the wards it overlaps

The result is a description of a reachable area rather than a radius, in one workflow, without a spatial join in the middle. Radius-based analysis is the thing everyone does because the data made it easy; travel time is the thing that reflects reality.

Getting started

The Data API is available now.

1. Get your credentials. Create a TravelTime account and find your application ID and API key on the dashboard. If you already use the TravelTime API, the same pair works for the Data API.
2. Set your headers. Send X-Application-Id and X-Api-Key with every request to https://data.traveltimeapp.com.
3. Make your first request. Each result comes back with a name, category, location, verified flag and H3 cell. That cell is on the same grid as every other layer.
4. See what’s available. Call /v1/catalog/{country}, for example /v1/catalog/gb, to list the datasets for a country and when each was last updated. Call /v1/categories to browse the place taxonomy.
5. Go further. Read the Data API docs for every endpoint, including how to pass a travel-time catchment as H3 cells.

Frequently asked questions

Which countries does the TravelTime Data API cover?

Full data in 33 countries, with public transport in a further 95. Neighbourhood data covers 6 countries and proximity 9. /v1/catalog lists coverage per country or visit the Data page.

Where does the POI data come from?

Foursquare Open Places, OpenStreetMap and Overture, matched into one record per place, with government registers overriding them where one exists for that category.

Can I store the data?

Yes. It is built to be stored, joined and aggregated. Place IDs change with each update, so re-resolve any you store, while other IDs stay stable.

Can I use it with the TravelTime API?

Yes. The Data API uses the same H3 grid as the TravelTime H3 API, so reachable cells pass straight into any layer.

Does it include opening hours, phone numbers or reviews?

No, by design. Those attributes go stale fastest and carry the heaviest licence restrictions.

Are there rate limits?

Yes. 120 hits per minute per application across all Data API endpoints, with higher limits available on request.

How is the Data API priced?

The Data API is included with a TravelTime licence on fixed-cost plans. The price is customised to your business based on capacity and service needs.