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.
Event types use the following naming convention: resource.event.
The name of the event usually reflects the current state of that resource. For example, when an order moves into an accepted state, we create an order.accepted event and when an invoice becomes uncollectible, we create an invoice.uncollectible event.
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 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.
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.