Event Destinations
Send events from Stripe to webhook endpoints and cloud services.
Note
If you donât see the Event destinations tab in Workbench or the Developer Dashboard, enable Event Destinations in your Product previews setting.
Set up an event destination to receive events from Stripe across multiple destination types, including webhook endpoints, and Amazon EventBridge.
Additionally, you can use thin events created by API v2 endpoints. The SDKs for API v2 includes helpers that allow your application to fetch the latest object state from Stripe.
Use cases
When building Stripe integrations, you might want your applications to receive events in real-time from your Stripe accounts, enabling your backend systems to respond and perform actions accordingly.
With an event destination, Stripe pushes real-time event data from your account, enabling you to run backend actions, such as:
- Sending users a notification when a customer confirms a payment
- Initiating an internal claims reconciliation process when a customer disputes a charge
- Granting access to your user when they make successful recurring subscription payments
Supported destination types
Send events to an AWS account using Amazon EventBridge, or deliver them to an HTTPS endpoint through webhook endpoints.
Events overview
Stripe generates event data to keep you informed about the activity in your account.
When an event occurs, Stripe generates a new Event
object. After your destination receives the Event
, your app can run backend actions (for example, calling your shipping providerâs APIs to schedule a shipment after you receive a payment_
event). We provide two different types of Event
objects:
- Thin events: These events only include the ID of the affected objects. These are generated by API v2 endpoints. API v1 endpoints also generate thin events. See a full list of thin events.
- Snapshot events: These events provide an eventually-consistent snapshot of the object that has changed and are only generated by API v1 endpoints. They might include a
previous_
property that indicates the change when applicable. See a full list of snapshot events.attributes
This table outlines high-level differences across thin events and snapshot events.
Characteristics | Snapshot events | Thin events |
---|---|---|
Created by | API v1 resource state changes | API v2 resource state changes |
Payload | Large: Includes a snapshot of the API object related to the event | Small: Only includes an ID of the API object related to the event |
SDK typing | Untyped | Typed |
Versioning | Versioned by API version | Unversioned, allowing you to upgrade your integration without changing your webhook endpoint configuration |
A single API request might result in the creation of multiple events. For example, creating a new subscription for a customer might result in customer.
and payment_
events. Select the events you want to subscribe to for each event destination.
Thin events
Thin events are lightweight events you can access through the API v2 namespace. Thin events have a more granular permissions model and their payloads contain no API-versioned data, only the IDs of the objects related to the event. This helps update integrations that receive events and are built with a well-typed Stripe SDK. Thin Events:
- Include a
data
property that can include additional information about the event. - Are fully typed in the SDKs for API v2.
You can retrieve Event objects for each notification from the /v2/core/events
endpoint. These API objects include the data
property that can provide additional details about the thin event.
Prevent application errors
If your application needs a corresponding API object related to an event (for example, the Meter), you must call the Stripe API for the objectâs latest state. Although this method requires an additional network call to Stripe, it helps prevent application errors caused by outdated object data (for example, race conditions). The SDKs for API v2 contain helper methods that allow you to retrieve records associated with an event.
Example thin event payload
The following is an example of an v1.
event. The related_
field includes the id
of the object, but doesnât include the object record itself.
{ "id": "evt_test_65R9Ijk8dKEYZcXeRWn16R9A7j1FSQ3w3TGDPLLGSM4CW0", "object": "v2.core.event", "type": "v1.billing.meter.error_report_triggered", "livemode": false, "created": "2024-09-17T06:20:52.246Z", "related_object": { "id": "mtr_test_61R9IeP0SgKbYROOx41PEAQhH0qO23oW", "type": "billing.meter", "url": "/v1/billing/meters/mtr_test_61R9IeP0SgKbYROOx41PEAQhH0qO23oW" } }
As a result, a thin event payload is much smaller than a snapshot event payload. For comparison, the following is an example of an invoice.
snapshot event:
{ "object": { "id": "in_1KnN0G589O8KAxCGfVSpD0Pj", "object": "invoice", "account_country": "US",
Retrieve additional information associated with a thin event
There are two types of information you can retreive related to a thin event:
- Related object resource definition: Each thin event details a specific occurrence related to a Stripe object. Use the
fetchRelatedObject()
method to retrieve the latest version of the object associated with the event. For example, if you receive av1.
event,billing. meter. error_ report_ triggered fetchRelatedObject()
retrieves the current version of the meter object that triggered an error report. - Additional event payload fields: Thin events might contain additional contextual data thatâs only retrievable with the API. Use the
retrieve()
call with the thin event ID to retrieve these additional payload fields. For example, fetching av1.
event with the API return an additionalbilling. meter. error_ report_ triggered data
hash. This hash includes contextual fields about the errors triggered, such as the time the validation error occurred, a list of sample error messages, and the number of validation errors.
The following example demonstrates how to retrieve the related object definition and additional event payload fields associated with a thin event:
Event permissions
To view an event in the Dashboard, assign the Admin or Developer role to your user account. To retrieve an event using the API, use either a secret API key, which allows you to view all event types by default, or a restricted API key with Read
access enabled for the specific event typeâs resource. For example, you can grant Read
access to payment_
resources on your restricted API key to programmatically retrieve payment_
.
Event retention
You can access events created within the last 13 months in the Events tab in Workbench; however, you can only manually re-send or view delivery attempts that are less than 15 days old from the Event Deliveries section. For events older than 30 days, you can access a summary view, which only includes truncated fields of the original event data.
You can access thin events within the last 30 days using the Retrieve event and List events API v2 endpoints. To access snapshot events within the last 30 days, use the Retrieve event and List event API v1 endpoints.
Manage an event destination
To create, delete, and update an event destination in the Dashboard, open the Event destinations tab in Workbench or use the Event Destinations API.
Disable an event destination
You can disable an event destination. After you disable it, Stripe stops sending any events to that destination. After you re-enabled a destination, Stripe resumes sending events to the destination.