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 article outlines the general process of requesting, retrieving, and interpreting audit logs in Airtable.
NOTEThis is an Enterprise-only feature. If you are interested in learning more about our Enterprise plan and the additional features that it offers, then visit this page.
Enterprise administrators are able to request and download audit logs of activity that take place in enterprise workspaces and bases. This includes, but is not limited to, activity such as:
- Upgrading / deleting workspaces
- Adding / removing collaborators
- 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
Audit logs are retrieved via a processing workflow. The user first requests an audit log given the 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. You can find sample code for calling the API and integrating with Splunk, Sumo Logic, and Azure Logging here.
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 on the Admin Panel.
You will see the form where you can request an audit log by year, month, and day. If you check the “Filter by model ID or IPv4 address” box, then you can filter by user, workspace, base, and table IDs, or IP address. You can find more information on how to determine the various IDs in this support article.
NOTEOur current retention policy is 180 days. If you attempt to choose a time period outside of this range then you will see an error message popup.
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 a half-hour 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.
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.
NOTEDepending upon the computer and software you have running, you may need to download a zip file program in order to unzip the audit log data that we generate.
Interpreting Audit Logs
The audit log files are newline-delimited JSON. Here is an example JSON:
- 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 public API action (PUBLIC_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.