What are the disadvantages of webhooks?
The main disadvantages of webhooks are that you do not control the server receiving them, delivery is best-effort rather than guaranteed, and a consumer that was offline has no way to catch up on what it missed. Each receiver is also a public HTTP endpoint that has to authenticate every request it accepts.
You are depending on somebody else's server
A webhook delivery only succeeds if the receiver is up, reachable, and fast enough to answer within your timeout. None of those three are under your control. Receivers deploy without telling you, sit behind proxies that return 502 for a minute, or run signature verification and database writes inline so a 200 takes eight seconds to come back.
That pushes work onto the sender. You need a timeout short enough that one slow subscriber cannot occupy your workers, retries with exponential backoff for the failures that are temporary, and circuit breakers so an endpoint that has been down for an hour stops consuming retry capacity that other subscribers need. A dead letter queue catches whatever never lands.
Delivery is at-least-once, so duplicates happen
Retries and network timeouts mean a receiver will occasionally process the same event twice: the handler succeeded, the response was lost, the sender retried. Ordering is not guaranteed either, because a retried event arrives after events that were created later. Anyone consuming webhooks has to make handlers idempotent, usually by storing event IDs and dropping repeats, and cannot assume that subscription.updated arrives after subscription.created. The delivery guarantees page covers what senders can and cannot promise.
There is no replay unless the sender built one
This is the sharpest difference from a log-based system. A Kafka consumer that was down for six hours restarts, reads its committed offset, and processes the backlog. A webhook consumer that was down for six hours has whatever the sender's retry window happened to cover and nothing else. If the sender gives up after 24 hours, events older than that are gone from your side of the boundary.
Senders can fix this by exposing a list-events API or a manual replay button, and good ones do, but it is extra product surface rather than something HTTP gives you. See webhooks vs Kafka for where the two models fit.
Every receiver is an authenticated public endpoint
The URL has to be reachable from the internet, which means anyone can post to it. Receivers have to verify a signature on every request, reject stale timestamps so a captured payload cannot be replayed later, and compare signatures in constant time. Skipping any of that turns the endpoint into an unauthenticated write path into your database.
Senders carry their own risk, since a subscriber controls the URL you make requests to. Without validation, a customer can point an endpoint at an internal address and use your servers to reach it, the SSRF problem. Webhook security 101 walks through both directions.
Debugging crosses an organizational boundary
When an event does not show up, the sender sees a 200 and the receiver sees nothing, or the receiver sees a malformed body and the sender's logs are already rotated. Neither side can read the other's stack traces, so a single failure often costs a support ticket and a day of round trips. This is why delivery logs, request and response bodies, and a way for subscribers to inspect their own attempts matter more for webhooks than for a normal API. Svix Play gives you a throwaway URL for seeing exactly what a provider sends, and the webhook debugging guide covers the rest.
Sending webhooks is more infrastructure than it looks
Sending a POST is easy. Sending millions of them is a queue, a retry scheduler with persistent state, per-endpoint rate limiting so one subscriber's throttling does not stall the rest, fanout when one event goes to hundreds of subscribers, signature key management and rotation, and a dashboard subscribers can self-serve from. Teams routinely start with a background job and rebuild it twice as the failure modes arrive. That whole layer is what webhook infrastructure refers to, and it is the part Svix replaces.
When the downsides are worth it
Webhooks are still usually the right answer for cross-organization events, because the alternatives are worse at that job. Polling wastes requests and adds latency proportional to the interval, as webhooks vs API polling lays out, and a WebSocket requires the consumer to hold a connection open and reconnect forever, which you cannot ask of every customer integrating with your API. The honest trade is that webhooks move complexity from the network model into your reliability engineering, and most of that complexity is solved once rather than per integration.