Configuring Webhooks

Permissions

Webhooks can be set up and configured by users with developer permissions on a per-deal basis. Users can see which the deals for which they have developer permissions on their Dashboard.

Please contact the DealMaker team to set up developer permissions for each of your deals.

Configuring Webhooks

To configure your webhooks, click on the dropdown menu in the top right corner and select "Integrations".

Here, you can configure DealMaker to send webhooks to a URL on your server. Below, we'll discuss the available controls here, and how they relate to configuring your server to receive webhook payloads from DealMaker.

 

 

Enable Webhooks

Toggle this switch to enable the delivery of webhooks to the provided Payload URL. In the event of recurring delivery failures, webhook delivery will be automatically disabled after 6 failed attempts.

Payload URL

HTTP POST requests will be sent to this URL from DealMaker. Ensure that your server is configured to receive webhook payloads at this URL. Ensure that your server is able to receive payloads at this URL, and respond with appropriate HTTP status codes.

Any HTTP status other than 200 OK returned from your server will be considered a delivery failure.

We strongly recommend using HTTPS endpoints on your server to avoid the security vulnerabilities associated with unencrypted web traffic. 

Secret

Setting a webhook secret allows you to ensure that POST requests sent to the payload URL are from DealMaker. When you set a secret, you'll receive the X-DealMaker-Signature header in the webhook POST request. You can generate a new secret, clear the secret, and copy the secret to your clipboard.

You can set up an environment variable for your server containing the secret, which you can use to verify the webhook payload in your server-side code:

See Payload Verification with DealMaker for more details on request verification using the secret. 

Leaving the Secret field blank will result in the X-DealMaker-Signature header not being included with webhook payloads sent to your server. We strongly recommend against leaving this field blank as other methods of verifying payload authenticity are considerably less reliable.

Alerts Email

This email will be used to deliver error notifications in case of a delivery failure. The field is populated with the signed in user's email by default, but any valid email address can be used.

Add Deals

Search and select deals to add them to the endpoint you are setting up. You may select from any of the deals on which you are a team member. Because you may create any number of endpoints, you may choose to direct different deals to different endpoints, in whichever combination suits your usage. Here you may remove deals from the endpoint as well.

Saving your Configuration

Once you are satisfied with your webhook configuration, click Save Changes to ensure it is applied. You can return to Integrations to change this configuration, or disable webhooks altogether, at any time.

Multiple Endpoints

It is now possible to set up multiple endpoints. This means you may divert different deals to different destinations, or direct all deals to one endpoint, or any combination thereof. 

Edit Endpoint

You may edit your endpoints at any time by clicking "edit endpoint" and editing the fields, then clicking "Save Changes to Endpoint"

 

Payload Verification with DealMaker

After setting up your server to accept payloads, it will await incoming data sent to your specified endpoint.

For enhanced security, ensure that your endpoint only accepts requests originating from DealMaker. DealMaker offers a unique secret for validating incoming information. To utilize this, implement a verification method. If the provided secret doesn't match, your method should return an HTTP error code.

Understanding the Process

  1. Hash Signature Creation: Once you define a secret token, DealMaker uses this to generate a hash signature for every payload.

  2. Signature Transmission: This hash signature is sent with every request, included in the headers under the name X-DealMaker-Signature.

  3. Server-side Verification: Your server's task is to calculate a hash using the secret token (stored as an environment variable named SECRET_TOKEN). It then confirms that this hash corresponds with the one received from DealMaker. Note: DealMaker employs an HMAC hex digest for hash calculation.

  4. Consistency Across Languages: While implementations might differ, the basic approach to verifying signatures remains largely consistent across various programming languages and frameworks.

  5. Signature Details: Every hash signature begins with sha1=, utilizing your secret token and the payload's content.

  6. Safe Comparisons: Avoid using a simple == operator for comparisons. Instead, opt for methods like secure_compare. This method conducts a "constant time" string comparison, making it resistant to specific timing attacks that affect standard equality checks.

Documentation

Please refer to our Developer Documentation for the latest guidelines on using Webhooks. You'll find detailed instructions on how to seamlessly integrate them with your portal and other platforms!