Webhooks

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 https //www tines com/ , https //zapier com/ and https //ifttt com/ are a few examples of such services here's how to configure flare for webhooks for detailed instructions, follow the storylane demo provided below validating the request signature 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 basic auth this is optional since the request signature validation explained above is unfortunately non standardized, it you encounter any issue with your webhook integration you can use the more standardized basic auth as explained below you can also validate the webhook using the optional basic authentication configuration this will include a header of the format authorization basic agvsbg8= in the request the string after the basic keyword follows https //datatracker ietf org/doc/html/rfc7617#section 2 related articles