Webhooks

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.

Fires on every order status transition — picked up, in transit, delivered, exception, cancelled. Configure with order_status_change_webhook_url.

Fires 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. Each file also carries its event context: tracking_event_id, tracking_event_status_id, tracking_event_key, service_type (1 = delivery / 2 = pickup) and service_status (1 = success / 2 = failed), all null for legacy files without a recorded event.

Fires once after a batch order import finishes processing. Payload contains the per-row results array. Configure with order_create_async_postback_url.

Fired 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. Each file also carries its event context: tracking_event_id, tracking_event_status_id, tracking_event_key, service_type (1 = delivery / 2 = pickup) and service_status (1 = success / 2 = failed), all null for legacy files without a recorded event.

Fired when an order is permanently deleted, so your system can mirror the removal. Opt-in via order_deleted_webhook_url.

Fired 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.

Fired whenever a Route Board seat changes hands or the board changes state — action tells you what happened (claimed, standby, pooled, promoted, withdrawn, vetoed, replaced, assigned, awarded, lost, displaced, settled, board_opened, board_closed, board_cancelled). Business-level only. Opt-in via route_board_webhook_url.

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). Each compartment also carries pickup_locker_code — the "{shelf_code}-{pickup_locker_number}" label the recipient is sent to, null when the compartment has no pickup number. The payload also includes pickup_code — the recipient pickup code, allocated the moment the doors open; it remains the same code after the courier confirms the deposit, and only becomes usable for pickup once the deposit is confirmed.

Delivered to Locker — Fires when a drop-off is confirmed and the parcels are in the locker. The payload includes the recipient pickup code. Each compartment also carries pickup_locker_code — the "{shelf_code}-{pickup_locker_number}" label the recipient is sent to, null when the compartment has no pickup number. For doors opened through the remote-open API the deposit is settled by the platform as soon as the cabinet reports every opened door closed, so this event fires without a confirm call; confirmed_by names the path that settled: courier_terminal, partner_api, door_close, timeout_door_closed or console.

Picked Up — Fires when the recipient has collected the deposited packages.

Delivery Failed — Fires when a delivery fails; per-package failure codes are included.

Expired — Fires when an unused delivery code or an uncollected deposit passes its expiry time.

Cancelled — Fires when a delivery is cancelled before completion.

Correction 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. Each compartment also carries pickup_locker_code — the "{shelf_code}-{pickup_locker_number}" label the recipient is sent to, null when the compartment has no pickup number.

partner_locker_delivery.event_type_code_rotated — Fires when the partner rotates a delivery's access code or pickup code. The rotation block names which code was replaced, when, and whether the recipient notification was re-sent — the new code itself never travels in a webhook; it is revealed only in the direct rotation API response.

Assignment Created — Fires when an order is assigned to the provider — by an automatic rule or manually. The payload carries the assignment number, order identifiers and package tracking numbers.

Packages Handed Over — Fires when the warehouse has physically handed all packages of the assignment over to the provider.

Assignment Cancelled — Fires when the platform withdraws an assignment from the provider. The reason field distinguishes cancelled (the assignment was cancelled at the carrier), fallback_to_self_delivery (the platform took the order back into self delivery) and reassigned (the order was moved to another provider).

Partially Delivered — Fires when part of a shipment has been delivered while other packages are still in progress. The packages array carries each parcel's outcome, and legs lists the external orders booked with the carrier — one per package when the carrier does not accept multi-piece shipments.

A driver was assigned to the order (manually, by route planning or by automatic assignment). data.source = auto_assign when the orchestrator did it.

The order lost its driver (hand-off, revoke, rejection, time-out). data.previous_driver_id tells who had it.

The driver accepted an auto-assigned order in the app (driver duty with acceptance required).

The driver rejected an assigned order; data.reason carries the optional free-text reason.

The driver started the pickup (status Start Pickup / Out for Pickup).

The parcel was picked up (status Already Picked Up).

The parcel is on the way to the recipient (status Start Delivery / Out for Delivery).

The delivery succeeded (status Successful).

The delivery attempt failed (Redelivered Later, Need Rescheduled, Rejected by Recipient).

The order was cancelled.

Staff (or a driver, when allowed) marked the order ready for pickup (Dispatch Options → ready for pickup).

A driver went on or off duty in the app (driver duty option).

A driver position from the app or tracker, throttled per driver by driver_location_min_interval_sec (default 60 s). Sent to driver_location_webhook_url only.

A parcel was placed in the machine and is waiting for the next person (recipient, courier or operator, see data.device_order.next_actor). due_at is the collection deadline.

The parcel was taken out by the person it was waiting for — the recipient, the courier or staff emptying a smart drop.

Staff took the parcel out of the machine. removal_reason says why: overdue_return, handover, relay, anomaly or recovery.

The parcel passed its due_at without being collected. It is still in the machine and its code still works; overdue_at is set and next_actor becomes operator.

A problem was opened on the handling (for example door_left_open, deposit_unverified, item_missing, overdue). data.exception carries id, type, severity and status.

A person closed a problem on the handling. data.exception.status is resolved or dismissed and resolution_action says what was done.