---
title: "Add Webhook Authentication Methods"
slug: "add-webhook-authentication-methods"
updated: 2024-03-18T14:58:01Z
published: 2024-03-18T14:58:01Z
canonical: "help.bringg.com/add-webhook-authentication-methods"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://help.bringg.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Add Webhook Authentication Methods

To ensure that your other systems recognize and accept webhooks from Bringg, you may need to authenticate them. To do this, add authentication methods in Bringg, then select the relevant authentication method when registering for individual webhooks.

Bringg supports the following authentication methods:

| Method | Description |
| --- | --- |
| JSON Web Token (JWT) | This method consists of three parts: a header, a payload, and a signature. The header contains information about the type of token and the algorithm used for the signature. The payload contains the claims or information about the user or entity being authenticated. The signature is created by hashing the header and payload with a secret key to ensure the integrity of the token. |
| OAuth 2.0 | OAuth 2.0 provides multiple layers of security, requiring Bringg to access a token to include in your webhooks. To use OAuth 2.0, create an app in the receiving system to generate a Client ID and a Client secret for Bringg to use when requesting an authentication token. You can determine if OAuth 2.0 data is included in webhooks as a form, JSON, or query strings. |
| Static Headers | Include an authorization token or API key in the header of the HTTP request. |

You can also read this article in our [developer docs](https://developers.bringg.com/docs/webhook-authentication-methods).

## Before You Begin

- Confirm you have the Admin user type in ​Bringg.
- Determine the requirements of the systems that will receive webhooks from Bringg.
  - Check which authentication method they require.
  - List the specific fields that they require. For example, do scopes (access levels) need to be defined? You can find a list of possible fields for [OAuth 2.0](/v1/docs/add-webhook-authentication-methods#oauth-20) and [JWT](/v1/docs/add-webhook-authentication-methods#jwt) below.
  - Generate and copy API keys.

## Configure JWT or OAuth 2.0

**Step 1** In Bringg, select your username from the sidebar, then select **​Settings > Platform Integrations > Authentication Methods**.

![](https://cdn.document360.io/a18074ef-073a-4ab1-bcab-12625715280e/Images/Documentation/su-integration_authentication_access_2(1).jpg)

**Step 2** Select **Add Authentication Method**.

**Step 3** Under **Use for** select **Webhooks**.

**Step 4** Enter a **Display name** for the authentication method that you and other members of your team will recognize. For example, you can enter the authentication type.

**Step 5** Select the relevant authentication type ( **JWT** or **OAuth 2.0**).

**Step 6** Enter the relevant details for the selected method:

#### OAuth 2.0

![](https://cdn.document360.io/a18074ef-073a-4ab1-bcab-12625715280e/Images/Documentation/image(44).png)

| Field | Description |
| --- | --- |
| **Client ID** | This is the public identifier for your OAuth app and does not change, even when you regenerate the key. You can think of this as the app username. |
| **Client secret** | This is the key that Bringg uses to request an authentication token. You can think of this as the app password. |
| **Authorization URL** | This is where Bringg sends the token request, including your Client ID and Client secret key. |
| **Path** | (Optional) A URL path includes a forward slash `/` and content following it. For example, in the URL for this article, the path is `/docs/webhook-authentication-methods-copy`. |
| **Request type** | This determines how Bringg includes your OAuth data in webhooks: - Form: included as form data in the body of the webhook HTTP request. The header `Content-Type: application/x-www-form-urlencoded)` instructs your listening system to parse the included form. - JSON: included in the body of the HTTP request using JSON formatting. - Query strings (qs): included in the HTTP request URL. This is generally considered less secure than the other options. |
| **Scope** | (Optional) Scopes determine which data in the receiving system Bringg's webhooks can change. The structure of scopes varies and depends on the structure of your listening system, but they are typically formatted as `access level: resource`. For example, `read:orders`. Select **None** to send an empty set of scopes, or select **Enter your own** to add the required scopes for this webhook. |
| **Resource** | (Optional) This is the resource that the authentication method is requesting access to. |
| **Headers** | (Optional) Add static headers to be included in all webhooks using this authentication method. Static heads are made up of key-value pairs. |

#### JWT

![](https://cdn.document360.io/a18074ef-073a-4ab1-bcab-12625715280e/Images/Documentation/su-integration_authentication_jtwt(3).jpg)

| Field | Description |
| --- | --- |
| **Signature key** | This is the key provided by your receiving system and appears below the webhook payload as part of the signature object. |
| **Token expiration** | This indicates how long the token can be used before it expires, in minutes. |
| **Issuer (iss)** | This is the identity of the entity sending the webhook (Bringg). |
| **Algorithm** | This is the algorithm used to encrypt the signature key. |
| **Audience (aud)** | This specifies the audience for your webhook. This is one way that your systems filter the payloads they receive. |
| **Subject (sub)** | This is a unique identifier that is recognized by the recipient system. This could be an email or a tag like `bringg-event`. |
| **Encoding** | (Optional) When `base64` encoding is enabled, the header and payload are converted into ASCII string format, making it possible to send where text-based communication is required or preferred. |
| **Not before (nbf)** | (Optional) This determines when the token becomes valid. It cannot be used "before" the specified time. This should be formatted in Unix epoch time. |
| **Token Type** | This lets your listening system know the structure and format of the access token. |

**Step 7** Select Save to finalize your authentication method.

## Configure Static Headers

You can configure static headers when [subscribing to individual webhooks](/v1/docs/send-webhooks).

## Edit or Delete Authentication Methods

**Step 1** To update or remove an authentication method, open Bringg and navigate to **Settings > Platform Integrations > Authentication Methods**.

**Step 2** Select the action menu next to the relevant method, then select **Edit** or **Delete.**

> [!WARNING]
> Caution
> 
> Depending on the configuration of your external systems, editing or deleting an authentication method can cause your webhooks to fail. Be sure to test your webhooks after making changes.

## Subscribe to Webhooks

Once you create authentication methods, you can select the appropriate one for each webhook. [Learn more about subscribing to webhooks.](/v1/docs/send-webhooks)

Use Bringg webhooks to notify other enterprise systems in real-time as soon as a predefined event occurs, like updating your order management systems (OMS) that an order arrived at its destination.

You can have multiple systems listen to the same webhook rather than each making an independent data request. The webhook sends data in its payload to designated URLs.![download (1)](https://cdn.document360.io/a18074ef-073a-4ab1-bcab-12625715280e/Images/Documentation/download%20(1).png)

Webhooks send data to other systems when an event occurred Webhooks send data to other systems when an event occurred

Webhooks notify systems that an event occurred, whereas APIs initiate a specific request for another system to act.

Any applications subscribed to a single webhook receive the payload at the same time, but its content may vary depending on the parameters which each system requires.

For example, if you register a webhook URL in your OMS and ERP for the event Order Is Cancelled, the OMS receives one payload belonging to Order Is Cancelled to update the status of this order. At the same time, the ERP receives a slightly different payload with details to update the inventory.

You can register webhook URLs for automatic updates of events throughout the order lifecycle including when it is assigned to a driver, when a driver delivers the goods or services, and so on. Learn more