What Are Webhooks? How They Work, Examples & Best Practices

The company had an order integration solution that passed all of their tests and then silently broke in production. The customer made a payment, and his order just stood there since the webhook response timed out when the endpoint was taking 14 seconds to reply.

A webhook is the simplest concept in integration, and that is the very reason why it breaks. We observe that companies in the process of implementing a webhook into their business simply consider it 'just another URL' and fail to apply the crucial checks while digital technologies are pushing everyone to the event-driven architecture. Missing an event leads to losses for your company before you even take a look at the logs.

What Is a Webhook?

A webhook is a request sent automatically by one application to another through HTTP, in response to a specified event. The webhook meaning can be seen in its name: Web represents HTTP, while hook refers to an action associated with an event. Think of a store calling you when the product you need is in stock.

• It's also referred to as an HTTP callback or reverse API because the server pings you.
• The people looking for 'what does webhook mean', 'what is a webhook' or 'what is webhook' need two systems to communicate without continuous polling.
• Typical triggers: A landing page form submission, a payment, a code push.

What Is a Webhook URL?

A webhook URL is the endpoint on the receiving application where the sender delivers each payload. Three rules apply to every one of them.

• It must be publicly reachable over HTTPS.
• Localhost needs a tunnel.
• Treat it like a credential, because anyone who finds it can post to it.

How Webhooks Work

And what does a webhook do? On the occurrence of an event, the provider sends you a payload. Webhooks eliminate polling, where the server asks 'anything new?' each minute. So, at one request every 60 seconds, there would be 1,440 requests made per resource each day, all for naught.

Events, Payloads, and Endpoints

Webhooks have three main components, all of which could fail separately. Here are the components in order.

• Event: The trigger for the event, for example, a successful payment.
• Payload: Mostly JSON that has information about event type, timestamp, and object ID.
• Endpoint: The receiver, which accepts an HTTP POST.

The payload is the part teams misread most often. A typical webhook payload for a successful payment looks like this:

{
  "id": "evt_1042",
  "type": "payment.succeeded",
  "created": 1767225600,
  "data": { "object": { "order_id": "ord_5531", "amount": 4900 } }
}

The receiver reads the type, finds the order by ID, and acts. That is the entire data contract.

A Webhook Integration Step by Step

A webhook integration follows five steps. The order matters, because each step assumes the previous one succeeded.

1. Register your URL in the provider dashboard.
2. Pick the events you want.
3. The event fires and the provider POSTs the payload.
4. Your receiver validates and processes it.
5. Your receiver returns a 2xx status.

Skip step five, and the provider assumes failure, then resends. See the wider pattern in our guide to AI agent workflows.

Webhooks vs APIs

If you search 'what is api' or 'what is an api', the answer is an interface that lets one application request data or actions from another. A REST API does this over HTTP: You call, it answers. With a webhook, the provider calls you, and the webhook vs API choice decides cost, latency, and failure modes.

Polling vs push is not old versus new. Push is event-driven, while polling is the right call whenever near-real-time does not pay for itself.

Worth being specific here: The two work together. The webhook signals a change, then you call the API for the authoritative record. Good API design keeps that second call cheap.

Webhook Examples

And what is a webhook used for in reality? There is only one approach used in all webhook examples; the only thing that changes is the event names.

• Slack: Send JSON data to the webhook URL of Slack, and it will appear in the Slack channel. Slack incoming webhook notifications automation includes notifications of deployment and on-call; see Slack incoming webhooks documentation.
• Stripe: A payment_succeeded event updates the order after verification of the signature.
• GitHub: A version control push event fires a CI build process, a common practice in software development.
• Webhooks by Zapier: The Catch Hook action starts a no-code automation workflow, such as landing page leads to CRM software integration for a better conversion rate.
• Discord: A Discord webhook sends alerts to the channel just like that.
• E-commerce: Shopify orders trigger e-commerce API integration.
• Other: Social media mentions notifications, connected TV playback events, customer service ticket changes, and events forwarding to Google Analytics.

Each example is a small, well-defined event, not a firehose, so subscribe narrowly and keep the receiver simple. Here is the smallest useful payload, a Slack message:

{ "text": "Deploy finished: checkout-service v2.4" }

How to Set Up and Test a Webhook

Learning how to use webhooks takes an afternoon once you know your side. Senders publish events. Receivers accept them, and receivers are where most teams get hurt.

Creating a Webhook Endpoint

Here is how to make a webhook receiver: One route that accepts POST, parses JSON, and returns 200 quickly.

import express from "express";
const app = express();

// Keep the raw body: signature checks need the exact bytes sent
app.post("/webhooks/payments", express.raw({ type: "application/json" }), (req, res) => {
  queue.add(JSON.parse(req.body));
  res.sendStatus(200); // acknowledge fast, process later
});

Below is the step-by-step on how to create a webhook URL. Each step is quick, but the order matters:

• Deploy the route using HTTPS, so the provider can reach it securely.
• Copy the address to the provider's dashboard.
• Select the events you require, and nothing more.

Testing and Debugging Webhooks

Here is how to test a webhook. Work through three checks before go-live.

• Inspect payloads on webhook.site.
• Use a tunnel so the provider can reach localhost.
• Fire the provider's 'send test event' button, or send one yourself:

curl -X POST http://localhost:3000/webhooks/payments \
  -H "Content-Type: application/json" \
  -d '{"id": "evt_1042", "type": "payment.succeeded"}'

When delivery fails, check delivery logs and match event IDs. The usual culprit is a framework parsing the body before you verify the signature, which changes the bytes and breaks the check.

Webhook Best Practices

A retail client's handler processed one refund twice after the provider retried a slow response. Finance spotted the duplicate three weeks later at month-end. The webhook worked; the handler had no memory of what it had already done.

The least obvious cause of incidents is retries. Every retry is another chance to process the same event twice. These effective practices cover it:

• Verify the sender: Webhook signature verification means checking an HMAC or shared secret against the raw request body, over HTTPS only. Read each provider's API documentation, since Stripe and Twilio both specify it, and add security protocols such as replay windows.
• Acknowledge fast: GitHub allows 10 seconds before marking a delivery failed. Keep response length minimal (an empty 200) and queue heavy work.
• Make handlers idempotent: Store the event ID and skip repeats, because idempotency is your only defence against double delivery.
• Plan retry logic and replay: Decide what happens to missed events before they go missing.
• Subscribe narrowly: Handle only events you act on, with user permissions scoped so few people can change endpoints.
• Treat the payload as a signal: For payments, fetch fresh data from the API first.

Whether to replay failures automatically depends on the event, since refunds and chat alerts deserve different rules. That tradeoff has no clean answer.

How BNXT.ai Helps You Build Webhook Integrations

Webhooks are the trigger layer for AI agents: An event arrives, an agent reasons over it, and an action follows. Our low-code agent builder takes webhook events, passes them to Large Language Models with tool use, and returns a governed action, using structured workflows, prompt optimization, and human review workflows.

Every event gets delivery logs, traces, and replay, with no model lock-in and no hand-built receiver to maintain. Build in-house when volume is low, and use Zapier webhooks for light triggers. Shortlisting the best API integration platform? Check observability first. For custom API integration services, our AI services team can help.

What a BNXT.ai Webhook Implementation Looks Like

Most rollouts follow four stages. Timelines flex with the number of providers and event types.

• Discovery (Days 1-3): List the failures, their owners, and cost for each.
• Integration (Days 4-7): Map out the providers, check signatures, and create queues.
• Deployment (Starting Week 2): Deploy the biggest event first with a human in the loop.
• Iteration (continuously): Train the agent with traces and replays.

You finish with working agents, monitored endpoints, and runbooks. Your team owns all three.

Conclusion

Webhooks provide event data to your endpoint, and the webhooks you should trust have failure built into them: Verifying signatures, idempotent handling of requests, replaying of any lost events. Consider your endpoint a product that has been tested, owned, and has dashboards of its own, rather than something slapped together as an afterthought late on a Friday. The difficult part is receiving.

Most of the webhook failures we encounter are far from spectacular: A response timeout, no verification of a signature, duplicate handling. The difficult part is figuring out what your system should do with an event after it arrives.