Running the API and editing the solution in the interface

We recommend the following use case:

  1. The solution is sent via the API from the source system.

  2. A business user logs in to the RouteQ interface and then views or edits the solution.

  3. If the solution was edited, the user exports the resulting solution to the RouteQ internal system. The link between the edited solution and the source solution is saved automatically. To get the edited solution later, use the /children request with the ID of the original task. By not editing the solution, the user confirms that they're content with the obtained solution.

  4. The final solution is downloadable regularly via the API.

Note

The final solution is optimized again after manual adjustments. Treat it the same way you treat other API tasks for route optimization: wait until the task is completed.

Child tasks

You can link route planning runs to each other by task_id. As a result, the parent task will be uplinked by one or more child tasks. This way you can get the list of linked tasks from the parent solution ID, and continue working with any of child task.

A child task can have multiple other child tasks (in other words, be a parent task itself).

Child tasks can represent edited versions of the original result. Besides changes made by the logistician at their discretion, the solution is adjusted during additional planning. If the new optimization runs are linked to the original task, you can upload the updated routes to the source system using the parent ID.

Another use case is to compare different solutions for the same task. You can request a list of child task_id by the ID of the parent planning. This way, you can compare the indicators for different versions and select the best-suited option. Solution metrics are available in the result.metrics field of the API response.

How it works

Alert

Parent and child tasks must be received from the same API key.

The link is established using the query parameter parent_task_id that passes the ID of the parent solution when the routing task is added. (This ID is returned by the service after the parent task is created.)

The list of child tasks includes the task_id of the linked solutions and the time of their run added_at. You can get this array by the parent_task_id and then download the results you want to work with next.

Example

Routes built during the first planning:

API request (JSON)API response

The result was adjusted by the logistician (one order was handed over to a less loaded courier). A new solution has been created:

API request (JSON)API response

When you send a query with the edited solution in the query's parent_task_id parameter, indicate the source planning ID so that the second task becomes a child of the first task.

The list of child tasks contains information about the edited solution:

[
   {
      "task_id": "bd593556-342668cc-db3bcdfe-c98d112c",
      "added_at": 1632906716.03281
   }
]
Contact support