How it works
How Danoffice IT Commerce Cloud events work and what to expect from the order event lifecycle.
Danoffice IT Commerce Cloud uses a webhook-based event system to push real-time updates to your systems. Instead of polling for order status, you register an HTTPS endpoint and Commerce Cloud delivers events to you as things happen on our side.
Event lifecycle
Every order that goes through Danoffice IT Commerce Cloud follows a predictable lifecycle. The diagram below shows the sequence of events from the moment your order is accepted to the final invoice.
Available events
| Event | When it fires |
|---|---|
order.received | Danoffice IT has registered the order in our sales team. |
order.shipped | The order has left the warehouse — includes tracking info, and optionally asset details if you need it. |
order.delivered | The carrier has confirmed delivery. Please note this is not live from the carrier, but Commerce Cloud will ship the event data immidiately when its reqistered. |
order.invoiced | The invoice has been issued for one or more sales orders. |
Payload structure
All events share a common envelope. The data object contains fields specific to each event type.
{
"event": "order.received",
"timestamp": "2026-04-14T10:30:00Z",
"data": { ... }
}| Field | Type | Description |
|---|---|---|
event | string | The event type, e.g. order.received |
timestamp | string | ISO 8601 UTC timestamp of when the event was emitted. |
data | object | Event-specific fields — see individual event pages. |
The correlationId
The correlationId is the key to linking events back to your own data. The value is available in the data object. It is returned in the 201 Created response when you place an order and is included in every subsequent event for that order.
Store the correlationId
Always persist the correlationId alongside your internal order reference. It
is the only stable identifier shared across all events for an order.
Event ordering
Events are emitted in lifecycle order, but you should not rely on strict delivery ordering. Network conditions and retries mean an event could arrive slightly out of sequence. Use the timestamp field and your own state machine to handle this gracefully.