How to access Enterprise Audit logs

The Reports page of the admin panel offers a variety of tools that can output various information about share links, workspaces, bases, users, user activity, and more. In this article, we'll dig into the Audit log section of the Reports page.

Overview

As an admin, at times you may need to perform an audit of which users have had access or have made changes to certain workspaces or bases. This section outlines the general process of requesting, retrieving, and interpreting audit logs in Airtable. This includes, but is not limited to, activity such as:

Workspaces

• Upgrading / deleting workspaces
• Adding / removing collaborators

Bases

• Creating / deleting / moving bases
• Creating / deleting / modifying tables / views / columns
• Creating / deleting / modifying records
• Adding / removing collaborators
• Creating / deleting / modifying share links
• Exporting data as CSV
• Uploading / downloading attachments
• Creating / deleting / updating automations
• Commenting

Audit logs are retrieved via a processing workflow. An Airtable admin first requests an audit log given a set of parameters (time period and optional filter). When the audit log request is completed, an email will be sent to the requesting user containing links to the audit log data.

Read on for more information about requesting, retrieving, and interpreting Airtable Enterprise audit logs.

Requesting Audit Logs

There are two ways to request an audit log: API or through the UI. The API documentation specifically related to audit logs can be found at: https://www.airtable.com/api/enterprise#auditLog

To request audit logs from the UI, go to the Reports page of the Admin Panel. The Audit log section will be just below the Share link report section.

You will see the form where you can request an audit log by year, month, and day. If you check the filter box, then you can filter by user, workspace, base, and table IDs, or IPv4 address. You can find more information on how to identify the various IDs from the UI in this support article. Alternatively, admins can use the Users, Workspaces, and Bases pages in the admin panel to surface various IDs.

After you request an audit log, the page will show that the request is being processed and a timestamp of the last request will be shown.

Retrieving Audit Logs

Whether it was requested through the API or Admin Panel, once an audit log request finishes processing, the audit logs will be available to download for further processing by the user. You can expect a 5-15 minute timeframe for processing to finish in most cases. However, processing time may take up to 30 minutes depending upon the amount of data being retrieved for the report.

From the Reports page in the Admin Panel, an administrator can download a CSV file that contains the list of audit log file URLs. This same list of files is also accessible through the Enterprise API. For security purposes, the files are accessible for only seven days after processing is done. We will also email the audit log requester with a link to the reports page after the request has been finished.

The files containing the audit log data are gzip compressed. There are many ways to decompress these files, including utilities built into most operating systems and add-ons, visit this page for more information. Once decompressed, each file will contain one or more lines of JSON objects. Each JSON object is a single audit log entry.

Interpreting Audit Logs

The audit log files are newline-delimited JSON. Here is an example JSON:

{
  "enterprise_account_id": "entxdxhQtloBk0ZEn",
  "originating_user_id": "usrOQJHq9v4h8wfhQ",
  "api_name": "PRIVATE_API",
  "api_version": "0.3",
  "action_id": "actXs6ZWKZ4ScX3NN",
  "client": {
    "ipaddress": "xx.xxx.xxx.xxx"
 },
  "context": {
    "workspaceid": "wspRhexYIRR73ZCgH",
    "applicationid": null,
    "tableid": null
 },
  "request": {
    "requestid": "reqZgB8ylMPeBHAfA",
    "starttime": "2020-06-10T19:52:06.501Z",
    "modelclassname": "application",
    "modelid": "app2nHVnSAkEVkVaw",
    "action": "read",
    "parametersjson": "{...}"
 },
  "response": {
    "success": true,
    "message": null
 }
}

JSON Attributes

• enterprise_account_id - The enterprise account ID that the action was done under.
• originating_user_id - The user that made the action.
• api_name - Whether the action was a Web API action (Web_API) or done in our UI / apps (PRIVATE_API).
• api_version - The version of the API.
• action_id - An internal action ID. This is useful to include when sending bug reports to Airtable.
• client.ipaddress - The IP address of the client making the request.
• context.workspaceid - The workspace ID the action was made under, if applicable.
• context.applicationid - The base ID the action was made under, if applicable.
• context.tableid - The table ID the action was made under, if applicable.
• request.requestid - The internal request ID. This is useful to include when sending bug reports to Airtable.
• request.starttime - The time of the action.
• request.modelclassname - The model that was being acted upon. Expected values: workspace, application, table, view, column, row.
• request.modelid - The model ID that was being acted upon.
• request.action - The action name.
• request.parametersjson - The request parameter values included in the action. The shape and contents of this object will vary depending on the action name.
• response.success - Boolean response that indicates whether the action succeeded or not.
• response.message - An error message is included if the response was not successful.