Skip to content
shadcn.io

shadcn.io is not affiliated with official shadcn/ui

Webhook Endpoint Setup Integration Block for React

An integration setup section for a failed-payment recovery tool connecting to Stripe: three numbered bands (a copyable webhook endpoint, a signing secret in a password field, four event checkboxes) and a foot band with a test event and a Finish setup Shine Button.

Framework
UI library

Preview

Preview width

Installation

Part of Pro
Pro unlocks the code and one-line install of every Pro button and text effect, plus the MCP for your AI editor.
Have Pro already? Sign in to open it.Opens here as soon as you're Pro.

Overview

An integration setup section for React with Base UI, written for Dunlark, a fictional failed-payment recovery tool, and its Stripe connection. A compact header carries the mark pair at its end. Then three numbered bands, each under its own rule with the step at the start and its control at the end. Band 1 shows the webhook endpoint in a read-only field with a copy button; band 2 takes the signing secret in a password field and checks that it starts with whsec_; band 3 lists the four events Dunlark listens to as checkboxes, the first two always on, with a count worked out from the choices. A foot band holds a polite status line, present from load, a "Send a test event" button that waits for the secret, and a "Finish setup" Shine Button that waits for the test. Finishing says "Connected in this demo" and clears the secret; a connected state shows a ghost Disconnect. It's built from Guides, Field, InputGroup, PasswordInput, CopyButton, Checkbox, Button and ShineButton, with your theme's tokens for every colour. Stripe is named in text only: no Stripe logo, colour or wordmark ships with the block.

FAQ

What stays local?

Everything. The secret is checked only for its whsec_ shape, never stored, never sent and cleared on finish; the test event only changes the status line, and the endpoint address is on a reserved example domain. Wire your own endpoint, signature check and test where the demo changes state.

Are the secret and event names real?

Yes. Each webhook endpoint you add in the Stripe Dashboard has its own signing secret that starts with whsec_, which is used to verify the signature header Stripe sends with every event. The four event names (invoice.payment_failed, invoice.paid, customer.subscription.deleted, charge.dispute.created) are real event types.

Why can't the first two events be unticked?

The schedule starts on a failed payment and stops when the invoice is paid, so without them the product cannot work. Pressing a locked row leaves it on and says why in the status line.

How do keyboard and screen reader users work it?

Each band is a list item whose heading starts with "Done:" or "To do:" for screen readers. Every field has a visible label, the checkboxes are named by their event, the unavailable buttons are marked as such and explain themselves in the status line, which is a polite live region present from load.

Why does Send a test event need the secret?

A real test needs a secret to sign against. Until the secret has the right shape the button is marked unavailable; pressing it says what is missing. Changing the secret or the events afterwards clears the test, so Finish setup waits for a fresh one.

How does it behave on a phone and in right-to-left layouts?

On a phone each band stacks its control under its step, and the foot band puts the buttons under the status line. In a right-to-left layout the bands mirror; the endpoint, the secret and the event names keep their own direction.

  • Pro

    An integration detail section for a failed-payment recovery tool connecting to Stripe: the dunning schedule as four hairline cells, a None, Read and Write table of what a restricted key allows, three steps and a Connect Stripe Shine Button.

  • Pro

    An integration grid section for a failed-payment recovery tool connecting to Stripe: three radio cards in shared hairlines, each drawing its retry schedule on a 14-day line, with a check and an inset rule on the chosen one.

  • Pro

    An integration list section for a failed-payment recovery tool connecting to Stripe: a real table of six failing subscriptions with plan, amount, attempts, next retry and decline reason, a row menu (Retry now, Email customer, Pause dunning) and a tally worked out from the rows.

  • Pro

    A connect flow for a post-incident review tool and Datadog: a three-cell progress strip and three bands to choose the site, paste an API key and an application key with length meters, and print a sample test alert, ending in Finish setup.

  • Pro

    An integration setup section for a spend approvals tool connecting to Slack: three steps (add the app under its five scopes, invite it with a copyable command, check that it joined) beside a drawn member list with a radar pulse that settles to Joined.

  • Pro

    A talk-to-sales split for a scheduling platform: what happens next as three numbered steps and a band of contact details beside a form that checks itself, shows each problem under its field and confirms in place.