{partner} with your workspace’s subdomain (slug) and
{access_token} with a token from the
authentication flow. Tokens are partner-bound: a
token minted for one workspace only works on that workspace’s subdomain.
Everything on the wire is snake_case, in both directions — request
bodies and response keys alike (shipment_ref, country_of_origin,
parcels[].items[]).
Example POST request — create a consignment
Example POST request — create a consignment
Example GET request — list consignments
Example GET request — list consignments
Example DELETE request — delete a consignment
Example DELETE request — delete a consignment
Response envelope
Success responses carrysuccess: true and a human-readable message
(empty for reads), with the payload spread alongside:
POST /screen, whose
result object is the body directly, with no envelope.
Request ids
Every API request is audited and answered with anX-Request-Id response
header (a UUIDv7). Quote it to support, or look the request up in
Settings → Developers later.
Every data call is auditable by that one id: the original request payload
(including any classify image) and the produced result are stored and
retrievable via GET /api/requests/{id} (+ /body for the archived payload).
This covers classify (single, bulk, regulator), calculate (single, stacking,
multiple), screen, restrict, CDS, and consignment assessments. Runs that never
travel over HTTP — flow actions, bulk-file rows, background workflows — are
recorded under a generated UUIDv7 with source internal or flow (bulk-file
rows link to the run’s originating request id), so the same lookup works for
every classification or calculation the platform ever produced.
Resources
Classify, calculate, restrict, and screen are first-class resources on the
same base URL — one token, one host, one contract.