Basic Route Optimization

In this example we will play around with basic constraints offered in’s Route Optimization Flexible API. The constraints covered here are time windows of jobs, vehicle shift timings, skills needed to complete the tasks and capacities involved to carry out pickup/delivery type tasks. We specifically demonstrate how the time windows are used to determine the job sequence & assignment and if the time windows are such that they could not be honored then the task would be left unassigned. We will also see how the starting and ending stops for the vehicle are configured when they are assigned to depots versus when they are not assigned to depots.

Get Started

Readers would need a valid NextBillion API key to try this example out. If you don’t have one, please contact us to get your API key now!


Once you have a valid API Key, you can start setting up the components to be used in this example. Let’s take a look at them below.

Jobs & Shipments

We start by defining 5 jobs and 2 shipments. For these tasks we add:

  • A unique identifier for each task
  • Location indexes for each task
  • Specify the schedule of tasks. This is done by adding time windows within which a task must be completed. We have added a 15 min time window for all tasks for the sake of simplicity, but the Route Optimization Flexible API is fully capable of handling much complex task schedules.
  • Skills needed to perform each task
  • Pickup and Delivery amounts for all jobs
  • The actual time taken to complete the task once the driver/vehicle is at the task’s location i.e. the service time for each task. We have added a uniform

service time of 2 mins for all tasks, but the readers can use varying service times instead.

Let’s take a look at the jobs JSON after the above properties are configured:

2 "jobs": "[...]",
3 "shipments":"[...]"


Next, we add a depot that we want to assign to one of the vehicles. The assigned vehicle would start from the depot’s location. We assign an ID and a location_index to the depot:

1"depots": [
2 {
3 "description":"Depot 1",
4 "id":0,
5 "location_index":9
6 }
7 ]


Next, we add 2 vehicles that are responsible for fulfilling the tasks within the defined constraints. To describe the vehicles and their properties we add:

  • A unique ID for each vehicle
  • Vehicle shift time or the time window
  • Capacity to denote the amount of load that the vehicle can take
  • Vehicle’s depot, if any.
  • Start_index to denote the point from where the vehicle would start. It is important to highlight here that we need to add a start point for all vehicles either by specifying the start_index or by assigning them to a depot. In this example, we cover both cases and define a start_index for one vehicle and assign a depot to the other.
  • Skills of the driver or the vehicle
  • We are not mentioning any cost for the vehicles. Please take a look at the Vehicle Cost example to know more about its usage.

Once the vehicle and their properties are defined, the resulting vehicles JSON is:

2 "vehicles": "[...]"


And now, lastly we define the locations object and add all the locations used in the problem along with a valid id. The locations object with all the points used in this example:

2 "locations": "{...}"

Optimization POST Request

Bringing all these components together to create the final POST request that we will submit to the optimizer.

1curl --location '<your_api_key>'
2--header 'Content-Type: application/json'
3--data '{...}'

Optimization POST Response

Once the request is made, we get a unique ID in the API response:

2"id": "777fe88e8748be4f95d478ce657252d8",
3"message": "Optimization job created",
4"status": "Ok"

Optimization GET Request

We take the ID and use the Optimization GET request to retrieve the result. Here is the GET request:

1curl --location '<your_api_key>'

Optimization GET Response

Following is the optimized route plan:

2 "description": "Basic Route Optimization Example",
3 "result": '{...}',
4 "status": "Ok",
5 "message": ""

Following is a visual representation of the initial locations of tasks, vehicles and the routes suggested after optimization as per the given constraints


Analyzing the Solution

Looking at the result we can observe some interesting insights:

  • summary section:

    • We get an overview of the overall result with a total distance of 33584 meters covered within a total duration of 4162 seconds of driving time to complete all the assigned tasks.
    • There are 2 routes with a total cost of 4162. This cost is in seconds as we did not explicitly specify any travel_cost, so the solver went with the default setting of duration.
    • Other fields in summary tell us that there are 2 tasks (belonging to the shipment with ID 2) which remained unassigned, total service time of all the assigned tasks, total waiting_time for the assigned tasks and other details.
  • routes section:

    • Gives step wise and route wise details of each route along with the vehicle which is going to cover each of them.
    • For each route we get details of the steps involved, ID of the vehicle which is going to cover the route, cost of the route, distance of the route and duration needed to cover it, encoded geometry of the route, service and setup times, pickup/delivery amounts involved in the route among other details. Please note the cost value is based on the travel_cost value provided in the input request. In our example, the cost is calculated based on the duration, hence all costs in the solution are in seconds. Consequently, we can see that cost and duration of both routes are the same as no vehicle costs were involved.
    • For each step we get details like - step type, arrival time at the location of the step, service time, priority, setup time, location, ID of the job/shipment among others.
    • We can see that vehicle 1 is taking care of job 1, 2 & 4 while vehicle 2 is assigned to fulfill jobs 3 & 5 along with the shipment 1 pickup and delivery. This is because of the skills needed to complete those jobs. Take a look at the skills specified for jobs and 1,2 and 4 and that specified for vehicle 1.
    • The vehicle 1 starts from the provided start point but the vehicle 2 start from the depot location to which it was assigned to
    • On analyzing the routes further we can see that vehicle 1 waited for more than 3 plus hours to complete jobs 1 & 4. This is because vehicle 1, after completing job 2, arrives at the location of job 1 almost an hour earlier than scheduled time to start job 1. The vehicle then waits for the start of the time window when job 1 can be completed. Same happens with job 4 for which the vehicle arrives almost two and half hours earlier than the scheduled start time of the job. If the high waiting time is a concern, we recommend you to look at the max_waiting_time example to understand how you can cut down on the vehicle’s waiting time.
    • unassigned section gives the details of the tasks that remained unassigned along with the reason for it. We can observe that this task was scheduled outside the time_window of vehicle 2 and hence remained unassigned. The shift timing of the other vehicle did also not cover the task’s scheduled time, but please note that vehicle 1 could not have fulfilled the task anyway because of the missing skills.

As we witnessed,’s Route Optimization Flexible API closely adheres to the time windows, skill constraints of the tasks and returns the best possible routes while keeping other factors into consideration. We encourage you to go ahead and try out different configurations of locations, time windows, skills, number of tasks and explore the powerful Route Optimization Flexible API.

We hope this example was helpful. Check out some more use cases that Route Optimization Flexible API can handle for you!