Getting started with Track & Trace

The Track & Trace API scopes every call to a single shipment through an mxtt_traceinfo cookie. Unlike the rest of the MendriX REST API, there is no API-token exchange and no bearer token — you obtain a cookie by presenting a shipment’s trace credentials, then send that cookie on every subsequent call.

Host has no api. prefix

The Track & Trace host is https://<your-client-name>.mendrix.cloud — note there is no api. in the DNS name for this API (unlike the REST API and Driver API). Replace <your-client-name> with the client name assigned by MendriX.

How the trace session works

1. Start a trace session. Perform a GET on the entry point https://<your-client-name>.mendrix.cloud/WorldLink/TrackAndTrace/ with the shipment’s trace credentials as query parameters. On a successful lookup the response carries a Set-Cookie: mxtt_traceinfo=<value> header.
2. Reuse the cookie. Send that cookie on every call under https://<your-client-name>.mendrix.cloud/WorldLink/TrackAndTrace/v1 (address, goods, milestones, traces, appointment, and so on).

The entry point sits above /v1

The session entry point is /WorldLink/TrackAndTrace/ — one level above the /v1 prefix that all the data endpoints use.

Two ways to identify a shipment

Tracecode is always required. Combine it with either of:

Flow	Query parameters
Trace code + order id	Tracecode + Orderid
Trace code + address	Tracecode + Postalcode + Number (house number)

The server validates the combination against the order; only a matching shipment yields data.

Read a shipment’s milestones

Manual (curl)

CLIENT="your-client-name"           # the client name assigned by MendriX
BASE="https://$CLIENT.mendrix.cloud/WorldLink/TrackAndTrace"
TRACECODE="MXTTF5F23DD15103C8BE"
POSTALCODE="5171KW"
NUMBER="1"

# 1. Start the trace session and capture the mxtt_traceinfo cookie
curl -s -c cookies.txt \
  "$BASE/?Tracecode=$TRACECODE&Postalcode=$POSTALCODE&Number=$NUMBER" \
  -o /dev/null

# 2. Call a v1 endpoint with the stored cookie
curl "$BASE/v1/Milestones" \
  -b cookies.txt \
  -H "Accept: application/json"

n8n

n8n does not need a login/credential node for Track & Trace — the cookie is issued by the entry-point request and carried forward automatically.

1. Config (Set node) — store client, tracecode, postalcode and number as workflow values so the URLs stay configurable.
2. Start trace session (HTTP Request node) — GET https://{{$json.client}}.mendrix.cloud/WorldLink/TrackAndTrace/ with query parameters Tracecode, Postalcode and Number (or Tracecode + Orderid). Turn on “Response → Include Response Headers and Status”, and enable the node option Enable Cookies (Settings → Response → Full Response, and the built-in cookie jar) so the mxtt_traceinfo cookie is retained for the next request.
3. Get milestones (HTTP Request node) — GET https://{{$json.client}}.mendrix.cloud/WorldLink/TrackAndTrace/v1/Milestones. With cookies enabled on the same workflow execution, n8n replays the mxtt_traceinfo cookie automatically; no Authorization header is needed.

If your n8n version doesn't share a cookie jar

Some n8n setups don’t persist cookies between HTTP Request nodes. In that case, read the set-cookie value from the entry-point node’s response headers ({{ $json.headers['set-cookie'] }}) and take everything after the first = up to the first ; — the value contains Base64 padding and a .-separated signature, so splitting on every = truncates it — then set that as a Cookie header on the milestones request.

Extract it per execution rather than storing it as a workflow value: cookies stop being accepted after a MendriX upgrade, because the signing key is regenerated on install. A rejected cookie is treated as if none was sent, so start a new trace session instead of replaying an old value.

How the cookie is protected

The mxtt_traceinfo cookie value is a Base64-encoded JSON object followed by a . and an HMAC-SHA256 signature over that payload. The signing key is per installation, so the cookie cannot be forged or tampered with: a cookie with a missing or invalid signature is rejected and treated as if no cookie was sent. You therefore don’t have to defend against a caller editing the cookie to point at a different shipment — the server does that for you.

It is issued as a session cookie with Path=/ and SameSite=Lax, plus Secure when the request arrived over HTTPS. It is deliberately not HttpOnly, because the portal front-end reads it.

The payload is signed, not encrypted: it carries the trace credentials you sent (trace code, and the order id or postcode + house number) in readable form. A cookie value is therefore exactly as sensitive as the trace link it came from — no more, no less. Treat a trace link like any other capability link: send it only to the recipient, and always over HTTPS.

Rate limiting

Failed trace lookups are throttled per client IP. Once too many lookups with unknown trace credentials arrive from one IP within a short window, further lookups from that IP are rejected with 429 Too Many Requests carrying a Retry-After header with the number of seconds to wait; the body is the usual Code/Msg error object. Read Retry-After instead of hard-coding a back-off — the window is a server-side setting.

Normal portal traffic is unaffected:

• Successful lookups are not counted, so repeatedly opening a valid trace link is never throttled.
• Calls that already carry an mxtt_traceinfo cookie are exempt, so polling /v1/Milestones for a live shipment never consumes the budget.

Rescheduling an appointment

The appointment flow is a multi-step “concept” process: propose a new date or address as a concept, confirm it, and — when the reschedule carries an extra cost — complete a Mollie payment before the final confirmation. Every step is documented in the interactive reference under the Appointment and Payment tags.

Next steps

• Browse every endpoint in the interactive reference — address, goods, milestones, traces, live route, task instructions, and the full appointment/payment reschedule flow.