WEBHOOKS
Receive real-time events from Superroute — orders, status changes, tracking updates. With signed payloads, automatic retries, and a built-in debugger.
A webhook is an HTTP POST that Superroute sends to a URL you configure whenever something happens — an order is created, a delivery is completed, a tracking event is recorded. You build a receiver endpoint, we deliver the event there.
Events are queued and sent asynchronously. Each request carries an HMAC-SHA256 signature so you can verify it really came from us. Failed deliveries (non-2xx response or timeout) are retried with exponential backoff up to 5 times.
You configure a shared secret on the settings page. Every outgoing webhook is signed with that secret. Your receiver recomputes the signature and compares — if they match, the payload is genuine and untampered.
Five outbound event types are available. Each has its own URL field on your settings page — you can subscribe to any subset.
Fires whenever a local-delivery order (Delivery / Pickup / P2P) is created via any path — web form, REST/GraphQL API, ecommerce platform sync, automatic rules, import rows, etc. Excludes label-service and other non-delivery order types. Skipped in batch flow when order_create_async_postback_url is also configured for the same recipient. Configure with order_create_webhook_url.
Payload ExamplesFires on every order status transition — picked up, in transit, delivered, exception, cancelled. Configure with order_status_change_webhook_url.
Payload ExamplesFires on each tracking lifecycle event recorded against a package (information submitted, start delivery, delivery success, not delivered, etc.). Configure with tracking_event_webhook_url. Delivered and picked-up events also carry the proof of delivery: proof_files plus proof_files_detail (file_id, type, url, full_url, signed download URL). Photos uploaded after the event arrive as pod.files_updated.
Payload ExamplesFires once after a batch order import finishes processing. Payload contains the per-row results array. Configure with order_create_async_postback_url.
Payload ExamplesFired when a delivery photo or signature is added, replaced or removed (action: added / updated / removed) — one delivery per file, no more polling for attachments. Opt-in via pod_files_webhook_url.
Payload ExamplesFired when an order is permanently deleted, so your system can mirror the removal. Opt-in via order_deleted_webhook_url.
Payload ExamplesFired when a cancel attempt is rejected (for example the order is already out for delivery), so your ops pipeline can monitor failed cancels without polling API responses. Opt-in via order_cancel_failed_webhook_url.
Payload ExamplesA separate webhook channel for third-party delivery partners integrating with smart lockers. Events are delivered to the endpoint configured for your partner account, and each endpoint can subscribe to any subset of event types.
Doors Opened — Fires the moment compartment doors open for a delivery attempt — whether the courier used the locker screen with the access code or the remote-open API — including reassignment re-openings. The opening block lists every opened compartment with its grid_id, hardware compartment_number and pickup_locker_number (sequential display number counted top-to-bottom within a column, then left to right).
Payload ExamplesDelivered to Locker — Fires when a drop-off is confirmed and the parcels are in the locker. The payload includes the recipient pickup code.
Payload ExamplesPicked Up — Fires when the recipient has collected the deposited packages.
Payload ExamplesDelivery Failed — Fires when a delivery fails; per-package failure codes are included.
Payload ExamplesExpired — Fires when an unused delivery code or an uncollected deposit passes its expiry time.
Payload ExamplesCancelled — Fires when a delivery is cancelled before completion.
Payload ExamplesCorrection Reopened — Fires when the deposited compartments are reopened within the correction window to fix a wrong placement — from the locker screen or via the API. The correction block lists the reopened compartments.
Payload ExamplesSignature & Verification: Partner locker webhooks use their own signing scheme: X-Webhook-Signature is base64(HMAC-SHA256(secret, timestamp + "\n" + delivery id + "\n" + raw body)), where the timestamp and delivery id come from the X-Webhook-Timestamp and X-Webhook-Delivery-Id headers. Also verify X-Webhook-Content-Digest (SHA-256 of the body) and reject stale timestamps. X-Webhook-Id stays stable across retries — use it for idempotency.
How to Configure: Endpoints are managed under Third-Party Delivery → Partner Locker → Settings, one endpoint per partner, with a selectable event list. Failed deliveries are retried with exponential backoff for up to 7 attempts before dead-lettering; dead-lettered events can be retried manually from the Events page.
You can configure webhooks at two levels: at the business level (covers everything) or per customer (overrides for that specific B2B sub-account).
Log in and go to Settings → API & Webhooks. Customer-level overrides are on the customer detail page.
Pick any string at least 16 characters long, ideally 32+ random bytes. This secret is what your receiver will use to verify signatures.
Fill in only the URLs for events you care about. Leave the rest blank to skip them.
webhook_sign_secretYou configure a shared secret on the settings page. Every outgoing webhook is signed with that secret. Your receiver recomputes the signature and compares — if they match, the payload is genuine and untampered.order_create_webhook_urlFires whenever a local-delivery order (Delivery / Pickup / P2P) is created via any path — web form, REST/GraphQL API, ecommerce platform sync, automatic rules, import rows, etc. Excludes label-service and other non-delivery order types. Skipped in batch flow when order_create_async_postback_url is also configured for the same recipient. Configure with order_create_webhook_url.order_status_change_webhook_urlFires on every order status transition — picked up, in transit, delivered, exception, cancelled. Configure with order_status_change_webhook_url.tracking_event_webhook_urlFires on each tracking lifecycle event recorded against a package (information submitted, start delivery, delivery success, not delivered, etc.). Configure with tracking_event_webhook_url. Delivered and picked-up events also carry the proof of delivery: proof_files plus proof_files_detail (file_id, type, url, full_url, signed download URL). Photos uploaded after the event arrive as pod.files_updated.order_create_async_postback_urlFires once after a batch order import finishes processing. Payload contains the per-row results array. Configure with order_create_async_postback_url.pod_files_webhook_urlFired when a delivery photo or signature is added, replaced or removed (action: added / updated / removed) — one delivery per file, no more polling for attachments. Opt-in via pod_files_webhook_url.order_deleted_webhook_urlFired when an order is permanently deleted, so your system can mirror the removal. Opt-in via order_deleted_webhook_url.order_cancel_failed_webhook_urlFired when a cancel attempt is rejected (for example the order is already out for delivery), so your ops pipeline can monitor failed cancels without polling API responses. Opt-in via order_cancel_failed_webhook_url.What’s new in the API and webhooks — idempotent cancel, reconciliation feeds, v2 signatures, new events — with copy-paste examples. Everything is fully backward compatible.
Every outgoing webhook carries a hex-encoded HMAC-SHA256 signature in the request header. Your receiver must recompute the signature over the raw request body using the shared secret, and reject the request if it does not match.
Your endpoint should respond with a 2xx status quickly. If it returns anything else, times out, or is unreachable, the delivery is retried.
Paste a payload you received from us along with the Signature header value and your secret — this tool recomputes the signature in your browser (nothing leaves this page) and tells you if it matches.
Fire a real, properly-signed webhook from our server to a URL you provide. Use this to test that your receiver is reachable, that you parse the payload correctly, and that your signature verification logic works.
View the most recent webhook delivery attempts on your account — both real production events and tests sent from this page. Paste your Bearer token to load.
| Time | Event | URL | Status | HTTP | Attempt | Time (ms) | Test? | Actions |
|---|---|---|---|---|---|---|---|---|
| No webhook deliveries found yet. | ||||||||