Webhook Events & Verification
Webhook Events & Verification
Webhook Events & Verification
Register a webhook endpoint to receive real-time delivery status updates instead of polling.
Webhook registration is account-scoped: a single webhook configuration is shared across every store in your organization. The x-retailer-id header is not used on /dd/v1/webhooks — only your API key is required.
Setup
The response includes a signing secret (prefixed alwh_). Store it securely — it is only shown once. If you need to rotate your secret later, call PUT /dd/v1/webhooks with { "rotate_secret": true }; the new secret is returned in full.
URL requirements
The url you register must:
- Use
https://(plainhttp://is rejected). - Use a hostname, not a bare IP literal (IPv4 or IPv6).
- Resolve to a publicly routable address — loopback, RFC1918 private, link-local, multicast, and CGNAT ranges are rejected.
Invalid URLs are rejected at registration with 400:
detail is one of INVALID_URL, NOT_HTTPS, BARE_IP_REJECTED, DNS_RESOLUTION_FAILED, or BLOCKED_TARGET. The same validation runs again at dispatch time on every delivery attempt, so a hostname whose DNS record later flips to a private address will stop delivering rather than be exploited.
Events
Payloads
When an event fires, Autolane sends a POST request to your registered URL with a JSON body. Use the external_delivery_id field to correlate events with the order_id you supplied when creating the delivery.
pickup_status.changed
The vehicle_location field is only present if your webhook is subscribed to pickup.vehicle_location.changed. When subscribed, it’s an object with a fresh fix (≤ 5 minutes old), or null when no fresh fix is available or no vehicle is assigned yet. If your webhook isn’t subscribed to the location event, the field is omitted entirely.
tracking_link.created
pickup.vehicle_location.changed
recorded_at is when the underlying telemetry sample was taken (ISO 8601). It may lag the outer timestamp by a few seconds — use timestamp to order events relative to each other, and recorded_at if you need the precise moment of the GPS fix.
The event fires on two triggers while a delivery is in the active window (EN_ROUTE_TO_STORE, ARRIVED_AT_STORE, WAITING_FOR_LOAD, LOADED, EN_ROUTE_TO_CUSTOMER):
- Movement-driven: the vehicle has moved enough since the last fix (~50 m).
- Heartbeat: at least 60 seconds have elapsed since the last emit, even if the vehicle is stationary.
The event stops firing automatically once the delivery transitions to ARRIVED_AT_CUSTOMER, COMPLETED, FAILED, or CANCELLED. No action is required on your end to unsubscribe per-delivery.
Event ordering note
Webhook delivery is at-least-once with no cross-type ordering guarantee. A pickup.vehicle_location.changed event may arrive shortly after a terminal pickup_status.changed for the same delivery — reconcile relative ordering using the timestamp field rather than receive-order.
Each request includes these headers:
Your endpoint should return any 2xx status code to acknowledge receipt. Non-2xx responses trigger retries.
Verifying Signatures
Use the signing secret from your webhook registration to verify that each delivery is authentically from Autolane. The X-Autolane-Signature header contains an HMAC-SHA256 hex digest of the raw request body, computed using your alwh_-prefixed secret.
Always verify signatures using a timing-safe comparison to prevent timing attacks:
Idempotency
Each delivery includes an X-Autolane-Delivery-Id header — a UUID that stays the same across retries. Store processed delivery IDs and reject duplicates to ensure idempotent handling.
Retries
Failed deliveries (non-2xx responses or timeouts) are retried up to 7 times with exponential backoff.