Progetta la tua integrazione di conformità

Un'integrazione della Compliance API in produzione comporta tre scelte di progettazione: come consuma l'Activity Feed, come il suo output si correla con il tuo sistema di "security information and event management" (gestione delle informazioni e degli eventi di sicurezza), o SIEM, e dove risiedono le copie a lungo termine delle attività e dei contenuti. Queste scelte sono indipendenti dagli endpoint stessi; questa pagina ti aiuta a valutare i compromessi.

Questa pagina presuppone che tu abbia letto Interroga l'Activity Feed, che definisce i parametri e il contratto di paginazione a cui si fa riferimento in tutto il documento, e Recupera ed elimina chat, file e progetti, che definisce gli endpoint dei contenuti e la semantica di deleted_at a cui si fa riferimento in Pianifica la conservazione dei contenuti.



Scegli un pattern di consumo del feed

L'Activity Feed supporta due pattern di consumo: il polling periodico a finestre delimitato da created_at.gte e created_at.lt, e le letture incrementali guidate da cursore che persistono un cursore da una risposta e lo passano nella richiesta successiva. Entrambi restituiscono oggetti Activity identici; la differenza è lo stato che il tuo client persiste tra le chiamate.

Entrambi i pattern condividono questi vincoli:

• Le attività sono interrogabili entro 1 minuto dal loro verificarsi e vengono conservate per 6 anni.
• Il limit massimo per ogni pagina è 5.000.
• I valori del cursore sono stringhe opache che non devi analizzare.
• Le richieste sono limitate a 600 al minuto per organizzazione padre, condivise tra ogni chiave, ogni organizzazione collegata e ogni endpoint /v1/compliance/*; consulta 429 Too Many Requests per gli header di risposta e il contratto di retry.



Polling a finestre

Imposta created_at.lt ad almeno 1 minuto nel passato in modo che ogni attività nella finestra sia già interrogabile. Usa created_at.gte per il limite inferiore e created_at.lt per il limite superiore in modo che le finestre consecutive si affianchino senza lacune o sovrapposizioni; riutilizza il valore lt della finestra precedente come valore gte della finestra successiva.

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"

Quando la risposta ha has_more: true, la finestra contiene più di una pagina di attività. Pagina all'interno della finestra passando il last_id della risposta come after_id nella richiesta successiva (fermandoti quando has_more è false), oppure scegli una finestra temporale più piccola. Consulta Pagina i risultati per il contratto completo.

Anche con un affiancamento pulito, un'attività che viene indicizzata dopo la chiusura della sua finestra non appare mai in una finestra successiva. Deduplica sull'id dell'attività e amplia ogni nuova finestra in modo che si sovrapponga alla precedente di qualche minuto, oppure esegui un passaggio periodico di riconciliazione che interroga nuovamente una finestra più vecchia.



Letture incrementali guidate da cursore

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"

Scorri le pagine finché has_more non è false, quindi persisti first_id dall'ultima risposta e passalo invariato come before_id nell'esecuzione successiva per recuperare le attività più recenti del cursore salvato. Per procedere nella direzione opposta per un backfill, persisti last_id e passalo invece come after_id. Per il riferimento completo cursore-vs-token-di-pagina e la semantica dei retry, consulta Pagina i risultati.

Un ciclo di recupero in produzione preleva le attività registrate dall'ultimo polling guidando l'iterazione tramite has_more e 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)

I cursori sopravvivono alla rotazione delle chiavi; consulta Gestisci e ruota le chiavi.



Correla con il tuo SIEM

Ogni Activity contiene campi che puoi unire agli eventi già presenti nel tuo SIEM (Splunk, Datadog, Microsoft Sentinel, Cribl o simili):

actor.user_id e actor.email_address sono presenti quando actor.type è user_actor; controlla il discriminatore prima di leggerli. user_id è un identificatore stabile e opaco per l'account utente: è coerente in ogni endpoint della Compliance API e in ogni payload di attività, e non cambia quando l'email o il nome visualizzato dell'utente cambiano. Usa user_id, non email_address, come chiave di join primaria.

Le chiamate alla Compliance API stessa emettono attività compliance_api_accessed. Ingerisci queste attività insieme agli altri tipi di attività in modo che il tuo SIEM registri chi ha interrogato i dati di conformità e quando. Passa activity_types[]=compliance_api_accessed per delimitare la query, quindi nel tuo client leggi actor.api_key_id da ogni attività il cui actor.type è api_actor per attribuire l'accesso a una specifica Compliance Access Key o chiave API Admin.



Pianifica la conservazione dei contenuti

Tre orizzonti di conservazione governano ciò che puoi recuperare in seguito:

Per come il resto della Claude Platform gestisce la conservazione, consulta API e conservazione dei dati.

Decidi tra esportazione-e-archiviazione e recupero on-demand tramite API come segue:

• Se il tuo orizzonte di legal hold o di audit supera i 6 anni per i metadati delle attività, esporta le pagine dell'Activity Feed nel tuo archivio man mano che le ingerisci.
• Se la tua policy di conservazione dei contenuti è più breve del tuo orizzonte di eDiscovery, esporta i contenuti di chat e file prima che la finestra di conservazione scada; la Compliance API non può restituire contenuti che la conservazione ha già rimosso.
• Se un flusso di lavoro potrebbe emettere un'eliminazione definitiva tramite la Compliance API (ad esempio, l'applicazione di policy DLP), recupera e archivia prima il contenuto di destinazione. Non esiste una finestra di recupero dopo un'eliminazione definitiva; le eliminazioni soft da claude.ai rimangono recuperabili con deleted_at popolato, ma le eliminazioni della Compliance API no.

In ogni altro caso, affidati al recupero diretto tramite API ed evita di mantenere una copia parallela.



Garanzie di consegna e completezza

Tratta l'Activity Feed come at-least-once: un attraversamento paginato correttamente restituisce ogni attività almeno una volta, ma un retry dopo un errore parziale può riconsegnare attività che hai già memorizzato. Deduplica sul campo id dell'attività.

Gli endpoint di elenco non restituiscono un campo total_count né un checksum. Per attestare che un'esecuzione di esportazione è completa, registra:

• Il cursore iniziale e il last_id terminale.
• Il numero di record esportati.
• Il timestamp dell'esecuzione e il request-id dell'ultima pagina.

Gli endpoint dei contenuti (chat, file, progetti e allegati dei progetti) servono solo dati di claude.ai; l'Activity Feed espone eventi amministrativi e di risorse a livello di organizzazione. La Compliance API non include:

• Testo dei prompt o risposte del modello dai carichi di lavoro di Claude Console o della Claude API.
• Contenuti rimossi dalla policy di conservazione della tua organizzazione.
• Contenuti eliminati definitivamente tramite la Compliance API.

Consulta le FAQ della Compliance API per maggiori informazioni su cosa la Compliance API acquisisce e cosa no.

Per la catena di custodia, memorizza i record esportati con metadati di provenienza: endpoint di origine, parametri della query, timestamp dell'esecuzione e un hash del contenuto di ogni record.



Prossimi passi