Create a manifest in Zimark based on WMS data, then keep it in sync as pallets change. This is the most common integration a warehouse builds: when an order is ready to be shipped, mirror its pallets into a Zimark manifest so they can be verified at the gate during loading.
If you want the why behind when to trigger each call, see the Realtime Manifest Creation use case. This guide is the how.
- An API key (
ZIM.…). See Authentication. - A unique number from the WMS to identify the manifest, e.g., an order number.
- Your pallet IDs from the WMS.
Throughout this guide, the manifest's external ID is your WMS order ID (for example MAN-2024-001), and each asset is a pallet's WMS ID (for example LPN00012345).
When the order reaches fully allocated or picked in your WMS, create the manifest with its allocated pallets.
POST /integration/rest/api/v1/manifest
curl -X POST "https://api.zimark.link/integration/rest/api/v1/manifest" \
-H "X-AUTH-KEY: ZIM.your-api-key-here" \
-H "Content-Type: application/json" \
-d '{
"identifier": "MAN-2024-001",
"assets": ["LPN00012345", "LPN00012346"]
}'| Field | Type | Required | Notes |
|---|---|---|---|
identifier | string | Yes | The manifest's external ID, usually your WMS order ID. Must be a string, not a number. |
assets | string array | Yes | At least one pallet's WMS ID. |
200 OK returns the manifest's internal UUID:
{
"uuid": "6a7132c4-a035-4602-a1af-baa0b5569e17"
}Store nothing from this response if you don't need to. You address the manifest by the identifier you chose. The UUID is Zimark's internal handle.
During picking, operators sometimes add, remove, or swap pallets (a pallet is damaged and replaced by another with the same SKU / the load is too heavy for a truck and some pallets need to be removed). Send the complete updated asset list. The update is declarative, so Zimark adds, removes, and keeps assets to match what you send. You do not send a diff.
PUT /integration/rest/api/v1/manifest/{manifestExternalId}
curl -X PUT "https://api.zimark.link/integration/rest/api/v1/manifest/MAN-2024-001" \
-H "X-AUTH-KEY: ZIM.your-api-key-here" \
-H "Content-Type: application/json" \
-d '{
"assets": ["LPN00012345", "LPN00099999"]
}'In the example above LPN00012346 was dropped and LPN00099999 added; LPN00012345 stays. The response is 200 OK.
Fetch the manifest's pallets to confirm the current list matches what you sent. You address the manifest by the identifier you chose.
GET /integration/rest/api/v1/manifest/{manifestExternalId}/asset
curl -X GET "https://api.zimark.link/integration/rest/api/v1/manifest/MAN-2024-001/asset" \
-H "X-AUTH-KEY: ZIM.your-api-key-here"The response lists one entry per pallet on the manifest. trackIdentifier is the pallet's WMS ID, and loadingStatus shows where it is in the loading workflow (NOT_LOADED for a freshly created manifest):
[
{
"trackIdentifier": "LPN00012345",
"loadingStatus": "NOT_LOADED"
},
{
"trackIdentifier": "LPN00099999",
"loadingStatus": "NOT_LOADED"
}
]The pallet IDs returned here should match the list from your most recent create or update call.
If a call fails, check Troubleshooting. The most common causes are a missing/invalid X-AUTH-KEY or sending identifier as a number instead of a string.
- Realtime Manifest Creation: when to trigger each call across the order lifecycle.
- Coupling API: how pallets become camera-verifiable by carrying a Zimarker.
- Manifest webhooks: receive events as the manifest and its assets change.