What Are Webhooks? How Apps Talk to Each Other Instantly

You just paid for a cab ride, and your bank balance updates on your phone within a second, no refresh needed. You didn't check for that update. The app didn't ask your bank "has anything changed yet?" every few seconds either. Something told it the moment the money moved. That something is a webhook, and it's quietly running a huge chunk of the apps you use every day.

So what actually is a webhook?

Think of a webhook as a phone number one app gives another app, with instructions: "call me the second something happens, don't make me keep calling you to ask." In technical terms, a webhook is an automated HTTP request that one system sends to another the instant a specific event occurs, carrying a small packet of data (called a payload) about what just happened.

This is different from a regular API (Application Programming Interface, the standard way two pieces of software exchange data) call in one important way. With a normal API, your app has to actively reach out and ask, "any updates?" With a webhook, the other system reaches out to you, unprompted, the moment there's news.

Polling vs. webhooks: why this difference matters

Before webhooks became common, developers relied heavily on polling, where an app repeatedly pings a server every few seconds or minutes to check if anything new has shown up. It works, but it's wasteful. Most of those checks come back empty, and you're still burning server resources and battery on every single one.

Webhooks flip the arrangement around. Instead of a thousand apps asking "anything new?" a thousand times a minute, the source system sends exactly one message, exactly when it matters.

• Polling: your app asks repeatedly; most checks find nothing; delay between an event and your app knowing about it; load scales with how often you check.
• Webhooks: the source system pushes data only when something happens; near-instant delivery; far less wasted traffic; your app needs a public endpoint ready to receive the call.

That last point is the trade-off worth knowing: webhooks require your application to expose a URL that can receive incoming requests at any time, which means you also have to think about verifying that the request genuinely came from who it claims to, usually via a signature check, so nobody can fake an event and trick your system.

Where you've already run into webhooks

You've used systems built on webhooks more often than you realize:

• A payment gateway like Razorpay or Cashfree sends a webhook to a merchant's server the instant a UPI payment settles, so the order confirmation page updates without you hitting refresh.
• GitHub fires a webhook when someone pushes code, which is what kicks off an automated build or test run on services like Jenkins or GitHub Actions.
• A Slack or Discord bot posting an alert the second a deployment fails is almost always sitting on the receiving end of a webhook.
• E-commerce platforms notify a shipping partner's system the moment an order is packed, rather than the shipping partner constantly checking order status.

Why this matters more in India than it might seem

India runs an enormous share of its digital economy on real-time settlement, and webhooks are the quiet plumbing underneath it. When UPI processes roughly fifteen billion transactions a month, the only way merchant apps can reflect "payment received" within a second or two, rather than minutes, is through event-driven notifications rather than apps constantly asking banks for status updates. The same pattern shows up in GST e-invoicing and e-way bill systems, where government portals push status changes to registered software rather than forcing every business's accounting system to poll continuously. For Indian developers building anything that touches payments, logistics, or compliance, understanding webhooks isn't optional, it's close to table stakes.

A webhook isn't a feature you add to an app. It's a design decision about who initiates the conversation, and getting that right is often the difference between an app that feels instant and one that feels laggy.

Setting one up, in plain terms

If you're building or integrating a webhook for the first time, the steps are roughly the same regardless of platform:

1. Create an endpoint, a URL on your server that's ready to accept incoming HTTP POST requests.
2. Register that URL with the service you want notifications from (most dashboards, from Razorpay to Stripe to GitHub, have a "webhooks" settings page for exactly this).
3. Verify the signature on every incoming request so you know it actually came from the service you registered with, not an impersonator.
4. Respond quickly, usually within a few seconds, acknowledging receipt, then process the actual data separately. Slow responses often cause the sender to assume failure and retry, leading to duplicate events.
5. Handle duplicates gracefully anyway, since most providers will resend an event if they don't get a fast enough acknowledgment.

Webhooks aren't complicated once you see the shape of them, but they do ask you to think differently: instead of your code deciding when to check for news, you're building something that's always ready to receive it. That shift, from pulling information to having it pushed to you, is worth understanding even if you never write a line of backend code yourself, because it's the reason so much of what you use online feels instant instead of sluggish.