Mark an order as delivered or missed from your own application
A POST request to the /orders/{orderUuid}/complete endpoint marks an order delivered or missed. It is the programmatic equivalent of a driver tapping the delivered or missed button in the Routific driver app — the same customer notifications, route timeline updates, ETA recomputation, analytics, and webhooks all fire automatically.
Use this endpoint when you are running your own driver app or completing orders from a third-party system and want Routific to reflect the outcome without requiring a driver to be present in the Routific app.
This endpoint behaves identically to driver completion
Completing an order through the API fires the same customer notification, updates the same route timeline, and produces the same analytics events as a driver completing the order in the Routific app. You do not need to trigger anything separately.
Request URL
Request Payload - Delivered
{
"status": "delivered",
"completedAt": "2026-07-17T16:30:00Z",
"notes": "Left with receiving"
}
Request Payload - Missed
{
"status": "missed",
"completedAt": "2026-07-17T16:30:00Z",
"missedReason": "Customer unavailable",
"notes": "Called twice"
}
The body of the request accepts the following fields.
| Fields | Type | Description |
|---|---|---|
| status (required) | String | The completion outcome. Accepts delivered or missed. |
| completedAt (required) | String | The time the delivery was attempted, in ISO 8601 format. Used as the basis for inferred stop events and ETA recomputation on the rest of the route. |
| notes | String | Delivery notes from the driver or your application. Visible in the dispatcher app and in webhooks. Maximum 2,000 characters. |
| missedReason | String | The reason the delivery was not completed. Required when status is missed. Invalid and rejected when status is delivered. Maximum 255 characters |
The order must be on a published route
Completion is only accepted for orders that belong to the current published solution. Publishing is the handoff that makes a route executable. If the route has been modified since it was last published, the order may not be completable until the route is republished.
Completion is not reversible
Once an order is marked delivered or missed, subsequent calls with any status return
409 ORDER_ALREADY_COMPLETED. To see the current state of an order, callGET /v2/orders/{orderUuid}.
Response Payload
[
{
"name": "Metro",
"locations":
[
{
"address": "510 W 8th Ave, Vancouver, BC V5Z 1C5",
"status": "Geocoding"
}
],
"phone": "16043215582",
"email": "[email protected]",
"duration": 600,
"load": 1,
"instructions": "Deliver at loading bay at the back of the building.",
"timeWindows":
[
{
"startTime": "09:00",
"endTime": "10:00"
}
],
"customerOrderNumber": "external-1",
"tags":
[
"refrigerated"
],
"routificOrderNumber": "ORD-12356",
"createdOn": "2025-03-12T16:07:07.135Z",
"uuid": "6a8e071a-4ee0-470b-982e-b24ed1d1b90c",
"workspaceId": 693240,
"status": "delivered",
"deliveryTime": "2026-07-17T16:30:00Z",
"deliveryNotes": "Left with receiving",
"missedReason": null,
"packages":
[
{
"barcode": "ref-10000"
}
]
}
]
Description of attributes returned in the response payload:
| Fields | Type | Description |
|---|---|---|
| name | String | Customer name for the order |
| locations | Location object | Address and coordinates of the delivery address. If the lat/lng was adjusted on the Routific UI, this will fetch the latest pin location. |
| phone | String | Phone number of the customer |
| String | Email of the customer | |
| duration | Number | Expected time spend at location. This is the input, not the actual time spent. For actual durations, you can Fetch route timelines. |
| load | Number | A number used to account for how much of a route's capacity is utilized by the order |
| instructions | String | Delivery instructions for the order, such buzzer number, etc. |
| timeWindows | TimeWindow object | A time range within which the order must of serviced. |
| createdOn | String | DateTime field of when the order was created in Routific's system |
| workspaceId | Integer | The ID of the workspace associated with the order. |
| uuid | String | An internal ID used to identify an order within Routific's system |
| customerOrderNumber | String | The external ID or customer order number. |
| routificOrderNumber | String | The internal Routific order number (as displayed in the UI). |
| status | String | The current status of the order. Possible values: not_scheduled, scheduled, delivered, missed. |
| deliveryTime | String | The time the delivery was attempted, in ISO 8601 format. |
| deliveryNotes | String | Delivery notes from the driver or your application. |
| missedReason | String | The reason the delivery was not completed. Present only when status is missed. |
| deliveryDate | Date | The date you plan to execute the order in YYYY-MM-DD format. This field helps organize and filter orders by day within Routific, making it easier to schedule specific orders for specific dates |
| packages | Packages object | Barcodes for packages that need to be delivered or picked up at the order's location. |
| tags | String array | Tags can be used to restrict or bind an order to particular route or vehicle. For example, if an order has tags of ["A","B"] it can be served by a route with tags "A" or "B". If none of the routes tags match the order's tag, the order will be left unserved. Orders without a tag can be served by any route with or without a tag attached to them |
What happens after a successful completion
You do not need to trigger any of the following separately — they happen automatically as part of the completion call, in the same way they would if a driver completed the order in the Routific app:
- The route's timeline is updated and ETAs for remaining stops are recomputed.
- Customer notifications (email and SMS) are sent if your workspace has them enabled.
- The
order.status_updatedwebhook fires. - The order appears as delivered or missed in the dispatcher app's route view and analytics.
Multi-order stops
When several orders are grouped at the same stop, completing one order does not close the stop. The stop remains open until every order at that location is marked delivered or missed. The final order to be completed triggers the departure and closes the stop.
Stop lifecycle is managed automatically
You do not need to send arrival or departure events. Routific derives the stop lifecycle from the completion calls — creating an inferred arrival on the first completion and an inferred departure when the stop resolves. These events keep the route timeline coherent without requiring your application to know anything about stop metadata.