Webhooks, Event Gateways, and the Chaos of Vendor

Alex Bouchard started Hookdeck because he was trying to sell women's fashion online and kept getting buried in webhook failures. That's the origin story in one sentence, and it's a better encapsulation of why event infrastructure is a real business problem than any whitepaper you'll read this year.

Bouchard sat down with the Better Stack podcast recently, and the conversation moved fast through territory that most infrastructure companies won't touch directly: the hidden latency problems that vendors create for their own customers, the political awkwardness of AI-generated PRs with hallucinated APIs, and why he thinks poll-based queuing systems are, in his words, "just very dumb." He's not wrong on any of these counts, though the degree to which you care depends heavily on where you sit in the event delivery chain.

The iceberg under the HTTP request

Bouchard's framing of webhooks as a "gateway drug to event-driven architecture" is the most useful thing he says in the whole conversation. Not because it's novel, but because it accurately describes how most developers actually encounter the problem.

You integrate Stripe. Stripe sends you a webhook. Suddenly you're learning about idempotency, ordering guarantees, dead letter queues, and why your server needs to respond within five seconds or the whole thing falls over. None of this was in the tutorial. Welcome to asynchronous event-driven programming — hope you packed a lunch.

The standard advice for handling this, as Bouchard lays it out, involves a fairly brutal stack: ingestion consumers that can autoscale, an SQS queue, a fleet of downstream consumers, dead letter queue handling, and then some bespoke tooling to replay events when things go wrong. That's before you've dealt with the fact that Stripe gives you a decent UI for inspecting payloads and Intercom doesn't. The complexity isn't fake. It's just that most of it is accidental rather than inherent.

Hookdeck's pitch is that it absorbs most of that stack for you. The event gateway sits between your vendors and your infrastructure — you swap in a Hookdeck URL wherever your webhook endpoint used to be, and you get filtering, transformation, routing, queuing, replay, and alerting as a managed layer. No redeployment. No cloud vendor lock-in. It works over HTTP, which means the only hard requirement is updating a URL.

The more recent product, Outpost, runs the other direction: it's for teams that need to send webhooks and events, not just receive them. And it's Apache 2.0 open source, which brings us to the part of this story that's actually interesting from a sustainability standpoint.

Open source with aligned incentives (for once)

Bouchard makes a pointed distinction between genuine open source and what he calls "fake open source" — projects that are technically open but structured so that nobody really benefits from self-hosting, or that quietly add license restrictions once they've built a user base. He's describing a phenomenon my colleague Marcus Chen-Ramirez and I have covered at length: the open core bait-and-switch that's become almost a cliché in VC-backed infrastructure companies.

What Hookdeck did with Outpost is structurally different, and it's worth paying attention to the logic. Bouchard's argument is that receivers of webhooks outnumber senders by orders of magnitude — if you send webhooks to a thousand customers, there are a thousand potential webhook consumers for every one sender. The consumer side is the bigger business opportunity, so open-sourcing the sender tooling costs Hookdeck almost nothing and builds goodwill with exactly the people who might eventually become paying customers on the receive side.

"Our job I think is to encourage producing of events," Bouchard says on the podcast. "And that's the thing that we ultimately care about because we want more people to consume those webhooks."

The incentive alignment here is genuine, not performative. The managed version of Outpost runs the exact same Docker build as the open source version — no private fork, no hidden feature tier. You're choosing between operational burden and paying someone else to carry it. That's a clean, honest tradeoff.

The flip side is that open source projects with real users attract AI-generated contributions, and not all of those contributions are what they appear to be. Bouchard describes one open PR to add Cloudflare Queues as a destination that, when you actually read the code, uses entirely fabricated Cloudflare APIs. Nobody ran it. The PR is still open because closing it risks looking like Hookdeck is hostile to a potential competitor destination. It's a micro-level governance headache that's becoming increasingly common: the contribution looks legitimate on the surface, creates social obligations when opened, and puts the maintenance burden on the maintainer to clean it up or reject it diplomatically.

When your vendor DDoSes you

The most technical — and frankly most alarming — section of the conversation is about what happens during vendor outages. When Shopify goes down for thirty minutes and then recovers, it doesn't slowly ease back into normal traffic. It blasts through its backlog as fast as possible, scaling beyond its usual capacity to clear the queue. That traffic hits your servers all at once.

Bouchard describes this dynamic clearly: the cascade is self-reinforcing. The more overwhelmed your server gets, the slower the response times. The slower the response times, the harder it is for the vendor to get throughput. The vendor scales up. Your server gets more overwhelmed. At some point, vendors cut the connection entirely to avoid holding open thousands of HTTP connections — which means you lose events.

One of Hookdeck's investors was previously the CPO at Twilio, and Bouchard notes on the podcast that the investor described Twilio as "routinely just DDoSing their customers" — not maliciously, just as an inherent property of how vendor webhook delivery works at scale.

This is the part that Hookdeck's Radar product is specifically trying to surface. By aggregating latency data across all customers receiving webhooks from a given vendor, they can tell you whether your slow webhook processing is your fault or Shopify's fault. That's a genuinely useful thing to know. The Spider-Man meme of everyone pointing fingers at each other's team while the actual culprit is a third-party platform's delivery latency is a real dynamic, and having the data to cut through it matters.

The contrast Bouchard draws between raw downtime and latency degradation is sharp: if webhooks stop entirely, your observability tools catch it immediately. If delivery latency climbs from a normal baseline to sixty seconds, that's nearly invisible from your side — you're not measuring vendor-side delay, you're measuring your own processing time. Meanwhile your business logic, which assumed near-real-time events, starts producing subtle bugs and wrong outputs.

AI agents are coming for your event queue

The AI dimension of this conversation isn't speculative. Bouchard's read — backed by conversations he describes having with people who run platforms seeing these trends firsthand — is that LLM adoption is creating entirely new webhook use cases for data nobody cared about before. The customer support ticket that used to route to a human agent now might trigger an automated workflow. The event that previously had no downstream consumer suddenly matters.

"When you move from humans triggering to agents," Bouchard says, "what triggers agents is events."

That shift has infrastructure implications. Agentic workflows are non-deterministic and can run for unpredictable amounts of time, which makes capacity planning much harder. If what runs in response to a webhook is a five-minute LLM pipeline instead of a three-hundred-millisecond function, your assumptions about throughput and back pressure need to be completely rebuilt.

Bouchard is careful to note that his team hasn't solved this internally — they're "still trying to figure out the right way." He's skeptical of the idea that AI tooling alone can get you to high-quality shipped product, and he's spending more time reviewing AI-generated PRs than he'd like. But he also notes that non-engineers on his ten-person team are now shipping code — the designer is "fully responsible for the website" and doing dashboard work — because the barrier shifted from syntax to taste. That's a real redistribution, even if the bottleneck just moved rather than disappeared.

The poll vs. push argument

Bouchard's hot take — that poll-based queuing systems are fundamentally dumb compared to push-based ones — is the kind of opinion that tends to land differently depending on whether you've hit the scaling wall he's describing.

The core argument: every poll-based queue needs a dedicated consumer. If you want per-customer queues (to prevent noisy neighbors from blocking each other), you need as many consumers as you have queues. That multiplexing problem gets expensive and complicated fast. Push-based systems sidestep it: all queues push to the same consumer endpoint, which you can scale independently of how many queues exist.

Whether this constitutes a category-level design failure or a reasonable tradeoff that most teams haven't needed to optimize around yet is an open question. What's not open is that the teams Hookdeck works with who have hit this problem tend to find it fairly convincing.

The "event gateway" category that Bouchard coined — and that has since been adopted by players ranging from Kong to Azure — is still coalescing around shared terminology and expectations. AWS EventBridge solved the problem for teams already living in the AWS ecosystem. Hookdeck is betting that a meaningful slice of the market wants something cloud-agnostic, push-based, and developer-friendly enough to not require a week of onboarding.

That bet started with a frustrated Medium post in a basement and five readers who responded. Five people that felt like enough to keep going — which is either a good origin story or a reminder of how low the bar is when you're building something nobody knew they needed.

Dev Kapoor covers open source software and developer communities for Buzzrag.