Introducing Convoy
Tags: webhooks, go, opensource, showdev
Published: 2022-02-18 18:52:42

Hi dev.to, I’d like to show you Convoy. 

![Sample Instance UI](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/tppmoxz81dlbgyb0v7q7.png)

Convoy is an open-source webhooks service. **You can think of it as a swiss army knife for publishing webhook events.** Few months ago, I was building a Fintech API and I was looking around for a tool to push webhooks events. I wanted something simply, ease-to-use, language-agnostic, and cloud-native. Ideally, I wanted a container I could deploy, publish events to it, and it reliably publishes events to the endpoints. I couldn’t find a such a tool, so we built it. Convoy exposes a REST API to register endpoints, and publish events to respective endpoints.

### Webhook Issues

On the surface, webhooks isn't simply HTTP Push. There exist several naunces and some use-cases needed for some type of integrations. I'd like to talk about a few: 

<br />

- Bad Endpoints
    
    Publishing webhooks requires you to deal with several poorly designed endpoints, endpoints that respond with large payload sizes, endpoints that hang unending and eventually timeout, some other endpoints have expired certificates. A good webhook system will provide visibility into these issues for both publishers and consumers.
    
<br />

- Delivery Attempt Logs
    
    Building against webhooks can be non-trival for developers at times. Developers often times, use ngrok to pipe events to their local machine to debug several things; signing payload, parsing payload structure, responding with a 200 status code fast, monitoring successful retries, testing url per events. Building a great webhooks delivery system requires building a delivery attempt log showing what was sent vs. what was returned.

<br />
    
- Delayed Job Implementation.
    
    Because webhooks is inherently an asynchronous activity, It needs an underlying resilient job/task queuing system to account for scalability, retries for transient & non-transient failures of events. A standard webhooks delivery system is an implementation over a job queuing system (e.g. redis, kafka, rabbit, nats etc) to provide such features.  
    
<br />

- Security
    
    Publishing webhook events with HTTP requires consumers to secure their endpoints from malicious users. Consumers need to know who is posting and if they're authorized to post events. Several consumers have several layers of security: Signing payload with a shared secret (common), Static IPs (common in fintech), Mutual TLS (found in PagerDuty). Essentially, a good webhook delivery system needs to support all forms of security depending on what respective consumers require.
    
<br />

- URL per Events.
    
    In this age of no-code tools, and serverless functions. It is common for developers to receive webhook events from a provider (e.g. Stripe) and fan-out to several apps behind the scene to perform any desired action. Stripe, as an example provides first-class support for this where users can subscribe an endpoint to specific events, but isn't found in many other applications. A good webhook delivery system should provide first-class support for URL per events.

It is all this fragmented implementations of webhooks, we are trying to solve with [Convoy](https://github.com/frain-dev/convoy). 

### Getting Started
To get started you can head over to [https://getconvoy.io/docs/guide](https://getconvoy.io/docs/guide) and follow the step by step guide to running Convoy on your local machine. 

### Conclusion
We believe we're still very early in abstracting the fragmented implementations of webhooks into Convoy, but we're happy to share our progress so far and invite to you be a part of our community 

You can join our slack community [here](https://join.slack.com/t/convoy-community/shared_invite/zt-xiuuoj0m-yPp~ylfYMCV9s038QL0IUQ)

We can’t wait to hear your feedback!