Webhook Integration
Flare provides a generic webhook integration that allows you to receive alerts into any service that supports receiving data from an incoming webhook. Automation services such as Tines, Zapier and IFTTT are a few examples of such services.
You can click on the provided link to see a step-by-step guide on Webhook integration: https://app.storylane.io/share/e0cpqnjvecvv
The service you are sending alerts to will provide the URL that you need to configure the Flare Webhook with.
Click on "Create a New Alert Channel"
Select "Webhook" from the Dropdown Menu
Name the Alert Channel
In this example, this webhook is being created for use with https://tines.com, so we'll indicate that in the title.
Notice that when you click into the title field, the rest of the alert channel details will slide open. If they don't, simply click on "See details" to expand.
Enter the Webhook URL
After configuring the webhook collector on Tines.com you will be given a url that you need to enter here in the Webhook URL field. Paste in the URL and click the "Test" button. You should see the message "Test alert was sent successfully". If you recieve an error, double check the url.
Click "Save"
This step is only necessary if you have implemented a webhook collector endpoint on your own system and want the added security of validating the payload.
To add a new request signature secret, click the + button to the right of the field. This will add a new header to the request called X-Flare-Signature and it will contain a hash that can be used to validate the payload on your end.
To validate the payload, follow these steps:
- The string in the header is formatted as follows: t=<timestamp>,v1=<signature>.
- Extract the text from the header named X-Flare-Signature.
- Split the text on ,. You now have two parts.
- Split both parts on =. You now have the timestamp and the signature.
- Generate a HMAC hash:
- They key is the secret that you generated and copied from webhook alert channel.
- The data or msg will be a combination of the timestamp retrieved from the X-Flare-Signature above and the raw request body separated by a period as follows: <timestamp>.<raw_request_body>.
- The algo should be set as sha256.
IMPORTANT: To prevent replay timing attacks, it is important to compare the hashes using a constant-time-string comparison algorithm. For example, in Python you would use hmac.compare_digest(), in Php you would use hash_equals(). Use the appropriate comparison function you have available to you and compare the hash that you received within the X-Flare-Signature header and the one you generated from step 5.
Optional: Another step you can take is to limit the time window in which you will allow the processing of a request. With the timestamp received within the X-Flare-Signature, compute the difference between that timestamp and the current time. Then decide if it's within your tolerance.
Please note that there is no standard for building request signature strings. Therefore, it is unlikely that our request signature will work with other third party systems. Again, taking the example of Tines.com, their endpoint expects a different formatting of the msg/data string to be hashed and, therefore, their validation will fail with the signature that we provide. We provide this feature for those who can implement their own webhook endpoint and compute the signature as described above.