Apidog Audit Logs record supported security-related activity at the organization level. Organization Owners and Admins can use them to identify who performed an action, when it occurred, the source IP address, and the affected organization resource.
This tutorial covers filtering, investigation, CSV export, and API-based collection. These records are administrative audit logs; they are not production API request or gateway access logs.
Before you start
- Audit Logs are available on the Enterprise SaaS plan.
- They are not currently available in Apidog On-Premises.
- Only Organization Owners and Organization Admins can view, export, or query them.
- Audit log data is retained for 180 days.
If your investigation may extend beyond 180 days, export or collect the required records before they expire.
Step 1: Open Audit Logs
Open your Apidog organization and go to Audit Logs in the organization settings.
The table includes:
- actor
- event
- description
- IP address
- time
Audit Logs provide organization-level records for supported security and administration events.
Authentication events appear only when Apidog can reliably attribute them to the organization.
Step 2: Define the investigation window
Start with a specific question, such as:
- Who changed a member's organization role?
- When was an access token rotated or revoked?
- Which account changed the SSO configuration?
- Who changed a Docs Site or shared-document access setting?
- Was a user provisioned or removed through SCIM?
Use the narrowest practical time range. Available presets include the last 7, 30, 90, and 180 days. You can also select a custom range within the 180-day retention period.
Record the time zone used by your incident or audit process before comparing these events with identity-provider, ticketing, Git, or service logs.
Step 3: Apply filters
Filter the table by:
- Time range - when the event may have occurred.
- Event - the relevant action, such as a role change, sign-in failure, access-token change, or audit-log export.
- Actor - the user or integration that performed the action.
Combine time, event, and actor filters to isolate the records required for an investigation.
If you do not know the actor, begin with time and event. If the event name is uncertain, begin with the actor and a short time range.
Step 4: Review the event details
For each relevant row, capture:
- the event time
- the actor or integration
- the action and description
- the source IP address
- the affected member, team, setting, or resource
Then correlate the event with the source that can answer the next question:
| Question | Additional evidence |
|---|---|
| Was the action approved? | Change request, access review, or ticket |
| Was the sign-in expected? | Identity-provider sign-in and device logs |
| What API traffic followed? | Gateway, application, or API access logs |
| What content changed? | Resource history, specification diff, or Git history |
| Was a credential used? | Logs from the system that issued the credential |
An audit event shows that a supported action occurred. It does not by itself prove that the action was authorized, safe, or compliant.
Step 5: Export the filtered results to CSV
After the filters are correct:
- review the visible result set
- select the CSV export option
- store the file in the approved investigation or audit location
- record the export time, filter criteria, and person handling the file
CSV export uses the filters currently applied to the Audit Logs page and includes matching records within the 180-day retention period.
Exporting Audit Logs is itself recorded in Audit Logs. The downstream CSV is a separate copy, so protect it with appropriate access, retention, and integrity controls.
Step 6: Collect Audit Logs with the API
Enterprise organizations can query records programmatically through the Audit Logs API. The API supports time-window queries and cursor pagination within the 180-day retention period.
For a scheduled collection process:
- choose a collection interval shorter than the retention window
- query a defined start and end time
- follow cursor pagination until the result set is complete
- store the collection checkpoint
- retry failed windows without creating silent gaps
- protect the destination according to its sensitivity and retention policy
Each API query is recorded as a summary that can include the caller, IP address, query window, limit, result, and timestamp. The full returned payload is not copied into that event's metadata.
Validate the current API reference before implementing authentication, endpoint paths, request parameters, or response parsing. Do not copy an unverified code sample into a production collector.
Verify the investigation record
Before closing an investigation, confirm that you have:
- saved the exact time range and filters used
- captured all relevant pages of results
- preserved the original CSV or API response in an approved location
- correlated important actions with identity, change-management, and runtime evidence
- documented any gaps caused by retention, attribution, or unsupported event types
For access changes, also verify the current state. A log can show that a role changed, but the member page shows which role is assigned now.
Sensitive-data handling
Apidog applies the same redaction policy to the Audit Logs page, CSV exports, and API responses. Audit records do not expose token values, passwords, secret values, raw SAML assertions, reset tokens, private keys, or exported file content.
Metadata can still be sensitive. Restrict access to exported records and avoid placing them in public tickets or shared documents.
Troubleshooting
| Problem | What to check |
|---|---|
| The Audit Logs page is unavailable | Confirm the organization uses Enterprise SaaS and the viewer is an Organization Owner or Admin. |
| An expected authentication event is missing | Authentication events appear only when Apidog can reliably attribute them to the organization. Check the identity provider as well. |
| The CSV contains fewer records than expected | Review the active time, event, and actor filters. Export uses the current filters. |
| An API collector skips records | Check the query window, cursor handling, retries, and the 180-day limit. |
| Runtime API calls are missing | Use gateway, application, or API access logs. Apidog Audit Logs are administrative organization logs. |
Important limitations
Audit Logs do not provide production request logs, Resource History, rollback, or full field-level recovery. Native SIEM connectors, Syslog, generic webhook forwarding, and real-time streaming are not currently supported. Scheduled API collection is the documented option for sending records to an external monitoring or audit pipeline.
Related API governance tutorials:
These tutorials cover complementary controls for governing an enterprise API workspace:
- API Governance Framework — connect ownership, controls, evidence, and lifecycle decisions.
- SAML Group Mapping with Microsoft Entra ID — assign team access from identity-provider groups.
- Secret Scanner — review possible exposed credentials in supported Apidog assets.
- Audit Logs — investigate and export administrative organization activity.
- SCIM Provisioning — manage organization users through the identity lifecycle.
- Enterprise Policies — configure credential, membership, SSO-session, and invitation controls.
- Self-Service API Teams — allow member-created teams while retaining ownership oversight.
- GitHub Enterprise Cloud Integration — connect supported GHE.com repositories for OpenAPI workflows.
Related official documentation:
