Postman collection

A ready-to-run collection with one request per endpoint, ordered the way a real integration performs them. Run top to bottom and you have covered the whole flow, from credentials to a cancelled delivery. Each request carries assertions, so a green run is evidence rather than a guess.

Download the collection

Import it into Postman with File → Import and drop the file in.

Setup

Two variables, both issued when your integration application is approved:

Variable	Where to find it
clientId	In your approval e-mail. Not secret.
clientSecret	In your approval e-mail, prefixed hzl_test_. Stored nowhere else — if you lose it, ask for a new one.

baseUrl already points at sandbox. Everything else fills itself in as the run proceeds: the token request stores the bearer token, store registration stores the fleet id, order creation stores the order id.

Sandbox credentials only

Do not run this collection with a hzl_live_ secret. Orders placed in production dispatch a real courier and are billed to the fleet.

What is inside

#	Request	Covers
1	POST /token	Exchanges credentials for a token valid one hour
2	PUT /stores/{externalStoreId}	Registers the store and lists the fleets serving it
3	PUT /stores/{externalStoreId}	Attaches the chosen fleet
4	POST /orders	Creates the delivery request
5	GET /orders/{orderId}	Returns current status and event history
6	POST /orders/{orderId}/cancel	Cancels the delivery

Run them in order. Each request produces what the next one needs: a store must exist before an order can be placed, and an order must exist before it can be queried or cancelled.

Requests 2 and 3 hit the same endpoint. That is the point: fleet selection needs no endpoint of its own. The first call omits fleetId and returns the fleets serving that address; the second attaches the one the restaurant chose.

Error codes and sandbox scenarios are deliberately out of scope here. They are documented, with the conditions that trigger them, under Errors and Sandbox.

Assertions worth knowing about

Some tests check things that are easy to miss by eye:

• The access token is decoded and checked for the absence of a role claim. If it carried one, it could one day satisfy a role check somewhere it should not.
• Fleet discovery is checked for leaked contact details — phone, e-mail, tax number and polygons must not appear.
• Cancellation accepts both 200 and 409 CANCEL_TOO_LATE as correct. The sandbox courier collects the package at +30s; a cancel sent after that second is supposed to be refused.

Keeping it honest

The collection is generated against the OpenAPI specification. Where the two disagree, the specification wins — and please tell us, because it means we have drifted.