Send audit log activities to another tool using webhooks
Establish a real-time streaming solution to automatically send audit log data to designated URLs of your choice.
Audit log webhook is a customized HTTP callbacks that trigger in response to audit log activities. When an activity occurs, the source system sends an HTTP request to the URL registered for the webhook in JSON format.
It’s important to know that webhook can be hosted or provided by any third-party tool. You should make sure that it’s appropriate for this data to be shared with your third-party tool before adding a webhhook.
Who can do this? |
How webhook works
Here is an example of how a webhook works:
Identify and choose a third-party service or application that will process incoming webhook notifications (e.g., a logging tool or a custom API endpoint).
Retrieve the URL from the selected tool which will receive audit log data.
Navigate to webhook settings and register a new webhook by providing the URL obtained from the tool and an optional authorization header.
When an action occurs within the Atlassian organization it triggers an associated audit log event.
The newly generated log is sent to the registered URL. This transmission occurs asynchronously. Explore the structure and appearance of the payload
Add a webhook
You can't ads upto 3 webhooks for an organization.
To register a webhook URL:
Go to Atlassian Administration. Select your organization if you have more than one.
Select Security > Audit log.
Select Settings.
Select the Webhook tab.
Select Add webhook.
Enter a Name for the webhook.
Enter the Webhook URL (the destination where you wish to receive real-time activity updates).
Optionally enter secure authorization credentials to authenticate access to a protected resource. Encode the username and password as Authorization: Basic <credentials>.
Select Add.
You can edit or remove a webhook if you need to.
Limitations
Webhook has the following limitations:
Retries: events will be retried up to three times before failing to send to the registered URL.
Ordering: event delivery is not guaranteed to be in chronological order. For example, Event B may be delivered before Event A, even if Event A occurred first.
De-duplication: events may be delivered more than once. Each event will have the same information and ID. You must implement their own de-duplication logic.
Service Level Objectives (SLOs): there are no public SLOs. No guarantees are provided regarding uptime or the delivery time of audit log.
Edit a webhook
To edit the details of a registered webhook:
Go to Atlassian Administration. Select your organization if you have more than one.
Select Security > Audit log.
Select Settings.
Under the desired webhook select More actions menu (⋯) .
Select Edit from the dropdown.
Update the details and select Save.
Alternatively, select Remove registration to remove a webhook.
Test a webhook
This test evaluates your webhook's capacity to manage aggregated activities, which are sent with a brief delay to prevent the transmission of redundant updates.
Go to Atlassian Administration. Select your organization if you have more than one.
Select Security > Audit log.
Under the desired webhook select Actions select (…) and select Test from the dropdown.
Was this helpful?