Progetta la tua integrazione di conformità

Un'integrazione di produzione della Compliance API richiede 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 di attività e contenuti. Queste scelte sono indipendenti dagli endpoint stessi; questa pagina ti aiuta a valutare i compromessi.

Questa pagina presuppone che tu abbia letto Interrogare l'Activity Feed, che definisce i parametri e il contratto di paginazione a cui si fa riferimento in tutto il documento, e Recuperare ed eliminare 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 "window polling" (polling periodico a finestre) delimitato da created_at.gte e created_at.lt, e le letture incrementali basate su cursore che persistono un cursore da una risposta e lo passano alla 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 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.

Window polling

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 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à. Puoi paginare all'interno della finestra passando il last_id della risposta come after_id nella richiesta successiva (fermandoti quando has_more è false), oppure scegliere una finestra temporale più piccola. Consulta Paginare 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 in base all'id dell'attività e amplia ogni nuova finestra in modo che si sovrapponga alla precedente di alcuni minuti, oppure esegui un passaggio di riconciliazione periodico che interroga nuovamente una finestra più vecchia.

Letture incrementali basate su 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"

Pagina fino a quando has_more è false, quindi persisti first_id dalla risposta finale 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 invece last_id e passalo come after_id. Per il riferimento completo su cursore vs page token e la semantica di retry, consulta Paginare i risultati.

Un ciclo di catch-up (recupero) di produzione recupera 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 Gestire e ruotare le chiavi.

Correla con il tuo SIEM

Ogni Activity contiene campi che puoi unire in join con 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; verifica 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. Acquisisci queste 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 limitare l'ambito della 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 Admin API.

Pianifica la conservazione dei contenuti

Tre orizzonti di conservazione determinano cosa 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 API on-demand come segue:

• Se il tuo orizzonte di legal hold o audit supera i 6 anni per i metadati delle attività, esporta le pagine dell'Activity Feed nel tuo archivio man mano che le acquisisci.
• 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 workflow potrebbe emettere un'eliminazione definitiva tramite la Compliance API (ad esempio, applicazione 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 tramite la 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

Considera l'Activity Feed come at-least-once (almeno una volta): un attraversamento correttamente paginato restituisce ogni attività almeno una volta, ma un retry dopo un fallimento parziale può riconsegnare attività che hai già memorizzato. Deduplica in base al campo id dell'attività.

Gli endpoint di elenco non restituiscono un campo total_count o 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 della pagina finale.

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

• Testo dei prompt o risposte del modello da workload di Claude Console o 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 cattura e cosa no.

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

Passaggi successivi