Key takeaways
- Polling asks another system for changes on a schedule; webhooks have that system notify you when something happens.
- Webhooks are faster and use fewer API calls, but you must handle retries, duplicates and security.
- Polling is simpler and works when the other system offers no webhooks, at the cost of delay and API usage.
- Robust integrations often combine both: webhooks for speed and a periodic reconciliation poll as a safety net.
Almost every integration has to answer one question: how does system B find out that something changed in system A? There are two basic answers, polling and webhooks, and choosing well determines how fast, reliable and expensive your integration is.
Polling
With polling, your integration asks the source system at intervals, for example every five minutes: “What has changed since my last check?” It usually filters by a last-modified timestamp and processes whatever comes back.
- Pros: simple to build, works with almost any API, and you control the pace.
- Cons: data is always somewhat delayed, most calls return nothing, and frequent polling can exhaust API limits.
Webhooks
With a webhook, the source system sends an HTTP request to a URL you provide as soon as an event happens, such as “invoice paid” or “order created”. Your endpoint receives the payload and processes it.
- Pros: near real-time, efficient, and scales without wasted calls.
- Cons: you must run a reliable public endpoint, verify that requests are genuine, and handle retries, duplicates and out-of-order events.
Comparison
| Polling | Webhooks | |
|---|---|---|
| Freshness | Delayed by the polling interval | Near real-time |
| API usage | High, many empty calls | Low, only real events |
| Build effort | Low | Moderate: endpoint, security, retries |
| Failure mode | Next poll catches up | Missed events if not retried or reconciled |
Making webhooks reliable
- Verify signatures. Most providers sign webhook payloads; reject requests whose signature does not match.
- Respond fast, process later. Acknowledge the request quickly and push the work onto a queue, so slow processing does not trigger provider timeouts and retries.
- Be idempotent. Providers may deliver the same event more than once. Store event IDs and ignore repeats.
- Expect disorder. Events can arrive out of sequence. Use timestamps or fetch the latest record state before updating.
- Log everything. Keep a record of received events and their outcome for troubleshooting.
The best of both
For integrations that matter, such as payments or orders, we usually combine the two. Webhooks deliver changes in real time, and a scheduled reconciliation job compares both systems periodically to catch anything missed during outages. In Salesforce, the equivalents are Platform Events and Change Data Capture for outbound changes, and Apex REST endpoints or middleware for inbound webhooks.
A worked example: payments into a CRM
A business takes card payments through a payment provider and wants every payment recorded in its CRM. With polling, a job runs every 15 minutes, asks the provider for transactions since the last run, and creates payment records. It works, but staff see payments up to 15 minutes late and the job makes 96 calls a day even when nothing happens.
With webhooks, the provider sends a “payment succeeded” event the moment a charge completes. The integration verifies the signature, stores the event ID, queues it and creates the payment record within seconds. A nightly reconciliation job compares the day’s transactions in both systems and flags any difference, which catches the rare event lost during an outage.
Designing a webhook endpoint
- Use a dedicated URL per provider and environment, served over HTTPS.
- Verify the signature or shared secret before doing anything else.
- Return a success response quickly, then process asynchronously from a queue.
- Store each event ID and skip duplicates.
- Record failures with enough detail to replay them once the cause is fixed.
- Monitor volume: a sudden drop to zero events usually means something broke.
When polling is still the right answer
- The source system offers no webhooks or events.
- Data only needs to be fresh once a day, such as nightly reporting.
- You need to pull large historical volumes, where bulk exports are more efficient.
- Your environment cannot expose a public endpoint and middleware is not an option.
Frequently asked questions
Are webhooks secure?
They can be, if you use HTTPS, verify signatures or shared secrets, validate payloads and avoid exposing sensitive actions without checks.
How often should we poll?
As rarely as the business can tolerate. Match the interval to how fresh the data needs to be and to your API limits.
Can Salesforce receive webhooks?
Yes, through a public Apex REST endpoint on an Experience Cloud site or Salesforce Site, or more commonly through middleware that receives the webhook and calls Salesforce APIs.
