Are webhooks outdated?
No. An HTTP POST to a URL the receiver registered is still the standard way one server tells another that something happened, and the API providers most developers integrate with, Stripe, GitHub, Shopify, Slack, all ship webhooks as their primary event mechanism. What has aged is hand-rolled delivery code, not the pattern itself.
Where the impression comes from
Two things feed it. The first is that newer transports got the attention. WebSockets, server-sent events, gRPC streaming, and more recently MCP all arrived with a story about real-time data, and it is easy to read that as the older mechanism being superseded. They solve a different problem. A webhook is one event, one request, no connection held open, crossing from a company you do not control to a server you do.
The second is that the painful parts of webhooks are the visible ones. A team that wired up an endpoint and then spent a quarter on duplicate events, missed deliveries, and signature bugs tends to conclude the mechanism is dated rather than that their implementation was thin. Those problems are real, and the disadvantages page covers them honestly, but every one of them has a known fix.
What actually replaced webhooks, and where
Browser-facing updates moved to persistent connections, correctly. If a user is watching a dashboard that has to change within a second, you want SSE or a WebSocket, not an HTTP callback to a server the browser does not have. Webhooks were never a good fit there, so nothing was lost. The webhook vs WebSocket comparison lays out where the line falls.
High-volume internal event traffic moved to brokers. Inside one trust boundary, where you own both ends and can run infrastructure, Kafka, Kinesis, or a queue gives you ordering, replay, and throughput that HTTP callbacks cannot match. That is a genuine displacement, and webhooks vs Kafka is worth reading if you are choosing between them. It only applies inside your own perimeter.
Agent tooling added MCP, which is a pull mechanism: a model asks a server for data or invokes a tool. It sits alongside webhooks rather than over them, and the two are often wired together, with a webhook waking the agent that then pulls context.
Subtract all three and the case webhooks own is untouched: pushing an event across an organizational boundary to a receiver who is not running your client library, will not hold a connection open, and wants to be told rather than to keep asking. The alternative there is polling, which is worse on latency and worse on load.
The evidence they are current
Providers keep versioning and extending their webhook APIs, which is not what deprecation looks like. When Slack retired custom integrations, incoming webhooks through a Slack app stayed and became the documented path, a distinction that trips people up often enough to need its own page. The direction of travel is standardization rather than replacement: the Standard Webhooks specification exists to make signature headers and payload metadata consistent across providers, which is an investment in the format, not an exit from it.
What has changed is who runs the delivery
The bar for a credible webhook implementation is higher than it was five years ago. Receivers now expect signed requests they can verify, retries with exponential backoff, a dead letter queue for what never lands, delivery logs they can search when an event goes missing, and a portal where they can add an endpoint and replay a failure themselves. Meeting all of that is a service, not a background job, and the webhook infrastructure page describes the pieces.
So the honest version of the question is not whether webhooks are outdated but whether writing the sending side yourself still makes sense. Most teams find the first version takes a week and the next two years go to rate limits, endpoint outages, secret rotation, and support tickets about events that arrived twice. Svix provides that layer as a service, and Svix Play gives you a URL to inspect what your service is actually sending while you build it.