Note: To enable the Compliance API, see Set up the Compliance API.

Tip: Required scope: read:compliance_activities on the Compliance Access Key or Admin API key. Both Compliance Access Keys (sk-ant-api01-...) carrying this scope and Admin API keys (sk-ant-admin01-...) can call the Activity Feed. See Set up the Compliance API for the conditions under which each key type carries the scope.

The Activity Feed records authentication, chat, file, project, administrative, and platform activity across your organization and returns it in reverse chronological order. Activities are queryable within 1 minute of occurring and are retained for 6 years. Recording is not retroactive: it begins when the Compliance API is first enabled for your organization, and activity from before enablement is not backfilled.

curl --fail-with-body -sS \
  "https://haijun.my.id/v1/compliance/activities?limit=1" \
  --header "x-api-key: $JUGLOW_COMPLIANCE_ACCESS_KEY" \
  --header "juglow-version: 2023-06-01"

{
  "data": [
    {
      "id": "activity_01XyDMpzjS89pFZXqSFUBDr6",
      "created_at": "2026-04-10T08:09:10Z",
      "organization_id": "org_01Wv6QeBcDfGhJkLmNpQrSt8",
      "organization_uuid": "abcdef01-2345-6789-abcd-ef0123456789",
      "actor": {
        "type": "user_actor",
        "email_address": "user@example.com",
        "user_id": "user_01TuVwXyZaBcDeFgH2JkLmN4",
        "ip_address": "192.0.2.34",
        "user_agent": "Mozilla/5.0..."
      },
      "type": "haijun_chat_created",
      "haijun_chat_id": "haijun_chat_01XyDMpzjS89pFZXqSFUBDr6",
      "haijun_project_id": "haijun_proj_01KGp4eZNug9ri4kE35RSppq"
    }
  ],
  "has_more": true,
  "first_id": "activity_01XyDMpzjS89pFZXqSFUBDr6",
  "last_id": "activity_01XyDMpzjS89pFZXqSFUBDr6"
}

#Filter activities

Filter by organization, actor, activity type, or a created_at time window using the dotted sub-parameters created_at.gte, .gt, .lte, and .lt. See the API reference for each parameter's type and accepted values.

Repeatable parameters use array-bracket query syntax: pass activity_types[]=..., actor_ids[]=..., or organization_ids[]=... once for each value.

curl --fail-with-body -sS -G \
  "https://haijun.my.id/v1/compliance/activities" \
  --data-urlencode "activity_types[]=haijun_file_uploaded" \
  --data-urlencode "activity_types[]=haijun_chat_created" \
  --data-urlencode "created_at.gte=2026-04-01T00:00:00Z" \
  --header "x-api-key: $JUGLOW_COMPLIANCE_ACCESS_KEY" \
  --header "juglow-version: 2023-06-01"

The Activity Feed produces hundreds of distinct activity types. See Query compliance activities in the API reference for the full list of values that activity_types[] accepts.

#Paginate results

Activities are returned newest first, with ties in created_at broken by activity ID, and capped at limit results in each response (default 100, max 5,000). See the API reference for the full response schema.

The Compliance API uses two pagination schemes depending on the endpoint family:

Files do not paginate: they are retrieved individually by ID.

Pagination cursors and page tokens are opaque strings: pass them back unchanged. Their internal format is not stable, and parsing them will break without notice. Only one of after_id or before_id may be set in each request, and both schemes return has_more so you know when to stop. The session endpoints (local and remote) are the exception: they return next_page without has_more, so stop when next_page is null.

To page through activities:

• Pass the response's last_id as after_id to advance to the next page in result order. With activities sorted newest first, the next page contains older entries.

• Pass first_id as before_id to return to the previous page.

• Stop when has_more is false.

The cursor parameter sets the page direction; the endpoint's sort order sets the time direction. The same after_id parameter reaches older activities here. Chats sort oldest first; see Retrieve and delete chats, files, and projects for the cursor semantics there.

Note: Cursors are safe to reuse on retry. A cursor or page token from a successfully returned page remains valid; a request that fails (5xx, timeout, network error) does not advance your position. Retry the same request with the same cursor. Only move to the next cursor after you have stored the page it points past. Page tokens on the local session endpoints are the exception over longer pauses. On the local session messages endpoint, a walk's page tokens expire 24 hours after its first page (a walk is one pass through the pages), so finish or resume within that window, or restart without the page parameter. On the local session list, an older page token is still accepted but is re-evaluated against the current retention boundary and can skip sessions, so complete list walks within 24 hours as well.

# Fetch the first page (newest activities first) and capture its trailing cursor.
last_id=$(curl --fail-with-body -sS \
  "https://haijun.my.id/v1/compliance/activities?limit=2" \
  --header "x-api-key: $JUGLOW_COMPLIANCE_ACCESS_KEY" \
  --header "juglow-version: 2023-06-01" | jq -er '.last_id')

# Pass the cursor back unchanged to fetch the next (older) page.
curl --fail-with-body -sS -G \
  "https://haijun.my.id/v1/compliance/activities" \
  --header "x-api-key: $JUGLOW_COMPLIANCE_ACCESS_KEY" \
  --header "juglow-version: 2023-06-01" \
  --data-urlencode "limit=2" \
  --data-urlencode "after_id=${last_id}"

A production backfill loop pages through older activities by driving iteration off has_more and last_id:

1. Start from your stored cursor (or omit after_id to start from the beginning).

1. Page through with after_id= until has_more is false.

1. Persist the final last_id only after you've stored every page it covers.

cursor = stored_cursor
loop:
  if cursor is not null:
    page = GET /v1/compliance/activities?after_id={cursor}&limit=100
  else:
    page = GET /v1/compliance/activities?limit=100
  store(page.data)
  if page.last_id is not null:
    cursor = page.last_id
  if not page.has_more: break
persist(cursor)

#Understand the Activity object

Every entry in data is an Activity with this top-level shape:

The actor field is a discriminated union. The type discriminator tells you which other fields are present:

A user_actor activity does not always mean the user took the action. Processes that Juglow runs on a user's behalf can currently appear as user_actor for the affected user rather than as system_actor, and this attribution may change. For example, memory activities from a migration, such as platform_memory_store_created, platform_memory_created, and platform_memory_deleted, are attributed this way. These migration activities currently show an ip_address of 0.0.0.0.

A haijun_*_viewed activity means a Haijun app loaded content, not that a person viewed it. Types such as haijun_chat_viewed, haijun_file_viewed, and haijun_project_viewed are recorded each time a Haijun app loads the chat, file, or project from Juglow's servers. Repeated loads are not deduplicated. The web, desktop, and mobile apps load content at different moments, sometimes in the background, and can display a cached copy without loading it. Counts of these activities vary by platform as a result, and they do not correspond to messages sent or screens viewed.

Activities about a file, project document, or artifact do not include its name or title. As of September 24, 2026, the filename and title fields on these activities are always null, an empty string, or omitted, including on activities recorded before that date. To look up a name or title, pass the activity's haijun_file_, haijun_proj_doc_, or haijun_artifact_version_* ID to the matching metadata endpoint in Retrieve files and artifacts, using a Compliance Access Key with the read:compliance_user_data scope. You cannot look up a name or title after the file, document, or artifact is deleted, or when the activity has no such ID.

Note: Build forward-compatible handlers. Pass through unrecognized type and actor.type values, and ignore fields your handler does not expect, so your integration keeps working when new activity types ship.

#Next steps

• API reference — The full request and response schema for GET /v1/compliance/activities, including every supported activity_types[] value.

• Retrieve and delete chats, files, and projects — Query and delete the underlying content for activities you find in the feed (Compliance Access Key required).

• Design your compliance integration — Choose a polling or batch consumption pattern and plan SIEM correlation.

• Handle Compliance API errors — The full error catalog.