Order Documentations API

Open in Postman

Read driver-recorded order events — deviations, comments, waiting time, photos, and signatures — exactly as they appear on the order's Documentation card.

A documentation is an event recorded against an order while it is being executed — almost always by the driver in the mobile app: damage with photos, “no one there”, waiting time, free-text comments, returned goods, signatures. Dispatchers see these on the order’s Documentation card; these endpoints give your integration the same data.

For an API key the surface is read-only — events are created by drivers and resolved by dispatchers, and your integration reads the result.

Where this fits in your operation

Deviation handling: pull damage, no_one_there, and unable_to_handle events (with photos) into your ERP or customer-service tooling, and use the solved fields to track which ones a dispatcher has already dealt with.
Waiting-time billing: waiting_time events carry time_in_minutes — the data you need to invoice demurrage.
Returns: return_goods events record that goods are coming back (return_to_terminal, assign_to_driver_id).
Audit: every event has a creator, a timestamp, GPS coordinates, and optionally the specific stop (order_location_id).

Interactive API Explorer

Loading API Documentation...

Authentication


Authorization: apikey YOUR_API_KEY_HERE

Base URLs

Production: https://app.zenderatms.com/api/
Staging: https://staging.zenderatms.com/api/

Event types

`type`	Recorded when
`damage`	Goods are damaged — usually with photos attached.
`comment`	The driver leaves a free-text note.
`no_one_there`	Nobody was present at the stop.
`waiting_time`	The driver had to wait — duration in `time_in_minutes`.
`unable_to_handle`	The goods could not be handled as planned.
`return_goods`	Goods are being returned (`return_to_terminal`, `assign_to_driver_id`).
`message`	A message/chat entry between driver and dispatch.
`tt_irregularity`, `tt_report`	Track & trace irregularities and reports from terminal scanning.
`other`	Anything that doesn’t fit the above.

contactless_delivery_proof can also appear in responses, but it is not accepted as a ?type= filter value.

Endpoints

List events on an order

GET /v1/orders/{orderID}/documentations?type=damage&type=waiting_time

Returns every documentation on the order, oldest first. type is repeatable; omit it to get all types. Returns 204 No Content when the order has none, 400 when the order doesn’t exist (or belongs to another organization).

Each entry is snake_case JSON:


{
  "id": 88421,
  "order_id": 5335569,
  "order_location_id": 9912023,
  "type": "waiting_time",
  "comment": "Dock occupied, waited for slot",
  "time_in_minutes": 25,
  "solved": false,
  "latitude_f": 59.9139,
  "longitude_f": 10.7522,
  "created_by": 314,
  "created_at": "2026-06-11T09:42:17Z",
  "images": [],
  "signatures": []
}

order_location_id ties the event to a specific stop; it’s null for order-level events.
solved / solved_comment / solved_at / solved_by are set when a dispatcher marks a deviation as handled — useful for filtering out events your team no longer needs to act on.
images[] and signatures[] are embedded directly in the list response — you rarely need the per-documentation endpoints below.

Images and signatures for one event


GET /v1/orders/{orderID}/documentations/{documentationID}/images
GET /v1/orders/{orderID}/documentations/{documentationID}/signatures

Images carry a signed download_url plus download_url_expires_at. Signatures pair a signee_name with a signature image.

Sibling events from one driver submission

GET /v1/orders/{orderID}/documentations/{documentationID}/batch-id

When a driver records one event covering several stops in a single submission, each affected order gets its own documentation sharing a batch insert id. Given one documentation, this returns the others created in the same batch (see also batch_stops[] on the list response).

Common gotchas

Read-only for API keys. Creating, deleting, and resolving documentations are driver/dispatcher actions in the Zendera apps — there is no write access on this surface.
snake_case JSON (v1 endpoint family).
Download URLs expire. download_url is a signed link — fetch it fresh when you need the file instead of persisting the URL. If you need the image long-term, download the bytes.
Expect 204. An order with no events returns 204 No Content, not an empty 200 array — don’t treat it as an error.
This is not the proof of delivery. The final POD (signature, signee, photos at completion) lives on GET /v2/orders/{orderId}/completion-proof. Documentations capture what happened along the way.
No feed semantics. This is a per-order read, not a change feed — to detect that something happened, poll the order status feed (or re-read documentations for orders that changed).

Orders — completion proof, cancel/replan, and other per-order operations
Order Summary — the status feed that tells you an order changed
Product Status Feed — per-product status changes at each stop
Notifications Log — the messages Zendera sent about the order