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
/
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
No line in this hunk matches that.