Receive Webhooks with Ruby

In this guide we'll explain how to receive webhooks using Ruby and validate their signatures.


Tip: You can use the Svix Play webhook debugger to inspect, test and debug your webhooks during development.


If you are interested in a tool to manage receiving third-party webhooks, please contact us for more information.

Receiving Webhooks 101

Webhooks are how services notify each other of events. At their core they are just a POST request to a pre-determined endpoint. You normally use one endpoint per service, and that endpoint listens to all event types. For example, if you receive webhooks from Acme Inc., you can structure your URL like this:

https://www.example.com/acme/webhooks/.

The way to indicate that a webhook has been processed is by returning a 2xx (status code 200-299) response to the webhook message within a reasonable time-frame (e.g. 15s with Svix).

Another important aspect of handling webhooks is to verify the signature and timestamp when processing them.

Verifying Webhook Signatures

Because of the way webhooks work, attackers can impersonate services by simply sending a fake webhook to an endpoint. Think about it: it's just an HTTP POST from an unknown source. This is a potential security hole for many applications, or at the very least, a source of problems.

In order to prevent it, Svix signs every webhook and its metadata with a unique key for each endpoint. This signature can then be used to verify the webhook does indeed come from Svix, and only gets processed if it is.

Another potential security hole are replay attacks. A replay attack is when an attacker intercepts a valid payload (including the signature), and re-transmits it to your endpoint. This payload will pass signature validation, and will therefore be acted upon.

To mitigate this attack, Svix includes a timestamp for when the webhook attempt occurred. Our libraries automatically reject webhooks with a timestamp that are more than five minutes away (past or future) from the current time. This requires your server's clock to be synchronised and accurate, and it's recommended that you use NTP to achieve this.

For additional information about webhook vulnerabilities, please refer to the webhook security section of our docs.

Verifying Webhook Signatures with Svix

You can use Svix using the Ruby library as shown in the examples below, or alternatively verify signatures manually if you prefer.

In addition to Ruby we also have guides for: Python, JavaScript, TypeScript, Go, Java, Kotlin, Rust, C#, PHP, and Svix CLI.

Install the Dependencies

First install the library if you haven't already:

gem install svix

Then verify webhooks using the code below. The payload is the raw (string) body of the request, and the headers are the headers passed in the request.


Important: use the raw request body

You need to use the raw request body when verifying webhooks, as the cryptographic signature is sensitive to even the slightest changes. You should watch out for frameworks that parse the request as JSON and then strigify it because this too will break the signature verification.

See examples below for how to get the raw request body with different frameworks.


The signature you should get from where you added the endpoint, e.g. the application portal.

require 'svix'


# These were all sent from the server
headers = {
  "svix-id" => "msg_p5jXN8AQM9LWM0D4loKWxJek",
  "svix-timestamp" => "1614265330",
  "svix-signature" => "v1,g0hM9SsE+OTPJTGt/tmIKtSyZlE3uFJELVlNIOLJ1OE="
}
payload = '{"test": 2432232314}'

wh = Svix::Webhook.new("whsec_MfKQ9r8GKYqrTwjUPD8ILPZIo2LaLaSw")
# Raises on error, returns the verified content on success
json = wh.verify(payload, headers)

Verifying Signatures Manually

Each webhook call includes three headers that are used for verification:

  • Svix-Id: the unique identifier for the webhook message. This id is unique across all messages (except is a message is resent due to a previous failure).
  • Svix-Timestamp: timestamp in seconds since epoch.
  • Svix-Signature: the Base64 encoded list of signatures (space delimited).

Info: Business tier customers can have the headers white-labeled to use the Webhook- prefix instead of the Svix- prefix used above. The Svix libraries support both.


Constructing the Signed Content

The content to sign is composed by concatenating the id, timestamp and payload, separated by the full-stop character (.). In code, it will look something like:

signed_content = "${svix_id}.${svix_timestamp}.${body}";

Where body is the raw body of the request. The signature is sensitive to any changes, so even a small change in the body will cause the signature to be completely different. This means that you should not change the body in any way before verifying.

Determining the Expected Signature

Svix uses an HMAC with SHA-256 to sign its webhooks.

To calculate the expected signature, you should HMAC the signed_content from above using the base64 portion of your signing secret (this is the part after the whsec_ prefix) as the key. For example, given the secret whsec_MfKQ9r8GKYqrTwjUPD8ILPZIo2LaLaSw you will want to use MfKQ9r8GKYqrTwjUPD8ILPZIo2LaLaSw.

This generated signature should match one sent in the Svix-Signature header.

The Svix-Signature header is composed of a list of space delimited signatures and their corresponding version identifiers. The signature list is most commonly of length one. Though there could be any number of signatures. For example:

v1,g0hM9SsE+OTPJTGt/tmIKtSyZlE3uFJELVlNIOLJ1OE=
v1,bm9ldHUjKzFob2VudXRob2VodWUzMjRvdWVvdW9ldQo=
v2,MzJsNDk4MzI0K2VvdSMjMTEjQEBAQDEyMzMzMzEyMwo=

Make sure to remove the version prefix and delimiter (e.g. v1,) before verifying the signature.

Please note that to compare the signatures it's recommended to use a constant-time string comparison method in order to prevent timing attacks.

Verify Timestamp

As mentioned above, Svix also sends the timestamp of the attempt in the Svix-Timestamp header. You should compare this timestamp against your system timestamp and make sure it's within your tolerance in order to prevent timestamp attacks.

Further Reading

That's it! We covered everything you need to know in order to integrate Svix with your service. Though there are many more APIs that you can use to improve the experience of your users or your own development experience. Two such examples are event types and the Svix CLI. For the most up to date information please refer to the Svix docs.

If you have any questions, or you just want to chat, please join the Svix Slack community.

Related articles

You may also be interested in reading the following related guides: