There are three durable ways to move data between two systems: webhooks (system A pushes to system B when something changes), polling (system B asks system A on a schedule), and event streams (both systems publish to and read from a shared bus). They're often presented as “just pick whichever the vendor supports,” which is roughly as helpful as picking a car based on what colour the dealer has in stock.
Each has a different reliability profile, latency profile, cost profile, and a different set of failure modes that bite six months after the integration ships. This is a working decision guide for which to use when — and the operational realities nobody puts on the marketing page.
Webhooks: fast, fragile, and the default choice
How it works: the source system makes an HTTP POST to your endpoint whenever something it cares about happens. You process it, return a 200, and move on.
What webhooks are good at
- Low latency. Updates arrive in seconds, not minutes.
- Efficient.No wasted calls polling for changes that haven't happened.
- Cheap to start. Most modern SaaS supports them out of the box.
What webhooks are bad at
- Reliability. If your endpoint is down when the webhook fires, the event might never arrive again. Vendors vary wildly on retry behaviour — some retry for hours, some give up after one failed attempt.
- Ordering. Webhooks usually arrive in roughly the right order, not guaranteed order. Two rapid edits to the same record can land out of sequence.
- Backfill.If you need to know what the system looked like before you connected the webhook, the webhook doesn't help. You also need a one-time bulk pull.
- Bursts.A vendor mass-update fires 50,000 webhooks in a minute. Your endpoint needs to handle that, or you'll drop events.
The honest summary: webhooks are great for “keep me in sync” flows where occasional misses are recoverable. They're a bad foundation for “this must never be wrong.”
Polling: boring, durable, and underrated
How it works: you call the source API on a schedule — every five minutes, every hour, every night — pull the records that have changed since last time, and apply them.
What polling is good at
- Reliability. If a poll fails, the next one will pick up whatever you missed. Self-healing by design.
- Backfill. The first poll handles the existing data. The same pattern works for steady-state.
- Rate-friendly. You control how often you call, so you control the load on both ends.
- Simple to operate.“Did last night's sync run?” is an easier question to answer than “did we miss a webhook?”
What polling is bad at
- Latency. Your data is by definition stale until the next poll. Five-minute polling means up to five-minute staleness; nightly means up to 24 hours.
- API quota. Polling lots of endpoints frequently eats API limits, especially on vendors that count list calls aggressively.
- Deletes.Most APIs don't expose deleted records via the “changed since” endpoint. Polling systems struggle to detect when something was deleted unless you do a periodic full sweep.
Polling is underrated. For most internal integrations, where five minutes of staleness is fine, polling is more reliable and easier to operate than webhooks. The reason you don't see it recommended more often is that “real-time” sounds better on a feature comparison.
Event streams: powerful, expensive, and usually overkill
How it works: a message broker (Kafka, AWS Kinesis, Google Pub/Sub, RabbitMQ) sits between producers and consumers. Producers publish events; consumers subscribe to whichever topics they need. Events are durable in the broker for hours or days.
What event streams are good at
- Many-to-many. One event, five consumers, each processing at its own pace. Adding a sixth consumer is free.
- Replay. If a consumer was down or buggy, you can rewind and reprocess the event log.
- Decoupling.Producers don't need to know who's listening. Consumers don't affect the producer's performance.
- Volume. Comfortably handles millions of events per second at scale.
What event streams are bad at
- Cost. Both the infrastructure and the team time to operate it. Running Kafka in-house is not a side project; managed services (Confluent, MSK) are real money.
- Complexity.Ordering, partitioning, exactly-once vs at-least-once semantics, schema evolution — there's a lot to learn and a lot to get wrong.
- Two-system integrations. When you only need to move data from system A to system B, an event stream is industrial machinery for cutting an apple.
Event streams earn their keep when you have five-plus internal services that all need the same events, or when you're building data infrastructure (analytics, ML pipelines) that needs to replay history. For point-to-point SaaS integrations, they're almost always the wrong tool.
The decision guide
- Webhooks when you want the lowest-latency push, you have one consumer, and missed events are recoverable (or you can supplement with periodic polling to catch any drops).
- Pollingwhen reliability and operability matter more than seconds-of-latency, when the source API doesn't offer webhooks, or when you need to track deletes and changes you might have missed.
- Webhooks + polling together for production- critical integrations: webhooks for low latency, a scheduled poll as a safety net for missed events.
- Event streamswhen many internal services need the same events, or when you're building infrastructure that has to replay history.
The operational checklist nobody talks about
Whichever pattern you pick, the same set of operational concerns determines whether it survives in production:
- Idempotency. The same event can arrive twice. Your consumer must be able to handle that without double- processing.
- Dead-letter handling.Events that can't be processed need to go somewhere — not into the bit bucket, not into an infinite retry loop.
- Monitoring.You need to know when events stop arriving, not just when they fail. “Last successful webhook” is a metric.
- Schema evolution. Fields will be added, renamed, and removed by the source system. Plan for that, or your integration breaks every time a vendor ships a release.
- Replay capability. When something goes wrong, can you re-process the last hour of events? Webhooks make this hard; polling and event streams make it easy.
The most common mistake we see
Building a webhook-only integration for data that has to be right. The vendor's webhook delivery isn't guaranteed; your endpoint occasionally returns a 500 under load; you lose events. A year later, the systems disagree on 0.3% of records, and the team spends every Tuesday morning reconciling.
The fix is almost always to add polling as a safety net. Webhooks keep latency low. A nightly delta poll catches whatever fell through. The combination is more durable than either alone, and the marginal cost is small.
The honest bottom line
Pick the pattern that fits the operational reality, not the one that sounds best on the slide. Polling is fine — sometimes excellent — for internal integrations. Webhooks alone are not a safe foundation for data that has to match. Event streams are powerful and probably more than you need. The architecture that's right for your team is the one that's still running, in five years, with the next person maintaining it.