> ## Content Index
> Fetch the complete content index at: https://blog.afi.io/llms.txt
> Use this file to discover other available public pages before exploring further.

# Mapping travel time with the Google Maps Isochrones API
- URL: https://blog.afi.io/blog/mapping-travel-time-with-the-google-maps-isochrones-api/
- Published: 2026-07-26T00:33:17.000Z
- Updated: 2026-08-21T05:08:37.000Z
- Description: A first look at the Google Maps Isochrones API. How it works, how to make your first call, and real world use cases in logistics, retail and more.
- Author: Afian Anwar
- Tags: googlemaps

An isochrone, from the Greek root words *iso* (equal) and *chronos* (time), is a line that connects points of equal travel time around a given location. In urban planning, they underpin ideas like the [15 minute city](https://www.15minutecity.com/?ref=blog.afi.io), where the aim is for residents to reach their daily needs within a short walk or ride. They also expose the opposite: the food deserts, healthcare gaps, and isolated communities where transit access falls short. In this tutorial, I'll show you how to use the [Google Maps Isochrones API](https://developers.google.com/maps/documentation/isochrones/overview?ref=blog.afi.io) for a wide variety of applications in last mile delivery, retail, real estate and more!

![](https://storage.ghost.io/c/c6/4d/c64da7e8-63a6-4cff-acdc-2782a6ebc377/content/images/2026/07/GoogleMap-Isochrone.png)

**Part 1: Mapping travel time with the Google Maps Isochrones API (this article)**  
Part 2: [How isochrones work: From shortest paths to polygons](https://afi.io/blog/how-isochrones-work-from-shortest-paths-to-polygons/?ref=blog.afi.io)  
Part 3: Build a travel time map using the Google Isochrone API

[Show how far you can travel from a point in a set amount of time using the Google Isochrones APIMapping travel time and reachability with the Google Isochrones API![](https://storage.ghost.io/c/c6/4d/c64da7e8-63a6-4cff-acdc-2782a6ebc377/content/images/icon/favicon-81ef9119-1a29-46f1-8fd3-abf8a8e18533.ico)![](https://storage.ghost.io/c/c6/4d/c64da7e8-63a6-4cff-acdc-2782a6ebc377/content/images/thumbnail/logo512-710ae97a-1495-49f2-a48b-afb0592a3427.png)](https://google-isochrones-demo.afi.dev/?ref=blog.afi.io)

### What is the Google Maps Isochrones API?

The [Google Maps Isochrones API](https://developers.google.com/maps/documentation/isochrones/overview?ref=blog.afi.io) calculates the area reachable within a specified amount of time from a location, and returns the reachable regions as contours of polygons or lines that you can display on a map. An isochrone doesn't answer "how far away is this?". It answers "what can I reach in a set amount of time". And because it follows the real road network instead of drawing a straight line radius, it captures the roads, highways, traffic patterns, and transportation modes that affect how long it takes to get somewhere.

![An isochrone around a location in downtown Vancouver](https://storage.ghost.io/c/c6/4d/c64da7e8-63a6-4cff-acdc-2782a6ebc377/content/images/2026/07/Screenshot-2026-07-23-at-9.33.56---AM.png)

An isochrone around a location in downtown Vancouver

Overlay that reachable area with data on jobs, population, or amenities and you get hard numbers: how many jobs someone can reach by bike in half an hour, or what share of households sit within a thirty minute drive from a popular school.

### Google Maps Isochrones API worked example

![](https://storage.ghost.io/c/c6/4d/c64da7e8-63a6-4cff-acdc-2782a6ebc377/content/images/2026/07/Screenshot-2026-07-24-at-12.16.48---AM.png)

30 minute driving isochrone generated by the Google Maps Isochrones API

Here's a quick example of a driving isochrone that starts from downtown Vancouver, BC.

**Endpoint** `POST` [https://isochrones.googleapis.com/v1/isochrones:generate](https://isochrones.googleapis.com/v1/isochrones:generate?ref=blog.afi.io)

**Headers**  
Content-Type: *application/json; charset=utf-8*  
X-Goog-Api-Key: *YOUR\_API\_KEY*

**Request Body**

```
{
  "location": {
    "latitude": 49.2768282,
    "longitude": -123.1090144
  },
  "travelDuration": "1800s",
  "travelMode": "DRIVE",
  "routingPreference": "TRAFFIC_AWARE",
  "enableSmoothing": true,
  "travelDirection": "FROM"
}
```

`location` is the coordinate `latitude` `longitude` pair around which to center the isochrone lines.

`travelDuration` is the time horizon for the isochrone calculation. The API supports a maximum travel time of 3600 seconds (1 hour) for the `DRIVE` mode, and 7200 seconds (2 hours) for the **"WALK"** and **"BICYCLE"** modes.

`travelMode` is the mode of transport used. It can be one of **"DRIVE"**, **"WALK"** or **"BICYCLE"**.

`routingPreference` controls how traffic data influences the generated polygon. 

- `TRAFFIC_UNAWARE` (default): Builds the polygon from speed limits and road hierarchy alone. The result is deterministic i.e. the same request returns the same shape regardless of when you send it, which makes it the right choice for baseline analysis and scenario planning.
- `TRAFFIC_AWARE`: Uses live and predictive traffic at the time of the request, so the reachable area contracts during congestion and expands off peak. Only available when `travelMode` is **"DRIVE"**.

`enableSmoothing` adds a purely cosmetic post processing of the isochrone boundary when set to `true`. It changes how the polygon *looks*, not what the routing engine computed.

![Smoothing vs Non Smoothing applied to the isochrone](https://storage.ghost.io/c/c6/4d/c64da7e8-63a6-4cff-acdc-2782a6ebc377/content/images/2026/07/image-10.png)

Smoothing vs Non Smoothing applied to the isochrone

`travelDirection` lets you find both the inbound and outbound reachability of the specified `location`:

- **"FROM"** (Outbound): Calculates the area reachable *from* the origin point within the specified time limit. This is suitable for use cases like delivery zones or service coverage.
- **"TO"** (inbound)**:** Calculates the area from which you can travel *to* the origin point within the specified time limit. This is suitable for determining catchment zones, like where employees can commute from to reach a central office.

![Inbound (red) vs Outbound (blue) isochrones for the same address](https://storage.ghost.io/c/c6/4d/c64da7e8-63a6-4cff-acdc-2782a6ebc377/content/images/2026/07/Screenshot-2026-07-24-at-11.46.45---AM.png)

Inbound vs Outbound isochrones for the same address

As the map shows, the two isochrones don't quite match. One-way streets, the placement of highway on-ramps and off-ramps, and real time traffic conditions all mean the route into a point isn't the mirror image of the route out.

**Response**

```
{
    "isochrone": {
        "geoJson": {
            "type": "MultiPolygon",
            "coordinates": [
                [
                    [
                        [
                            -123.04089955052466,
                            49.345896722245961
                        ],
                        [
                            -123.04388583603397,
                            49.345115056654834
                        ],
                        [
                            -123.04654204969817,
                            49.344082599800913
                        ],
                        //... Rest of coordinate array
                    ]
                ]
            ]
        }
    }
}

```

The API returns the isochrone geometry as a standard GeoJSON `MultiPolygon`. This is neat, because it means that you can drop the response straight into a Google Map out of the box. 

The [Maps Javascript API data layer](https://developers.google.com/maps/documentation/javascript/datalayer?ref=blog.afi.io) parses GeoJSON natively. It reads the `MultiPolygon`, handles the holes and disconnected pieces, and crucially takes GeoJSON's `[longitude, latitude]` axis order as is without having to reverse them (Google's own [LatLng object literal](https://developers.google.com/maps/documentation/javascript/examples/map-latlng-literal?ref=blog.afi.io) are latitude first). In a React app with the [@vis.gl/react-google-maps](https://visgl.github.io/react-google-maps/?ref=blog.afi.io) library, rendering the isochrone is as easy as calling `useMap()` to give you the map instance, and `map.data.addGeoJson()` to add the polygon vertices to the data layer.

```
/*** components/Isochrone.jsx ***/
import { useEffect } from 'react';
import { useMap } from '@vis.gl/react-google-maps';

export default function Isochrone({ geoJson, style }) {

  const map = useMap();

  useEffect(() => {
    if (!map || !geoJson) return;

    const layer = new google.maps.Data({ map });

    layer.addGeoJson({
      type: 'Feature',
      geometry: geoJson,
      properties: {},
    });

    layer.setStyle({
      fillColor: style.fillColor,
      fillOpacity: style.fillOpacity,
      strokeColor: style.strokeColor,
      strokeWeight: style.strokeWeight,
      zIndex: style.zIndex,
    });

    return () => layer.setMap(null);

  }, [map, geoJson, style]);

  return null;
}
```

Styling is done by passing a standard [google.maps.Data.StyleOptions](https://developers.google.com/maps/documentation/javascript/reference/data?ref=blog.afi.io#Data.StyleOptions) object into `layer.setStyle()`. Don't worry if you didn't catch all that. Sample working code is available in our [google\_isochrone\_sandbox](https://github.com/afilabs/google%5Fisochrone%5Fsandbox/?ref=blog.afi.io) repo on GitHub.

### Why choose the Google Maps Isochrones API?

[Mapbox](https://docs.mapbox.com/api/navigation/isochrone/?ref=blog.afi.io), [HERE Maps](https://www.here.com/learn/blog/introducing-the-new-here-isoline-api?ref=blog.afi.io), [TravelTime](https://docs.traveltime.com/api/overview/isochrones?ref=blog.afi.io), and the open source stack ([Valhalla](https://valhalla.github.io/valhalla/api/isochrone/?ref=blog.afi.io), [OpenRouteService](https://openrouteservice.org/example-apartment-search-with-ors/?ref=blog.afi.io)) have offered isochrones for years. So what makes the Google Maps Isochrones API special? Three things:

**Traffic aware isochrones**

![Real time traffic vs no traffic applied to the isochrone](https://storage.ghost.io/c/c6/4d/c64da7e8-63a6-4cff-acdc-2782a6ebc377/content/images/2026/07/image-8.png)

Real time traffic vs no traffic applied to the isochrone

Unlike Google, both Valhalla and OpenRouteService build on [OpenStreetMap](https://www.openstreetmap.org/?ref=blog.afi.io) road data, which means they calculate travel times from posted speed limits rather than actual traffic conditions. The difference matters. Imagine a real estate portal like [Zillow](https://www.zillow.com/?ref=blog.afi.io) or [Trulia](https://www.trulia.com/?ref=blog.afi.io) using isochrones to show what's within reach of a listing. A traffic unaware isochrone will overstate how accessible those amenities are, promising a 15 minute commute that takes much longer at peak hour.

**Data accuracy**

![](https://storage.ghost.io/c/c6/4d/c64da7e8-63a6-4cff-acdc-2782a6ebc377/content/images/2026/07/image-9.png)

The isochrone from the Google Maps Isochrones API compared to the Mapbox Isochrone API

Google has spent years building one of the strongest traffic and road datasets in the industry by combining anonymized location data from Google Maps users and Android devices with road network and live disruption feeds from transportation authorities and city governments. 

That data advantage shows up throughout the Google Maps APIs, which consistently return travel times close to what real drivers experience on the road at a given time of day. This means that an isochrone from Google reflects the roads people actually use and the speeds they actually travel at. If you are using an isochrone to decide where to buy a house, rent an apartment or build a new [Costco](https://www.costco.com/?ref=blog.afi.io), you'd want to use the API with the most accurate data. That means paying for the [Google Maps Isochrones API](https://developers.google.com/maps/documentation/isochrones/overview?ref=blog.afi.io).

**Features**

![](https://storage.ghost.io/c/c6/4d/c64da7e8-63a6-4cff-acdc-2782a6ebc377/content/images/2026/07/browser-window-6-hires.png)

The API gives you everything you need to build accurate, good looking isochrones in your app.

- It features three travel modes: `WALK`, `BICYCLE` and `DRIVE`,
- It lets you toggle between `TRAFFIC_UNAWARE` (free flow speed) and `TRAFFIC_AWARE` (real time traffic) settings,
- It lets you switch between `FROM` and `TO` travel directions to flip the question from "Where can I get to?" to "Who can reach me?".
- It also lets you smooth the isochrone's edges for a cleaner, less jagged shape and,
- It's fast. A 60 minute driving isochrone over a city like Vancouver comes back in 200 - 300 milliseconds.

That said, the Google Maps Isochrone API does have one major drawback. It does not support multi modal travel modes. For a hotel aggregator like [Booking.com](http://www.booking.com/?ref=blog.afi.io) wanting to show how well connected a property is by public transit, that rules the API out entirely.

### Comparing isochrone APIs

As I've noted in my previous posts on Google Maps recent push into [route optimization](https://blog.afi.io/blog/gmpro-google-maps-platform-route-optimization-api/) and [in-app navigation](https://blog.afi.io/blog/google-navigation-sdk-standalone/), Google has spent the last several years playing catch up. So how does the Google Maps Isochrone API compare to its competition?

| **Google**        | **Mapbox**  | **HERE Maps** | **TravelTime** |                |
| ----------------- | ----------- | ------------- | -------------- | -------------- |
| Transport Modes   | 🚙 🚶‍♂️ 🚲 | 🚙 🚶‍♂️ 🚲   | 🚙 🚶‍♂️ 🚲    | 🚙 🚶‍♂️ 🚲 🚌 |
| Max Travel Time   | 2 hrs       | 1 hr          | no cap         | 4 hrs          |
| Real Time Traffic | ✅           | ⛔️            | ✅              | ⛔️             |
| Travel Distance   | ⛔️          | ✅             | ✅              | ✅              |
| Contours Returned | 1           | 4             | no cap         | no cap         |
| Accuracy          | high        | very low      | low            | med            |
| Speed             | very slow   | slow          | med            | very fast      |
| Pricing model     | per req     | per req       | per req        | fixed          |

Google doesn't win on every metric. But the two I care most about are *accuracy* and *real time traffic*, and Google beats the market in both. When I show a user an isochrone, I want it to reflect what they'll actually experience on the road, and Google's data is what I trust to do that.

### Google Maps Isochrones API use cases

Isochrones show up more often than you'd think, anywhere the useful question is "what's reachable in a given time?" rather than "how far away is it?".

**Retail site selection**

![Using the Google Maps Isochrones API for site selection](https://storage.ghost.io/c/c6/4d/c64da7e8-63a6-4cff-acdc-2782a6ebc377/content/images/2026/07/image-14.png)

Using the Google Maps Isochrones API for site selection

One classic business problem isochrones solve is site selection: deciding where to open a new store so it reaches the most customers without cannibalizing existing stores. This is a `travel_direction=TO` use case.

The map above plots every Costco in Metro Vancouver alongside its 30 minute drive time isochrone. Costco has Vancouver pretty much covered (dark overlapping blue areas have more than one Costco within a 30 minute drive) except for the western tip around the [University Endowment Lands](https://maps.app.goo.gl/jjq1WNdY5LHAAavb7?ref=blog.afi.io).

**Real estate commute time search**

![Using the Google Maps Isochrones API for real estate search](https://storage.ghost.io/c/c6/4d/c64da7e8-63a6-4cff-acdc-2782a6ebc377/content/images/2026/07/image-13.png)

Using the Google Maps Isochrones API for real estate search

Say you teach at the [University of British Columbia](https://maps.app.goo.gl/VKMVkoBGzLb9PZgt9?ref=blog.afi.io) and your partner is a doctor at [Vancouver General Hospital](https://maps.app.goo.gl/1sKUVL66JT673r5U8?ref=blog.afi.io). You both bike to work and want to keep each commute under 30 minutes. Where should you live? Draw a 30 minute bike isochrone around each workplace and the overlap appears immediately - right along the border between Kitsilano and West Point Grey. Choosing `travel_direction=TO` or `travel_direction=FROM` doesn't really matter here. Bike isochrones look nearly the same in both directions because cycling routes are usually bidirectional and bike speed barely responds to traffic.

**Logistics delivery zones**

![DoorDash uses the Google Maps Isochrones API for to set up delivery zones](https://storage.ghost.io/c/c6/4d/c64da7e8-63a6-4cff-acdc-2782a6ebc377/content/images/2026/07/Screenshot-2026-07-25-at-3.23.56---PM.png)

DoorDash uses the Google Maps Isochrones API for to set up delivery zones

Logistics providers often use isochrones to determine whether an address falls within a service area.

In Vancouver, [Loblaw](https://www.loblaw.ca/en/home/?ref=blog.afi.io), one of Canada's largest grocery chains, runs a rapid grocery service called [PC Express Rapid Delivery](https://www.pcexpress.ca/rapid-delivery?ref=blog.afi.io) in partnership with [DoorDash](https://www.doordash.com/?ref=blog.afi.io), with delivery in as little as 30 minutes ([Bringing on-demand groceries to 8 million Canadians, Oct 2025](https://www.loblaw.ca/en/bringing-on-demand-groceries-to-8-million-canadians/?ref=blog.afi.io)). Behind that speed sits a network of dark stores (see map above). These delivery-only fulfillment centers allow couriers pick up pre-packed orders and deliver by e-bike to skip the parking that slows cars in the urban core.

Dark stores are the textbook `travel_direction=FROM` use case. DoorDash's real question is "how many customers can we *reach* within a 30 minute delivery window," which is a 30 minute isochrone around the store. On the PC Express Rapid Delivery site, customers must enter their delivery address before they can add anything to their cart. This lets the service check whether the address is close enough to a dark store to reach the customer within the advertised delivery window.

### Google Maps Isochrones API pricing

The Google Maps Isochrones API is free to use while it's in Preview. Google hasn't announced a GA rate yet, so any figure is guesswork. But for a rough sense of the market, Mapbox's comparable [Isochrone API](https://www.mapbox.com/blog/using-isochrones-to-understand-reachability-in-web-and-mobile-applications?ref=blog.afi.io) starts around US$2.00 per 1,000 requests on its first paid tier and drops toward US$1.20 at higher volumes.

### My thoughts on the Google Maps Isochrones API

This post covered what an isochrone is, where they're useful, and how to generate one with the [Google Maps Isochrones API](https://developers.google.com/maps/documentation/isochrones/overview?ref=blog.afi.io). It's genuinely impressive and easy to use, but I'm skeptical about how big a commercial success it'll be. Most companies generate an isochrone once per location, then reuse that polygon as a fixed query area for filtering locations, checking coverage, or driving operational decisions. The recurring API revenue might be thinner than it looks.

The ideal customer might be a real estate portal like [Zillow](https://blog.afi.io/blog/add-data-to-google-maps-with-data-driven-styling/) or [Redfin](https://www.redfin.com/?ref=blog.afi.io), generating a fresh traffic aware isochrone for every listing so buyers see how accessible an address really is.

Note: The Google Maps Platform terms don't yet spell out caching rules for isochrone data specifically. Based on how Google treats other web service APIs, there is a 30 day limit on cached values, after which you must delete them. It's reasonable to expect similar temporary only caching for isochrones, with definitive terms likely arriving at GA.

**This article was written by** [**Afi Labs**](https://afi.io/?ref=blog.afi.io)**, a** [**Google Maps Premier Partner**](https://www.afi.io/?ref=blog.afi.io) **and reseller. We build route optimization, navigation, and fleet tracking software on Google Maps, and offer volume pricing on GMP licensing.** [**Talk to an engineer**](https://www.afi.io/contact%5Fus?ref=blog.afi.io) **or** [**follow Afian on LinkedIn**](https://www.linkedin.com/in/afian-anwar/?ref=blog.afi.io)**.**

Next: [Part 2: How isochrones work: From shortest paths to polygons](https://afi.io/blog/how-isochrones-work-from-shortest-paths-to-polygons/?ref=blog.afi.io)