Introducing webhook workflows

In the past few weeks, I’ve had the chance to work on what is potentially the proudest feature I’ve ever contributed to on a product.

We — Sam and I — have released workflows on Octohook for free for everyone! 🔥

Let’s step back a bit.

Octohook is a web application we’ve built to bring visibility to your webhooks. Concretely, we give you a webhook URL that you can use to receive webhooks and then you tell us where you want us to redirect them — typically back to your application.

Why? Because now you have a dedicated place to browse, search and debug any webhook that reached your application. You may even explore what webhooks your providers send before forwarding them to your application so you don’t have to build your integrations in the dark.

Until now you could only forward the exact same webhook received.

Now, with workflows, you can customise just about everything in an intuitive and playful way. That means you can now:

• Parse the webhook data into a direct API endpoint of your application.
• Connect two applications together similar to how you would in Zapier but with much more flexibility.
• Ensure a webhook is forwarded if and only if the incoming data is valid by your own standards.
• Customise how webhooks are displayed in Octohook to improve search-ability.

Now, I could talk about this feature for hours so I’m going to stop the article here and show you a quick demo explaining how you can connect two APIs together using Octohook’s workflows.

More concretely, I register a Sentry webhook and make it create a new GitHub issue every time a new error is discovered.

Alrighty, I hope you enjoyed it and please don’t hesitate to give lots of feedback because we want this feature to keep becoming better and better.

And let’s not forget, it’s freaking free so you’ve got no excuses not to build something awesome!

Ahoy! 🐙