You set up an integration with Stripe. Now you check their dashboard every hour to see if payments came through.
A customer cancels their subscription. You find out three days later when they email asking for a refund.
Your team manually exports data from five different tools every morning to keep your systems in sync.
You should know the moment something happens, not hours later.
FOUNDATIONAL - Real-time integrations depend on receiving events as they happen.
Instead of checking Stripe every 10 minutes to see if someone paid, Stripe calls YOUR server the moment a payment succeeds. That's a webhook. The external system pushes data to you when events happen, rather than you pulling to check for changes.
You give an external service a URL on your server. When something happens, they send an HTTP POST request to that URL with details about what happened. Your server receives it, processes it, and responds.
Webhooks flip the integration model. Instead of asking 'did anything change?' a thousand times a day, you get told once, immediately, when it does.
Webhooks solve a universal problem: how do you react to events you don't control, the moment they happen, without constantly checking?
Expose an endpoint. Subscribe to events. Receive notifications. Process and respond. This pattern works whether you're receiving payment events, form submissions, or deployment notifications.
Send test webhooks and watch them get verified and processed. Try toggling the settings to see what breaks.
What you just discovered:
Valid webhooks flow through quickly. Fakes get rejected before any processing happens. This is why both verification AND async processing matter.
Create a URL that can receive POST requests
You expose a public URL like yoursite.com/webhooks/stripe. This endpoint accepts POST requests and can read the JSON body. It must be publicly accessible from the internet.
Confirm the webhook came from who it claims
The sender includes a signature (usually in a header) computed from the payload and a shared secret. You recalculate the signature and compare. If they match, it's authentic.
Handle the same event multiple times safely
Webhooks can be retried if your server doesn't respond quickly. If Stripe sends 'payment succeeded' twice, you shouldn't charge the customer twice. Store the event ID and skip duplicates.
Your customer upgrades from Basic to Pro in Stripe. Without webhooks, you'd poll every 10 minutes and they'd wait up to 10 minutes for access. With this flow, their premium features unlock in under 3 seconds.
Hover over any component to see what it does and why it's neededTap any component to see what it does and why it's needed
Animated lines show direct connections · Hover for detailsTap for details · Click to learn more
Foundation layer - no upstream dependencies
You receive a Stripe webhook and immediately try to update your database, send emails, and call three other APIs. The request takes 45 seconds. Stripe times out and retries. Now you're processing the same event multiple times.
Instead: Acknowledge the webhook immediately (return 200), then process asynchronously via a queue.
Anyone who discovers your webhook URL can send fake events. Someone sends a fake 'subscription upgraded' event. You give them premium access without payment.
Instead: Always verify the signature using the secret provided by the sender. Reject unverified requests.
Customer subscribes, then cancels. But the cancel webhook arrives before the subscribe webhook due to network timing. You try to cancel a subscription that doesn't exist yet.
Instead: Check event timestamps. Store events with their order. Handle out-of-order gracefully.
You've learned how to receive real-time notifications from external systems. The natural next step is understanding how to process these events and trigger actions in your own systems.