The Claude Compliance Source in Cribl Stream collects enterprise observability and compliance data from Anthropic’s Claude 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 Claude 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.
• A Claude Compliance access key , with the scopes required for the endpoint types you plan to collect. Note that an Admin API key can substitute for a Compliance Access Key, but grants access to the Activity Feed only.
• 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 Claude Compliance Source Works ​

The Source organizes the Claude Compliance API into collection tiers:

• Tier 1 (directly collectible): List endpoints with no required path parameters. The Source calls these directly on each collection run. You enable or disable each one individually in the Endpoints sidebar.
• Tier 2 (detail/drill-down): Endpoints that require IDs discovered from Tier 1 responses. The Source fetches these automatically as part of the same collection job when the parent Tier 1 endpoint is enabled. Tier 1 data fetched for this purpose is used for ID discovery only and does not generate events. For example, when Chat Messages collection is active, the Source discovers chat IDs from the Chats endpoint and then fetches messages for each chat. Only message events are generated; no chat events are produced.

When a collection job runs, the Source:

1. Calls each enabled Tier 1 endpoint with your API key.
2. Pages through results using cursor-based or page-based pagination until all available records are retrieved.
3. For endpoints with associated Tier 2 detail endpoints, discovers item IDs from Tier 1 responses and fetches per-item details automatically.
4. Ingests each record as an event in Cribl Stream.
5. 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 a Claude Compliance 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 Claude Compliance API key.
   • Tags: Optionally, add UI tags to group this Source in Stream. Tags are not added to events.

3. Under Endpoints, select each endpoint from the sidebar to configure its collection settings. By default, only the Activities endpoint is enabled, with state tracking on. All endpoints support:

   • Enabled: Toggle collection for this endpoint on or off.
   • Cron schedule: Schedule on which to run this collection job. Activities defaults to */5 * * * *; all other endpoints default to 0 7 * * *.
   • Job timeout: Maximum runtime for a single collection job (for example, 30, 45s, 15m). Enter 0 for unlimited time (default: 300).

   Endpoints that support time filtering (Activities, Chats, Chat Messages, Projects, Project Details) additionally include:

   • 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).
   • State tracking: Toggle to track progress between consecutive scheduled runs. When enabled, configure State update expression and State merge expression.

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.

Endpoints ​

The Claude Compliance Source supports 5 directly collectible (Tier 1) endpoints and 4 detail (Tier 2) endpoints discovered and fetched automatically. All nine appear in the Endpoints sidebar.

Tier 1: Directly Collectible ​

Tier 1 endpoints are list endpoints with no required path parameters. Toggle each one independently in the Endpoints sidebar.

Activities and Chats use cursor-based pagination. For Activities, the Source sends order=asc and reads last_id and has_more from each response, passing last_id back as after_id in the next request. For Chats, the Source sends order_by=updated_at on each request. Projects, Groups, and Organizations use token-based pagination. For timestamp extraction: Activities uses created_at; Chats and Projects use updated_at; Groups and Organizations use the current time.

Tier 2: Detail/Drill-down ​

Tier 2 endpoints require IDs discovered from Tier 1 responses. Each Tier 2 endpoint appears individually in the Endpoints sidebar with its own Enabled, Cron schedule, and Job timeout settings. Endpoints that support time filtering (Chat Messages, Project Details) also include Earliest, Latest, and State tracking; the remaining Tier 2 endpoints (Organization Users, Organization Roles) do not.

For field definitions, response schemas, 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.

Earliest and Latest time syntax ​

The Earliest and Latest fields on time-filtered endpoints accept the following syntax:

[+|-]<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. Default values are preconfigured per endpoint to match each endpoint’s timestamp field. For example, for the Chats endpoint:

State Update Expression ​

updated_at && updated_at > (state.latestCreatedAt || '') ? {latestCreatedAt: updated_at} : state

This expression checks whether updated_at is present and newer than the stored state.latestCreatedAt. If so, it updates state to the new value; otherwise it keeps the existing state. State values must resolve to an object. If the expression does not resolve to an object, Cribl Stream ignores the result.

State Merge Expression ​

(prevState.latestCreatedAt || '') >= (newState.latestCreatedAt || '') ? prevState : newState

It compares prevState (the previously saved state) to newState (the state from the most recent collection task), keeping whichever has the greater timestamp value.

The field names used in state expressions vary per endpoint – they match the endpoint’s time filter field (created_at, updated_at, or the collection run time). If you modify an endpoint’s time filter behavior, update its state expressions accordingly.

Managing State ​

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

API limits and large exports ​

Several endpoints, especially activities and chats, can return large volumes of paginated records. Tier 2 endpoints multiply request volume further, since the Source issues one request per discovered ID. 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.