Order status & track-and-trace

Once an order is in MendriX, you usually want to know when its status changes: accepted, on the way, delivered, and every scan in between. The recommended pattern is webhooks for immediacy + polling as a safety net.

Treat the webhook as a trigger

Webhook payloads are shaped by a per-customer XSLT template (details). Treat each webhook as a “something changed” signal and then call the REST API for the authoritative state, rather than relying on the payload’s exact shape.

Step 1 — Receive status events (webhooks)

Ask your MendriX administrator to configure the relevant Event–Consequence pairs pointing at your endpoint. Useful events for tracking:

• order accepted / rejected / finished,
• order trace (scan status) changed,
• task status changed / task completed,
• ETA / late-notification events.

Manual (REST)

Expose an HTTPS endpoint that returns 2xx quickly, then processes asynchronously:

import express from 'express';
const app = express();
app.use(express.json());        // or express.text() for XML templates

app.post('/webhooks/mendrix', (req, res) => {
  // 1) Acknowledge fast so MendriX does not retry.
  res.sendStatus(204);

  // 2) Extract the order id from the payload (shape is tenant-defined) and
  //    fetch the authoritative state from the REST API.
  const orderId = req.body.orderId ?? req.body.OrderId;
  queue.add(() => refreshOrder(orderId));
});

app.listen(8080);

Secure the endpoint with one of the supported outbound auth methods (Basic, Bearer, Digest, OAuth2) — MendriX does not HMAC-sign payloads. See Webhooks.

n8n

1. Add a Webhook trigger node; note its production URL and give it to your MendriX administrator as the consequence URL.
2. Set the webhook’s Authentication to match what the administrator configured (e.g. Header/Basic auth).
3. Respond immediately (Webhook node → Respond: Immediately, 204).
4. In the following nodes, read the order id from the payload and add an HTTP Request node to fetch the current order state from the REST API.

Importable workflow: order-status-tracking.json.

Step 2 — Fetch the authoritative state

After a webhook (or on a schedule), read the order and its tasks via REST to get the current status:

Manual (REST)

# Rank / inspect an order's data via the Order service.
curl "$MENDRIX_BASE/order/orders/ORDER_ID/rank-purchase-options" \
  -H "Authorization: Bearer $MENDRIX_ACCESS_TOKEN"

The exact read endpoints and their fields are in the REST API reference; use the Order service to inspect orders and tasks.

n8n

Add the Get access token login node (see Using n8n), then an HTTP Request node (GET) against the relevant Order endpoint with the Authorization: Bearer …access header, using the order id from the webhook.

Step 3 — Polling fallback

Webhooks can be missed (endpoint down longer than the retry window — see the retry policy). Run a periodic sweep as a safety net:

Manual (REST)

Use an incremental since= sweep on a schedule to catch anything a webhook missed, and reconcile against your local copy.

n8n

Add a Schedule Trigger (e.g. every 15 minutes) → HTTP Request with since= → reconcile. This complements the webhook workflow above.

Recommended pattern

1. Webhook → enqueue the order id.
2. REST read → fetch authoritative status, update your system.
3. Scheduled since= sweep → safety net for missed deliveries.
4. Make every write idempotent so duplicate signals are harmless.