What changed between v1 and v2 version of the new Routific API
v2 extends the Routific API with a full dispatch lifecycle — you can now create routes, trigger optimization, mark deliveries complete, and delete orders entirely from your own systems. v1 stays exactly as it is, and you can adopt v2 one endpoint at a time.
To use v2, update your request URL and the version segment to this:
https://api.plan.routific.com/v2/orders
v1 is unchanged
v1 endpoints continue to work and nothing is deprecated yet. You can run both versions side by side and migrate at your own pace.
New capabilities
Orders
| Endpoint | What it does |
|---|---|
DELETE /v2/orders/{orderUuid} | Delete a single order — scheduled or unscheduled. |
DELETE /v2/orders | Delete up to 500 orders in one call. |
POST /v2/orders/{orderUuid}/complete | Mark an order delivered or missed from your own app. |
Routes
| Endpoint | What it does |
|---|---|
POST /v2/routes | Create routes in a workspace. |
Scheduling
| Endpoint | What it does |
|---|---|
POST /v2/schedules | Trigger Routific's scheduling run — schedule all orders for a date, or assign specific orders to specific routes. |
GET /v2/schedules | List your organization's scheduling runs. |
GET /v2/schedules/{actionUuid} | Fetch the status of an scheduling run. |
GET /v2/schedules/{actionUuid}/solution | Fetch the full scheduled plan once a run has finished. |
Workspaces
| Endpoint | What it does |
|---|---|
GET /v2/workspaces | List your workspaces and their uuids. |
What changed in existing endpoints
| Endpoint | What changed |
|---|---|
POST /v2/orders | workspaceUuid replaces workspaceId. |
GET /v2/orders/{uuid} | Response now includes the order's tracking link and signature URL. |
PUT /v2/orders/{uuid} | Now accepts scheduled orders, may return 202 for scheduling constraint changes, and includes packages. |
GET /v2/routes | workspaceUuid replaces workspaceId. |
POST /v2/routes/publish | New path; workspaceUuid replaces workspaceId. |
Workspaces are addressed by workspaceUuid
v1 uses a numeric workspaceId that you read from the browser URL. v2 uses a uuid, which you can look up from GET /v2/workspaces.
# v1
POST /v1/orders?workspaceId=650603
# v2
POST /v2/orders?workspaceUuid=7c9e6679-7425-40de-944b-e07fc1f90ae7
How asynchronous operations work
Some operations run in the background — optimization, publishing routes, editing certain fields on a scheduled order, or deleting scheduled order all involve recalculating routes that take longer than a request should wait.
The status code tells you whether to poll:
200— the operation completed immediately. The response is the result. Nothing to poll.202— the operation is running in the background. Poll for the outcome using theactionUuidin the response.
A 202 response looks like this:
{
"actionUuid": "42204cf7-0acc-4bfa-a5ed-faee590c6539",
"actionName": "schedule",
"status": "pending"
}
Poll the appropriate endpoint for your operation until status is finished or failed:
| Operation | Poll Endpoint |
|---|---|
| Scheduling / optimization | GET /v2/schedules/actions/{actionUuid} |
| Order updates or deletion | GET /v2/orders/actions/{actionUuid} |
| Publishing routes | GET /v2/routes/actions/{actionUuid} |
Once status is finished, the response includes a summary of what changed. If the operation failed, the response includes a reason.