Événements et requêtes

Un événement (Event, evt_…) dit ce qui s’est passé. Une requête (ApiRequest, req_…) dit ce que vous avez appelé. Ces deux journaux sont en ajout seul : rien ne s’y modifie.

Droits de clé : events:read et requests:read.

Je veux…

Je veux…	Appel
Lire la chronologie d’une facture	`GET /v1/events?object=clm_…`
Suivre un type	`GET /v1/events?type=claim.*`
Borner une période	`GET /v1/events?created[gte]=1793970000`
Trouver ce qu’une requête a produit	`GET /v1/events?request=req_…`
Relire un événement	`GET /v1/events/{id}`
Lister mes erreurs	`GET /v1/requests?status=4xx`
Relire un appel	`GET /v1/requests/{id}`

Forme d’un événement


{
  "id": "evt_…",
  "object": "event",
  "type": "claim.paid",
  "livemode": false,
  "created": 1793970000,
  "api_version": "2026-11-01",
  "request": "req_…",
  "data": {
    "object": { "id": "clm_…", "object": "claim", "status": "paid" },
    "previous_attributes": { "status": "acknowledged" }
  }
}

data.object porte l’objet, data.previous_attributes les champs changés et leur valeur d’avant. Un événement ne porte jamais de donnée de santé : pour le reste, relisez l’objet. Le catalogue donne la charge de chaque type.

Requêtes

GET /v1/requests rend les appels reçus avec une clé : méthode, chemin, statut, durée, clé utilisée et corps. Les données de santé y sont masquées. status accepte un code (404) ou une famille (4xx), key une clé, object l’identifiant d’un objet visé par le chemin.

Les actions du tableau de bord n’y laissent pas de trace : seules les clés d’API y paraissent.

Pièges

Les listes vont du plus récent au plus ancien, chronologie comprise.
Un événement est figé. api_version dit sous quelle version il a été produit.
Plusieurs événements peuvent venir d’une seule requête : un retour simulé traverse plusieurs états.
Un jeu d’événements n’est pas un état. Pour décider, relisez l’objet.