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.

Order status is a SOAP-only read today

The REST Order service only exposes PATCH (update) endpoints and the unrelated rank purchase options endpoint (which ranks operator/product combinations by price for an order — it has nothing to do with order or task status). There is no REST endpoint to read an order’s or task’s current status yet. Use the SOAP Custom Link’s RequestOrdersNormal(Ids) for order/task state and RequestTracesGoods for scan events, as shown below, until a REST read endpoint ships.

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 SOAP Custom Link 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 (curl)

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 (SOAP)

After a webhook (or on a schedule), call the Custom Link to get the order’s current fields and task statuses. This is a two-step SOAP call: request the matching Ids, then request the full order data for them — see Order retrieval & sync for the full field reference. For scan-level events (pickup scanned, delivered, …), use RequestTracesGoods — see Traces (track & trace).

Manual (curl)

Request the full order (including its tasks) by Id:

<?xml version="1.0" encoding="windows-1252"?>
<EoCustomLinkRequestOrdersNormal Type="TEoCustomLinkRequestOrdersNormal">
  <Nested>False</Nested>
  <Filter Type="TEoFilterOrdersNormal">
    <KeysExplicitAsCsv>ORDER_ID</KeysExplicitAsCsv>
  </Filter>
</EoCustomLinkRequestOrdersNormal>

Entity-escape this payload into the ARequest parameter of the ExecuteRequest SOAP operation and POST it to the Custom Link endpoint — see how calls work and the server time example for the full envelope and a working curl command.

For scan events on the order’s goods, call RequestTracesGoods with OrderIdsAsCsv set to the order Id — see Traces (track & trace).

n8n

Custom Link calls in n8n use the same four-node shape as every other Custom Link command — see Using n8n with Custom Link for the general pattern. Swap the envelope-building node’s payload for EoCustomLinkRequestOrdersNormal (shown above) or EoCustomLinkRequestTracesGoods, and wire the order id in from the webhook.

Importable workflow: order-status-tracking.json — receives the webhook, then calls RequestOrdersNormal via Custom Link for the order’s current state.

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 using the same SOAP calls as Step 2:

Manual (curl)

On a schedule, call RequestOrdersNormalIds with SequenceMinimum set to the highest Sequence value you’ve already processed — see incremental sync — then RequestOrdersNormal for the full data of any new Ids, and reconcile against your local copy.

n8n

Add a Schedule Trigger (e.g. every 15 minutes) before the SOAP call nodes from Step 2, using the same SequenceMinimum incremental-sync pattern to catch anything a webhook missed.

Recommended pattern

1. Webhook → enqueue the order id.
2. SOAP read (RequestOrdersNormal / RequestTracesGoods) → fetch authoritative status, update your system.
3. Scheduled SequenceMinimum sweep → safety net for missed deliveries.
4. Make every write idempotent so duplicate signals are harmless.