What is a Webhook?

Let Apps Tap You on the Shoulder

Polling asks "anything new?" a thousand times. Webhooks send one message the instant something happens. Same outcome, a fraction of the work.

5 min read Updated 2026-04-15 By Hasan

What Are Webhooks? (The Simple Version)

Think of webhooks like delivery notifications. When you order a package, you don't stand by the door all day waiting. Instead, the delivery company texts you the moment it arrives: "Your package was delivered!" That text is an automatic message that lands the instant something happens. No checking, no waiting, no effort on your part.
Without webhooks: your app checks the other service every few minutes. "Anything new? Anything new? Anything new?" This is called polling, and most of the time the answer is "nope." You waste network requests, drain server resources, and the news still arrives late because you only hear about it on your next check.
With webhooks: you give the other service a URL, like a phone number for your app. When something happens (payment received, code pushed, order shipped), the service calls that URL immediately with the details. Your app gets the news the moment it happens, and you did not burn a single request asking.
TL;DR

Webhooks = automatic notifications from one app to another when something happens. Like getting a text when your package arrives instead of refreshing the tracking page all day.

When to Use Webhooks

Webhooks isn't always the right call. Here's a quick mental model:

You need to know when something happens in another app

Customer paid? Order shipped? Pull request merged? Webhooks tell you immediately. Perfect for payment notifications, shipping updates, or syncing data between services.

You want real-time reactions

Send a welcome email the instant someone signs up. Update inventory the moment an order is placed. Webhooks let you react in real-time, not on a 5-minute delay.

You're connecting to a third-party service

Stripe, GitHub, Shopify, Twilio: almost every major service supports webhooks. They are the standard way to receive updates from external platforms.

You only need data once

If you just need to fetch a user's profile one time, use a regular API call. Webhooks are for ongoing notifications, not one-time lookups.

You control both systems

If you own both the sender and receiver, you might prefer direct function calls, message queues, or database triggers. Webhooks shine when connecting separate services.

You're building a tiny script

A simple script that runs once doesn't need webhook infrastructure. Keep it simple. Poll if you only need data occasionally.

Interactive Webhooks Demo

See the difference between polling and webhooks. Watch how polling wastes requests while webhooks deliver instant notifications.

Webhooks Simulator

Simulated — no real calls
Event Type:

🔄 Polling
Requests Made
Status
Waiting to start...
Webhook
Requests Made
Status
Endpoint ready...
Polling made requests before finding the update. The webhook received it instantly with just 1 request. That's the power of webhooks — no wasted "are we there yet?" questions.
What to notice:
  • Notice how polling makes many "any updates?" requests
  • Watch the webhook arrive instantly when the event triggers
  • See: zero wasted requests with webhooks

AI Prompts for Webhooks

Now that you understand webhooks, use these prompts with your AI coding agent. Copy the one that matches what you're building — the agent will handle the implementation.

Tip: These prompts work with any AI (ChatGPT, Claude, Cursor, Copilot). Just copy, paste, and let the AI write the code. You don't need to understand the webhook mechanics, the AI handles that.

Create a simple webhook endpoint that receives notifications from an external service. Framework: [Express, Flask, Django, FastAPI, etc.] Service: [Stripe, GitHub, Shopify, or describe what's sending webhooks] Keep it simple: 1. Create a POST endpoint at /webhooks/[service-name] 2. Parse the incoming JSON payload 3. Log what was received (for testing) 4. Return a 200 OK response quickly I want to understand the basic pattern first. Show me: - The endpoint code itself (keep it short!) - How to read the event type (e.g., "payment.succeeded") - How to access the event data (e.g., customer email, amount) - What response to send back I'm learning, so explain each part simply.
starter Start here - simplest webhook pattern
Add signature verification to my webhook endpoint. I want to make sure the webhook is actually from [Stripe/GitHub/the service] and not a fake request. Framework: [Express, Flask, Django, FastAPI, etc.] Service: [Stripe, GitHub, Shopify, etc.] Requirements: 1. Get the signature from the request headers 2. Verify it matches the expected signature 3. Reject requests with invalid signatures (return 401) 4. Only process the webhook if verification passes Show me: - Where to find my webhook signing secret (in the service dashboard) - How to compute the expected signature - How to compare signatures securely (timing-safe comparison) - What to log when verification fails (for debugging) Security matters here. Explain why signature verification is needed and what could go wrong without it. I'm learning, so explain each part simply.
starter Essential security - verify webhook authenticity
Create a complete payment webhook handler for Stripe. I want to handle successful payments and failed payments properly. Framework: [Express, Flask, Django, FastAPI, etc.] Handle these events: 1. payment_intent.succeeded - Payment was successful 2. payment_intent.payment_failed - Payment failed 3. customer.subscription.created - New subscription started 4. customer.subscription.deleted - Subscription cancelled For each event: - Log what happened - Update my database (show placeholder code) - Send appropriate emails (show where I would call my email service) Also show me: - How to handle events I don't care about (ignore gracefully) - How to avoid processing the same event twice (idempotency) - How to respond quickly so Stripe doesn't timeout I'm learning, so explain each part simply.
intermediate Common use case - payment processing
I have some webhook code but I don't fully understand what it's doing. Please explain it to me in simple terms. Here's the webhook code: [paste your webhook code here] Please explain: 1. What events does this webhook handle? (one sentence each) 2. Walk through it line by line: what happens at each step? 3. How does it verify the webhook is authentic? 4. What happens if something goes wrong? 5. Are there any security concerns or missing pieces? Also suggest improvements if you see: - Missing signature verification - No idempotency handling - Slow operations that might cause timeouts - Missing error handling I'm learning, so explain each part simply.
documentation Understand existing webhook code

Webhooks in Real Applications

Stripe payment notifications When a customer pays on your website, Stripe sends a webhook to your server. Your app receives the payment details instantly: who paid, how much, what product. You unlock the content, send a receipt, and update your dashboard automatically, the moment money hits your account.

GitHub deployment triggers Push code to your repository and GitHub sends a webhook to your deployment service. Vercel, Netlify, or your own server receives the notification and automatically rebuilds your site. No clicking "deploy". It just happens when you push.

SMS and email notifications Services like Twilio and SendGrid use webhooks to tell you what happened. Did the recipient open the email? Did the SMS get delivered? The webhook tells your app immediately so you can track engagement or retry failed messages.

Order fulfillment Connect Shopify to a shipping service and webhooks flow both directions. New order? Shopify webhooks the shipping service. Package shipped? The shipping service webhooks Shopify. Everything stays in sync automatically.

Common Webhooks Mistakes to Avoid

Not verifying webhook signatures

Anyone can send a POST request to your webhook URL. Without signature verification, an attacker could fake a "payment successful" event and steal your product. Always verify the signature using the secret key from your service dashboard.

Responding too slowly

Most services expect a response within 5-30 seconds. If your webhook does heavy processing before responding, the service might timeout and retry, causing duplicate events. Respond immediately with 200 OK, then process in the background.

Not handling duplicate events

Services often retry webhooks if they don't get a response. Your code might process the same payment twice! Store the event ID and check if you've seen it before. This is called idempotency: making sure the same event processed twice has the same result.

Exposing webhook URLs publicly

Your webhook URL should be hard to guess and protected by signature verification. Don't put it in client-side code or documentation. Treat it like a password. The fewer people who know it, the better.

Go Deeper on Webhooks

Webhooks Interview Questions →

4 common interview questions about webhooks, with clear practical answers.

Related Building Blocks

Also known as: webhook, webhook endpoint, http callback, event notification, webhook listener, reverse api

COURSE

Ready to Build Real Products?

Learn to ship MicroSaaS apps with AI in the Solo Builder course.

Start Building →