Get Started

The API consists of two main components: the input data and the routing and scheduling engine.

Input Data: This includes various mandatory or optional details about jobs (such as stops or destinations) and associated tasks (pickups, deliveries, or a combination of both). It also encompasses information about the fleet of vehicles, including their shifts and capacities.

Routing and Scheduling Engine: Utilizing the input data, this component calculates the most efficient routes and schedules for your vehicles.

The API’s flexibility allows it to handle complex constraints—such as capacity limits, service time windows, and vehicle availability—making it adaptable to various business needs. Additionally, the API supports real-time re-optimization of routes, enabling adjustments to ongoing schedules in response to new orders, cancellations, or other changes.

The API offers two key methods for managing routing and scheduling optimization:

1. Optimization POST – Use this method to submit a routing and scheduling optimization problem. After submitting a POST method, you will receive a unique reference ID.
2. Optimization GET – Use this method to retrieve the status of a submitted problem using the unique reference ID obtained from the POST method. If the optimization solution is ready, you can get the solution of the optimization problem as well.

Optimization POST Method

POST: https://www.ddswireless.com/scheduledroutes/key={your_api_key}

Use this method to submit your routing and scheduling optimization problem to the API. Once an optimization POST request is successfully submitted, the API will return a unique reference ID in the acknowledgement response. Use this unique ID to retrieve the actual solution using the Optimization GET Method (see next section).

An example for submitting an optimization problem using the POST method:

curl --location  'https://www.ddswireless.com/scheduledroutes/key=<your_api_key>'
  --request POST --header 'Content-Type: application/json' 
  --data-raw  '{problem}'

In the above example, you need to replace {problem} with your input problem to be solved by the API. The schema for the input problem is defined in the “Problem” section.

After submitting the POST method, you will get a response message with the following format:

Response Schema for the POST method:

{
 "id": "string",
 "message": "string",
 "status": "string",
}

If the submission is successful, the status will be “200,” with the message reading “OK” and the id representing the unique reference number. If there is an error, the status will indicate an error code, the id will be zero, and the message will describe the error. For more details, please refer to the POST status codes below.

POST Status Codes

Response Code	Description	Additional Notes
200	The request was successful.	A reference ID is returned.
400	Input validation failed.	There is a missing or an invalid parameter or a parameter with an invalid value type is added to the request.
401	API Key not supplied or invalid.	This error occurs when the wrong API key is passed in the request or the key is missing altogether.
402	API Key is valid but does not have access to requested resources.	You might be querying for a geographical region which is not valid for your account or requesting a service which is not enabled for you.
403	Requested host/path not found.	This error occurs when an incorrect host name is used.
404	Too many requests.	QPM (Query per Minute) reached or API request count quota reached.
500	Internal Service error.	There was an internal issue with our API. You can reach out to [support@ddswireless.com] for an explanation.

Optimization GET Method

GET: https://www.ddswireless.com/scheduledroutes/{id}&key={your_api_key}

Use this method to retrieve the optimized solution for the optimization tasks created using the Optimization POST Method. For this purpose, you need to specify the reference ID received from the POST method.

An example for getting the output response of the API using the GET method:

curl --location 
--request GET 'https://www.ddswireless.com/scheduledroutes/result?id=3b14afd6c5690eb

Response Schema for the GET method:

 "solution": {
      "status" : string
      "statistics": {},
      "routes": []
      "unassigned": [],
      }  

Depending on the status of the output solution, the status attribute may have different codes as described below. If the solution is ready, the other attributes (i.e. statistics, routes, unassigned) will be populated based on the obtained solution. The schema for the output solution is defined in the “Solution” section.

GET Status Codes

Response Code	Description	Additional Notes
200	Normal success case.	Normal success case. The solution of the problem is ready and it is returned via statistics, routes, unassigned.
300	Pending status.	Solution is not ready yet. statistics, routes, and unassigned will be empty.
400	Could not process the request.	A feasible solution could not be generated for the given set of locations or parameter configuration. statistics, routes, and unassigned will be empty.
500	Internal Service error.	There was an internal issue with our API. You can reach out to [support@ddswireless.com] for an explanation. statistics, routes, and unassigned will be empty.

To see a list of various API errors, see “API Errors”.

See Next:

Concepts: Problem

Problem

The Problem entity represents a routing and scheduling problem which can represent a Pickup and Delivery Problem (PDP). As shown in the following figure, it consists of four main components: fleet, jobs, objective, and configuration. Among these four components, fleet and jobs, are mandatory whereas objective and configuration are optional.

Note: To specify a location or address in the API, use the WGS84 Geo-coordinates with at least 5 decimal places for accuracy.

For example, if you have an address like “1600 Amphitheatre Parkway, Mountain View, CA,” its corresponding Geo-coordinate would be latitude 37.423021 and longitude -122.083739. Therefore, you specify it as:

"location":{"lat":37.423021, "lon":-122.083739}.

Note: The API uses the ISO 8601 timestamp format for defining times.

Example: 2024-07-31T14:45:30Z which represents July 31, 2024, at 2:45:30 PM UTC.

Note: Ensure that no confidential or personal information is included in the data sent to the API. For example, avoid using real-life identifiers, such as vehicle license plate numbers, as the vehicle ID or job/task IDs.

We will now provide a detailed description of each of these components:

Fleet: it specifies a list of vehicles along with their associated information, such as shift schedules, start and end locations, breaks, capacities, and skills.

• For each vehicle, you can define a shift schedule by specifying the start and end times, as well as the corresponding locations. To identify these locations, you’ll need to provide their Geo-coordinates, which consist of latitude and longitude.
• Each vehicle may have one or more optional breaks. For each break, you can define a time window during which it can be taken, as well as the location and duration of the break.
• For each vehicle, you can define one or more capacity types along with the available units for each type. Vehicle capacity can be represented using multidimensional units of measure, such as volume, mass, or size.
• For each vehicle, you can specify one or more skills that enable it to perform certain jobs. For example, you might assign “welding machine” and “oxygen tank” as skills for one vehicle, and “lift” as a skill for another vehicle. If a job requires a lift, only the vehicle equipped with this skill will be able to serve it.
• You can also set limits for each vehicle, such as the maximum number of stops and the maximum travel distance (in miles).

Jobs: it specifies a list of jobs to be served by the vehicles specified in the fleet Each job can include a series of tasks, which may be pickups, deliveries, or a combination of both. For each task, you can define various attributes such as their location, time windows, duration, capacity requirements, and necessary skills.

• To specify the location of a task, you need to provide its Geo-coordinate, which includes latitude and longitude.
• If you set a service time window for a pickup or delivery task, the optimizer will schedule the task to occur within that time frame. In other words, the estimated time of arrival (ETA) for the task in the API response will fall within the specified time window. If the optimizer cannot find a suitable ETA for a task within its specified time window, the job or task will remain unassigned. For tasks that are flexible or not time-sensitive, you can specify a broader time window, with a maximum span of 24 hours. The API uses the ISO timestamps.
• You can specify a duration (in seconds) for each task. This is the time spent at a given location,
• You can specify the capacity requirements for each task using multidimensional units of measure, such as volume, mass, or size. Additionally, you can create custom names for your capacity types, such as “seat,” “container,” “pallet,” or “bin.” For each capacity type, you can also define the exact amount needed to perform the task.
• You can also define a list of required skills for each task. Only vehicles with a matching skill set will be eligible to perform that task. For example, if you specify “welding machine” and “oxygen tank” as the required skills for a job, only vehicles equipped with these skills will be selected to complete the job.

Objective: it determines the optimization objective or strategy. Currently, the following three objectives are supported by the API:

• Minimize Total Travel Time: This is the default optimization strategy, and it tries to minimize the total travel time of the fleet while completing the specified jobs.
• Minimize Number of Routes: This optimization strategy focuses on reducing the number of vehicles needed to complete the specified jobs. However, this may lead to increased total travel time for the fleet or greater workload on individual vehicles as a trade-off.
• Balance Workload among Routes: This optimization strategy aims to evenly distribute the workload among all vehicles in the fleet. However, this balance may result in increased total travel time for the fleet.

Configuration: through configuration, you can adjust API settings or modify default options. For example, you can specify whether to include a summary of optimization statistics (such as total travel time and distance) or a list of unassigned jobs in the API response.

The schema of the input request to solve a route optimization problem is as follows:

 "problem": {
      "fleet": required 
      "jobs": required
        [
          "pickups": [...] 
          "deliveries": [...]
        ]
      "objective": optional
      "configuration": optional
      "version": optional
    }

To submit a problem using the API, this request must be included in the POST method as described in the “Get Started” section.

In a route optimization problem, a fleet of vehicles aims to serve a set of jobs efficiently. The above template allows users to define their fleet and their jobs. Each job can consist of a number of tasks as follows:

1. Pickup tasks only: These tasks involve picking up items along the route and delivering them to the route’s end location.
2. Delivery tasks only: These tasks require delivering items that are loaded onto the vehicle at the beginning of the route.
3. Pickup and delivery (P/D) tasks together: These tasks combine both pickup and delivery actions. They involve picking up something at one location and bringing it to another location.

Note that a job can have one pickup and multiple deliveries, or multiple pickups and one delivery or a combination of both. Hence, in the above template, two separate objects are provided for defining pickup and delivery tasks.

As seen from the input request schema defined above, each job consists of an array of pickup and delivery tasks. Here’s how it breaks down:

1. If only the “pickups” object is provided for a job, that job is considered a pickup-only job.
2. If only the “deliveries” object is provided for a job, it’s considered a delivery-only job.
3. When both “pickups” and “deliveries” are provided for a job, it’s categorized as a pickup and delivery job.

Note that at least one task must provide for each job. Also, the number of pickups and deliveries for a job can be different in various applications.

Task Assignment and Constraints

In vehicle routing and scheduling, each task can have various attributes and constraints that must be considered during the assignment process. These attributes may include capacity demands, service time windows, and required skills.

• Capacity Demands: Some tasks may require specific vehicle capacities, such as the ability to carry a certain weight or volume.
• Service Time Windows: Tasks often need to be completed within a specified time frame, which must be adhered to during scheduling.
• Required Skills: Certain tasks may necessitate specific skills or equipment, such as a vehicle equipped with a lift or ladder.

Visit Tasks: These tasks involve visiting specific locations to perform services, such as repairs, and can be seen as a specialized form of pickup or delivery tasks. Depending on their nature, visit tasks may or may not involve capacity requirements. The system assigns tasks to vehicles that meet the required criteria, ensuring that only suitable vehicles are deployed. For instance, if a task requires equipment like a lift or ladder, only vehicles equipped with these tools will be assigned to that task.

Input API Payload Elements

The input API payload includes several critical elements, each serving a distinct role in defining the routing and scheduling problem. Below is a detailed overview of each element:

1. Problem [Required]
This element defines the specific routing and scheduling optimization problem that the API will solve. It includes all necessary parameters and constraints to generate an optimized solution.

2. Fleet [Required]
This element provides comprehensive information about the vehicle fleet available for task assignment.

• id [Required]: A unique identifier (integer) for each vehicle in the fleet. This ID is crucial for tracking and managing the vehicles during the routing process.
• shifts [Optional]: An array of shift objects, each containing detailed information about the vehicle’s operational periods, including start and end times and locations. Shifts also encompass break periods, which are essential for ensuring compliance with labor regulations and operational efficiency.

start: Defines the start time and location for the vehicle’s shift.
> time [Optional]: The start time of the shift. If not provided, the default is set to 00:00:00 (midnight) of the current date.
> location [Optional]: The starting location for the shift.

end: Defines the end time and location for the vehicle’s shift.
> time [Optional]: The end time of the shift. If not provided, the default is set to 23:59:00 of the current date.
> location [Optional]: The ending location for the shift.

breaks [Optional]: An array of break objects, each specifying a break period during the shift. Breaks are necessary for legal compliance and driver well-being.
> serviceWindow [Required if breaks are used]: Specifies the time period during which the break can occur.
> duration [Required if breaks are used]: An integer value representing the duration of the break in minutes.
> location [Required if breaks are used]: The location where the break will take place.

Example:

    "shifts": [{
      "start": {
        "time": "2020-07-04T09:00:00Z",
        "location": {"lat": 52.46642, "lng": 13.28124}
      },
      "end": {
        "time": "2020-07-04T18:00:00Z",
        "location": [52.46642, 13.28124]
      },
      "breaks": [
        {
         "serviceWindow": ["2020-07-04T12:00:05Z","2020-07-04T14:05:05Z"],
         "duration": 150,
         "location": {"lat": 52.46642, "lng": 13.28124}
        },
        {
         "serviceWindow": ["2020-07-04T16:00:00Z","2020-07-04T16:45:00Z"],
         "duration": 600,
         "location": {"lat": 51.46642, "lng": 12.28124}
        }
      ]}

• capacities: [required] an array of capacity objects. Each capacity object is defined with the following keys:
  • name: [required] a string specifying the name of the capacity type (e.g. “wheelchair”, “box”, ”seat”, “bin”)
  • units: [required] an integer number specifying the available units of the capacity type
  • lifo: [optional] a binary flag that indicates whether the LIFO (Last In, First Out) constraint is applied to this capacity type. The default value is False. If LIFO is set to True for a capacity type, items of this type will be unloaded first during a delivery or drop-off task.

Example:

"capacities": [
{
"name": "wheelchair",
"units": 2,
"lifo" : True
},
{
"name": "boxes",
"units": 20,
"lifo" : False
        }        
      ]

• skills: [optional] a list of vehicle skills or equipment, each represented by an arbitrary string specific to your application. This allows you to customize the capabilities of your vehicles to match the requirements of the jobs they need to serve.

Example:

"skills": ["lift","fridge","oxygen tank"]

• limits: [optional] specifies constraints applied to the vehicle
  • maxDistance: [optional] a float number specifying the maximum distance limitation for the vehicle in miles
  • maxStops: [optional] an integer defining maximum number of stops (pickup or delivery tasks) the vehicle can serve in one shift
  • lifoDepth: [optional] an integer defining the LIFO depth of the vehicle

Example:

  "limits": {
    "lifoDepth" : 1,
    "maxDistance": 3000.12,
    "maxStops" : 20,
  }

• lastKnownLocation: [optional, used for re-optimization only] Specifies the last known location of the vehicle at the specified time. This information is crucial for re-optimizing an ongoing route to account for new changes, such as broken vehicles, late jobs, new jobs, or canceled jobs. The API uses this data to re-optimize the plan efficiently. Therefore, when re-optimizing an existing schedule, you need to provide the location of all involved vehicles.

Example:

"lastKnownLocation": {
      "location": [53.45612, 12,65421],
      "time" : "2020-07-04T12:00:05Z"
      }

• jobs: an array of job objects [at least one job is required]:
  • id : [required] a unique identifier (integer) for the job
  • pickups: [optional] an array of task objects, each defining a pickup task
  • deliveries: [optional] an array of task objects, each defining a delivery or drop-off task
  • Note: at least one task (either pickup or delivery) must be defined for each job.
  • Each Task Object consists of the following attributes:
    • id: [required] a unique identifier (integer) for the task
    • location: [required] It is an array that specifies the Geo-coordinates of the location where the task must be performed. The first element of the array specifies the latitude, and the second element specifies the longitude.

Example:

"location": [52.46642, 13.28124]

• serviceWindows: [required] It specifies the service time window for performing the task. The service window is an array of two elements: [A,B] where A and B are the start and end times of the service time window. The API will attempt to produce an ETA within the specified service window for that task. If this is not possible, the task/job will be listed as unassigned. In other words, times “A” and “B” define the earliest and latest times by which a task must be completed by a vehicle. For tasks that are flexible or not time-sensitive, use an arbitrarily large window (max 24 hours) to give the API more flexibility in scheduling other tasks.

Example:

"serviceWindows": ["2021-07-04T12:00:05Z","2021-07-04T14:05:05Z"]

• duration: [required] it is an integer that specifies the duration of the task (in seconds).

Example:

"duration": 1950

• demand: [required] An array of the required capacity demands for the task. The structure of each demand object is identical to that of the capacity object in the fleet entity defined above. Each capacity item consists of a name (string) and its available units (integer). The specified names must match those defined in the capacity object of the fleet entity.

Example:

    "demand": [
        {
        "name": "wheelchair",
        "units": 2,
        },
        {
        "name": "boxes",
        "units": 20,
        }        
      ]

• skills: [optional] an array of skills or equipment required to perform the task, each represented by an arbitrary string specific to your application. Only vehicles whose skills set match the skill set of the task will be considered for performing the task. These skills are matched to the skills defined in the fleet entity defined above.

Example:

"skills": ["lift", "ladder", "welding machine"]

• status: [optional, used for re-optimization only] it is a string that specifies the status of the task which can be one of these options: “pending”, “in_progress”, “performed”. This information is crucial for re-optimizing an ongoing route to account for new changes, such as broken vehicles, late jobs, new jobs, or canceled jobs. The API uses this data to re-optimize the plan efficiently. Therefore, when re-optimizing an existing schedule, you need to specify the value of this attribute. For new tasks or tasks that are not performed yet, set it to “pending”. If the task is already performed set it to “performed”. If the vehicle has already arrived at the location to do the task, and the task is in progress, set it to “in_progress”. The default value is “pending”.

Example:

"status": "pending"

• vehicleId: [optional, used for re-optimization only], it specifies the assigned vehicle ID (integer) for the already-scheduled tasks. This information is crucial for re-optimizing an ongoing route to account for new changes, such as broken vehicles, late jobs, new jobs, or canceled jobs. The API uses this data to re-optimize the plan efficiently. Therefore, when re-optimizing an existing schedule, you need to specify the value of this attribute. The default value is zero. For new tasks, set it to zero. For existing tasks that are already assigned to a vehicle, set this attribute to the assigned vehicle ID.

Example:

"vehicleID": 12

• eta: [optional, used for re-optimization only], it specifies the current ETA (estimated time of arrival) for the already-scheduled jobs. This information is crucial for re-optimizing an ongoing route to account for new changes, such as broken vehicles, late jobs, new jobs, or canceled jobs. The API uses this data to re-optimize the plan efficiently. Therefore, when re-optimizing an existing schedule, you need to specify the value of this attribute. The default value is 0. For the new or performed tasks, set it to 0 but for the existing pending tasks, set it to the existing ETA.

Example:

"eta": "2021-07-04T12:13:00.00Z"

objective: [optional] An integer specifying the optimization objective (strategy): (default = 1)

• • 1: Minimize Total Travel Distance [default]
  • 2: Minimize Number of Routes
  • 3: Balance Workload Among Routes
  • Example: “objective”: 1

configuration: [optional] it can be used to specify some additional settings or configurations:

• • • input: [optional]
      • siteId: [optional] it defines the site ID for loading the map data. This is useful for customers that operate in different cities. Using this ID, they can specify which city they want to do the optimization. The default value is zero.
      • loadFleetFromProfile: [optional] if it is set to True, the default fleet data stored in the user profile is used to define the fleet object. This may be useful to reduce the size of the input payload. If it is provided, the fleet object in the input payload is neglected. Default value is False, so by default, the fleet object is utilized.
    • output: [optional]
      • polyLineType: [optional] it specifies the type of the output polyline that can be returned for each scheduled route. It is a string from these options: “none”, “plain”, “encoded”. If “none”is selected, no polylines will be included in the output API response. If “plain” is specified, an ordered list of intersections that we need to travel between each pair of consecutive stops will be returned as the polyline. If “encoded” is used, the polyline is compressed into a string format that users can provide to third-party navigation APIs, such as Google Maps, to obtain turn-by-turn instructions. The default value is “none”.
      • unassignedJobs: [optional] it is a flag that determines whether the unassigned jobs/tasks must be included in the output response or not. Default is False. If, for any reason, the API cannot assign a job/task to a route, it will list it as unassigned.
      • statistics: [optional] it is a flag that determines whether the optimization statistics must be included in the output solution or not. Default is True.

Example:

"configuration": 
{
             "input": 
                    {
                     "loadFleetFromProfile": False,
                     }
             "output":
                     {
                      "polyLineType": "plain",
                      "unassignedJobs": False,
                      "statistics": True,
                     }
}

• version: [optional]: it specifies the version of the API. Default is 1.0.

To see various examples of a Problem and learn how to use the API in different use cases (e.g. re-optimization), see Tutorials.

See Next: Concepts: Solution

Solution

As explained in the “Get Started” section, once you submit a problem via the POST method, you will receive a unique reference ID. You can use this reference ID with the GET method to retrieve the status of the submitted problem. If the optimization solution is ready, you can access it in the “solution” entity. As shown in the following figure, the “solution” entity is composed of three main parts:

Statistics
The Statistics section provides key metrics that summarize the overall solution across all routes. Metrics like total travel distance help assess the efficiency and quality of the optimization. These insights enable you to evaluate the performance and effectiveness of the routing process.

Routes
The Routes section outlines the optimized paths for each vehicle, including specific stops and their estimated time of arrival (ETA). It may also include a polyline representing the vehicle’s path, aiding in visualizing and verifying the route.

Unassigned
The Unassigned section lists jobs or tasks that couldn’t be assigned to a route. It may also include reasons for their exclusion, offering insights into constraints or issues that affected the assignment process.

 

Output Solution Schema:

The template of the solution of the optimization problem provided in the output response of the API is as follows:

"solution": {
      "status" : integer
      "statistics": {},
      "routes": []
      "unassigned": [],
      }  

The Solution entity represents the solution of the route optimization problem which consists of the following attributes:

Here’s a concise and structured version of the content:

Status
A string indicating the state of the GET response. For successful responses, the value will be “200,” and the following objects/attributes will be returned. If unsuccessful, the error code is returned. Refer to the GET status codes in the “API Errors” section.

Statistics
The Statistics section provides a summary of key metrics for the entire solution, including:

Distance:

• totalMiles: The total distance (in miles) traveled by the entire fleet, including the journey from each vehicle’s start to end location.
• revenueMiles: The total revenue distance (in miles) covered, counting only the distance from the first to the last stop for each vehicle. It excludes the distance from the start location to the first stop and from the last stop to the end location.

Vehicles:

• used: The number of vehicles utilized in the solution.
• unused: The number of vehicles not used.

Jobs:

• scheduledJobs: The count of scheduled jobs.
• scheduledTasks: The count of scheduled tasks.
• unassignedJobs: The count of unassigned jobs.
• unassignedTasks: The count of unassigned tasks.

Times:

• totalHours: The total travel hours for the fleet, including time spent from start to end location for each vehicle.
• revenueHours: The total revenue hours, covering only the time from the first to the last stop. It excludes the travel time from the start location to the first stop and from the last stop to the end location.

 

Example:

"statistics": {
    "distance":
    {
      "totalMiles": 15000.23,
      "revenueMiles": 11000.12
    }
    "vehicles":
    {
      "used": 78,
      "unused": 5,
    }
    "jobs":
    {
      "scheduledJobs": 100,
      "scheduledTasks": 120,
      "unassignedJobs": 5,
      "unassignedTasks": 2
    }
    "times":
    {
      "totalHours":1003.23,
      "revenueHours":960.90,
    }
 }

 

Routes: This section provides an array of scheduled routes for each vehicle. Each scheduled route contains the following data:

• vehicleID: An integer that specifies the ID of the assigned vehicle.
• stops: An array of all stops to be performed by the vehicle. Each stop includes the following properties:
• ordinal: The stop’s position within the vehicle schedule, represented by its index (integer).
• jobID: The job ID related to this stop (integer).
• taskID: The task ID related to this stop (integer).
• type: The type of task (string) that must be performed at this stop, either “pickup” or “delivery.”
• location: The geographical coordinates of the stop’s location.
• eta: The estimated time of arrival (ETA) for the stop, provided in ISO timestamp format.
• polyline: The polyline connecting the stop to its preceding stop. The polyline can be one of two types:
  1. plain: If the “plain” polyline is specified in the “configuration,” it is an ordered list of intersections to travel between the preceding and current stops.
  2. encoded: If the “encoded” polyline is specified in the “configuration,” the plain polyline is encoded and returned as an encoded string.

Example:

"routes": [ 
      {
        "vehicleId": 12,
        "stops": [
          {
            "ordinal": 1,
            "jobId": 1,
            "taskId": 2,
            "type": "pickup",
            "location": [12.65321, 52.12230],
            "eta": "2020-07-04T09:19:01Z",
            "polyline": "[10.20306, 50.15682], [12.65321, 52.12230], [12.10217, 53.23271],[10.20306, 50.15682]"
          },
          {
            "ordinal": 2,
            "jobId": 2,
            "taskId": 5,
            "type": "delivery",
            "location": [12.10217, 53.23271],
            "eta": "2020-07-04T12:23:01Z",
            "polyline": "[12.65321, 52.12230], [12.65321, 52.12230], [12.10217, 53.23271],[10.20306, 50.15682]"
          }        
        ]
      },
      {
        "vehicleId": 18,
        "stops": [
          {
            "ordinal": 1,
            "jobId": 5,
            "taskId": 4,
            "type": "pickup",
            "location": [10.65321, 50.12230],
            "eta": "2020-07-01T09:19:01Z",
            "polyline": "[12.65321, 52.12230], [12.65321, 52.12230], [12.10217, 53.23271],[10.20306, 50.15682]"
          },
          {
            "ordinal": 2,
            "jobId": 4,
            "taskId": 7,
            "type": "delivery",
            "location": [13.10217, 51.23271],
            "eta": "2020-07-04T11:23:01Z",
            "polyline": "[12.65321, 52.12230], [12.65321, 52.12230], [12.10217, 53.23271],[10.20306, 50.15682]"
          }        
        ]
      },      
]

• unassigned: The optional unassigned job list is populated with jobs/tasks that cannot be assigned due to specific constraints. Each item consists of a job ID, a task ID, and possible un-assignment reasons (a code plus a description):
  • “id”:
    • “job”: the job ID (integer) of the unassigned task
    • “task”: the ID (integer) of the unassigned task
  • “reason”:
    • “code”: an array containing the code (integer) of the possible reasons
    • “description”: an array containing the description (string) of the possible reasons

Example:

"unassigned": [ 
      {
        "id":{
          "job": 2,
          "task": 1
        }
        "reason":{
          "code": 2,
          "description": "Not enough capacity for this job"
        }
      },
      {
        "id":{
          "job": "31",
          "task": "2"
        }
        "reason":{
          "code": [5],
          "description": ["The service time of the job is out of the shift hours"]
        }
      }
  ]

See Next: Tutorials

Glossary

Terms	Definition
problem	A routing and scheduling optimization problem to be solved by the API
solution	The solution of the routing and scheduling optimization problem provided by the API
fleet	A fleet specifies a list of vehicle types and their information
job	A list of pickup, delivery, or pickup and delivery tasks that must be performed by a specific vehicle
task	A task is part of a job and is to be performed at a specific location and time. The task could be a pickup, a delivery activity, or both.
break	An attribute to define one or multiple break times for drivers at specific locations
demand	As a task capacity requirement, demand is represented in multidimensional units of measure, such as volume, mass, and size. For example: “demand”: [1]
duration	The amount of time used for performing a task or a break
shifts	An object defining the vehicle schedule, their shift start and end times and locations and their potential breaks
pickup	A job task for picking up something along the route and delivering it later in the tour
delivery	A job task for delivering something loaded earlier in the tour
pickup and delivery	A job for picking and delivering along the route. It is used when both pickup and delivery places are specified and a job can have multiple pickups and deliveries
skills	A list of vehicle skills which is needed to serve jobs. For example, when a truck of a certain size or with a certain equipment is required. This attribute applies to both vehicles and tasks. Only vehicles with skills that match the requirements of certain tasks will be assigned to those tasks
service window	It is a time window consisting of two times, an start time and an end time that define the earliest and latest times a task must be completed by a vehicle
start/end location	The first/last location where the vehicle departs/arrives, such as a depot or garage
start/end time	Start/end times can be used for for shifts, breaks, departure time, and the plan part for specifying the tasks times. The times in the solution results are always returned in UTC.
location	The latitude and longitude of an address in WGS84 format
re-optimization	If you’ve already created a schedule using the API and begun executing it, but then new changes arise—such as new orders coming in or some orders being cancelled—you can update the status of your jobs and the current location of your vehicles. The API will then re-optimize the schedule to account for these changes.
ID	A unique identifier for a job, task or vehicle
VRP	Vehicle Routing Problem
CVRP	Capacitated Vehicle Routing Problem
PDP	Pickup and Delivery Problem
limits	Constraints applied to a vehicle type
objective	An optimization objective (strategy) to solve the routing and scheduling problem
statistics	Represents the statistics of the optimized routes in the output solution
stop	A stop specifies the list of activities performed at a specific time, at a specific place on a given route
unassigned jobs/tasks	Jobs/tasks which cannot be assigned to any routes due to different reasons
ETA	It is acronym for Estimated Time of Arrival. The API provides an ETA for all stops on a scheduled route in the output solution.
polyline	A polyline is a series of connected line segments that represents a path or route on a map. Each line segment in a polyline is defined by its endpoints, and together they create a continuous path. In the API, each endpoint is defined by its Geo-coordinates (latitude, longitude).
encoded polyline	An encoded polyline is a compact representation of a polyline used in mapping and routing applications. Instead of storing a series of coordinate pairs explicitly, an encoded polyline uses a string of characters to represent the polyline data efficiently. This encoding is commonly used in applications like Google Maps and other mapping services to reduce the amount of data that needs to be transmitted or stored. An example of an encoded polyline: _kv~uF|y~wGdkZ~gAx|]t@