Webhooks provide a lightweight, event driven method of notifying external systems of events within the MindBridge platform, enabling internal events to communicate data with external systems via HTTPS requests originating from our platform, allowing for a more robust automation potential, without the need to poll for status. In order to leverage webhook functionality, a URL must be provided, and a selection of events that you would like to receive notifications for associated with that URL.
. in them)..local, .azure.com, microsoft.net, mindbridge.ai, mindbridge.com are not allowed (this list is subject to change, as additional
restrictions may be introduced in the future).Each outbound request is sent as an HTTPS POST. The post will contain a JSON payload in the body of the message. As well as the JSON payload, there are a number of important HTTPS headers that are attached to each message. Using this information, combined with the public key associated with the configured webhook, allows the verification of a digital signature. The method of authenticating the payload will be covered in a separate section.
| HTTPS Header | Description |
|---|---|
webhook-id | A unique event ID for the event that triggered the outbound webhook request. |
webhook-timestamp | Timestamp associated with the outbound HTTPS request. |
webhook-signature | The digital signature that can be used to validate the authenticity of the webhook data. |
Webhooks operate by communicating with user provided HTTPS URLs. This can lead to potential security risks from malicious actors. In order to provide a way to
authenticate the validity of the webhook on the client side, we have implemented an asymmetric digital signature scheme that can be used to check that the
payload is from us, and has not been modified. When a webhook is registered within our system, clients are provided with a public key, which utilizes the
Ed25519algorithm. There are a number of measures used to avoid common attack scenarios within the digital signing scheme, which will be covered below.
In order to listen to webhook events, you must have a publicly accessible server that can accept HTTPS POST requests from the MindBridge system. This server must not implement any authentication protocols in order to receive data. The data signature scheme implemented provides a mechanism to ensure data integrity, and while this is optional to authenticate the received payload, it is highly recommended to utilize this data integrity check in your workflow.
How you respond to a webhook event has implications on the status of the webhook configured within the MindBridge system. We look at the HTTP response code, and in some cases the HTTP headers in order to determine actions we may take within our system.
| HTTP Code | Result |
|---|---|
| 200 series response | Successfully received webhook payload |
Utilizing the data from the payload, as well as the headers in the HTTP post, as well as the public key associated with your webhook configuration, you will be able to validate the digital signature that is attached in the HTTP header. In order to accomplish this, you need to format a string with the following format:
<webhook-id>.<webhook-timestamp>.<payload>
Values with < > surrounding them are variables to insert into the template above.
| Variable | Description |
|---|---|
| webhook-id | Found in the HTTP header |
| webhook-timestamp | Found in the HTTP header |
| payload | The unmodified contents of the HTTP POST request |
With this string generated, and using the public key from the webhook configuration, and the algorithm Ed25519, you can create a digital signature of the
formatted string created above, and compare it against the digital signature provided in the HTTP header, under the key webhook-signature. The creation of
this formatted payload helps to mitigate common attack patterns, such as replay attacks, which is why the timestamp of the outbound request is part of the
signed message.
| Name | Description | Event Type | Payload Model |
|---|---|---|---|
| Analysis Created | Notify the registered webhook URL that an Analysis has been created. | analysis.created | AnalysisWebhookPayload |
| Analysis Updated | Notify the registered webhook URL that an Analysis has been updated. | analysis.updated | AnalysisWebhookPayload |
| Analysis Deleted | Notify the registered webhook URL that an Analysis has been deleted. | analysis.deleted | AnalysisWebhookPayload |
| Analysis Archived | Notify the registered webhook URL that an Analysis has been archived. | analysis.archived | AnalysisWebhookPayload |
| Analysis Unarchived | Notify the registered webhook URL that an Analysis has been unarchived. | analysis.unarchived | AnalysisWebhookPayload |
| Analysis Complete | Notify the registered webhook URL that an analysis has been completed. | analysis.complete | AnalysisWebhookPayload |
| Analysis Failed | Notify the registered webhook URL that the Analysis has failed. | analysis.failed | AnalysisWebhookPayload |
| Engagement Created | Notify the registered webhook URL that an Engagement has been created. | engagement.created | EngagementWebhookPayload |
| Engagement Updated | Notify the registered webhook URL that an Engagement has been updated. | engagement.updated | EngagementWebhookPayload |
| Engagement Deleted | Notify the registered webhook URL that an Engagement has been deleted. | engagement.deleted | EngagementWebhookPayload |
| Unmapped Accounts | Notify the registered webhook URL that an engagement has unresolved account mappings that exist, which is the result of new accounts discovered during a data ingestion workflow. | unmapped.accounts | EngagementWebhookPayload |
| Ingestion Complete | Notify the registered webhook URL that a data ingestion workflow has been completed. | ingestion.complete | AnalysisSourceWebhookPayload |
| Ingestion Failed | Notify the registered webhook URL that a data ingestion workflow has been completed. | ingestion.failed | AnalysisSourceWebhookPayload |
| Data Added | Notify the registered webhook URL that new data has been added to an engagement. | data.added | FileManagerWebhookPayload |
| Export Ready | Notify the registered webhook URL that a requested file export has been completed. | export.ready | FileManagerWebhookPayload |
| User Invited | Notify the registered webhook URL that a User has been invited to the tenant. | user.invited | UserRoleWebhookPayload |
| User Role Updated | Notify the registered webhook URL that a User’s role has been updated. | user.role | UserRoleWebhookPayload |
| User Deleted | Notify the registered webhook URL that a User has been deleted. | user.deleted | UserWebhookPayload |
| User Login | Notify the registered webhook URL that a User has logged in. | user.login | UserLoginWebhookPayload |
| User Status Updated | Notify the registered webhook URL that a User has been enabled or disabled. | user.status | UserStatusWebhookPayload |
Bearer authentication header of the form Bearer <token>, where <token> is your auth token.
A unique event ID for the event that triggered the outbound webhook request.
Timestamp associated with the outbound HTTPS request.
The digital signature that can be used to validate the authenticity of the webhook data.
The event type that triggered the webhook.
analysis.completed, analysis.failed The ID of the event that triggered the outbound request.
The time that the webhook was triggered.
The ID of the registered webhook configuration that initiated the outbound request.
The name of the tenant that triggered the webhook.
The ID of the user that initiated the event that triggered the webhook.
The data associated with the webhook event.