Every time a payment clears in Stripe, or a form is submitted in Typeform, or a GitHub pull request gets merged, something needs to know about it immediately. That something is your app. And the mechanism that makes it happen is a webhook.
If you have ever watched a Slack message appear the instant someone sends it, or seen your inventory update the moment a sale closes on Shopify, you have already experienced webhooks doing their job. Most founders never think about them until they need one and do not know what to ask for.
What is a webhook?
A webhook is a one-way message that one system automatically sends to another when a specific event happens.
Think of it like a doorbell. Your app does not stand at the front door checking every five seconds whether someone has arrived. The doorbell rings only when a visitor actually shows up. The webhook is the ring. Your app is the house that receives it.
Here is a concrete example. You use Stripe to accept payments. A customer pays $99 for your product. Stripe needs to tell your app that the payment worked so your app can activate the customer's account, send a confirmation email, and update the order status. The way Stripe does that is by sending a webhook, a small message, delivered to a web address you provide, containing the payment details.
Your app receives that message and acts on it. The whole process takes under a second.
Webhooks are used everywhere in modern software. According to Postman's 2023 State of the API report, 56% of developers use webhooks regularly in production systems. Stripe, Shopify, GitHub, Twilio, HubSpot, Salesforce, and nearly every major platform support them as the primary way to notify external systems of events.
How does a webhook work in practice?
There are three moving parts: the sender, the message, and the receiver.
The sender is the platform where something happened, Stripe, Shopify, your CRM, or any other service that supports webhooks. When a specific event occurs (payment succeeded, order shipped, user signed up), the sender packages the relevant details into a small block of data and sends it to a web address.
That web address is called the webhook endpoint. It is a URL that lives on your own server, something like yourdomain.com/api/webhooks/stripe. Anyone who knows this address can send a request to it, so every properly built webhook system includes a verification step. The sender signs the message with a secret key, and your app checks that signature before trusting or acting on anything. Without this, a bad actor could send fake "payment succeeded" messages to unlock accounts for free.
The receiver is the code running on your server at that endpoint. It reads the message, checks the signature, and decides what to do: update a record in your database, trigger an email, activate a subscription, or fire off another process.
The whole sequence, event fires, message sent, your app responds, typically completes in under 200 milliseconds. That is why live dashboards update before you refresh the page, and why your email arrives seconds after a transaction clears.
One nuance worth knowing: webhook delivery is not always guaranteed on the first try. Networks fail, servers restart, endpoints go offline briefly. Every serious webhook implementation includes a retry system on the sender's side (Stripe, for instance, retries failed webhooks over 72 hours), and your receiver should be built to handle duplicate deliveries gracefully, meaning it should not charge a customer twice if the same payment webhook arrives twice.
Are webhooks expensive to build?
Not particularly, especially compared to the integrations they replace.
A standard webhook integration with a major platform like Stripe or Shopify takes 2–4 days to build properly. That includes writing the endpoint, verifying signatures, handling retries and duplicate events, writing automated tests, and deploying to production. At Timespade, this runs $500–$1,500 depending on complexity.
| Webhook type | Build time | AI-native team | Western agency |
|---|---|---|---|
| Single platform (e.g., Stripe payments) | 2–3 days | $500–$1,000 | $2,500–$5,000 |
| Multi-platform (3–5 sources) | 5–7 days | $1,500–$2,500 | $6,000–$10,000 |
| Event routing system (fan-out to multiple targets) | 8–12 days | $3,000–$5,000 | $12,000–$20,000 |
Western agencies charge $250–$400 per hour for this type of backend work. The same Stripe webhook that takes a developer 2 days to build lands on an invoice between $4,000 and $6,400. AI-native development compresses the repetitive parts of webhook code, signature verification, retry logic, test scaffolding, so a senior developer spends time on the logic that is specific to your product, not the boilerplate that looks identical in every project.
The ongoing cost is minimal. Webhooks do not require dedicated infrastructure the way a polling system does. Your server processes a message when it arrives and sits quiet in between. For most early-stage products, the hosting cost of a webhook endpoint is under $5 per month.
One thing that does add cost: building an internal webhook delivery system for your own product, where your platform notifies your customers' apps of events. This is a different scope from consuming a webhook. Building a reliable outbound webhook system with retries, logs, and a dashboard for customers to manage their endpoints typically runs $8,000–$15,000. Shopify, GitHub, and Stripe all built systems like this. Most early-stage founders do not need one until they are building a platform that other developers integrate with.
When do I need a webhook versus polling?
Polling is the alternative to webhooks. Instead of waiting to be notified, your app reaches out and asks "anything new?" on a schedule, every minute, every five minutes, every hour.
Polling works fine for certain tasks. If you are syncing exchange rates once a day, polling is simpler to build and perfectly adequate. The problem is that polling does not scale cleanly when you need data to be fresh.
Consider a real-time order status page. With polling, your app asks the shipping API for updates every 60 seconds. Across 10,000 active orders, that is 10,000 requests per minute, most of them returning "nothing has changed." You are paying for server compute, API rate limits, and network calls on data that has not moved. According to AWS's infrastructure benchmarks, polling-based systems consume 6–10x more server resources than event-driven (webhook-based) systems doing equivalent work.
Webhooks flip the model. The shipping API sends your app a message only when the order status changes. Zero wasted calls. Zero unnecessary load.
| Scenario | Right tool | Why |
|---|---|---|
| Payment confirmation | Webhook | Must be instant; polling introduces delays that confuse customers |
| New user signup in your CRM | Webhook | You want to trigger a welcome sequence immediately |
| Daily sales summary | Polling or scheduled job | No urgency; once-a-day is fine |
| Inventory sync across platforms | Webhook | Stock levels need to be accurate in near-real time |
| Checking if a report has finished | Either | Depends on how long the report takes and how quickly you need the result |
| Monitoring a sensor feed | Webhook | Continuous data stream; polling would generate millions of empty requests |
The decision usually comes down to two questions. Does the delay matter to your customers or your business operations? And how often does the event actually happen compared to how often you would need to poll? If the event is rare and the delay matters, a webhook is almost always the right answer.
For founders building on top of existing platforms, this decision is often already made for you. Stripe does not offer a "poll for payments" endpoint the way webhooks work, their event system is webhook-first. Same with GitHub, Shopify, and most modern APIs. Learning to receive and handle webhooks is not optional for any product that integrates with these platforms.
If you are unsure whether your product needs webhooks or a different integration pattern, the fastest path is a short scoping call. Book one here.
