You're building an automation. Your trigger source supports both webhooks and a polling API. Which do you choose? Most teams default to one or the other based on familiarity. The right answer depends on three constraints — let's work through them.
The Two Models in 60 Seconds
Polling means your automation asks the source system on a schedule: "Anything new?" Every 5 minutes, every hour, every day. The source system answers each time, even if nothing changed.
Event-driven (webhooks) means the source system tells you when something changes. You sit and listen. Zero requests when nothing happens. Instant signal when something does.
Constraint 1: Latency Tolerance
If your automation needs to react in under 60 seconds, polling at 5-minute intervals introduces an unacceptable lag. You'll miss the moment by the average 2.5 minutes. Webhooks land within 200-2000 milliseconds. So latency-sensitive workflows — fraud detection, customer support response, real-time pricing — should be event-driven.
If your workflow runs nightly or weekly anyway, latency is irrelevant. Polling at the cadence you actually need is fine and often simpler to operate.
Constraint 2: Rate Limits and Cost
Polling at 1-minute intervals = 1,440 API calls per day per resource. If you have 100 resources, that's 144,000 calls daily. Many APIs charge per call or rate-limit aggressively. Run the math: if the source system has even mild rate limits, polling at sub-hourly cadences breaks down quickly.
Webhooks send data only on actual changes. A resource that updates 5 times a day generates 5 webhook calls — regardless of how many resources you're tracking. The math reverses: webhooks scale linearly with change frequency, not with the number of monitored resources.
Constraint 3: Source System Support
Not every source system supports webhooks. Even systems that claim to often have caveats — limited event types, no retry logic, IP restrictions, certificate requirements. Audit before committing. A specific check: can the source system retry a failed webhook delivery? If not, you'll need to add polling as a backup anyway, and now you've doubled the operational complexity.
The Decision Matrix
| Scenario | Use |
|---|---|
| Sub-minute latency required | Webhooks |
| Daily/weekly batch processing | Polling |
| 1000+ monitored resources, low change rate | Webhooks |
| 10 monitored resources, very high change rate | Polling (aggregated) |
| Source system has unreliable webhook delivery | Polling, or hybrid |
| You can't expose a public endpoint | Polling |
The Hybrid Pattern
The strongest production setups combine both. Webhooks for real-time signal, low-frequency polling (hourly or daily) as a reconciliation backstop to catch anything the webhooks missed. The polling job's only output is a diff against what webhooks have already delivered — when the diff is non-empty, you've detected a delivery failure.
Tomorrow
We cover idempotency keys: how to make sure your automation doesn't process the same event twice when webhooks retry on failure.