DocuWare integration – API-Doku

The DocuWare integration files proof of delivery (POD) from a fleet's internal orders in a DocuWare file cabinet. It is one of several POD destinations, next to signed webhooks, cloud storage (S3, GCS, Azure Blob), and Snowflake.

For the DocuWare app registration and the setup steps, see Connect DocuWare for proof of delivery and POD destinations and integrations.

Scope#

Fleet workspaces only. Owners, admins, fleet managers, and dispatchers manage destinations. The fleet plan must include proof of delivery.
Internal orders only. The trigger is the internal event order.pod.uploaded.v1, sent when a driver uploads POD on an internal fleet order.
Not the public API. Deliveries booked through /v1/deliveries report proof with the delivery.pod_submitted webhook and GET /v1/deliveries/{deliveryId}/proof-of-delivery instead.
Web dashboard. DocuWare destinations are set up in the web dashboard under Fleet → Orders → POD destinations, not in the desktop app.

How it connects#

Maxmove signs in to DocuWare with the OAuth 2.0 authorization code flow and a refresh token, as a server-side web application. The redirect URL is https://api.maxmove.com/api/pod/docuware/callback, and the default scope is docuware.platform dwprofile openid offline_access.

During the pilot, the DocuWare administrator creates a custom app registration and enters its client ID and secret in Maxmove. The app registration must allow refresh tokens.

DocuWare Cloud and on-premises servers use the same Platform REST API. The server must be reachable from the internet; private addresses and localhost are rejected.

Data flow#

Driver uploads POD
The driver uploads photos, signatures, signed delivery notes, or documents at pickup or dropoff of an internal order.
Destination picks it up
Maxmove matches the event against each active destination's filters: checkpoints (pickup, dropoff) and file kinds (photo, signature, signed delivery note, document).
Filed in DocuWare
Maxmove uploads the original files, without ZIP or summary PDF, to the configured file cabinet through its store dialog and fills the index fields.

Document modes#

Mode	Result
`per_pod` (default)	One DocuWare document per POD upload.
`per_order`	One document per order. Later uploads are appended to it.

Index fields#

By default, Maxmove fills these fields when they exist in the store dialog:

Field	Content
`MM_REFERENCE`	The order's internal reference, or its order reference or id when it has none.
`MM_ORDER_REFERENCE`	The order reference.
`MM_ORG_ID`	The workspace id.
`MM_ORDER_ID`	The Maxmove order id.
`MM_POD_ID`	The id of the POD upload.
`MM_CHECKPOINT`	Pickup or dropoff.
`MM_WAYPOINT_ID`	The waypoint id.
`MM_OCCURRED_AT`	When the POD was uploaded.
`MM_SOURCE`	Where it was uploaded: `driver_app`, `dashboard`, or `public_link`.

In per_order mode, only the first four are used. You can map other fields yourself; the dashboard maps visible, writable MM_* fields automatically. If the store dialog has a required field that is not mapped, filing fails permanently.

Retries and replay#

Maxmove retries failed uploads with exponential backoff and jitter. The number of attempts is set per destination (1 to 20, default 5).
DocuWare answers in the 4xx range are not retried, except 408, 425, and 429.
Events that still fail are kept as failed. Replay them from the dashboard, by event or by time range, for example after you fixed the store dialog.
The Test button files a one-page test PDF to check the connection.

Requirements#

A fleet workspace whose plan includes proof of delivery. Without it, POD destinations can't be set up.
A DocuWare organization administrator to create the app registration.
A DocuWare server reachable from the internet, a file cabinet, and a store dialog.