# Webhook vs Long Polling: Real-Time Trade-offs

Long polling has your client send a request that the server holds open until data is available (or a timeout hits), then the client immediately reconnects, which approximates real-time without webhooks. A webhook flips the direction entirely: the source pushes to your endpoint with no connection to hold open. Long polling avoids the need for a public endpoint but ties up connections and scales poorly; webhooks are the more efficient choice for backend-to-backend event delivery.

## Webhooks vs long polling at a glance

|  | Webhooks | Long polling |
| --- | --- | --- |
| Direction | Source pushes to you | You hold a request open to the source |
| Open connections | None between events | One per waiting client |
| Latency | Near-instant | Near-instant while connected |
| Scaling cost | Grows with event volume | Grows with number of clients |
| Needs public endpoint | Yes | No |

## When to use each

Use webhooks when you control a backend service that can receive inbound requests and want to avoid holding connections open.

Use long polling when the consumer cannot expose an endpoint (a browser or a locked-down client) and you still need near-real-time delivery without WebSockets.

## How Hookdeck fits

Long polling keeps latency low by keeping your infrastructure busy waiting. Webhooks remove the waiting but hand you delivery concerns instead. Hookdeck absorbs those concerns: it holds a durable queue in front of your service, retries failed deliveries, and lets you replay any event, so a slow or down consumer never loses data. See the [Event Gateway overview](https://hookdeck.com/event-gateway).

## Related questions

* [Webhook vs API Polling](/webhooks/faq/webhook-vs-api-polling)
* [When is polling better than webhooks?](/webhooks/faq/when-is-polling-better-than-webhooks)
* [Webhook vs WebSocket vs SSE](/webhooks/faq/webhook-vs-websocket-vs-sse)