API Evangelist Conversation with Phil Leggetter on Webhooks, Event Destinations, and Building a Team as a Fleet of Agents

Hookdeck is great. We are quite small, about ten people, but that is a sweet spot for me, because you can be strategic and hands-on at the same time. When I joined two and a half years ago I thought, okay, webhooks, obviously used a lot in the API space and in automation. But it has been blowing my mind in terms of how big a problem it solves. We have two products now. There is the event gateway, which is essentially HTTP in, HTTP out — you can verify, queue, filter, transform, route, deduplicate, and fan out events, then plug into a different HTTP destination, which could be an API. It is like Zapier, except lower level. And then we open sourced Outpost, which is just outbound webhooks, with a hosted version of that. So I feel like we have the event space covered, properly and nicely packaged as two products. It is keeping us very busy.

The event-driven architecture space comes from a very enterprise place, and with that comes some necessary complexity and some over-architecting. I totally agree with you — a lot of the problems in the EDA space could be solved by good documentation, good communication, and HTTP, for both request-response and for asynchronous, event-driven communication. There is definitely a place for highly scalable systems like Kafka and event buses — distributed teams, however many two-pizza teams in an org, a centralized message bus. But it can be overly complex in some cases. HTTP is accessible to everybody, and at a certain scale it is fine. At larger scale, having a durable queue to reliably ingest and deliver events, with dead letter queues and so on, makes a lot of sense. That is effectively what we have built, just in much simpler packaging, with a focus on ingesting events from external services like Shopify, Twilio, and Stripe.

I have worked with this kind of architecture for a long time — even before Pusher, with Caplin Systems, where it was a pub-sub server, you subscribe to stock ticks and different events and put filters on those events. So this stuff has been around for a while. One of the things about technology is it can start simple and become complex, but it can also start complex and become very simple. I think we have come at it from both directions. We are webhooks-only in one sense, but we have also taken something that is inherently very complex and made it quite simple to understand and adopt, I hope. The durable queue, the reliable ingest and delivery, the dead letter handling — all the things you would expect from an enterprise event system — but accessible to everybody through HTTP.

We had been talking about event destinations. What we were seeing with companies like Shopify, Twilio, and Stripe is that they are offering the ability to deliver events from these external services directly into internal durable queues — SQS, Amazon EventBridge, GCP Pub/Sub — because at reasonable scale HTTP has problems. Stripe had already called their offering event destinations, so we spoke to folks at Stripe and Shopify, and to Patrick Malatack — Twilio is one of our investors through Matrix — and it seemed to be a real trend. But there was no open implementation of it, so we created Outpost as an open-source reference implementation, and it really resonated. The fundamental ask, which we genuinely had not planned for, was a hosted version. We did not open source it just to upsell hosting — the plan was to encourage the idea of event destinations. But the demand was clearly there, so that is how the hosted product came along.

If you think about how many people are building a platform that needs to publish events versus how many are building platforms that need to consume events, the pie is much bigger on the consumer side. So the event gateway has a much larger total addressable market than Outpost and the outbound side. But we are not daft — one of the Outpost event destination types, alongside SQS, EventBridge, GCP Pub/Sub, Kafka, and RabbitMQ, is the Hookdeck event gateway itself. So Outpost becomes a mechanism for introducing Hookdeck as a durable destination to consume events, and then to use as your backbone for distribution, delivery queues, and filtering. We are more small-to-medium focused, reaching the long tail of developers, educating best practices around webhooks and event destinations. The two products organically feed into each other.

That is a really good question. I wrote a post recently about making your developer platform agent-ready — there is a simple end with markdown files, llms.txt, handing instructions to the AI, through to much more complex things, like an agent discovering, signing up, building a proof of concept across three providers, and then going back to the human and saying, I have tried these, you can review and decide. I have spent a lot of time making our platform usable from an agent’s perspective, with test harnesses and scenarios so we can reliably measure whether a prompt or an agent journey works. On the pie, I think AI probably does make it bigger, though I would still say there are more consumers of events than producers. But you have challenged me, because agents both produce and consume events, and whether those grow at the same rate, I honestly do not know yet.

I probably should not admit this, but I think we are a little behind the curve. When you are seeing all the amazing things people are doing coming straight out of Anthropic and OpenAI, you feel like you should have a suite of agents doing twenty things in parallel overnight, and you come in and just review and kick off the next set. We are not quite there. We do have automated flows around content creation and skills creation for webhooks, but a lot of it is still manually triggered — a human has an idea, then we trigger the parsing, the querying of data, the generation, the pull request. We have maybe ten different scenarios where agents are in the mix, often cronned up — for example, our Outpost onboarding is now copy a prompt, create a .env, put the key in, and run, so we continuously test that works. We are cautious too, because you can burn through your tokens, and we are not Anthropic.

Gareth on our team, our head of product marketing, has built this out. He has agents with different roles — a VP of marketing, a social media manager, a paid ads manager — so his team is agents, and he vibe-coded a dashboard to look at cron runs, analyze data, and surface suggested tasks that he can accept or dismiss; accepted ones get categorized and routed to the agent that can execute. He shared this at a Shopify event in Paris and I had not thought about it that way: if I were building a physical team, what would the job specs be? Then transpose that into skills for agents, stand the agents up, and orchestrate and communicate between them — which we could do with the event gateway. I think that is how smaller and even bigger teams are scaling: identify the roles, decide which can be AI and which still need a human, and build the team out as a fleet of agents. There is tooling missing in that space, though — Gareth had to build his own.