Description
What is event delivery by webhooks vs polling?
Webhooks and polling are the two ways a system learns that something changed somewhere else. With polling, your code asks a REST API on a schedule — every 30 seconds, every 5 minutes — and compares the answer with what it saw last time. With webhooks, the other side calls your HTTPS endpoint the moment an event happens, so there is nothing to ask and nothing to compare; that push model is the building block of an event-driven architecture.
On the WhatsApp Cloud API the choice is largely made for you. Inbound customer messages and the sent, delivered, read and failed statuses of your outbound messages are delivered only through webhooks: there is no endpoint that lists an inbox or returns a message's delivery history. Some state can be read with ordinary Graph API calls — a template's status from GET /{WABA_ID}/message_templates, or a number's quality_rating — but those calls return the current state, not the sequence of events that led to it. And there is no API for fetching past webhook events: what your endpoint did not store, you cannot pull later.
This page compares the two approaches on latency, cost and reliability, and shows where polling still earns its place: as a slow reconciliation job that catches what a broken webhook path missed, including anything lost to an outage longer than the seven-day window of Meta's webhook retry policy. The webhook page explains how the mechanism itself works; this one explains why push wins for event streams and what pulling is still good for.
Key takeaways
- Webhooks push each event to your server as it happens; polling asks an API on a schedule whether anything changed.
- WhatsApp Cloud API inbound messages and message statuses arrive only by webhook: there is no inbox endpoint to poll.
- Meta offers no API for fetching historical webhook data, so store each payload when it arrives.
- Polling still earns a place as a slow reconciliation job for readable state such as template status and quality rating.
- Polling adds up to one interval of latency and spends rate limits on requests that mostly find nothing new.
Why it matters
Why does event delivery by webhooks vs polling matter?
The wrong model shows up in every metric. Polling a busy account adds latency equal to the poll interval, runs into Graph API rate limiting with requests that mostly say "nothing new", and still misses short-lived states between polls. Webhooks deliver in seconds and scale with real activity, but they demand a public endpoint, signature checks and idempotent handlers. Knowing which data is push-only and which can be pulled lets architects plan for both instead of finding the gap in production.
Properties
Event delivery by webhooks vs polling: key facts and limits
- Inbound messages
- Webhooks only — no inbox endpoint
- Message statuses
- Webhooks only: sent, delivered, read, failed
- Webhook retries
- Up to 7 days, with decreasing frequency
- Readable by API
- Template status, phone number quality rating
- Polling latency
- Up to one full poll interval
- Webhook requirement
- Public HTTPS endpoint with a valid certificate
Mechanics
How does event delivery by webhooks vs polling work?
step 1 — Use webhooks for event streams
Subscribe to
messagesfor inbound messages and statuses, and to account fields such asmessage_template_status_updateandphone_number_quality_update.step 2 — Acknowledge and queue
Answer each POST to your webhook endpoint with a 200 within seconds and process from a queue. Meta retries failed deliveries for up to seven days — at-least-once delivery — so short outages delay events rather than lose them, and duplicates must be skipped.
step 3 — Poll only current state, slowly
Where the API exposes state — template status, phone number quality — schedule an hourly or nightly reconciliation job, not a tight polling loop.
step 4 — Reconcile, don't replace
Compare polled state with what your webhooks reported. A mismatch means a webhook went missing: correct the record and raise an alert.
step 5 — Plan for what cannot be pulled
Inbound message content and per-message delivery history exist only in webhooks. Store raw payloads so you can rebuild from your own records.
Usage
Event delivery by webhooks vs polling in code
# Current template state — a snapshot, not a stream of eventscurl "https://graph.facebook.com/v26.0/{WABA_ID}/message_templates?fields=name,status,category&limit=100" \-H "Authorization: Bearer {ACCESS_TOKEN}"
Caveats
Common mistakes with event delivery by webhooks vs polling
Looking for an inbox endpoint
Teams coming from SMS or email APIs expect to fetch new messages. The Cloud API has no such endpoint; without a webhook, the integration is send-only.
Polling as the primary feed for state
A one-minute template-status poll across many WABAs spends rate limits and still reacts later than the webhook. Subscribe to the field and poll slowly for reconciliation only.
Trusting webhooks with no backstop
A deploy, an expired certificate or a load-balancer rule can drop events. A nightly comparison against readable state catches what slipped through.
Inferring history from snapshots
A poll that sees
APPROVEDtwice cannot tell you the template was paused for three hours in between. Only webhooks record the transitions.
Example
Example: Nothing to poll, one job worth keeping
A Mumbai skincare brand's old SMS integration polled its gateway's delivery-report API every 60 seconds, and the team planned to do the same on WhatsApp — until it found there is no endpoint to poll for messages or statuses. With a webhook endpoint, customer replies reach the order bot within seconds. The team kept one polling job: each night it reads every template's status with GET /{WABA_ID}/message_templates and compares it with the template webhooks received. Within a month it caught a paused festive template whose webhook had been dropped during a deploy, hours before the campaign was due to send.
Questions
Webhooks vs Polling FAQs
- What is the difference between webhooks and polling?
- Webhooks push events to you as they happen; polling pulls by asking an API repeatedly. Push gives seconds of latency and no wasted calls, while polling needs no public endpoint but is slower and blind between checks.
- Can I poll the WhatsApp Cloud API for new messages?
- No, inbound messages and statuses are delivered only by webhooks. A provider can host the endpoint for you, but something must receive the POSTs, because there is no inbox endpoint to call.
- Can I fetch past WhatsApp messages or statuses from the API later?
- No, the Cloud API has no endpoint for fetching past webhook events, inbound message content or delivery history. Store each payload when it arrives; it is the only record of inbound messages and per-message statuses you will have.
- Is polling ever useful with WhatsApp?
- Yes, for reconciliation. Template status, phone number quality and similar state can be read through the Graph API on a slow schedule and compared with what your webhooks reported.
- Are webhooks less reliable than polling?
- Not in practice, because Meta retries failed deliveries for up to seven days. Short outages delay events rather than lose them, while polling is dependable for current state but blind to anything between polls.
Notes
Best practices for event delivery by webhooks vs polling
- Use webhooks for anything event-shaped and polling only for state you can read back.
- Set reconciliation intervals in hours, not seconds, and stagger them across accounts.
- Keep raw webhook payloads for a few days — they are the only message history you will have.
- Treat every reconciliation mismatch as an incident in your webhook path, not just a data fix.