How to Get Webhook Secret in Stripe Easily 2026

Every webhook event Stripe sends to your endpoint is signed with this secret. Your app recomputes that signature and compares it against the one in the request header.

If they match, the event came from Stripe; if not, it's rejected. Without this check, anyone who knows your endpoint URL could send fake payment or subscription events, and your app would have no way to tell the difference. Stripe's own guidance recommends pairing this with IP allowlisting too, since Stripe sends webhook traffic from a published set of addresses.

From the dashboard's Overview screen, the left-hand Shortcuts panel under Workbench lists Overview, Webhooks, Events, Logs, and more, with a separate Documentation section below for API reference, SDKs, and Developer settings. Webhooks sits next to Events and Logs because the three are related: Events is the full history of what happened in your account, and Webhooks is where you configure which of those events get pushed to your app automatically. If you're working in a sandbox, a banner across the top confirms you're testing, not touching live data, which is the safer place to build this out first.

Clicking Create an event destination opens a multi-step wizard. The first step asks which account scope to listen to (Your account, unless you're building a Connect platform), which API version to use, and which event types to send.

Events are grouped by category: Billing, Capability, Cash Balance, Charge, Checkout, Climate, Coupon, Credit Note, and more, each showing how many distinct event types fall under it. Select only what your app needs to react to.

A checkout flow generally cares about Checkout and Charge events, while a subscription business will also want most of Billing. Fewer, targeted events keep your endpoint's logic simpler and cut the traffic it has to filter through.

The next step asks where Stripe should send these events. There are three options: a Webhook endpoint (a URL you host that receives the events directly), Amazon EventBridge (routes events into your AWS account), or Azure Event Grid (routes events into Azure).

For most standard integrations, a Node, Python, or Ruby backend receiving and processing Stripe events, Webhook endpoint is the right choice. EventBridge and Event Grid only make sense if your infrastructure is already built around AWS or Azure event routing.

The final step asks for the actual URL your app exposes to receive these events, something like https://yourapp.com/api/stripe/webhook, along with an optional description to tell endpoints apart later if you create more than one. Once you confirm, Stripe generates the endpoint and a unique Signing Secret tied to it.

Each endpoint gets its own separate secret, so a test endpoint and a live endpoint end up with two different values. Stripe also caps accounts at 16 registered webhook endpoints in total, so it's worth pointing several event types at one endpoint instead of creating a new one per feature.

The Signing Secret appears on the endpoint's detail page behind a Reveal action, not shown in plain text by default. That friction is intentional: anyone with this value can forge valid-looking webhook events.

Copy it into your app's environment variables, a .env file locally or your host's secret manager in production, never directly into source code, and keep it out of version control entirely. If the secret is ever exposed, don't delete and recreate the endpoint. Stripe's documented way to rotate a secret is the Roll secret option in the endpoint's overflow menu, which keeps the old and new secret both valid for up to 24 hours while you update your server.