Skip to main content

​
Authentification

La clé détermine l’organisation, le domaine et les scopes. N’envoyez pas d’en-têtes d’identité : l’API les déduit de la clé.

​
Idempotency-Key

Toute mutation exige un identifiant unique :
  • même clé + même corps : la réponse d’origine est rejouée ;
  • même clé + corps différent : 409 idempotency_key_reused ;
  • n’utilisez jamais la même clé pour deux intentions métier.
Conservez la même clé et le même corps lors d’un retry après timeout : vous récupérez le résultat du même appel sans créer un second tour. Pour une nouvelle action métier, générez une nouvelle clé. L’idempotence ne remplace pas le contrôle de concurrence par state_version.

​
state_version

Les mutations d’une session existante exigent la dernière state_version reçue. Si deux workers écrivent à partir de la même version, un seul réussit ; l’autre reçoit 409 state_version_conflict.
1

Relire

Appelez GET /v1/sessions/{session_id} après un conflit.
2

Réévaluer

Vérifiez que votre événement est encore pertinent sur le nouvel état.
3

Réessayer

Envoyez une nouvelle Idempotency-Key avec la nouvelle state_version.
Ne réessayez pas automatiquement une erreur de validation ou une réutilisation de clé avec un corps différent. Corrigez d’abord la requête.