The API is exceptionally performant. Our protocol buffers service offers the highest levels of performance, and is able to calculate 100,000 travel times in under 150ms.
Test the performance for yourself using our benchmarking tool.
We continually benchmark our models against the results from other leading routing providers, to ensure that they match up as closely as possible.
We’ve built a drive time comparison tool to allow easy comparisons to be run vs Google, TomTom, HERE, Mapbox, and others.
The API is built to support the largest applications in the world. We offer licences able to support tens of thousands of requests per minute, and billions of elements per minute.
Our highest performance endpoints for calculating travel times (/time-filter/fast and Protocol Buffers) can take up to 100,000 locations per request.
Our H3 and Geohash services are able to calculate travel times to several hundred thousand cells in a single request.
We have an extensive set of mature SDKs, each supporting the full range of endpoints and parameters available through the API.
We also have supported integrations for Elasticsearch and Solr.
We offer licence packages that allow for caching, in accordance with our Terms of Service.
We never offer transactional pricing models. Our licences always offer unlimited usage of the API for a fixed annual cost. So we never charge you based on the number of requests you make.
A variety of factors influence the overall response time of a particular request. The highest performance is available through the /fast endpoints and the Protocol Buffers service.
When not either of these options, the parameters that have the biggest impact on performance are:
- Travel Time* - longer travel times mean a larger area to traverse
- Range - applying a range to public transport arrival or departure times increases the search space
- Level of Detail - a higher level of detail means more coordinates being returned per isochrone
*When using the /time-filter endpoint, the value of the travel_time parameter in the request has more impact on the response time than the actual travel times returned. So using a value that is much longer than is required for the desired calculations will have an unnecessary impact on performance.
Each core service (/time-map, /time-filter, /h3, /geohash) supports a high performance version (/fast). These endpoints are recommended for any use case where performance is a key consideration, as they can be up to 10x faster depending on the exact parameters. The fast version of the /time-filter endpoint also supports a much larger request size (100,000 locations vs 2,000).
The /fast endpoints come with a few restrictions to be aware of when choosing whether to use them or not:
- Available in the core countries listed here
- No support for cross-border journeys (or journeys that cross state borders in the USA)
- Two traffic models (peak and off peak) as opposed to any specific arrival or departure time
- Lower maximum travel time (3 hours instead of 4 hours)
- Fewer detailed public transport parameters (such as the maximum walking time)
All of our endpoints are synchronous, but the majority of our SDKs offer asynchronous functionality.
Travel times are calculated using our own proprietary models and algorithms.
The driving model takes a wide range of data sources and uses statistical modelling techniques to reflect the drive times from representative samples of routes from other leading providers.
The public transport model uses real published timetables that are collected / cleaned / consolidated / updated by our dedicated team of data scientists.