Synchronous and asynchronous endpoints

AI-generated Key Takeaways

• The Route Optimization API offers two methods: OptimizeTours for synchronous processing of smaller, simpler requests and BatchOptimizeTours for asynchronous handling of larger, more complex requests.

• OptimizeTours requires an open connection until a response is received, while BatchOptimizeTours utilizes Google Cloud Storage for requests and responses, enabling background processing.

• BatchOptimizeTours relies on Long Running Operations (LROs) to track batch progress, which can be monitored via the GetOperation method.

• When using BatchOptimizeTours, users should submit the request, poll for completion using the LRO, and retrieve results or address errors as indicated by the LRO status.

European Economic Area (EEA) developers

If your billing address is in the European Economic Area, effective on 8 July 2025, the Google Maps Platform EEA Terms of Service will apply to your use of the Services. Functionality varies by region. Learn more.

The Route Optimization API exposes two methods:

• OptimizeTours is a synchronous method that returns an optimized route in response to an OptimizeToursRequest. Clients must maintain an open connection to the Route Optimization API until the request is processed and an OptimizeToursResponse or error is returned.
• BatchOptimizeTours is an asynchronous method that accepts URIs for one or more OptimizeToursRequest and corresponding OptimizeToursResponse messages, returning the resource name of a Long Running Operation (LRO) (REST, gRPC) that is used to check for batch completion. OptimizeToursRequests are processed in the background, so clients maintain an open connections to the Route Optimization API only long enough to submit the BatchOptimizeToursRequest or to call GetOperation to check LRO status. BatchOptimizeTours reads requests from and writes responses to Google Cloud Storage.

Use cases

OptimizeTours is convenient for solving small and simple requests, or for requests with solving times of a few minutes or less. Maintaining long-lived connections to the Route Optimization API increases risk of interruption before a solution can be returned.

BatchOptimizeTours can handle larger requests and requests with longer solving time because it does not require a long-lived connection to the Route Optimization API.

Long running operations

LROs are read from the Route Optimization API using the GetOperation method to check the completion status of a batch. LROs include a done property that indicates whether processing of the entire batch is complete and an error field that reports errors encountered during processing. If done is true and no error is present, the batch completed successfully. The presence of an error indicates that some or all of the batch failed processing.

Note: REST GetOperation responses omit the done property if its value is false and the error property if no errors occurred.

The typical lifecycle of a BatchOptimizeTours request is as follows:

1. Submit a BatchOptimizeToursRequest to the Route Optimization API, which returns the resource name of an LRO.
2. Poll GetOperation with the returned LRO resource name until the done or error properties appear in the LRO response.
3. If done is true and no error is present, read OptimizeToursResponses from the Google Cloud Storage URIs specified in the BatchOptimizeTours request. If error is present, inspect the error, update the OptimizeToursRequests accordingly in Google Cloud Storage, and retry as appropriate depending on the observed error.

You can send OptimizeTours and BatchOptimizeTours requests in a variety of ways, either from the command line or using a client library.

Next: Make an API Request