Allocates the next unassigned zimarker code(s) for the calling organization. quantity defaults to 1 when omitted; quantity greater than 1 allocates a batch, reserved atomically as a single block (all-or-nothing). quantity is capped at a configurable maximum batch size. Returns an ordered list of allocated entries, each with the marker code and its marker image. imageDelivery selects the image form: BASE64 (default) returns a 1-bit, 600x600 black-and-white PNG inline as base64 in markerImage; URL returns the marker's public image URL in markerImageUrl instead of inline bytes.
- Allocate one or a batch of zimarker codes
Zimark Integration API (v0)
Zimarker
Allocate zimarker code(s) on demand for the calling organization, each with a printable, inline base64 marker image. Allocation is synchronous, atomic, and exactly-once per organization.
Render a zimarker code's marker image on demand. Public, stateless, and addressable by code at a stable URL — no authentication required.
- Mock server
https://docs.zimark.link/_mock/api/integration/rest/api/v1/zmarker-code/allocate
https://your-org.zimark-staging.link/integration/rest/api/v1/zmarker-code/allocate
https://your-org.zimark.link/integration/rest/api/v1/zmarker-code/allocate
- curl
- JavaScript
- Node.js
- Python
- Java
- C#
- PHP
- Go
- Ruby
- R
- Payload
curl -i -X POST \
'https://docs.zimark.link/_mock/api/integration/rest/api/v1/zmarker-code/allocate?quantity=1&imageDelivery=BASE64' \
-H 'X-AUTH-KEY: YOUR_API_KEY_HERE'OK
The marker rendered as a 1-bit, 600x600 black-and-white PNG, base64-encoded (inline). Present only when imageDelivery is BASE64 (the default).
The marker image's public, stable URL ({base-path}/{markerCode}.png). Present only when imageDelivery is URL.
Request
Allocates the next zimarker code for the calling organization (always synchronous) and couples it to a new track. The synchronous variant (async=false, default) additionally waits for coupling and returns the resulting track alongside the allocated code and its marker image with 200. The asynchronous variant (async=true) couples in the background and returns 202 with the allocated code, its marker image and an operation identifier (no track). imageDelivery selects the image form: BASE64 (default) returns the marker inline as base64 in markerImage; URL returns its public image URL in markerImageUrl instead of inline bytes. The supplied WMS identifier is stored as-is and NOT validated against any WMS connector.
When true, couple in the background and return 202 with the allocated code, image and an operation identifier; when false (default), wait and return 200 with the track too.
External asset identifier (WMS id) stored on the track. It is NOT validated against any WMS connector — an identifier with no matching WMS record still couples.
- Mock server
https://docs.zimark.link/_mock/api/integration/rest/api/v1/track/get-and-couple
https://your-org.zimark-staging.link/integration/rest/api/v1/track/get-and-couple
https://your-org.zimark.link/integration/rest/api/v1/track/get-and-couple
- curl
- JavaScript
- Node.js
- Python
- Java
- C#
- PHP
- Go
- Ruby
- R
- Payload
curl -i -X POST \
'https://docs.zimark.link/_mock/api/integration/rest/api/v1/track/get-and-couple?async=false&imageDelivery=BASE64' \
-H 'Content-Type: application/json' \
-H 'X-AUTH-KEY: YOUR_API_KEY_HERE' \
-d '{
"wmsId": "PAL-001",
"customFields": [
{
"fieldKey": "CARRIER",
"fieldValue": "DHL Express"
}
]
}'Ok (synchronous): allocated code, image and track
The allocated marker rendered as a 1-bit, 600x600 black-and-white PNG, base64-encoded (inline). Present only when imageDelivery is BASE64 (the default).
The allocated marker image's public, stable URL ({base-path}/{markerCode}.png). Present only when imageDelivery is URL.
The resulting coupled track (standard integration track representation). Present only on the synchronous variant; omitted on the asynchronous variant, which couples in the background.
Request
Couples an existing zimarker code with a WMS identifier and the track's custom fields, creating a new track. The synchronous variant (async=false, default) waits for coupling and returns the resulting track with 200. The asynchronous variant (async=true) validates up front, then couples in the background and returns 202 with an operation identifier correlating the outcome (delivered via the COUPLING_SUCCEEDED / COUPLING_FAILED webhook). The supplied WMS identifier is stored as the track's external asset identifier and is NOT validated against any WMS connector. Existing coupling rules and concurrency safeguards apply (marker uniqueness, the already-coupled rule, duplicate-creation protection).
External asset identifier (WMS id) stored on the track. It is NOT validated against any WMS connector — an identifier with no matching WMS record still couples.
- Mock server
https://docs.zimark.link/_mock/api/integration/rest/api/v1/track/couple
https://your-org.zimark-staging.link/integration/rest/api/v1/track/couple
https://your-org.zimark.link/integration/rest/api/v1/track/couple
- curl
- JavaScript
- Node.js
- Python
- Java
- C#
- PHP
- Go
- Ruby
- R
- Payload
curl -i -X POST \
'https://docs.zimark.link/_mock/api/integration/rest/api/v1/track/couple?async=false' \
-H 'Content-Type: application/json' \
-H 'X-AUTH-KEY: YOUR_API_KEY_HERE' \
-d '{
"markerCode": 123456,
"wmsId": "PAL-001",
"customFields": [
{
"fieldKey": "CARRIER",
"fieldValue": "DHL Express"
}
]
}'- Mock server
https://docs.zimark.link/_mock/api/integration/rest/api/v1/zmarker-code/image/{code}.png
https://your-org.zimark-staging.link/integration/rest/api/v1/zmarker-code/image/{code}.png
https://your-org.zimark.link/integration/rest/api/v1/zmarker-code/image/{code}.png
- curl
- JavaScript
- Node.js
- Python
- Java
- C#
- PHP
- Go
- Ruby
- R
- Payload
curl -i -X GET \
https://docs.zimark.link/_mock/api/integration/rest/api/v1/zmarker-code/image/123456.png \
-H 'X-AUTH-KEY: YOUR_API_KEY_HERE'