Проектирование вашей интеграции для соответствия требованиям

Производственная интеграция Compliance API предполагает три проектных решения: как она потребляет Activity Feed, как её вывод сопоставляется с вашей системой «security information and event management» (система управления информацией о безопасности и событиями безопасности), или SIEM, и где хранятся долгосрочные копии активности и контента. Эти решения не зависят от самих конечных точек; эта страница поможет вам оценить компромиссы.

Эта страница предполагает, что вы прочитали Запрос Activity Feed, где определены параметры и контракт пагинации, на которые ссылается весь текст, а также Получение и удаление чатов, файлов и проектов, где определены конечные точки контента и семантика deleted_at, упоминаемые в разделе Планирование хранения контента.



Выбор шаблона потребления ленты

Activity Feed поддерживает два шаблона потребления: периодический опрос окон, ограниченных created_at.gte и created_at.lt, и инкрементальные чтения на основе курсора, которые сохраняют курсор из одного ответа и передают его в следующем запросе. Оба возвращают идентичные объекты Activity; разница заключается в состоянии, которое ваш клиент сохраняет между вызовами.

Оба шаблона имеют следующие общие ограничения:

• Активности доступны для запроса в течение 1 минуты после возникновения и хранятся 6 лет.
• Максимальный limit для каждой страницы — 5 000.
• Значения курсора — это непрозрачные строки, которые вы не должны разбирать.
• Запросы ограничены 600 в минуту на родительскую организацию, совместно для всех ключей, всех связанных организаций и всех конечных точек /v1/compliance/*; см. 429 Too Many Requests для заголовков ответа и контракта повторных попыток.



Опрос окон

Устанавливайте created_at.lt как минимум на 1 минуту в прошлое, чтобы каждая активность в окне уже была доступна для запроса. Используйте created_at.gte для нижней границы и created_at.lt для верхней границы, чтобы последовательные окна стыковались без пропусков и перекрытий; повторно используйте значение lt предыдущего окна как значение gte следующего окна.

curl --fail-with-body -sS -G \
  "https://api.anthropic.com/v1/compliance/activities" \
  --header "x-api-key: $ANTHROPIC_COMPLIANCE_ACCESS_KEY" \
  --data-urlencode "created_at.gte=2026-04-20T07:00:00Z" \
  --data-urlencode "created_at.lt=2026-04-20T08:00:00Z" \
  --data-urlencode "limit=5000"

Когда ответ содержит has_more: true, окно содержит более одной страницы активностей. Либо выполняйте постраничный обход внутри окна, передавая last_id из ответа как after_id в следующем запросе (останавливаясь, когда has_more равно false), либо выберите меньшее временное окно. См. Пагинация результатов для полного контракта.

Даже при чистой стыковке активность, которая индексируется после закрытия своего окна, никогда не появится в более позднем окне. Выполняйте дедупликацию по id активности и либо расширяйте каждое новое окно так, чтобы оно перекрывало предыдущее на несколько минут, либо запускайте периодический проход сверки, который повторно запрашивает более старое окно.



Инкрементальные чтения на основе курсора

first_id="activity_01XyDMpzjS89pFZXqSFUBDr6"  # first_id from a previous response

curl --fail-with-body -sS -G \
  "https://api.anthropic.com/v1/compliance/activities" \
  --header "x-api-key: $ANTHROPIC_COMPLIANCE_ACCESS_KEY" \
  --data-urlencode "limit=5000" \
  --data-urlencode "before_id=$first_id"

Выполняйте постраничный обход, пока has_more не станет false, затем сохраните first_id из последнего ответа и передайте его без изменений как before_id при следующем запуске, чтобы получить активности новее сохранённого курсора. Чтобы идти в противоположном направлении для обратного заполнения, сохраните last_id и передайте его как after_id. Полный справочник по курсорам и токенам страниц, а также семантику повторных попыток см. в разделе Пагинация результатов.

Производственный цикл догоняющей синхронизации получает активности, записанные с момента вашего последнего опроса, управляя итерацией через has_more и first_id:

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

Курсоры переживают ротацию ключей; см. Управление ключами и их ротация.



Сопоставление с вашей SIEM

Каждая Activity содержит поля, которые вы можете соединить с событиями, уже находящимися в вашей SIEM (Splunk, Datadog, Microsoft Sentinel, Cribl или аналогичной):

actor.user_id и actor.email_address присутствуют, когда actor.type равно user_actor; проверяйте дискриминатор перед их чтением. user_id — это стабильный, непрозрачный идентификатор учётной записи пользователя: он согласован во всех конечных точках Compliance API и полезных нагрузках активностей и не меняется при изменении адреса электронной почты или отображаемого имени пользователя. Используйте user_id, а не email_address, в качестве основного ключа соединения.

Вызовы самого Compliance API порождают активности compliance_api_accessed. Принимайте их вместе с другими типами активностей, чтобы ваша SIEM фиксировала, кто и когда запрашивал данные соответствия. Передайте activity_types[]=compliance_api_accessed, чтобы ограничить запрос, затем в вашем клиенте читайте actor.api_key_id из каждой активности, у которой actor.type равно api_actor, чтобы отнести доступ к конкретному Compliance Access Key или ключу Admin API.



Планирование хранения контента

Три горизонта хранения определяют, что вы сможете получить позже:

О том, как остальная часть Claude Platform обрабатывает хранение данных, см. API и хранение данных.

Выбирайте между экспортом с архивированием и получением через API по требованию следующим образом:

• Если ваш горизонт юридического удержания или аудита превышает 6 лет для метаданных активности, экспортируйте страницы Activity Feed в ваш собственный архив по мере их приёма.
• Если ваша политика хранения контента короче вашего горизонта eDiscovery, экспортируйте контент чатов и файлов до истечения окна хранения; Compliance API не может вернуть контент, который уже был удалён политикой хранения.
• Если рабочий процесс может выполнить жёсткое удаление через Compliance API (например, принудительное применение DLP), сначала получите и заархивируйте целевой контент. После жёсткого удаления нет окна восстановления; мягкие удаления из claude.ai остаются доступными для получения с заполненным deleted_at, но удаления через Compliance API — нет.

Во всех остальных случаях полагайтесь на прямое получение через API и избегайте поддержания параллельной копии.



Гарантии доставки и полнота

Рассматривайте Activity Feed как at-least-once (как минимум один раз): корректно пагинированный обход возвращает каждую активность как минимум один раз, но повторная попытка после частичного сбоя может повторно доставить активности, которые вы уже сохранили. Выполняйте дедупликацию по полю id активности.

Конечные точки списков не возвращают поле total_count или контрольную сумму. Чтобы подтвердить, что запуск экспорта завершён, записывайте в журнал:

• Начальный курсор и конечный last_id.
• Количество экспортированных записей.
• Временную метку запуска и request-id последней страницы.

Конечные точки контента (чаты, файлы, проекты и вложения проектов) обслуживают только данные claude.ai; Activity Feed отображает административные и ресурсные события по всей организации. Compliance API не включает:

• Текст подсказок или ответы модели из рабочих нагрузок Claude Console или Claude API.
• Контент, удалённый политикой хранения вашей организации.
• Контент, жёстко удалённый через Compliance API.

Подробнее о том, что Compliance API фиксирует и не фиксирует, см. в FAQ по Compliance API.

Для цепочки хранения сохраняйте экспортированные записи с метаданными происхождения: исходная конечная точка, параметры запроса, временная метка запуска и хэш содержимого каждой записи.



Следующие шаги