Getting Started with the Zendera API

This guide is for developers building integrations against Zendera — the Transportation Management System used by transport operators to plan, dispatch, and bill deliveries. If you’re building an ERP, OMS, WMS, marketplace, or partner tool that needs to push orders into Zendera and read order status back, you’re in the right place.

This article covers the basics: environments, your first call, the data model in plain English, the typical wholesale order lifecycle, and the cross-cutting conventions used across every endpoint.

Quick Start by Use Case

Environments

Treat staging and production as separate organizations with separate API keys. All endpoint paths in this guide are relative to the base URL. For example, POST /v3/orders/import → https://app.zenderatms.com/api/v3/orders/import.

How to make your first API call

POST /v3/orders/import

Core concepts (plain English)

You’ll see these terms throughout the API. Knowing them upfront saves time.

Organization

The tenant. An API key is scoped to a single organization — it can only see and modify that org’s data.

Customer and Department

A customer is the company being billed. A department is an optional sub-unit of a customer with its own address and contacts. When you import an order, you target either a customer or a specific department.

Order

The transport job. An order has:

• A customer (and optionally a department)
• An order type (e.g., “Standard delivery”)
• A vehicle type required (e.g., “Van”, “Truck > 3.5t”)
• Pickup and delivery (each is a stop)
• One or more products
• An internalOrderNumber — your unique ID within the organization. Used for dedup on import.
• A serial code (Zendera-assigned, displayed in the UI)

Stop (Order Location)

One physical action at one location: a pickup or a delivery. An order with one pickup and one delivery has two stops.

In the API, stops are usually modelled as OrderLocations and referenced via orderLocationId.

Location

A reusable record for a physical place (an address). Locations can have contacts (people to notify) and time windows (recurring opening hours, expressed as RRule). See Locations.

Driver, Vehicle

A driver is a person; a vehicle is a vehicle. Drivers can be managed via the API — create, update, deactivate/reactivate, and schedule workdays through /v1/drivers. Vehicles are managed in the Zendera UI; there is no vehicle CRUD in the integration API.

Product (and Atoms)

A product is a line item on an order — name, quantity, unit, weight, volume, barcode.

With the atoms feature, products are hierarchical: a parent product can contain children, and children can contain grandchildren. This mirrors how goods are physically packed:

Pallet (parent)
 ├── Carton 1 (child)
 │    ├── Unit 1.1 (grandchild)
 │    └── Unit 1.2
 └── Carton 2
      └── Unit 2.1

The hierarchy is expressed via parentId on each product. A product with no parentId is a top-level item.

When a wholesale order arrives, the products often describe the requested goods at SKU level. After the warehouse picks and packs, the actual physical hierarchy is sent back. Both views live on the same order, distinguished by parentId.

See Products and atoms for the endpoints.

Plan and dispatch

Once an order exists, Zendera’s dynamic route optimizer assigns it to a driver and sequences the stops automatically. There is no API call you have to make to “plan” an order — it happens continuously in the background. Dispatchers can override decisions in the UI (lock a stop to a driver, freeze a route), but as an integrator you do not need to drive planning.

Your responsibilities are typically:

• Push orders in (via import).
• Read status changes back (via the status feed).
• Optionally update specific fields (vehicle type, products, custom field values) when your business state changes.

Status feed

A polling endpoint (GET /v2/orders/summary/orderstatusfeed) that returns order status changes since a saved token. The recommended way to keep your downstream system in sync — much more efficient than re-reading the orders list. See Order Summary → status feed. For per-product status changes at each stop, there is a companion Product Status Feed.

Documentation (driver events)

A documentation is an event the driver records on an order during execution: damage (with photos), “no one there”, waiting time, comments, returned goods, signatures. Dispatchers see them on the order’s Documentation card; your integration reads them via Order Documentations — including whether a dispatcher has marked each deviation as solved.

Custom fields

Organization-defined fields used to record info beyond the built-in schema. Definitions are managed via /v1/admin/custom-field-definitions (Custom field definitions); the values themselves are set on locations and order locations (Custom field values).

Cargo carrier

A way of representing returnable equipment (pallets, crates, beer kegs, etc.) that needs to be tracked separately from the goods on the order — including per-location balances and deposit accounting. See Cargo carriers.

The wholesale order lifecycle

Most Zendera integrations follow a similar lifecycle. This is the typical flow for a wholesale customer whose ERP/WMS pushes orders into Zendera and reads status back.

[1] Order created in your ERP
        │
        ▼
[2] Order sent to Zendera     ──── POST /v3/orders/import
        │                          (returns: orderCreated / draftCreated /
        │                           orderUpdated / orderMerged)
        ▼
[3] Picking starts              (your WMS picks the goods)
        │                          ── you may call POST /v1/order-products/upsert
        │                             to update products as they're picked
        ▼
[4] Packing complete            (your WMS records the actual packed hierarchy)
        │                          ── you call PATCH /v1/atoms/{orderId}/tree
        │                             so Zendera knows what physically exists
        │                             (pallets containing cartons, etc.)
        ▼
[5] Zendera optimizer           (auto, no API call needed — assigns to a driver,
    plans the stop                sequences the day)
        │
        ▼
[6] Dispatch to driver app      (status visible via the status feed)
        │
        ▼
[7] Driver executes the stop    (status updates flow through the status feed)
        │
        ▼
[8] Proof of delivery           (signature/photos uploaded by driver app;
        │                          read via GET /v2/orders/{orderId}/completion-proof)
        ▼
[9] Order complete              (final status visible in the status feed; close in your ERP)

What this means for your integration

You can short-circuit any step. Smaller integrations might skip steps 3–4 (push the order, read final status). Larger ones use every step.

Cross-cutting conventions

These conventions apply across every endpoint in the API.

• JSON casing follows the endpoint generation — v2/v3 endpoints use camelCase (externalId, internalOrderNumber, nextToken), while several v1 endpoints use snake_case (internal_product_number, is_external). Each API page states which convention applies; don’t assume one serializer setting across the whole surface.
• Timestamps are ISO 8601 UTC: 2026-04-19T08:30:00Z.
• IDs are integers (e.g. orderId: 12345). Some are int32, some int64 — see the swagger for each.
• Localized errors — set Accept-Language: nb (or en, da) to control error message language.
• Pagination varies by endpoint:
  • Cursor-based (status feed, cargo-carrier submissions list): token + pageSize, response carries nextToken.
  • Offset-based (recurring orders, locations paginated, notifications search): page + perPage (or limit + offset), response carries total/totalPages.
• Idempotency — not built-in. Dedupe on your side. For order imports, dedupe by internalOrderNumber per organization (Zendera will return a clear result for already-existing imports).
• Rate limits — soft. Contact Zendera if you expect more than 10 requests/second sustained.

Status codes

Where the API ends and the admin UI begins

The integration API is a deliberately narrow surface. The following are out of scope and managed only in the Zendera admin UI:

• User accounts and roles
• Customer / department CRUD (the API can read and search customers, but not create or edit them)
• Vehicle CRUD (drivers, by contrast, can be managed via the API)
• Product catalog master data (the API can read the catalogue, but products are created/edited in the UI)
• Order type, zone, freight-level, and price-list configuration (the API can resolve zones and compute freight levels, but not change the configuration)
• Single-order create or monolithic update
• Order status transitions (these happen as a result of driver actions)
• Feature flags

If you call something outside this surface, you’ll get 403 Forbidden.

Available APIs

The reference is organized by where each API sits in the order flow — the same grouping as the sidebar.

Getting started

Reference data

Look up the master data you’ll reference when importing and enriching orders.

Create orders

Manage & enrich orders

Track & sync

External fulfilment

Returnables & settlement

Resources