Standard HTTP is a request-response protocol: the client sends a request, the server sends a response, the connection closes or is returned to a pool. This model is efficient for most API use cases. It is the wrong model when the server needs to push data to the client without waiting for a client request — live dashboards, chat applications, collaborative editing, real-time notifications, trading feeds. Three patterns exist to bridge this gap, each with a different complexity profile and a different set of constraints.

Every integration eventually confronts the same question: how does my system learn that something changed in someone else’s system? The two answers are polling and webhooks. Polling asks the question repeatedly. Webhooks get notified when the answer changes. Understanding which approach fits a given situation — and why — shapes everything from latency and cost to reliability and operational complexity.

Polling: The Default That Mostly Works

Polling is the simpler mental model. Your application sends requests to an API on a schedule — every 30 seconds, every minute, every hour — and checks whether anything has changed since the last check. If yes, process the changes. If no, wait for the next interval.