Somewhere between "I'll just poll it every minute" and a full event-driven architecture, there's a practical middle ground that most teams land on. Webhooks are a big part of that. Once you see how they work, what can go wrong, and when they're the wrong tool entirely, the decision gets a lot clearer.
TLDR:
- A webhook is an HTTP POST request a source system sends to your endpoint the moment an event fires, no polling needed
- Webhooks use "at-least-once" delivery, so make your handler idempotent using the event
idto skip duplicates - Secure your endpoint with HMAC-SHA256 signature verification, used by 65% of webhook implementations
- Use webhooks for live event reactions and polling for bulk historical data; most production systems need both
- hotglue fires webhook callbacks with UUIDs and direct record URLs after each sync, so your backend knows exactly what changed
What a Webhook Is
A webhook is an HTTP request that one system sends to another the moment a specific event occurs. No polling, no manual refresh. When the event fires, the data goes out automatically.
Think of it like a text notification from your bank. You don't call every hour to ask if your paycheck arrived. They notify you when it does. Webhooks work the same way.
When a trigger event fires (a new order, a failed payment, a completed sync), the source system sends an HTTP POST request for real-time data transfer to a URL you've defined in advance. That request carries a payload (usually JSON) describing what happened. Your server receives it, processes it, and responds.
No waiting, no wasted requests.
How Webhooks Work
A webhook call starts when something happens in the source system: a new customer signs up, a payment fails, an order ships. That event triggers an HTTP POST request carrying a JSON payload that describes what occurred, sent to a webhook URL you registered in advance (the endpoint).
Your server receives it, processes the payload, and returns an HTTP 200 response to confirm receipt. If that 200 never arrives, most systems will retry delivery after a short delay.
The whole cycle typically completes in milliseconds. Your endpoint just needs to be publicly accessible and ready to receive POST requests.
Webhooks vs. APIs: Push vs. Pull
With a traditional API, your app asks a server "anything new?" on a schedule. That's polling. Most of those requests return nothing useful, burning compute and API rate limits just to check. Webhooks flip that: the source system tells you when something happens, and only then.
As Strapi puts it, webhooks push data to you when something happens, while APIs let you pull data when you need it. Neither is universally better. The right choice depends on your use case.
| Webhooks | API Polling | |
|---|---|---|
| Data delivery | Push, event-triggered | Pull, request-triggered |
| Latency | Near real-time | Depends on poll frequency |
| Resource usage | Low (fires only on events) | High (fires regardless of changes) |
| Best for | Event-driven updates | Scheduled reads, bulk queries |
Polling still makes sense when you need historical data on demand, when the source doesn't support webhooks, or when you want explicit control over when data is fetched. See batch vs. trigger sync methods for a deeper breakdown. For reacting to live events, webhooks are the cleaner pattern.
Common Webhook Use Cases
Webhooks show up everywhere once you know what to look for, and once you do, you'll start seeing them in every system you've ever integrated (congratulations, it's a one-way door). A few common scenarios:
- A Stripe payment succeeds and fires a webhook to your backend, which triggers an invoice email and updates the customer's subscription status
- A Shopify order is placed and notifies your fulfillment system so it can start picking and packing without any manual hand-off
- A GitHub push hits main and triggers a CI/CD pipeline to run tests and deploy
- A HubSpot deal moves to "Closed Won" and syncs the new customer record into your billing or ERP system
- A user completes onboarding and fires a webhook that starts a drip email sequence
The pattern is the same in each case: something happens, a system you trust tells you about it, and your app responds. The event is the trigger; the webhook is the messenger.
Webhook Payload Structure
Most webhook payloads are JSON objects. Here's a representative example of what arrives at your endpoint:
Nearly every provider's payload includes a few common fields:
event(ortype): what happenedtimestamp: when it happenedid: a unique event identifier useful for deduplicationdata: the actual resource or object the event describes
The id field is worth paying attention to. Networks retry failed deliveries, so your endpoint may receive the same event more than once. Storing processed event IDs lets you skip duplicates safely.
Webhook Delivery Guarantees and Reliability
Webhooks are reliable in practice, but HTTP delivery carries no built-in guarantee. Your endpoint could be down, slow to respond, or return a 500 at exactly the wrong moment. Most webhook providers solve this with retry logic, but that introduces a new problem: your endpoint may receive the same event more than once.
This is the "at-least-once" delivery model. The provider keeps retrying until it gets a 200. Exactly-once delivery is far harder to guarantee, and most systems don't promise it.
Two things help here. First, respond fast. Most providers enforce a timeout of a few seconds. If your processing logic is slow, return 200 immediately and handle the actual work asynchronously in a queue. A pre-processing layer can help manage this cleanly. Second, make your handler idempotent. Using the event id field to track which events you've already processed means a duplicate delivery becomes a no-op instead of a problem.
Webhook Security: How to Protect Your Endpoints
Your webhook endpoint is a public URL, which means anyone can send a POST request to it, including bad actors beyond the service you're expecting. Without verification, a malicious actor could trigger actions in your app with a convincing fake payload.
The industry standard defense is HMAC signature verification. HMAC is used by 65% of webhook implementations studied. The provider signs each request using a shared secret key and a hashing algorithm (typically HMAC-SHA256), includes the signature as a request header, and your server recomputes and compares it to confirm legitimacy.
Two additional controls round out a solid implementation:
- Timestamp validation: providers include a timestamp in the request so you can reject anything older than a few minutes, blocking replay attacks where a valid payload gets captured and re-sent.
- TLS enforcement: only accept webhook traffic over HTTPS so payloads cannot be intercepted in transit.
Store your webhook secret in an environment variable and rotate it if you suspect it has been compromised.
When to Use Webhooks and When Not To
Webhooks are a strong fit when you need to react to events as they happen and the source system supports them. Low latency requirements, high event frequency, and architectures that are already event-driven all point toward webhooks.
Polling holds up better in a few specific cases:
- The source system exposes only a REST API and emits no events of its own.
- You need bulk historical data instead of live updates.
- Events are infrequent enough that a scheduled pull is simpler to operate.
- You want explicit control over when data is fetched, such as in batch-focused ETL workflows.
Here is a rough decision guide to help you choose:
| Scenario | Better choice |
|---|---|
| Payment status changes instantly | Webhook |
| Nightly accounting data pull | Polling |
| Real-time inventory updates | Webhook |
| Source API has no webhook support | Polling |
| Bulk backfill on new customer onboarding | Polling |
If your system needs both live reactions and historical context, combining the two approaches works well, including bi-directional integrations, with webhooks for ongoing events and polling for the initial data load.
Webhooks in the Context of Broader Data Integration
Webhooks are one piece of a larger puzzle. Most real integration architectures combine several data movement patterns, and knowing where webhooks fit saves you from over-engineering one part while underbuilding another.
Each pattern covers ground the others cannot:
- Batch ETL pulls historical data on a schedule, useful for reconciliation and backfills.
- REST APIs give you on-demand reads when you need to query state at a specific moment.
- Webhooks handle the reactive layer: something happened, go act on it now.
Webhook volume grew 2-3x year-over-year, yet only 9% of teams self-report using them. This gap is covered in detail when looking at the future of data integration. Teams are often running on webhooks without fully accounting for them in their integration architecture.
In practice, a well-built product integration uses all of these patterns together. An initial customer onboarding might trigger a bulk historical sync via polling, ongoing changes then arrive through webhooks, and a scheduled ETL job aligns records nightly.
How hotglue Handles Webhooks and Data Integration
Webhooks handle the reactive moment well. What they don't handle is everything around it: authentication, stateful sync, deduplication across tenants, historical backfills, and connector maintenance as third-party APIs evolve. In a B2B SaaS context, this work typically lands on the engineering team (often a platform or integrations engineer), with the CPO or Head of Partnerships accountable for making sure it actually ships on time and doesn't quietly become a six-month detour.
That's the gap hotglue fills. We process roughly 10 billion records weekly across 38,000+ active tenants, and the orchestration layer covering scheduling, retries, field mapping, and delivery guarantees is handled for you. After a sync completes, hotglue fires webhook callbacks containing UUIDs and direct URLs to the records created or updated, so your backend knows exactly what changed without parsing raw payloads. If a sync fails mid-run, it fails loudly: a partial sync will never silently succeed, preserving state for a clean retry.
For product teams embedding customer-facing integrations, rebuilding that reliability layer for every connector is the part that quietly consumes months of engineering time. Building a data integration pipeline without tech debt is exactly the problem hotglue is designed to solve. hotglue's open-source connectors, Python transformation layer, and tenant-based architecture give you a production-grade embedded iPaaS integration layer without starting from scratch each time.
Final Thoughts on What Webhooks Are and How to Use Them
Webhooks keep your app in sync with the world around it, no polling required. The fundamentals are approachable, but building the reliability layer around them, retries, deduplication, signature verification, takes real effort at scale. Knowing when to use webhooks and when to reach for polling is what makes the difference between an integration that holds up and one that quietly breaks. If you want to skip rebuilding that infrastructure yourself, book a demo with hotglue.
FAQ
What is a webhook and how is it different from a regular API call?
A webhook is an HTTP POST request a system sends automatically when a specific event occurs, such as a payment succeeding, an order shipping, or a record updating. A regular API call works the opposite way: your app requests data on a schedule, whether or not anything has changed. Webhooks are event-driven and push data to you; API polling is request-driven and pulls data from the source.
Webhooks vs. polling: which should I use for live payment and order event updates?
Webhooks are the right choice for reacting to live events like Stripe payment confirmations or Shopify order placements, since they fire the moment something happens with near-zero latency. Polling works better when the source system has no webhook support, when you need bulk historical data, or when you want explicit control over fetch timing, such as a nightly accounting sync to QuickBooks or NetSuite.
How do I secure a webhook endpoint against spoofed requests?
Use HMAC-SHA256 signature verification: the provider signs each request with a shared secret, includes the signature as a request header, and your server recomputes it to confirm the payload is legitimate. Pair that with timestamp validation to block replay attacks and enforce HTTPS so payloads cannot be intercepted in transit. Store your webhook secret in an environment variable, never hardcoded.
What handles everything around a webhook that the webhook itself doesn't cover: auth, deduplication, retries, and historical sync?
Webhooks handle the reactive moment well, but the surrounding orchestration (authentication, stateful sync, deduplication across tenants, historical backfills, and connector maintenance as third-party APIs change) requires a separate layer. hotglue fills that gap: after a sync completes, it fires webhook callbacks with UUIDs and direct URLs to the records created or updated, guarantees a partial sync will never silently succeed, and handles retry logic and field mapping across 650+ open-source connectors processing roughly 10 billion records weekly.
How do I build a new integration connector when a prospect uses a tool my product doesn't yet support?
The fastest path is an embedded integration platform with a custom connector builder. hotglue can stand up a new connector in one to two weeks from sandbox API access, using either a no-code builder or Python SDK. Building in-house typically takes far longer once you account for authentication, schema mapping, rate limit handling, and ongoing maintenance as the third-party API evolves.