Get a Demo

API directory · Google Maps Platform

Distance Matrix API: bulk travel time and route matrix for logistics

If you are calculating travel times and distances across a grid of origins and destinations, the current Google Maps Platform surface to use is Compute Route Matrix within the Routes API. It supports up to 625 origin-destination element pairs with streaming, real-time traffic and two-wheeler mode. Lepton integrates the route matrix for dispatch, delivery and logistics platforms across India.

Get a demo →

What the API does

A grid of travel times and distances across origins and destinations

The Distance Matrix API is the legacy Google Maps Platform surface for origin-destination travel time and distance calculation. The current production replacement is Compute Route Matrix within the Routes API, and Google recommends new projects use the Routes API surface. Teams on the legacy Distance Matrix API can migrate using the provided migration guide.

Compute Route Matrix supports up to 625 origin-destination element pairs per request, with streaming responses for large matrices. Routing modes include driving, two-wheeler, bicycling, walking and transit. Real-time traffic is available. This is the standard approach for bulk ETA calculation in dispatch, delivery and logistics systems.

Google Maps Platform · Route Matrix
POST distanceMatrix/v2:computeRouteMatrix · 2 Mumbai hubs against 3 drop zones
host routes.googleapis.com · auth X-Goog-Api-Key · billed per element pair · origins x destinations must not exceed 625
200 OK
6 elements · streamed

Request headers and JSON body

POST https://routes.googleapis.com/distanceMatrix/v2:computeRouteMatrix
Content-Type: application/json
X-Goog-Api-Key: <your key>
X-Goog-FieldMask: originIndex,destinationIndex,distanceMeters,duration,condition

{
  "origins": [
    { "waypoint": { "location": { "latLng": {
        "latitude": 19.0760, "longitude": 72.8777 } } } },
    { "waypoint": { "location": { "latLng": {
        "latitude": 19.1136, "longitude": 72.8697 } } } }
  ],
  "destinations": [
    { "waypoint": { "location": { "latLng": {
        "latitude": 19.0330, "longitude": 73.0297 } } } },
    { "waypoint": { "location": { "latLng": {
        "latitude": 19.2183, "longitude": 72.9781 } } } },
    { "waypoint": { "location": { "latLng": {
        "latitude": 19.0178, "longitude": 72.8478 } } } }
  ],
  "travelMode": "DRIVE",
  "routingPreference": "TRAFFIC_AWARE"
}
Note what the response is not. It is not a grid, and it is not in request order: elements are streamed as they are computed, which is why every element carries its own originIndex and destinationIndex. Your dispatcher reassembles the matrix from those two numbers. condition is the per-cell verdict, so one unreachable pair returns ROUTE_NOT_FOUND without failing the other five.

Response streamed JSON array

[
  { "originIndex": 0, "destinationIndex": 2, "condition": "ROUTE_EXISTS",
    "distanceMeters": 8900,  "duration": "1320s" },
  { "originIndex": 1, "destinationIndex": 0, "condition": "ROUTE_EXISTS",
    "distanceMeters": 31200, "duration": "3180s" },
  { "originIndex": 0, "destinationIndex": 0, "condition": "ROUTE_EXISTS",
    "distanceMeters": 24500, "duration": "2760s" },
  { "originIndex": 1, "destinationIndex": 2, "condition": "ROUTE_EXISTS",
    "distanceMeters": 15600, "duration": "1860s" },
  { "originIndex": 0, "destinationIndex": 1, "condition": "ROUTE_EXISTS",
    "distanceMeters": 33800, "duration": "3540s" },
  { "originIndex": 1, "destinationIndex": 1, "condition": "ROUTE_EXISTS",
    "distanceMeters": 24100, "duration": "2400s" }
]
elements2 origins x 3 destinations = 6, and 6 objects come backcoverageeach of the 6 index pairs appears exactly once, in stream orderceiling625 is the documented limit on origins x destinations per request
Fig. · One computeRouteMatrix call, trimmed for the page. The endpoint, the request structure, every response field and the condition values are the documented Routes API surface. The hub and drop coordinates, distances and durations are illustrative and describe no real fleet, run or customer.

Use cases

Where the route matrix powers logistics and dispatch

  1. 01

    Dispatch · Nearest-driver assignment at scale

    Cab and delivery platforms calculate a travel-time matrix between multiple available drivers and multiple pending orders in real time, then assign the driver with the lowest travel time to each order.

  2. 02

    Logistics · Stop-order optimization for multi-drop routes

    A route matrix of all delivery stops within a zone gives the optimizer the input it needs to sequence stops by travel time rather than by entry order, reducing total route duration across the fleet.

  3. 03

    Retail · Coverage and catchment-area analysis

    Retail and dark-store teams calculate travel-time matrices from candidate warehouse locations to demand clusters to model catchment areas and select optimal hub placements before committing a lease.

  4. 04

    SLA · Pre-delivery ETA commitment to customers

    E-commerce and quick-commerce platforms use a route matrix call at order placement to compute a real-time traffic-aware ETA before the order is dispatched, so the committed delivery window is reliable.

Where Lepton comes in

Matrix architecture, legacy migration and India-specific routing modes

Route Matrix billing is per element pair, and large matrices can become a significant cost driver if not sized correctly. We design the matrix architecture against your dispatch pattern, and we run the migration from the legacy Distance Matrix API for teams that need to move.

  1. 01

    Migration · Distance Matrix API to Route Matrix migration

    We map the field differences between the legacy Distance Matrix API and Compute Route Matrix, validate the response schema against your dispatch logic and execute the cutover with parallel-run validation so ETA quality is maintained through the migration.

  2. 02

    Architecture · Matrix sizing and streaming call design

    We size the matrix to your actual dispatch pattern, partition large requests across streaming calls correctly and validate that two-wheeler mode is applied where your fleet is bike-based.

  3. 03

    Cost · Per-element billing engineering

    Route Matrix bills per element pair. We instrument your dispatch call frequency and matrix size to model cost at scale, then identify where sparse matrices or caching reduce spend without degrading ETA accuracy.

Get started

Tell us the matrix size and dispatch pattern. We will design the integration.

Bring the fleet dispatch or ETA grid use case. We size the Route Matrix call architecture and walk through the integration.

Get a demo →