Route optimization can now be submitted instead of waited on: Submit a route optimization takes the problem and answers straight away with a job ID, and Fetch a route optimization returns the finished route once it is ready.

This is what makes large tours optimizable. Optimize Route solves the problem while your request waits, which suits the handful of stops most optimizations involve — but our routing provider treats solving-while-you-wait as a small-problem operation and stops it after a few seconds. Past that ceiling the request does not come back slower, it comes back as an error, however many times you retry it. Submitting the problem lifts the ceiling instead of raising it: the optimization gets the time it actually needs.

Using it

Submit the same payload you send to Optimize Route today. The payload is validated before the job is accepted, so a malformed request still fails immediately rather than surfacing later.

To know when the result is ready, subscribe to maps.route_optimization.completed. It carries the job ID and whether the optimization succeeded, so you can fetch the route the moment it is done. If you would rather not receive webhooks, poll Fetch a route optimization instead: it answers 404 until the route is ready. Results can be fetched for 30 minutes after completion.

What comes back is exactly the payload Optimize Route returns — the stops in optimized order, the totals, the unassigned stops. Only the delivery changes, so whatever you already do with an optimized route keeps working unchanged.

One difference worth planning for

Because the optimization now runs after the request that submitted it, a problem that was accepted can still fail — for example when one of its existing stops is dispatched into another tour in the meantime. Fetch a route optimization reports that the same way Optimize Route does today, so the error handling you already have applies.

Small optimizations need no change at all, and are better off as they are: Optimize Route answers a handful of stops in one call, with nothing to poll or subscribe to. Reach for the asynchronous flow when the problem needs it, not by default. Large ones, however, have a deadline — see the deprecation notice.