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:

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


Audit Log Types

Each audit log entry carries a type field naming the action performed. The tables below list every type the API returns, grouped by product area. Every value except the ones under Retired log types is also accepted by the log_type query parameter. Harvey adds types as new functionality ships, so treat this list as a snapshot of the current set rather than a closed set, and parse an unrecognized type gracefully.
Types in the internal, internal_admin, and internal_mgmt categories record actions Harvey personnel take in Harvey’s own administrative tooling. They are excluded from the workspace admin audit log view and are not listed here, though some can still appear in API responses.

API Operations

Authentication

SCIM Provisioning

SCIM events record directory-driven changes to users, groups, and territory membership. The scim: category covers changes your identity provider pushes to Harvey; the admin:scim_* types cover changes an admin makes to the SCIM configuration itself.

Directory sync events

SCIM configuration

Admin Operations

Users, roles, and permissions

Workspace configuration

Client matters

Clients

Billing and usage

Single sign-on

Ethical walls

Integrations and MCP servers

Playbooks

History, exports, and retention

User Operations

Assistant, history, and threads

Files and documents

Vault

Review tables

Playbooks and playbook review

Clause library

Contract review

Deals, diligence, and portfolios

Facts and chronology

Horizon scanning

Timekeeping

Invoice review

Workflows and agents

Workflow builder

Knowledge sources and library

Structured datasets

Command Center and analysis

Tasks

Comments

Meetings, audio, and transcription

Email and mailbox

Integrations and DMS

MCP

Sharing, groups, and resource access

Ethical walls

Client matters

User settings and notifications

Microsoft add-ins

Microsoft Word, Outlook, Teams, and Copilot activity is captured as user audit log events. 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

Microsoft Teams and Copilot

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

Space templates and configuration

External connections

Spaces administration

System Operations

Automations

Automation events record actions a Harvey automation takes on a workspace’s behalf, without a user in the request.

Retired log types

These types were removed from Harvey and are no longer emitted. They remain documented because historical logs can still carry them. The log_type query parameter rejects them with a 400, so filter for them client-side.
Need help getting started? Contact your Harvey Customer Success Manager for more information.