The Anthropic Compliance API (Claude Compliance API) Source in Cribl Stream collects enterprise observability and compliance data from Anthropic’s Compliance API. It is intended for organizations using Claude Enterprise that need to feed Claude Platform activity into eDiscovery, data loss prevention (DLP), or SIEM tools, as well as to process that data in Cribl Stream before delivery to downstream systems.

Type: Pull | TLS Support: Yes | Event Breaker Support: Yes

TLS is enabled via HTTPS on the underlying Anthropic Compliance REST APIs. Event breaking is applied automatically using the Anthropic Compliance Ruleset; it is not user-configurable.

Prerequisites ​

Before you configure this Source, you need:

• A Cribl Stream deployment (Cloud or self-hosted).
• A Claude Enterprise organization with the Compliance API enabled.
• An Anthropic compliance API key, with permission to list and download compliance exports for your organization.
• Network connectivity from Cribl Workers to Anthropic’s compliance API hosts over HTTPS (direct or via an HTTP/S proxy).

For details, see Anthropic’s Compliance API reference.

How the Anthropic Compliance API Source Works ​

When a collection job runs, the Source:

1. Calls GET /v1/compliance/activities with your API key.
2. Pages through results using cursor-based pagination until all available records are retrieved.
3. Ingests each record as an event in Cribl Stream.
4. Tracks state so repeated polls avoid large gaps or unnecessary duplication.

You can then route, filter, enrich, and format events for your downstream Destinations, such as SIEM, observability, storage, or ticketing tools.

Configuring an Anthropic Compliance API Source ​

1. On the top bar, select Products, and then select Cribl Stream. Under Worker Groups, select a Worker Group. Next, you have two options:
   • To configure via QuickConnect, navigate to Routing > QuickConnect. Select Add Source and select the Source you want from the list, choosing either Select Existing or Add New.
   • To configure via the Routes, select Data > Sources. Select the Source you want. Next, select Add Source.
2. In the Source modal, configure the following under General Settings:
   • Input ID: Enter a unique name for this Source. If you clone it, Cribl Stream appends -CLONE to the original Input ID.
   • Description: Optionally, enter a description (for example, which event types or downstream SIEM this instance feeds).
   • API key (text secret): Select or create a stored text secret for your Anthropic compliance API key.
   • Endpoint types: A panel listing the available API endpoints. Currently only Compliance Activities (GET /v1/compliance/activities) is available. For each endpoint, configure:
     • Endpoint name: The name of the endpoint.
     • Description: Optionally, enter a description for the endpoint.
     • Enable endpoint: Toggle collection for this endpoint on or off.
     • Cron schedule: Schedule on which to run this collection job (default: */5 * * * *).
     • Earliest: Start of the collection time window, relative to now (default: -7d@d).
     • Latest: End of the collection time window, relative to now (default: now).
     • Job timeout: Maximum runtime for a single collection job (for example, 30, 45s, 15m). Enter 0 for unlimited time (default: 300).
     • State tracking: Toggle to track progress between consecutive scheduled runs. When enabled, configure State update expression and State merge expression.
   • Tags: Optionally, add UI tags to group this Source in Stream. Tags are not added to events.
3. Configure Scheduling settings as needed. Defaults are set for typical compliance polling.
4. Optionally configure Processing Settings, Retries, and Advanced Settings.
5. Under Connected Destinations, choose Send to Routes and/or QuickConnect depending on how you want data to leave this Source.
6. Click Save, then Commit & Deploy.

Endpoint Types ​

The Anthropic Compliance API Source currently supports the Compliance Activities (GET /v1/compliance/activities). It provides a paginated audit trail of all compliance-relevant actions across your Claude Enterprise organization. The source uses cursor-based pagination, reading last_id and has_more from each response and passing last_id back as after_id in the next request to retrieve records. No time range parameters are sent to the Anthropic API. The created_at field in each record is used for timestamp extraction.

For field definitions, response schema, and event categories, see Anthropic’s Compliance API reference.

Processing Settings ​

Fields ​

In this section, you can define new fields or modify existing ones using JavaScript expressions, similar to the Eval function.

• The Field Name can either be a new field (unique within the event) or an existing field name to modify its value.
• The Value is a JavaScript expression (enclosed in quotes or backticks) to compute the field’s value (can be a constant). Select this field’s advanced mode icon (far right) if you’d like to open a modal where you can work with sample data and iterate on results.

This flexibility means you can:

• Add new fields to enrich the event.
• Modify existing fields by overwriting their values.
• Compute logic or transformations using JavaScript expressions.

Pre-Processing ​

In this section’s Pipeline drop-down list, you can select a single existing Pipeline or Pack to process data from this input before the data is sent through the Routes.

Retries ​

Adjust how failed HTTP requests are retried.

Retry type: Backoff (default), Static, or Disabled.

Initial retry interval (ms): Delay before the first retry after a failure. Max 20,000 ms. 0 means retry immediately until Retry limit is reached.

Retry limit: Max retries per failed request (default 5, max 20). 0 disables retries.

Backoff multiplier: Base for exponential backoff (default 2).

Retry HTTP codes: Defaults are 429 and 503. Non-2xx responses are errors; tune this list per Anthropic’s behavior.

Honor Retry-After header: When enabled (default), honor Retry-After up to the product maximum (longer delays may be ignored). Stream logs the delay when applicable.

Retry connection timeout / Retry connection reset: Optionally retry on ETIMEDOUT or ECONNRESET for more resilient long downloads.

Advanced Settings ​

Request timeout (seconds): Max time to wait for a request (default 300; 0 means wait indefinitely).

Time to live: How long Collector job artifacts remain on disk and in Job Inspector (default 4h).

Environment: For GitOps, optionally limit this config to a single Git branch.

Connected Destinations ​

Send to Routes: Use the Routing table for conditional routing, filtering, and cloning.

QuickConnect: Send this Source’s output directly to one or more Destinations.

Scheduling ​

Cron schedule, earliest/latest time window, and job timeout are configured per-endpoint in the Endpoint types panel. The global Scheduling settings cover:

Log Level: Verbosity for task logs (use higher verbosity temporarily for troubleshooting).

The Earliest and Latest time syntax used per-endpoint follows:

[+|-]<time_integer><time_unit>@<snap-to_time_unit>

Syntax reference:

Rules:

• Earliest must not be later than Latest.
• Values without units are interpreted as seconds (for example, -1 = -1s).

Snap-to-time syntax ​

@ rounds down from the evaluated time. For example:

• @d – start of the current day.
• +128m@h – forward 128 minutes, then snap back to the hour boundary.

Week/month/quarter/year snaps (@w, @w1-@w6, @mon, @q, @y) behave like other Cribl Stream Collectors.

Working with State Tracking ​

You can configure the Source to track state, either by time or another arbitrary value. This can help prevent overlaps between jobs, where subsequent runs may return some of the same results as previous runs. Similarly, it can help prevent gaps in data by allowing a run to pick up from where the last run ended.

State update expression: JavaScript expression that defines how to update the state from an event. Use the event’s data and the current state to compute the new state.

State merge expression: JavaScript expression that defines which state to keep when merging a task’s newly reported state with the previously saved state. Evaluates prevState and newState variables, resolving to the state to keep.

Understanding State Expression Fields ​

The State update and State merge expressions control how state is derived from a collection run and how it is merged with existing state, respectively. They’re preconfigured to work with the common use case of tracking state by latest _time, but you may need to update them for other use cases. To understand what these fields do, let’s break down the default values.

State Update Expression ​

This expression has a default value of:

__timestampExtracted !== false && {latestTime: (state.latestTime || 0) > _time ? state.latestTime : _time}

The __timestampExtracted field is set to false if the Event Breaker was unable to parse time for the event. If this is the case, you don’t want to update state (the event’s _time value defaults to Date.now() if the Event Breaker was unable to parse out the correct time). If __timestampExtracted is false, take advantage of short-circuit evaluation to not update state.

State values must resolve to an object, such as:

{ "latestTime": 17122806161 }

If the expression does not resolve to an object, Cribl Stream will ignore the result.

{latestTime: (state.latestTime || 0) > _time ? state.latestTime : _time} - compare state.latestTime to the event’s _time value, keeping whichever value is greater.

State Merge Expression ​

This expression has a default value of:

prevState.latestTime > newState.latestTime ? prevState : newState

It compares prevState (the state that was previously saved) to newState (the state reported from the most recent collection task), keeping the state with the greatest latestTime value.

Managing State ​

Select Manage State to view, modify, or delete a state. For more information, see Manage State.

The default values for these fields are configured to track state by the latest _time field found in events gathered in a collection run.

API limits and large exports ​

The activities endpoint can return large volumes of paginated records. If Anthropic returns rate-limit responses (for example, HTTP 429), rely on Retry settings and a less aggressive schedule. Watch job logs and Anthropic’s documented quotas for your organization tier.

Proxying requests ​

To send HTTPS traffic through a corporate proxy, see System Proxy Configuration.

Internal fields ​

Stream attaches metadata you can read in Functions:

• __collectible – metadata about the collection job.
• __collectStats – per-request statistics.

Troubleshooting ​

Live Data: On the Source modal, use Live Data and Start Capture to preview events as they are ingested. See Capture Source data.

Logs: Use the Logs tab on the job or Source for request errors, auth failures, and download issues.

Monitoring: Use the Monitoring page to correlate drops in events or bytes with schedule or API errors.

Response errors ​

Non-2xx HTTP responses from the configured endpoints are generally treated as errors. Exceptions may apply when only some subtasks fail or when the HTTP client follows redirects (3xx) according to library behavior. See job messages for details.

If authentication fails, verify the compliance access key, header names, and any organization identifiers against Anthropic’s current Compliance API documentation.