How to Create Stripe API & Webhook Easily Step by Step 2026

Your API keys and webhook tools live under the same developer-focused menu, reached from the developer icon in the Stripe dashboard. Inside it you'll find SDKs, Stripe.js and CLI links near the top, followed by API keys, Apps and Developer settings.

API keys and webhook destinations are managed from this same area, so it helps to know your way around it since you'll return to it whenever you rotate a key or add an integration. Click API keys to see your publishable key and secret key, each shown separately for test mode and live mode.

Test keys start with pk_test_ and sk_test_ and simulate charges and events without moving real money. Live keys start with pk_live_ and sk_live_ and process actual transactions.

Build and debug with test mode keys, then switch to live mode only when you're ready to accept real payments. Never commit a secret key to a public repository; store it in an environment variable or a secrets vault instead.

Webhooks in the current Stripe dashboard are set up through Create an event destination, a short wizard that opens with Select events. Choose whether the destination receives events from Your account only, or from Connected and v2 accounts if you're managing a Connect platform, then confirm the API version the destination should use. This matters because the shape of the event payload can change between API versions, and Stripe lets you pin a destination to an older version so your handler code doesn't break when your account's default version moves forward.

On the same screen, select the event types you want to send to this destination. invoice.created, payment_intent.succeeded and checkout.session.completed are common choices depending on whether you're billing subscriptions or one-off purchases. Click Continue and choose a destination type.

A webhook endpoint is the standard choice, sending an HTTPS request to your server whenever a matching event fires. Amazon EventBridge and Azure Event Grid are also available if your team already routes events through AWS or Azure infrastructure.

Stripe caps each account at 16 registered event destinations per mode. If you hit that limit while testing, delete old test destinations you no longer use before creating a new one.

The final step summarizes your choices: account scope, payload style, API version and the events you selected. It then asks for a Destination name, an Endpoint URL, and an optional description.

Stripe suggests a random destination name, something like "energetic-finesse", that you can regenerate or replace with something meaningful. The Endpoint URL matters most: it has to be a publicly reachable HTTPS address on your server, ready to accept and parse Stripe's POST requests.

A localhost URL won't work here. Use a tunnelling tool such as ngrok, or test locally with the Stripe CLI first, then register the real public URL once your handler is deployed.

Once the destination is created, Stripe reveals a signing secret beginning with whsec_, specific to that one endpoint. Your server code should use this secret, together with Stripe's SDK helper, to confirm incoming requests genuinely came from Stripe instead of a spoofed source.

Skipping this check is a common gap in otherwise working integrations: anyone who finds your endpoint URL can otherwise post a fake payload shaped like a real event. Test mode and live mode each get their own signing secret, even for the same endpoint URL, so copy the one that matches the mode your handler is running against.

Stripe's dashboard logs every delivery attempt to your endpoint, including the response status your server returned, which makes it easy to confirm delivery before you depend on it. Trigger a manual test event from the destination's detail page, or run stripe trigger payment_intent.succeeded from the CLI, and check that it shows as delivered. Only then switch your integration to live mode keys and the live-mode version of the same event destination.