Verifying Incoming Webhook Requests
To prevent malicious actors from impersonating ShopSurvey and sending unauthenticated requests to your Webhook URL, we sign each Webhook request we send using HMAC cryptographic verification.
Verifying Webhook Request Headers Using HMAC Cryptographic Verification
To verify the authenticity of Webhook Requests, we suggest verifying the incoming X-SHOPSURVEY-WEBHOOK-HMAC-TOKEN
on each incoming request. To do this, follow these steps:
On each incoming request, retrieve the values of the following headers:
X-SHOPSURVEY-WEBHOOK-TOPIC
X-SHOPSURVEY-WEBHOOK-SENT-AT
X-SHOPSURVEY-WEBHOOK-REQUEST-ID
X-SHOPSURVEY-WEBHOOK-ATTEMPT
X-SHOPSURVEY-WEBHOOK-MESSAGE-ID
X-SHOPSURVEY-WEBHOOK-ID
X-SHOPSURVEY-WEBHOOK-HMAC-ALGORITHM
X-SHOPSURVEY-WEBHOOK-HMAC
Load these headers into a dictionary except for
X-SHOPSURVEY-WEBHOOK-HMAC
Sort the dictionary by key into ascending alphabetical order and transform it into a JSON string representing the HMAC payload
Use this generated payload, your unique Webhook HMAC Secret (found under Webhook settings), and the provided
X-SHOPSURVEY-WEBHOOK-HMAC-ALGORITHM
(SHA256) to calculate the HMAC hexdigestCompare the calculated HMAC with the value in
X-SHOPSURVEY-WEBHOOK-HMAC
, if these values are the same, you can process the webhook request.
Here's an example of performing this logic in Ruby on Rails:
Webhook Requirements
Your webhook endpoint must return a 200 OK Response within a 5-second timeout, or we will cancel the request and retry up to 2 more times (3 attempts total) to send the same Webhook message.
We highly recommend your endpoint verify the authenticity of the request and then internally enqueue the webhook message to be processed in a background worker (something like Sidekiq or Celery). This ensures that you aren't exceeding the timeout limit or missing webhook events. It also allows you to replay them internally if your processing logic contains a bug or raises an exception while running.
Last updated