Over the past year or so, we've been slowly working on a new product called Hook Relay, and we're now ready to officially introduce it to the world.

The idea for Hook Relay came from the work we've done in Honeybadger sending web hooks for notifications of events happening in our app. We've supported web hooks for a long time in Honeybadger, and we originally implemented them the way any typical developer would: by creating a background worker (e.g., a Ruby class that includes Sidekiq::Worker) that has one job — to make a POST request to an HTTP server with a JSON payload. But, as time went by, and as we encountered a variety of scenarios we hadn't originally anticipated with our naive approach, we discovered there was some additional functionality we needed to implement.

For example, it didn't occur to us that people would enter a private address, like http://localhost:3000, as the destination URL. When we started seeing our Sidekiq jobs run out of retries because they couldn't hit private addresses, we realized it's a really bad idea to allow customers to try to make us hit internal URLs. :) Similarly, we don't want our web hooks to be hitting things like the EC2 Metadata URL and possibly leaking sensitive data, or performing other types of Server-side request forgery attacks. As we were working to make sure private addresses wouldn't pass our validation checks, we decided we might as well avoid trying to deliver to URLs like http://wontever.resolve, too.

We added other little things here and there, too, not really paying much attention to web hooks (as long as they kept getting delivered), until one day I happened to be working on our Stripe integration (processing web hooks sent by Stripe) when I saw a support request about a web hook delivery to one of our customers. As I was digging in to that support request, I thought, "I wish we had a UI for seeing when web hooks were sent, and what was in them, like Stripe does, so I wouldn't have to dive into the database for this." Being subject to the entrepreneurial weakness of chasing the new shiny, decided I needed to build an app for that. :)

I was also doing a lot of work with AWS Lambda at the time, growing deeply familiar with the world of Serverless, so I thought it would be a cool project to build using the Serverless framework. In no time at all, I had an API that could receive a web hook and relay it to a destination URL hosted in multiple regions around the world. Then, I sprung the idea on the rest of the Honeybadger crew, bought Jumpstart Pro for the user-facing app, and got Kevin to get the UI to the point where we could get beta testers using it.

Of course, once other people started using it, we got feature requests. :) I was only thinking of outbound web hooks, but it didn't take long for customers to ask about inbound ones. They wanted to be able to handle the case where web hooks were being sent to them, and Hook Relay would retry deliveries if their apps went down. Next, we added the ability to just store the received payloads, rather than forwarding them to a destination URL, so Hook Relay could be used for development and testing work. Then we added the ability to send a web hook delivery to multiple target URLs. We love our customers and their feature requests. :)

That's not all, of course... Hook Relay can do other fun things, too, like transform the JSON payload that it receives into another shape before it gets sent on to the destination URL using JMESPath syntax. We'll keep adding things as we go, but the core value proposition will continue to be this: helping developers build awesome web hook features into their apps, whether they are sending or receiving them, without having to worry about background jobs, misbehaving servers, and all the other random bits involved with web hooks.

We hope you'll check out Hook Relay and let us know what you think!