Webhook Settings

Manage webhook endpoints with subscribed events, delivery health, retry policy, signing configuration, recent failures, and test delivery. This example brings Endpoints and Events together so administrators and growth teams can find the next task without losing context.

It includes representative records such as Product events endpoint and Billing events endpoint. Use the screenshot to study the layout, then adapt its components and product states to your own design system.

Webhook Settings

Template facts

Screen

Settings

Primary action

Add endpoint

Pattern

Settings

State

Default, loading, empty, error, permission, success

Design system

Configurable product UI theme

What this screen helps users do

Product and growth teams need to add endpoint while keeping endpoints, success rate and exceptions visible. The interface should show what changed and who should act next.

Key elements

  • Main workspace: Endpoints gives users an obvious place to start.
  • Supporting view: Events keeps the related context close.
  • Primary action: Add endpoint stays visible when people need it.
  • First signal: Endpoints shows a useful value (6).
  • Second signal: Success rate gives additional context (99.4%).
  • Sample record: Product events endpoint.
  • Next record: Billing events endpoint.

States worth designing

  • Default preferences: say what changed, protect progress, and offer a clear next step.
  • Unsaved changes: say what changed, protect progress, and offer a clear next step.
  • Policy blocks edit: say what changed, protect progress, and offer a clear next step.
  • Changes applied: say what changed, protect progress, and offer a clear next step.
  • Restricted settings: say what changed, protect progress, and offer a clear next step.
  • Connectivity interrupted: say what changed, protect progress, and offer a clear next step.

Where this screen sits in the flow

Endpoints → Events → Add endpoint → Review outcome

Patterns used

Settings, Endpoints, Events, contextual actions, error recovery

Why these choices work

Separate safe everyday choices from risky changes, show who can edit them, and confirm irreversible actions.

Pay attention to endpoints and events. People need to distinguish Product events endpoint from Billing events endpoint. Keep endpoints visible, especially when a record changes owner or status.

Before this screen reaches handoff, verify keyboard focus, empty and permission states, and what happens after someone chooses “Add endpoint”. Make error recovery as clear as the happy path.

Related screen examples to explore next: Data Export Center, Workspace Transfer, Bulk User Import.

Start from this in Figr

Design a webhook settings screen inside our existing product. Use our current components, tokens and content language. Include Endpoints and Events views, credible records like Product events endpoint, and a clear “Add endpoint” action. Use our product permissions and show loading, empty, error and success states. Keep the output editable in Figma.

Open Figr