Sign in Get started

Decision guide

Polling vs Webhooks (vs Streaming)

How should clients learn that something changed on your server?

Side by side

CriterionPollingWebhooksStreaming (SSE/WebSockets)
LatencyPoll intervalSecondsSub-second
Consumer requirementsHTTP client onlyPublic HTTPS endpoint + signature verificationPersistent connection handling
Delivery guaranteesClient controlsProvider retries; consumer dedupesReconnect + resync needed
Provider costWasted requestsRetry queues, delivery logsConnection management
Missed-event recoveryNaturalRetries + events API for backfillResync on reconnect
SecurityStandard authHMAC signatures, SSRF-safe deliveryAuth on connect, per-event authz

When to choose each

Polling

Clients periodically call GET (ideally with ETags / updated_since).

Choose when

  • Simple integrations
  • Clients behind firewalls (no public endpoint)
  • Low change frequency

Avoid when

  • Near-real-time needs at scale
  • Many clients polling frequently

Webhooks

Server POSTs signed events to a URL registered by the consumer.

Choose when

  • Server-to-server integrations
  • Event-driven workflows (payments, shipping)
  • Avoiding wasted polling

Avoid when

  • Consumers without public HTTPS endpoints
  • Browser/mobile clients

Streaming (SSE/WebSockets)

Persistent connection pushing events.

Choose when

  • Browser/app UIs needing instant updates
  • High-frequency updates

Avoid when

  • Server-to-server integrations (connections must be kept alive)

Verdict

For server-to-server integrations, offer webhooks plus a list/events endpoint for backfill and reconciliation (webhooks can be missed). Use streaming for interactive UIs and polling as the universal fallback.

Learn more

Sources