Workflow Hub

Webhook basics for teams that need a cleaner debugging workflow

Start here when the main question is how to capture a request, inspect it clearly, forward it into localhost, or replay it after a fix.

Why workflow-first debugging matters

Most webhook problems look provider-specific at first glance — a failed Stripe signature, a missing GitHub delivery, a silent Shopify callback. But the underlying debugging process is almost always the same: prove the request reaches a public URL, inspect what it actually contains, route it into your local environment, and replay it until your handler passes. When you start with the workflow instead of the provider, you fix problems faster because you stop guessing which layer broke. The four steps below give you that workflow. Each step links to a dedicated product page where you can take action immediately. Once you reach a provider-specific wall — signature mismatches, HMAC quirks, event-type edge cases — the provider hubs linked at the bottom pick up exactly where these workflow guides leave off.

Four steps to a working webhook

Jump in at whichever step matches your current situation. You don't need all four every time.

When to use which tool

Match your current situation to the right starting point.

Your situation Best tool Why
"I don't know if the provider is sending anything" Request Bin Creates a public endpoint that captures every incoming delivery so you can confirm the provider side works.
"I can see the request but something looks wrong" Request Viewer Gives you a formatted view of headers, body, and status — faster than reading raw logs or provider dashboards.
"I need real traffic hitting my local server" Localhost Forwarding Routes live webhook traffic into your local handler without deploying or opening firewall ports.
"I fixed a bug and need the same payload again" Replay Resends a previously captured request so you can validate your fix without recreating the upstream event.
"Signature verification keeps failing" Debugger + Viewer Inspect the raw request body alongside headers so you can isolate whether the secret, body parsing, or timing is off.

Provider-specific hubs

Switch to these when you hit a provider-specific wall.

  • Stripe Guides

    Local testing, signature failures, and replay for Stripe webhooks.

  • GitHub Guides

    Ping events, signature validation, and "not delivering" debugging.

  • Shopify Guides

    HMAC validation, order events, and local Shopify app testing.

  • Slack Guides

    URL verification, event payloads, and local Slack event routing.

Docs worth opening next

Frequently asked questions

Do I always need to follow all four steps?

No. Start at whichever step matches your current situation. If delivery is already working, skip the request bin step. If you just need to replay a saved event, go straight to replay.

Can I use these workflows with any webhook provider?

Yes. The capture-inspect-forward-replay loop works with Stripe, GitHub, Shopify, Slack, and any other provider that sends HTTP callbacks. The workflow is provider-agnostic.

What is the difference between a request bin and a webhook debugger?

A request bin captures and displays incoming HTTP requests. A webhook debugger does the same but adds features like localhost forwarding, replay, signature verification tools, and persistent request history.

When should I switch from workflow guides to provider-specific guides?

Switch when you hit a provider-specific issue like Stripe signature verification, GitHub ping events, or Shopify HMAC validation. The workflow guides handle the general debugging process; provider guides handle provider-specific quirks.