Enabling Audit Logs in Self-Hosted LangSmith

Prerequisites

Audit logs are available in LangSmith v0.12.33 and later. You can check your version with:

helm list -n <namespace>

Enabling Audit Logs

Add the following configuration to your Helm values.yaml file:

backend:
  deployment:
    extraEnv:
      - name: AUDIT_LOGS_ENABLED
        value: "true"
      - name: DEFAULT_ORG_FEATURE_CAN_USE_AUDIT_LOGS
        value: "true"

Then apply the changes:

helm upgrade langsmith langchain/langsmith -n <namespace> -f values.yaml --wait

Important: Added Step For Existing Organizations

The DEFAULT_ORG_FEATURE_CAN_USE_AUDIT_LOGS environment variable only applies as a default for newly created organizations. If your organization existed before you enabled these flags, it has can_use_audit_logs: false stored in the database, which takes precedence over the environment variable.

To enable audit logs for an existing organization, run this database update:

UPDATE organizations
SET config = COALESCE(config, '{}'::jsonb) || '{"can_use_audit_logs": true}'::jsonb
WHERE id = '<your-organization-id>';

You can find your organization ID by:

1. Querying SELECT id, display_name FROM organizations;

2. Or checking the LangSmith UI URL (the UUID in the path)

After running this update, restart the backend pods and the audit logs endpoint should work.

Verification

1. Confirm the audit_logs table exists

kubectl exec <postgres-pod> -n <namespace> -- psql -U postgres -d postgres -c "\dt audit_logs"

2. Test the API endpoint

Requires an organization admin API key:

curl "https://your-langsmith-url/api/v1/audit-logs?start_time=2026-01-01T00:00:00Z&end_time=2026-01-30T00:00:00Z&limit=10" \
  -H "X-API-Key: your_org_admin_api_key"

What Gets Logged

The system logs approximately 70+ administrative operations including:

• API key management - Create/delete API keys, PATs, service keys

• User and role management - Create/update/delete roles, invite users, manage org members

• SSO configuration - Create/update/delete SSO settings, update login methods

• Workspace operations - Create/update/delete workspaces, manage members, update secrets

• Resource management - Bulk exports, TTL settings, usage limits, charts, deployments

• Tag operations - Create/update/delete tag keys, values, and taggings

All logs are stored in OCSF 1.7.0 format (Open Cybersecurity Schema Framework), making them compatible with SIEM tools like Splunk and Datadog.

Accessing Logs

Audit logs are stored in the PostgreSQL database and accessible via:

• API: GET /api/v1/audit-logs with time range parameters

• Direct database queries to the audit_logs table

API Parameters

Required:

• start_time - Start datetime (ISO 8601 format)

• end_time - End datetime (ISO 8601 format)

Optional:

• limit - Number of items (1-100, default 10)

• cursor - Pagination cursor

• workspace_id - Filter by workspace

Note: Accessing audit logs requires the ORGANIZATION_MANAGE permission (organization admin role).

Example Response

{
  "items": [
    {
      "class_uid": 6003,
      "class_name": "API Activity",
      "activity_id": 1,
      "activity_name": "Create",
      "status_id": 1,
      "status": "Success",
      "time": 1706400000,
      "api": {"operation": "create_api_key"},
      "http_request": {
        "http_method": "POST",
        "url": {"path": "/api/v1/api-keys"}
      },
      "actor": {
        "user": {"uid": "...", "credential_uid": "..."}
      },
      "resources": [{"uid": "..."}]
    }
  ],
  "cursor": "..."
}

Storage

Audit logs are stored in the PostgreSQL database in the audit_logs table and are queryable via the API within time ranges you specify.