Orders Export API

When an order is fulfilled outside Zendera’s own driver fleet — by an external carrier or a partner’s TMS — this API is the integration loop. Your system pulls the shipments Zendera has marked for export, confirms it accepted them, and reports progress (picked up, delivered, damage, nobody home) back so dispatchers and end customers see live status in Zendera.

Updates you push here appear on the order’s external carrier timeline, readable via GET /v2/orders/{orderId}/external-updates.

Interactive API Explorer

Authentication

Authorization: apikey YOUR_API_KEY_HERE

Base URLs

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

The integration loop

1. Poll for work — GET /v1/orders/export returns the shipments assigned to your carrier integration.
2. Acknowledge — POST /v1/orders/export/status reports per order whether your system accepted it (EXPORTED_SUCCESSFULLY) or could not (FAILED + failureReason).
3. Report progress — POST /v1/exported-order/update pushes pickup/delivery events as they happen on your side.

1. Fetch shipments to export

GET /v1/orders/export?page=1&perPage=50

An order appears in this feed when it is dispatched and assigned to an external driver that has order export enabled (configured by your Zendera contact). It stays in the feed until you acknowledge it with EXPORTED_SUCCESSFULLY, or until five export attempts have failed.

Response (shipments[] plus page, perPage, total, totalPages):

Each Shipment carries everything your system needs to execute the transport: sender/delivery addresses and contacts, parcels with dimensions and weights, references, carrier service, and optional cash-on-delivery details. Parcels include metadata from the originating order rows (and contributorMetadata for grouped trade items), so reference data from the order import round-trips into your system. Explore the full schema in the API explorer above.

2. Acknowledge the export

POST /v1/orders/export/status

{
  "create": [
    { "orderId": 12345, "status": "EXPORTED_SUCCESSFULLY" },
    { "orderId": 12346, "status": "FAILED", "failureReason": "Unknown postal code" }
  ]
}

Failed exports surface to dispatchers (and on the order’s external-updates timeline as EVENT_TYPE_ORDER_EXPORTED with success: false) so they can correct the order and retry.

3. Report pickup/delivery progress

POST /v1/exported-order/update

{
  "orderId": 12345,
  "status": "COMPLETE",
  "location": "DELIVERY",
  "completeInfo": {
    "date": "2026-06-11T14:30:00Z",
    "coordinates": { "latitude": 59.91, "longitude": 10.75 },
    "pod": {
      "date": "2026-06-11T14:30:00Z",
      "comment": "Left at front desk",
      "pictures": [],
      "signeeName": "John Smith",
      "isContactless": false
    }
  }
}

Common gotchas

• This API is for external fulfilment. If Zendera’s own drivers deliver your orders, you don’t need it — read statuses via the order status feed instead.
• Acknowledge what you fetch. Orders stay in the export feed until your system has confirmed them via export/status — polling alone never drains it.
• Five strikes. After five failed export attempts an order drops out of the feed and needs dispatcher attention in Zendera.
• status decides which info object is read. Sending status: "DAMAGE" with only completeInfo populated loses the detail.
• camelCase JSON throughout (orderId, failureReason, perPage) — unlike some other v1 endpoints.

Related documentation

• Orders API — external carrier updates — read back the timeline your updates create
• Orders Import — how orders enter Zendera in the first place