Concevoir votre intégration de conformité

Une intégration de l'API de conformité en production repose sur trois choix de conception : la manière dont elle consomme le flux d'activité, la manière dont sa sortie est corrélée avec votre système de « security information and event management » (gestion des informations et des événements de sécurité), ou SIEM, et l'emplacement où résident les copies à long terme des activités et du contenu. Ces choix sont indépendants des points de terminaison eux-mêmes ; cette page vous aide à évaluer les compromis.

Cette page suppose que vous avez lu Interroger le flux d'activité, qui définit les paramètres et le contrat de pagination référencés tout au long de ce document, ainsi que Récupérer et supprimer des conversations, des fichiers et des projets, qui définit les points de terminaison de contenu et la sémantique de deleted_at référencée dans Planifier la rétention du contenu.

Choisir un modèle de consommation du flux

Le flux d'activité prend en charge deux modèles de consommation : l'interrogation périodique par fenêtre délimitée par created_at.gte et created_at.lt, et les lectures incrémentielles pilotées par curseur qui conservent un curseur d'une réponse à l'autre et le transmettent lors de la requête suivante. Les deux renvoient des objets Activity identiques ; la différence réside dans l'état que votre client conserve entre les appels.

Les deux modèles partagent les contraintes suivantes :

• Les activités sont interrogeables dans la minute suivant leur occurrence et conservées pendant 6 ans.
• La valeur maximale de limit pour chaque page est de 5 000.
• Les valeurs de curseur sont des chaînes opaques que vous ne devez pas analyser.
• Les requêtes sont limitées à 600 par minute par organisation parente, partagées entre toutes les clés, toutes les organisations liées et tous les points de terminaison /v1/compliance/* ; consultez 429 Too Many Requests pour les en-têtes de réponse et le contrat de nouvelle tentative.

Interrogation par fenêtre

Définissez created_at.lt à au moins 1 minute dans le passé afin que chaque activité de la fenêtre soit déjà interrogeable. Utilisez created_at.gte pour la borne inférieure et created_at.lt pour la borne supérieure afin que les fenêtres consécutives se juxtaposent sans lacunes ni chevauchement ; réutilisez la valeur lt de la fenêtre précédente comme valeur gte de la fenêtre suivante.

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"

Lorsque la réponse contient has_more: true, la fenêtre contient plus d'une page d'activités. Soit vous paginez à l'intérieur de la fenêtre en passant le last_id de la réponse comme after_id lors de la requête suivante (en vous arrêtant lorsque has_more est false), soit vous choisissez une fenêtre temporelle plus petite. Consultez Paginer les résultats pour le contrat complet.

Même avec une juxtaposition propre, une activité indexée après la fermeture de sa fenêtre n'apparaît jamais dans une fenêtre ultérieure. Dédupliquez sur l'id de l'activité et soit élargissez chaque nouvelle fenêtre afin qu'elle chevauche la précédente de quelques minutes, soit exécutez une passe de réconciliation périodique qui réinterroge une fenêtre plus ancienne.

Lectures incrémentielles pilotées par curseur

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"

Paginez jusqu'à ce que has_more soit false, puis conservez first_id de la réponse finale et passez-le tel quel comme before_id lors de l'exécution suivante pour récupérer les activités plus récentes que le curseur enregistré. Pour parcourir dans la direction opposée lors d'un remplissage rétroactif, conservez last_id et passez-le comme after_id à la place. Pour la référence complète curseur-vs-jeton-de-page et la sémantique des nouvelles tentatives, consultez Paginer les résultats.

Une boucle de rattrapage en production récupère les activités enregistrées depuis votre dernière interrogation en pilotant l'itération à partir de has_more et 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)

Les curseurs survivent à la rotation des clés ; consultez Gérer et faire tourner les clés.

Corréler avec votre SIEM

Chaque Activity contient des champs que vous pouvez joindre aux événements déjà présents dans votre SIEM (Splunk, Datadog, Microsoft Sentinel, Cribl ou similaire) :

actor.user_id et actor.email_address sont présents lorsque actor.type est user_actor ; vérifiez le discriminateur avant de les lire. user_id est un identifiant stable et opaque pour le compte utilisateur : il est cohérent sur tous les points de terminaison de l'API de conformité et toutes les charges utiles d'activité, et il ne change pas lorsque l'adresse e-mail ou le nom d'affichage de l'utilisateur change. Utilisez user_id, et non email_address, comme clé de jointure principale.

Les appels à l'API de conformité elle-même émettent des activités compliance_api_accessed. Ingérez-les aux côtés des autres types d'activité afin que votre SIEM enregistre qui a interrogé les données de conformité, et quand. Passez activity_types[]=compliance_api_accessed pour limiter la portée de la requête, puis dans votre client, lisez actor.api_key_id de chaque activité dont actor.type est api_actor pour attribuer l'accès à une clé d'accès de conformité ou une clé API d'administration spécifique.

Planifier la rétention du contenu

Trois horizons de rétention régissent ce que vous pouvez récupérer ultérieurement :

Pour savoir comment le reste de la Claude Platform gère la rétention, consultez API et rétention des données.

Choisissez entre l'exportation-et-archivage et la récupération à la demande via l'API comme suit :

• Si votre horizon de conservation légale ou d'audit dépasse 6 ans pour les métadonnées d'activité, exportez les pages du flux d'activité vers votre propre archive au fur et à mesure que vous les ingérez.
• Si votre politique de rétention de contenu est plus courte que votre horizon d'eDiscovery, exportez le contenu des conversations et des fichiers avant l'expiration de la fenêtre de rétention ; l'API de conformité ne peut pas renvoyer du contenu que la rétention a déjà supprimé.
• Si un workflow est susceptible d'émettre une suppression définitive via l'API de conformité (par exemple, l'application de règles DLP), récupérez et archivez d'abord le contenu cible. Il n'existe aucune fenêtre de récupération après une suppression définitive ; les suppressions logiques depuis claude.ai restent récupérables avec deleted_at renseigné, mais les suppressions via l'API de conformité ne le sont pas.

Dans tous les autres cas, appuyez-vous sur la récupération directe via l'API et évitez de maintenir une copie parallèle.

Garanties de livraison et complétude

Considérez le flux d'activité comme au-moins-une-fois : un parcours correctement paginé renvoie chaque activité au moins une fois, mais une nouvelle tentative après un échec partiel peut relivrer des activités que vous avez déjà stockées. Dédupliquez sur le champ id de l'activité.

Les points de terminaison de liste ne renvoient pas de champ total_count ni de somme de contrôle. Pour attester qu'une exécution d'exportation est complète, consignez :

• Le curseur de départ et le last_id terminal.
• Le nombre d'enregistrements exportés.
• L'horodatage de l'exécution et le request-id de la page finale.

Les points de terminaison de contenu (conversations, fichiers, projets et pièces jointes de projet) servent uniquement les données de claude.ai ; le flux d'activité expose les événements administratifs et de ressources à l'échelle de l'organisation. L'API de conformité n'inclut pas :

• Le texte des prompts ou les réponses du modèle provenant des charges de travail Claude Console ou Claude API.
• Le contenu supprimé par la politique de rétention de votre organisation.
• Le contenu supprimé définitivement via l'API de conformité.

Consultez la FAQ de l'API de conformité pour en savoir plus sur ce que l'API de conformité capture et ne capture pas.

Pour la chaîne de traçabilité, stockez les enregistrements exportés avec des métadonnées de provenance : point de terminaison source, paramètres de requête, horodatage de l'exécution et un hachage de contenu de chaque enregistrement.

Étapes suivantes