Bridge uses webhooks to provide other applications with real-time information. Webhooks are similar to APIs in that they send data from the app to a third party application. However, webhooks let you skip a step. With most APIs, there is a request for data followed by a response. With webhooks, data is automatically sent when there is new data to send. 

Currently, a webhook must be configured by a Bridge Support user. Email support@bridgeapp.com for help.

API Calls are useful when you need to extract a lot of data or when you need to extract data in an asynchronous way. If you can get data on  page-load, for example, or based on a specific event in your  application, you might use API calls to get that data. If you must sync  an initial set of data, you might need to use API calls and then  implement webhooks to receive updates on any changes after the initial  sync.

Webhooks are useful when you need to take real-time action on events that happen in  Bridge. They are much more efficient than making a lot of API calls, but they often wont have all the data you need.

• Name: This is only used for identifying the webhook. There are no  restrictions on what the name can be. We recommend giving it a name that  helps you remember what the webhook does and what tools or users are  using it.
• Destination URL: This is the location where Bridge will send the payload data. Payload  data is simply the requested information in a message. The destination  URL will need to have a way to receive the message and will need to be  correctly configured to process the JSON body that will be sent to it.
• Bearer Token: This is simple method for knowing that messages are coming from Bridge.  Each individual webhook can be configured with a secret token. This  secret token will be included in the header of the messages. As with  the webhooks name, there are no restrictions on what the secret token  can be.
• HMAC Secret: In  cases where the message needs to be authenticated, a shared secret key  can be provided. This key will be used to produce an HMAC, or message  signature, that will be used to verify the message was sent by Bridge  and has not been tampered with during delivery. This feature should be  used only if you are are already aware of HMAC.

Once the name,  destination, and tokens have been specified, you can begin configuring  your webhook. Configuration of the webhook includes choosing the  resources and events you would like to be sent to the Destination URL.  Resources are the objects where changes occur, such as users and  courses. Events are the type of changes that are made to those objects,  such as creation and deletion. You can select multiple resources  to be sent to one Destination URL. Additionally, multiple resources  events can also be sent to one Destination URL. For example, you can  request information about course creation, course updates, and live  training creation be sent to the same Destination URL. You can select as  many or as few events as you would like.

It is important to note that you must provide a secure endpoint to  ensure the security of your webhook messages. We also provide an  additional layer of security by giving you the option of providing a  bearer token to include in messages. You can also sign your webhook  messages with an HMAC token that can be used for verifying that the  message has come from Bridge.