Webhooks | Rendr | Documentation

Rendr provides real-time delivery status updates through webhooks, enabling seamless integration with your systems. As a delivery progresses through key stages — such as booked, assigned, collected, and delivered — Rendr automatically emits structured JSON payloads to your configured webhook endpoint.

Webhook endpoint configuration and payload structure are set up during onboarding. To configure or update your webhook settings, contact your Rendr implementation partner.

For a conceptual overview of how Rendr emits webhook events throughout the delivery lifecycle, see Notifications & Live Tracking in the Key Concepts section.

Webhook Payload

Each webhook is an HTTP request to your endpoint with a JSON body describing the delivery’s latest status.

Webhook payload

{
    "status": "delivered",
    "reference": "myorder-001",
    "delivery_id": "Qq1TkY0xXbDWscq99BHe",
    "updated_at": "2026-02-04T14:32:10+11:00",
    "label_url": "https://static.rendr.delivery/XXXXXX",
    "eta": "2026-02-04T16:24:10+11:00",
    "delivery_verification_url": "https://static.rendr.delivery/XXXXXX"
}

Field	Type	Description
`status`	String	The delivery’s current status. See Status Lifecycle for every possible value.
`reference`	String	Your reference for the delivery, as supplied when it was created.
`delivery_id`	String	The unique ID Rendr assigned to the delivery.
`updated_at`	String	When the delivery was last updated.
`label_url`	String	URL of the shipping label. Set only when a label is available.
`eta`	String (ISO 8601)	The estimated delivery time. Set only when an estimate is available.
`delivery_verification_url`	String	A URL relating to verification of the delivery. Set only when the data is available.

The payload has the same structure for every status — only the values change as the delivery progresses. Use delivery_id or reference to match the event to your own records, and status to decide what to do with it.

Conditional fields

label_url, eta and delivery_verification_url are set conditionally. Rendr only populates each one when the underlying data is available at the time the webhook is sent, so they will not be present on every event. When the data isn’t available, the field is empty.

Don’t assume any of these fields is populated. Check each one before you use it.

Verifying Webhooks

To verify that a webhook is from Rendr, you provide Rendr with an authorization key during setup. Rendr uses this key when it calls your endpoint.

Check the key on every incoming request, and reject any request that does not carry it.

Treat the authorization key like a password. Don’t expose it in client-side code or logs, and tell your Rendr implementation partner if you need to rotate it.

Retries

If a webhook delivery fails, Rendr retries it automatically with exponential backoff.

Setting	Value
Maximum retries	10
Initial delay	1 second
Backoff multiplier	3
Maximum delay	90 seconds

The delay between attempts grows by a factor of three each time, until it reaches the 90 second maximum:

Retry	1	2	3	4	5	6–10
Delay	1s	3s	9s	27s	81s	90s

All 10 retries take place within roughly 9½ minutes of the first failed attempt.

Handling retries

Respond with a 2xx status as quickly as possible, and do any slow processing after you’ve responded.
Make your handler idempotent. Retries mean you may receive the same event more than once, so use delivery_id, status and updated_at to detect duplicates.