Learn about the structure of events and when they are created
When something noteworthy happens in your account, we create an event object. More specifically, an event is created when the state of another API resource changes. Your integration can use these events to listen for and handle important updates in your account.
In the Digital River APIs, there are numerous event types that you can subscribe to. There are, however, certain key event types that we recommend every integration monitor.
In nearly all cases, an event's data contains the resource whose state changed.
To subscribe to an event, you need to set up webhooks that send designated events directly to an endpoint on your server. In Dashboard, you'll find a complete list of our supported event types. To access this list, create a webhook or view the details of an existing webhook.

Event types

Events use the following naming convention: resource.event.
The event's type usually reflects the current state of that resource. For example, when an order's state becomes accepted, we create an event whose type is order.accepted and when an invoice becomes uncollectible, we create an event whose type is invoice.uncollectible.
"id": "86976837-18b5-473c-9a2e-7e774a827670",
"type": "order.accepted",
"data": {
"object": {
"id": "247468780336",
"state": "accepted",
There are, however, certain exceptions. For example, a subscription.extended event indicates that the subscription remains in an active state. And even though checkouts don't contain a state attribute, you can listen for checkout.created, checkout.updated, and checkout.deleted events.
When an event occurs on a sub-resource, such as in the order.charge.cancelled event, the parent resource's state update event is not activated.
Some API requests trigger multiple events. For example, when you create a subscription, both the subscription.created and checkout.created events are emitted.

Event data

In the payload of an event, data.object typically contains the resource that changed.
Here are a couple of examples: (1) the data.object of an order.blocked event is an order in a blocked state and (2) the data.object of an order.charge.capture.complete event is a charge that contains a capture in a complete state.
In a few cases, however, this pattern isn't strictly followed. For example, the data.object of a fulfillment_order.shippedevent contains a shipment resource and the payload of a subscription.reminder event is both a subscription and an invoice.
An event's data.previousAttributes lists the resource's attributes that changed, along with the previous values of these attributes.‌