Follow Discord
Sweep 22 Oct 2026 · 04:32Z Build v2.1.308 527 read Stable v2.1.308 Latest v2.1.308 Next v2.1.308 Feeds RSS JSON llms.txt llms-full.txt Unofficial
One change · claude-docs

Compliance API changedgovernment/org-admin/compliance-api

Nearest release: v2.1.305, published 3 hours after upstream edited the page. Shown because the two are within 24 hours of each other. Nothing here says the release caused the edit.

Upstream edited this page at 20 Oct 2026 16:24 UTC, give or take a minute or two: the time comes from Anthropic’s own sitemap rather than from a commit. This site recorded the change at 20 Oct 2026 16:37 UTC.

Upstream edited
Recorded here
Lines+3added
Lines−3removed
From line 47 where the diff opens
First seen 14 Aug 2026 this site's first read of the page
Recorded edits9to this page, all time

The whole hunk

from line 47, old and new numbered
/
lines
from line 47
4747 
4848The exclusive bounds `created_at.gt` and `created_at.lt` are also accepted if your collector needs them.
4949 
50The API serves the most recent 30 days of activity. A lower bound earlier than that is treated as 30 days ago.
51 
5052### Response format
5153 
5254The response is a JSON envelope containing a page of events and the cursors for the next and previous pages.
from line 117
115117}
116118```
117119 
118The top-level `user_id` and `user_email` fields appear on activities recorded after they were added to the API. Earlier activities are not updated, so your collector should treat these fields as optional.
119 
120120### Activity types
121121 
122122Event types use a dotted `resource.action` naming convention. The categories emitted today include:
from line 132
132132 
133133## Connecting to your SIEM
134134 
135Most deployments run a small scheduled worker that polls the API on a fixed interval, forwards each event to the SIEM's HTTP ingest endpoint, and records a time watermark so the next run picks up where the last one left off.
135Most deployments run a small scheduled worker that polls the API on a fixed interval, forwards each event to the SIEM's HTTP ingest endpoint, and records a time watermark so the next run picks up where the last one left off. A worker that falls more than 30 days behind cannot recover the gap.
136136 
137137A typical run requests `since=<watermark>`, forwards every event returned, and if `has_more` is true, follows `after_id=<last_id>` for each further page until `has_more` is false. After all pages are drained, advance your watermark to the newest `created_at` you saw. Event `id` values are stable and unique, so your collector can deduplicate on `id` and safely retry a page or use an overlapping `since` without creating duplicate records in the SIEM.
138138 
Feedback