Skip to main content
The Audit Log API allows customers to query audit logs for their workspace. These APIs cover ways to query audit logs at a given time or from an ID and how to paginate through audit logs over time.
The current API request rate limits for Audit Log API endpoints are 60 requests per minute.

Overview

Use the Audit Log API to:
  • Track User Activity: Monitor all actions taken by users in your workspace
  • Maintain Compliance: Keep detailed records for audit and compliance purposes
  • Investigate Incidents: Retrieve historical logs to investigate specific events
  • Export Records: Fetch and store audit logs in your own systems

Endpoints

Search Audit Logs

Returns the audit log at or after a specified timestamp. Useful to begin pagination from a specific point in time. Parameters:
  • time (required): UTC epoch timestamp, up to 1 year old from now
  • log_type (optional): Filter to return only logs of a specific type (e.g., auth:login, admin:add_users)
Example:
Example with filtering by log type:

Get Earliest Audit Log

Returns the earliest audit log for the workspace. Useful to begin pagination from the very beginning. Parameters:
  • log_type (optional): Filter to return only logs of a specific type (e.g., auth:login, admin:add_users)
Example:
Example with filtering by log type:

Get Latest Audit Log

Returns the latest audit log for the workspace. Useful to begin pagination from the most recent event. Parameters:
  • log_type (optional): Filter to return only logs of a specific type (e.g., auth:login, admin:add_users)
Example:
Example with filtering by log type:

Query Audit Logs

Paginates forward in time from a given audit log ID. Use this endpoint to fetch multiple log entries at once. Parameters:
  • from (required): Audit log ID to begin fetching from (UUID format)
  • take (required): Number of audit log entries to fetch (max 1000)
  • log_type (optional): Filter to return only logs of a specific type (e.g., auth:login, admin:add_users)
Example:
Example with filtering by log type:

Audit Log Types

Each audit log entry includes a type field that identifies the specific action performed. Below is a complete list of audit log types you may encounter:

API Operations

Authentication

Admin Operations

User Operations

Microsoft add-ins

Microsoft Word and Outlook add-in activity is captured as user audit log events. You can filter for these events with the log_type query parameter, for example log_type=user:word_add_in_docx_drafting or log_type=user:outlook_add_in_ask.

Word add-in

Outlook add-in

System Operations

Shared Spaces

Shared Spaces and external connection audit logs capture collaboration activity: space membership, resource publishing, and external connection lifecycle. Events are scoped per workspace; each workspace sees audit events for actions its users perform or approve.

Space membership and lifecycle

Resource sharing in spaces

External connections


Use Cases

Use Case 1: Compliance Monitoring and Audit Trail Capture

Challenge: Organizations must maintain detailed records of all user activity for compliance and regulatory requirements. Solution: Regularly fetch and store audit logs using the pagination workflow. Each log entry includes the user, timestamp, IP address, and action type.

Use Case 2: Incident Response and User Investigations

Challenge: When investigating a security incident, teams need to reconstruct what happened during a specific time period. Solution: Use /search?time=<timestamp> to start from a specific point in time, then paginate through subsequent logs to track all activity during the incident window.

Use Case 3: Continuous Monitoring

Challenge: Security teams need to monitor recent activity in near real-time. Solution: Periodically poll /latest to get the most recent log entry, then use /audit?from=<last_seen_id>&take=100 to fetch any new logs since the last check.

Regular Cadence Fetching

For continuous monitoring and compliance requirements, you’ll want to fetch audit logs on a regular schedule. Here’s the recommended approach:

Initial Backfill

If you’re setting up audit log collection for the first time:

Incremental Updates

After your initial backfill, run this on a regular schedule (e.g., every 5-15 minutes):

Scheduling Recommendations

  • High-activity workspaces: Poll every 5-10 minutes with take=1000
  • Medium-activity workspaces: Poll every 15-30 minutes with take=500
  • Low-activity workspaces: Poll hourly with take=100

Key Considerations

  • Persistent storage: Always save the last processed log ID to disk/database so your process can resume after restarts.
  • Idempotency: Audit logs are immutable, so it’s safe to reprocess the same log multiple times if needed.
  • Error handling: If a fetch fails, retry from the same log ID and don’t skip ahead.
  • Rate limiting: With the 60 req / min, fetching 1000 logs takes approximately 1 second per batch. Plan your cadence accordingly.
  • Gap detection: Monitor timestamps to detect if you’re falling behind. If the latest fetched timestamp is more than your polling interval old, increase frequency or batch size.

Best Practices

  • Respect rate limits: The API is limited to 60 requests per minute. Implement appropriate delays in your polling logic
  • Store logs externally: Export audit logs to your own SIEM or audit repository for long-term retention and analysis
  • Handle timestamps correctly: The time parameter uses UTC epoch timestamps (seconds since January 1, 1970)
  • Track pagination state: Always save the last processed log ID to persistent storage to resume pagination if your process is interrupted
  • Monitor for new event types: The API may add new event types over time, so build your parsing logic to handle unknown types gracefully
  • Implement retries with backoff: If you hit rate limits or encounter errors, implement exponential backoff before retrying
  • Deduplicate on ingestion: Use the log id field as a unique identifier to prevent duplicate storage if you need to reprocess logs
  • Set up alerting: Monitor your sync process to ensure logs are being fetched regularly and alert if the process fails
  • Use log_type filtering when needed: When you only need specific types of logs, use the log_type parameter to filter server-side and reduce bandwidth, processing overhead, and API calls

Error Handling


Need help getting started? Contact your Harvey Customer Success Manager for more information.