Diseña tu integración de cumplimiento

Una integración de producción con la Compliance API toma tres decisiones de diseño: cómo consume el Activity Feed, cómo se correlaciona su salida con tu sistema de "security information and event management" (gestión de información y eventos de seguridad), o SIEM, y dónde residen las copias a largo plazo de la actividad y el contenido. Estas decisiones son independientes de los endpoints en sí; esta página te ayuda a evaluar las ventajas y desventajas.

Esta página asume que has leído Consultar el Activity Feed, que define los parámetros y el contrato de paginación a los que se hace referencia a lo largo del documento, y Recuperar y eliminar chats, archivos y proyectos, que define los endpoints de contenido y la semántica de deleted_at a la que se hace referencia en Planificar la retención de contenido.

Elige un patrón de consumo del feed

El Activity Feed admite dos patrones de consumo: "polling" (sondeo) periódico por ventanas delimitado por created_at.gte y created_at.lt, y lecturas incrementales basadas en cursor que persisten un cursor de una respuesta y lo pasan en la siguiente solicitud. Ambos devuelven objetos Activity idénticos; la diferencia es el estado que tu cliente persiste entre llamadas.

Ambos patrones comparten estas restricciones:

• Las actividades se pueden consultar dentro de 1 minuto después de ocurrir y se retienen durante 6 años.
• El limit máximo para cada página es 5,000.
• Los valores de cursor son cadenas opacas que no debes analizar.
• Las solicitudes están limitadas a 600 por minuto por organización principal, compartidas entre todas las claves, todas las organizaciones vinculadas y todos los endpoints /v1/compliance/*; consulta 429 Too Many Requests para conocer los encabezados de respuesta y el contrato de reintentos.

Polling por ventanas

Establece created_at.lt al menos 1 minuto en el pasado para que cada actividad en la ventana ya sea consultable. Usa created_at.gte para el límite inferior y created_at.lt para el límite superior de modo que las ventanas consecutivas se acomoden sin huecos ni superposición; reutiliza el valor lt de la ventana anterior como el gte de la siguiente ventana.

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"

Cuando la respuesta tiene has_more: true, la ventana contiene más de una página de actividades. Puedes paginar dentro de la ventana pasando el last_id de la respuesta como after_id en la siguiente solicitud (deteniéndote cuando has_more sea false), o elegir una ventana de tiempo más pequeña. Consulta Paginar resultados para ver el contrato completo.

Incluso con un acomodo limpio de ventanas, una actividad que se indexa después de que su ventana se ha cerrado nunca aparece en una ventana posterior. Deduplica usando el id de la actividad y, o bien amplía cada nueva ventana para que se superponga con la anterior por unos minutos, o ejecuta una pasada de reconciliación periódica que vuelva a consultar una ventana más antigua.

Lecturas incrementales basadas en cursor

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"

Pagina hasta que has_more sea false, luego persiste first_id de la respuesta final y pásalo sin cambios como before_id en la siguiente ejecución para recuperar actividades más recientes que el cursor guardado. Para recorrer en la dirección opuesta para un backfill, persiste last_id y pásalo como after_id en su lugar. Para la referencia completa de cursor frente a token de página y la semántica de reintentos, consulta Paginar resultados.

Un bucle de puesta al día (catch-up) en producción obtiene las actividades registradas desde tu último sondeo impulsando la iteración a partir de has_more y 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)

Los cursores sobreviven a la rotación de claves; consulta Administrar y rotar claves.

Correlaciona con tu SIEM

Cada Activity contiene campos que puedes unir con eventos que ya están en tu SIEM (Splunk, Datadog, Microsoft Sentinel, Cribl o similar):

actor.user_id y actor.email_address están presentes cuando actor.type es user_actor; verifica el discriminador antes de leerlos. user_id es un identificador estable y opaco para la cuenta de usuario: es consistente en todos los endpoints de la Compliance API y en todos los payloads de actividad, y no cambia cuando cambia el correo electrónico o el nombre para mostrar del usuario. Usa user_id, no email_address, como clave de unión principal.

Las llamadas a la propia Compliance API emiten actividades compliance_api_accessed. Ingiere estas junto con otros tipos de actividad para que tu SIEM registre quién consultó datos de cumplimiento y cuándo. Pasa activity_types[]=compliance_api_accessed para acotar la consulta y luego, en tu cliente, lee actor.api_key_id de cada actividad cuyo actor.type sea api_actor para atribuir el acceso a una Compliance Access Key o clave de Admin API específica.

Planificar la retención de contenido

Tres horizontes de retención rigen lo que puedes recuperar más adelante:

Para saber cómo el resto de la Claude Platform maneja la retención, consulta API y retención de datos.

Decide entre exportar y archivar o recuperación bajo demanda mediante la API de la siguiente manera:

• Si tu horizonte de retención legal o de auditoría supera los 6 años para los metadatos de actividad, exporta las páginas del Activity Feed a tu propio archivo a medida que las ingieres.
• Si tu política de retención de contenido es más corta que tu horizonte de eDiscovery, exporta el contenido de chats y archivos antes de que expire la ventana de retención; la Compliance API no puede devolver contenido que la retención ya ha eliminado.
• Si un flujo de trabajo podría emitir una eliminación permanente (hard-delete) de la Compliance API (por ejemplo, aplicación de DLP), recupera y archiva primero el contenido objetivo. No hay ventana de recuperación después de una eliminación permanente; las eliminaciones suaves (soft-deletes) desde claude.ai siguen siendo recuperables con deleted_at poblado, pero las eliminaciones de la Compliance API no.

En todos los demás casos, confía en la recuperación directa mediante la API y evita mantener una copia paralela.

Garantías de entrega y completitud

Trata el Activity Feed como at-least-once (al menos una vez): un recorrido correctamente paginado devuelve cada actividad al menos una vez, pero un reintento después de un fallo parcial puede volver a entregar actividades que ya almacenaste. Deduplica usando el campo id de la actividad.

Los endpoints de listado no devuelven un campo total_count ni una suma de verificación. Para certificar que una ejecución de exportación está completa, registra:

• El cursor inicial y el last_id terminal.
• El número de registros exportados.
• La marca de tiempo de la ejecución y el request-id de la página final.

Los endpoints de contenido (chats, archivos, proyectos y adjuntos de proyectos) sirven únicamente datos de claude.ai; el Activity Feed expone eventos administrativos y de recursos a nivel de toda la organización. La Compliance API no incluye:

• Texto de prompts ni respuestas del modelo de cargas de trabajo de Claude Console o de la API de Claude.
• Contenido eliminado por la política de retención de tu organización.
• Contenido eliminado permanentemente a través de la Compliance API.

Consulta las Preguntas frecuentes de la Compliance API para obtener más información sobre lo que la Compliance API captura y no captura.

Para la cadena de custodia, almacena los registros exportados con metadatos de procedencia: endpoint de origen, parámetros de consulta, marca de tiempo de la ejecución y un hash de contenido de cada registro.

Próximos pasos