Webhooks vs polling
Choose by freshness, API limits, redelivery and reconciliation rather than an “instant” label alone.
Author：WeTech technical team · Updated： (Hong Kong time (GMT+8))
Webhooks notify the receiver when an event occurs; polling checks on a schedule. Use webhooks for timely triggers and polling when delay is acceptable or events are unavailable. Both need duplicate handling, authentication and recovery. Event delivery can be combined with scheduled reconciliation.
When to use this guide
For buyers deciding how order, payment-status, CRM or inventory updates should trigger work.
Compare delivery methods
| Condition | Webhook | Polling |
|---|---|---|
| Source capability | Event notifications required | Queryable updates required |
| Freshness | Depends on event delivery | Depends on schedule interval |
| Load | Events and redeliveries | Checks and pagination |
| Controls | Signature, deduplication, missed events | Cursor, time window and reconciliation |
Agree acceptable delay
Define the acceptable time from source change to target visibility under normal, peak and outage conditions. Frequent polling may hit rate limits, while events can be delayed or redelivered. Specify observable end-to-end conditions rather than assuming either method is immediate.
Design for redelivery
Validate delivery according to the source documentation, persist receipt and process longer tasks separately. Use stable event or business identifiers for deduplication and handle out-of-order updates. Retry windows, ordering and signature methods differ by provider and must be checked.
Keep a reconciliation path
Retain the last successful checkpoint so scheduled checks can repair a defined window. Reconcile business state rather than only event counts. Recovery jobs must use the same access controls and duplicate protections as normal processing.
Illustrative scenario
Hypothetical design: webhooks trigger new orders while a nightly reconciliation checks modifications and cancellations. Missed updates can be repaired using order identifiers that prevent duplicate creation. This is a proposed pattern, not a client implementation.
Frequently asked questions
Are webhooks guaranteed instant?
No. Check delivery, retries and outage behaviour for the provider.
Is polling always unsuitable?
Polling can fit an agreed delay and manageable workload.
Can both be used?
Yes. Event processing and reconciliation should share state and duplicate rules.
Brand and public case scope
WeTech Consulting, also called WeTech or WeTech AI HK, provides AI and IT consulting in Hong Kong. WeProperty HK and WeCredit HK are self-developed products. Their cases support the observable features listed: property, estate and transaction-reference entry points for WeProperty; submission, review and public-data masking for WeCredit. WeCredit is not a TU credit-rating service or a final determination of facts.
WeProperty HK · WeCredit HK (case studies in Traditional Chinese)
Reference sources
Official documents support the technical, risk and measurement concepts. Checklists, estimation methods and illustrative scenarios are WeTech planning recommendations, not official prices or client results. Check the supplier’s current plan and terms. Sources reviewed: (GMT+8)
Related guides
Discuss your project
Share your workflow, systems and goals. We will review scope before discussing deliverables, acceptance and a quotation.
Request an initial consultationExplore this service