Is a webhook push or pull?
A webhook is push. The provider's server opens the HTTP connection and sends a POST to your URL the moment an event happens, and your application does nothing until that request arrives. Pull is the opposite model, where your code asks the API on a schedule whether anything changed. Webhooks remove that polling loop.
What push looks like on the wire
The roles are reversed from a normal API call. In a pull model your service is the HTTP client: you send GET /orders?updated_since=..., compare the response to what you already stored, and repeat. Most of those requests return nothing new, and the ones that do return something tell you about a change that happened somewhere in the gap since the last poll.
With a webhook you are the HTTP server. You register a webhook endpoint with the provider, and from then on the provider is the client. It builds a payload describing the event, signs it, posts it to your URL, and expects a 2xx back. There is no loop in your code, no cursor to keep, and no interval to tune. The tradeoff is that you now run a public HTTP handler and inherit the operational duties that come with it. For the full comparison of the two approaches, see webhooks vs API polling.
The hybrid case: a push that triggers a pull
Plenty of providers land in between, and it confuses the question. Their webhook carries a thin payload: an event type, an object ID, a timestamp, and little else. Your handler reads the ID and calls the API to fetch the current state of that object. The notification is pushed, the data is pulled.
Providers design payloads that way on purpose. A thin payload keeps sensitive fields out of a request that crosses the internet to an endpoint they do not control, it stays small enough to avoid delivery timeouts, and it sidesteps the staleness problem: because you read the object after the notification, you always act on its latest state rather than a snapshot that may be several retries old.
The cost lands on you. Every delivery becomes an API call, so a burst of events becomes a burst of requests against a rate limit, and the object you fetch can be newer than the event that told you to fetch it. An order marked paid in the notification may already be refunded by the time you read it, which is correct behavior but surprises code that assumes the two agree. If you send webhooks yourself, our notes on designing webhook payloads cover when a thin payload is worth that overhead.
What push means for your endpoint
Because the sender picks the timing, your traffic shape is set by someone else's event volume. A quiet integration can go from nothing to thousands of deliveries a minute when a customer runs a bulk import, and no configuration on your side throttles that. Three consequences follow.
- You cannot trust the caller. Anyone can post to a public URL, so verify the webhook signature on every request before acting on the body.
- You must answer fast. Senders enforce a timeout, often a few seconds, so acknowledge the request and do the real work asynchronously rather than inside the handler.
- Duplicates are normal. Push delivery with retries means at-least-once, not exactly-once, so key your processing on the event ID and make handlers idempotent.
None of those apply to a poller, which is why polling survives despite being wasteful. When your code initiates the request, you control the rate, you already know the caller, and a failed attempt is just a retry on your own schedule.
When you still need to pull
Push does not fully replace pull, and integrations that treat it that way develop quiet gaps. Webhooks only tell you about events that happened while your endpoint was registered and reachable. Anything before that, or during an outage longer than the sender's retry window, is invisible unless you go and read it.
Production integrations usually run both. Webhooks carry the live path, where latency matters, and a scheduled job pulls a window of recent records to reconcile: it fills in what was missed, corrects anything applied out of order, and confirms that the two sides agree. The pull runs every few hours instead of every few seconds, so it costs a fraction of what real polling would, and it turns a missed delivery into a delay rather than a permanently wrong record.
The direction of the request also decides who owns reliability. When you poll, a failure is yours to retry. When you push, the sender owns the retry schedule, the signatures, the delivery logs, and the support ticket when a customer's endpoint has been returning 500 for a week. Svix provides that sending infrastructure as a service, and Svix Ingest handles the receiving end when you are the one being pushed to.