Webhooks

MendriX can push events to your HTTPS endpoint as they happen, so you do not have to poll for every change. Webhooks are configured inside the TMS, not through a REST registration API.

How webhooks are configured

In the MendriX TMS, a webhook is an Event–Consequence pair:

• an Event (something happened, e.g. order accepted), paired with
• the consequence “Post message to URL (webhook)”.

There is no self-service REST registration. To set up a webhook, ask your MendriX TMS administrator to configure the Event–Consequence pair pointing at your endpoint URL.

For each webhook the administrator configures:

• the event that triggers it,
• your destination URL,
• the payload template (an XSLT export template — see Payloads below),
• the outbound authentication (see below).

Event types

Webhooks can be triggered by many TMS events, including:

• Order lifecycle — order created, accepted, rejected, finished.
• Order trace — scan/trace status changed.
• Tasks — task status changed, task completed.
• Rides — ride started, ride finished.
• Appointments — appointment status changed.
• Alerts & timing — temperature alerts, ETA / late-notification events, timers.

Which events are available and relevant depends on your TMS configuration; your administrator can tell you exactly which ones can be wired up.

Payloads

The payload is the order (or ride) data transformed by a configurable XSLT export template into the shape you want:

• Format: JSON or XML — whichever the template produces.
• Content-Type: application/json; charset=utf-8 or application/xml; charset=utf-8 accordingly.
• User-Agent: MendriX.
• Shape: customer-defined. Because the body is produced by your XSLT template, its exact structure is agreed during onboarding rather than fixed by this portal.

Design your consumer defensively

Since the payload shape is template-defined, parse defensively and treat the webhook as a notification/trigger: on receipt, call the REST API to fetch the authoritative current state of the referenced order or task rather than trusting the payload alone.

Outbound authentication

Because MendriX calls your endpoint, you choose how it authenticates. The supported outbound auth options are:

• None
• Basic
• Bearer
• Digest
• OAuth2

No HMAC payload signing

MendriX does not HMAC-sign webhook payloads. Authenticity relies on the chosen authentication method plus TLS. Protect your endpoint by requiring one of the auth methods above, serving it only over HTTPS, and — where possible — restricting inbound access to MendriX.

Delivery and retries

A delivery is considered failed on:

• 5xx responses,
• 408 Request Timeout,
• 429 Too Many Requests,
• connection timeouts.

On failure, MendriX retries with a capped back-off:

Attempt	Wait before retry
1st retry	1 minute
2nd retry	15 minutes
subsequent	120 minutes (capped)

Retries continue until the delivery job exceeds MaxAgeInHours (default 8 hours, configurable from 1 hour to 2 weeks). After that the job is abandoned.

Other 4xx (except 408/429) and 3xx responses are treated as permanent and MendriX gives up immediately — so make sure your endpoint returns a 2xx on success.

Make your endpoint reliable

• Respond fast with 2xx. Acknowledge quickly, then process asynchronously; slow handlers risk the timeout retry path.
• Be idempotent. A retried delivery may arrive more than once; de-duplicate on a stable key from the payload.
• Reconcile. Combine webhooks with a periodic since= sync so a missed delivery (endpoint down longer than MaxAgeInHours) is still eventually caught.

See Order status & track-and-trace for a worked example that consumes order events and falls back to polling.