How to Optimize the Order of Stops in a Route

Optimize the order of stops in a route

You have one origin, one destination, and several intermediate stops that may be visited in any order. The Routing API can reorder the intermediate stops to find a better visit order, then calculate the route through them.

Set optimize_stops=true in the routing request. The first waypoint remains the origin, the last waypoint remains the destination, and only the waypoints between them may move.

This option is useful for one route with flexible stops. It does not assign work to several drivers or apply operational constraints such as time windows and vehicle capacities.

Task flow: origin, flexible intermediate stops, and destination → Routing API with optimize_stops=true → optimized stop order and route.

Request an optimized stop order

Put the origin first, the destination last, and the flexible stops between them. Each waypoint uses latitude,longitude order, and | separates the waypoints.

This baseline request preserves all five stops in their supplied order:

https://api.geoapify.com/v1/routing?waypoints=52.5163,13.3777|52.5219,13.4132|52.5096,13.3760|52.5076,13.3904|52.5050,13.4397&mode=drive&format=json&apiKey=YOUR_API_KEY

Add optimize_stops=true to let the Routing API reorder the three intermediate stops:

https://api.geoapify.com/v1/routing?waypoints=52.5163,13.3777|52.5219,13.4132|52.5096,13.3760|52.5076,13.3904|52.5050,13.4397&mode=drive&optimize_stops=true&format=json&apiKey=YOUR_API_KEY

The waypoint indexes in the input are 0, 1, 2, 3, 4. Index 0 is the fixed origin, index 4 is the fixed destination, and indexes 1, 2, and 3 may be reordered.

Keep the waypoints, travel mode, route type, traffic settings, and avoid rules identical when comparing the supplied and optimized orders. Otherwise, the requests are solving different routing problems.

Read the optimized stop order

Read results[0].waypoints to get the calculated visit order. Each waypoint includes an original_index that maps it back to the corresponding waypoint in the request.

Reduced optimized response:

{
  "results": [
    {
      "distance": 9768,
      "time": 887.772,
      "waypoints": [
        {
          "location": [13.3777, 52.5163],
          "original_index": 0
        },
        {
          "location": [13.376, 52.5096],
          "original_index": 2
        },
        {
          "location": [13.3904, 52.5076],
          "original_index": 3
        },
        {
          "location": [13.4132, 52.5219],
          "original_index": 1
        },
        {
          "location": [13.4397, 52.505],
          "original_index": 4
        }
      ]
    }
  ]
}

The optimized visit order is therefore 0 → 2 → 3 → 1 → 4. The origin and destination stay fixed while the three intermediate stops move.

Response locations use GeoJSON coordinate order: [longitude, latitude]. This is the reverse of the latitude,longitude order used by the waypoints query parameter.

For this example, optimization reduces the route by 12690 - 9768 = 2922 meters, about 23%, and by 1188.254 - 887.772 = 300.482 seconds, about 25%. These savings apply to this input; results depend on the stops and routing options.

Choose stop-order or operational optimization

Use optimize_stops=true when a single route has one fixed origin, one fixed destination, and flexible intermediate stops. The option becomes useful when at least two intermediate stops can exchange positions—that is, with at least four waypoints in total.

The Routing API and Route Planner API solve different planning problems:

Keep your application data associated with each input index, then use results[0].waypoints[].original_index to place those records in the optimized order. Do not read the optimized order from properties.waypoints: that collection preserves the request inputs rather than representing the calculated visit sequence.