In this article

• Introduction

• What are Webhook Gateways

• Why use a Webhook Gateway

• Architecture of Webhook Gateways

• API Gateways vs Webhook Gateways

• Conclusion

Introduction

Webhooks are known as reverse APIs; this is because they reverse the usual flow of communication. So, instead of the client requesting data from the server(APIs), the server sends data to the client when a specific event occurs(Webhooks).
Now that you know this, let us dive into today's agenda!

What are Webhook Gateways?

A webhook gateway is a webhook management tool that sits between a webhook provider and webhook consumer. It acts as a reverse and forward proxy for webhooks. It can be deployed by both the API provider that sends webhooks and the consumer that receives webhooks to handle webhook events multiplexing and de-multiplexing respectively.

Why use a Webhook Gateway?

Speed is a competitive advantage in today's ever-changing user requirements. Development teams are required to move fast and deliver user value. More teams are adopting a serverless, micro-service, and service-oriented architecture to move fast. Teams are leveraging technologies like an API Gateway to consolidate duplicate tasks like authentication, rate limiting, circuit breaking etc. while product teams focus on their core business. With webhooks, teams and tech leads would need to answer the following questions:

1. How can we provide a consistent infrastructure to receive events from third-party providers and route these events to one or more micro-services to handle them?
2. How can we provide a consistent infrastructure to collect events from multiple backend services and send them to client endpoints?
3. How can we consolidate duplicate webhook responsibilities like endpoint authentication and security, rate limiting, and endpoint failure notifications?
4. Similar to API Gateways, how can we increase developer efficiency across the organisation, where webhooks become plug & play?
5. How can we provide an independent infrastructure to scale to handle webhooks traffic in peak periods? See Shopify BFCM Webhooks Stats.

Your challenge is offering developers in your organisation a simple and dependable experience in the face of any webhook complexity. A webhook gateway is a way to decouple all your microservices from your webhook implementations. When a microservice needs to send a webhook event, it should write to the broker, and the webhook gateway receives it and routes them to the right endpoint(s), whilst keeping track of everything.

Architecture of Webhook Gateways

The diagram above provides a high-level view of how a webhook gateway operates. We used AWS-specific elements but this can be any cloud environment - Azure, GCP, Digital Ocean, etc or even On-Prem. The arrows from the left show the flow of traffic from your backend services to client endpoints on the right, and the arrows from the right show the flow of traffic from third-party providers like (stripe, Twilio, etc.) to your backend services for processing.

Generally, to avoid vendor lock-in, a webhook gateway will (should) support multiple broker systems like Amazon SQS, Google PubSub, Kafka etc. to allow you to use the best broker for your scenario. Visit this page to learn about Convoy's internal architecture.

API Gateways vs. Webhook Gateways

Webhook gateways share similarities with API gateways such as Tyk and Kong

Conclusion

Convoy is the first ever open-source webhooks gateway to manage millions of webhooks end-to-end. If you’re exploring solutions for your webhooks, we welcome you to try out Convoy webhooks Gateway for free today.

Help me out!

If you feel like this article helped you understand Webhooks better! I would be super happy if you could give us a star! And let me also know in the comments ❤️
https://bit.ly/convoywebhooks

Thanks for reading!