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 covered . Today, we'll focus on how Bridge can help with . earlier post sending webhooks with Bridge receiving webhooks Consuming Webhooks With Bridge Bridge can act as an HTTP server, and with a little configuration, you can by configuring routes to act as with automatic signature verification (assuming you are receiving a webhook from Svix). consume webhooks endpoints Using Bridge to receive webhooks builds on the same pattern used for sending webhooks. "input, transformation, output" 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 type, we can set the field to the value found in the Svix App Portal when adding an endpoint. svix-webhook endpoint_secret With this, Bridge will each request's signature and reject those that fail. Requests that are accepted will be forwarded to the configured queue output. verify The defined here represents the trailing path segment for the route this receiver will match. The route for this example would be , and sending a request here with a valid JSON body will result in a new message published to the queue. path_id /webhook/acme POST acme This is to say that, if you're running Bridge at , the full URL you'd register as a Svix Endpoint would be . https://my-bridge.example.com 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, , 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. Omniqueue 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 from Docker Hub, or build Bridge yourself from the source. Docker Image Check out the for details on how to build, configure, and otherwise get up and running. repo For more content like this, make sure to follow us on , or for the latest updates for the , or join the discussion on . Twitter , GitHub RSS Svix webhook service our community Slack Also published here

Read My Stories

Too Long; Didn't Read

Making security fun one episode at a time

How to Receive Webhooks With Svix Bridge

Too Long; Didn't Read

Tom Hacohen

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

How to Receive Webhooks With Svix Bridge

Too Long; Didn't Read

Tom Hacohen

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES