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
time(required): UTC epoch timestamp, up to 1 year old from nowlog_type(optional): Filter to return only logs of a specific type (e.g.,auth:login,admin:add_users)
Get Earliest Audit Log
log_type(optional): Filter to return only logs of a specific type (e.g.,auth:login,admin:add_users)
Get Latest Audit Log
log_type(optional): Filter to return only logs of a specific type (e.g.,auth:login,admin:add_users)
Query Audit Logs
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)
Audit Log Types
Each audit log entry includes atype 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 thelog_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
timeparameter 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
idfield 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_typeparameter 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.