Skip to main content
POST /v1/org/shipments/imports
Send up to 100 shipments in one call, in the published structure, and get the outcome in the same response — no polling, no second call. By the time this returns, the shipments are in the ledger and you have a verdict for each one. Sized for how partners actually integrate: a step in your manifest-close flow, or an end-of-day scheduled job. For bigger runs send a file, which is queued instead.
Sending the same shipment twice is safe. A shipmentId already in the ledger is updated, not duplicated — its goods lines are replaced by the ones you send. Retries, re-runs and corrected re-sends all do the right thing.

Authorization

string
required
Your organisation API key (dzk_live_…).

Body

Shipment[]
required
1–100 shipments. See Shipment structure for every field. Each shipment needs at least one entry in items, at most 500, and the batch as a whole may carry at most 10,000 goods lines — send bigger runs as a file.
string
Your own reference for this push — a batch id, run date or filename. It is echoed on the import and recorded against every shipment it creates, so a shipment can be traced back to the run that sent it.
Unknown fields are rejected, not ignored. If you send weight where the structure says itemWeight, you get a 400 naming the field rather than a shipment that silently lost its weight.

Response

200 OK — the shipments are written. created and updated both mean the shipment is in the ledger; only failed needs action. Valid shipments are never held back because others in the batch were wrong. There is no import id to poll: this response is the outcome. Your customer still sees the submission in their Dyspach Activity Center, and your own sourceDetails is recorded against every shipment, so a specific push can always be traced back later.

Errors