How to Receive Webhooks With Svix Bridge

In order to consume webhooks, you typically have to stand up an HTTP server to receive the incoming POST requests, then do some sort of verification to make sure the request is legitimate.

After all that, you might reshape the payload and forward it somewhere to persist it or trigger some other event.

An earlier post covered sending webhooks with Bridge. Today, we'll focus on how Bridge can help with receiving webhooks.

Consuming Webhooks With Bridge

Bridge can act as an HTTP server, and with a little configuration, you can consume webhooks by configuring routes to act as endpoints with automatic signature verification (assuming you are receiving a webhook from Svix).

Using Bridge to receive webhooks builds on the same "input, transformation, output" pattern used for sending webhooks.

This is to say, each route you define in Bridge's HTTP server can be optionally mapped through a JS transformation, then forwarded on to one of the supported message queue outputs.

Using RabbitMQ as an example, here's how a receiver could be configured:

receivers:
  - name: 'events-from-acme'
    input:
      type: 'svix-webhook'
      path_id: 'acme'
      endpoint_secret: '${ENDPOINT_SECRET}'

    transformation: |
      function handler(input) {
        let event_type = input.eventType;
        delete input.eventType;
        // The `payload` field is what will be published to the queue.
        return { payload: { event_type, ...input } };
      }

    output:
      type: 'rabbitmq'
      uri: '${RABBITMQ_URI}'
      exchange: ''
      routing_key: 'acme'

When we configure the input with the svix-webhook type, we can set the endpoint_secret field to the value found in the Svix App Portal when adding an endpoint.

With this, Bridge will verify each request's signature and reject those that fail. Requests that are accepted will be forwarded to the configured queue output.

The path_id defined here represents the trailing path segment for the route this receiver will match. The route for this example would be /webhook/acme, and sending a POST request here with a valid JSON body will result in a new message published to the acme queue.

This is to say that, if you're running Bridge at https://my-bridge.example.com, the full URL you'd register as a Svix Endpoint would be https://my-bridge.example.com/webhook/acme.

Today, Bridge supports a short list of queue backends:

• GCP Pub/Sub
• RabbitMQ
• Redis
• SQS

Our new library, Omniqueue, was developed in tandem. Once adopted in Bridge, we'll be able to add support for more backends by expanding capabilities on the omniqueue side. Omniqueue should make it easier than ever to provide access to more queue backends.

For more on Omniqueue, check out Omniqueue: A Queue Abstraction Layer for Rust.

Wrapping Up

Bridge can be a low-code option to conveniently start consuming webhooks from Svix. If you want to conveniently consume Svix webhooks and publish them to a message queue, give Bridge a try!

• Grab the Docker Image from Docker Hub, or build Bridge yourself from the source.

• Check out the repo for details on how to build, configure, and otherwise get up and running.

For more content like this, make sure to follow us on Twitter, GitHub, or RSS for the latest updates for the Svix webhook service, or join the discussion on our community Slack.

Also published here