WebHook Events
The Events section of the API documentation provides an overview of the various events that customers can subscribe to in order to receive real-time updates about key activities and changes within the system. To subscribe to these events make use of the webhook endpoints. Each event follows the same message layout as the data that would be returned by the corresponding GET operation, providing consistency to the processing of data.
The webhook services do not guarantee the arrival order of webhook events because network latency or temporary system downtime can scatter delivery. To handle event ordering reliably in your application, you must use the internal timestamps provided in the event payloads rather than relying on the sequence in which your API endpoint receives the HTTP requests.
The following events can be subscribed to:
| event | description |
|---|---|
orderItem.cancelled.3 | Triggered whenever an orderItem quantity was modified downward as a result of fulfilment strategy execution, manually changes in Maya, or the respective ShopApi endpoints DELETE v3/orders/:id or DELETE v3/orderItems/:id. |
shipment.created.3 | Triggered whenever a shipment has been created, stock is assigned, but no label has been requested yet. The message model of the webhook will follow the GET v3/shipments/{id}?include=shipmentItems endpoint. |
shipment.readyToPick.3 | Triggered whenever a shipment is ready to be picked and packed. The message model of the webhook will follow the GET v3/shipments/{id}?include=shipmentItems endpoint. |
shipment.readyToShip.3 | Triggered whenever a shipment has been picked and packed and is ready for pick-up by the carrier. The message model of the webhook will follow the GET v3/shipments/{id}?include=shipmentItems endpoint. |
shipment.shipped.3 | Triggered whenever a shipment has been handed over tot he carrier. The message model of the webhook will follow the GET v3/shipments/{id}?include=shipmentItems endpoint. |
tracking.updated.3 | Triggered whenever the carrier updates the tracking information of a shipment. The model of a tracking even follows this structure. |
inbound.processing.3 | Happens when an inbound is created. |
inbound.checking.3 | Happens after the operator clicks 'complete entire inbound', happens once per inbound and regardless if there are differences with the packing slip. |
inbound.checkingUpdate.3 | Happens every time an inbound changes state from 'DIFFERENCE_GOODS_RECEIVING' (aka 'INBOUND RECOUNT') to either 'OK' or 'INBOUND CHECKED'. |
inbound.checked.3 | Happens when all locations of the inbound have been checked. Note: changes to the inbound are still possible! |
inbound.processed.3 | Happens when the inbound is closed. No more changes are possible and this is the final state. |
orderItem.cancelled.3
Triggered whenever an order line (item) was cancelled. This might occur resulting fulfilment strategy execution, manually triggered from Maya, or the respective ShopApi endpoints DELETE v3/orders/:id or DELETE v3/orderItems/:id. The message model of the webhook will follow the existing message model of the webhook GET v3/orderItems/:id endpoint, with the additional attribute origin that tells where the cancellation came from.
shipment.created.3
Triggered whenever a shipment has been created, stock is assigned, but no label has been requested yet.
shipment.readyToPick.3
Triggered whenever a shipment is ready to be picked and packed.
shipment.readyToShip.3
Triggered whenever a shipment has been picked, packed and sorted, ready for pick-up by the carrier
shipment.shipped.3
Triggered whenever a shipment has been handed over to the carrier.
tracking.updated.3
Triggered whenever a carrier notifies a change in the state of the delivery of a shipment.
inbound.processing.3
Happens when an inbound is created.
inbound.checking.3
Happens after the operator clicks 'complete entire inbound', happens once per inbound and regardless if there are differences with the packing slip.
inbound.checkingUpdate.3
Happens every time an inbound changes state from 'DIFFERENCE_GOODS_RECEIVING' (aka 'INBOUND RECOUNT') to either 'OK' or 'INBOUND CHECKED'.
inbound.checked.3
Happens when all locations of the inbound have been checked. Note: changes to the inbound are still possible!
inbound.processed.3
Happens when the inbound is closed. No more changes are possible and this is the final state.