> ## Documentation Index
> Fetch the complete documentation index at: https://docs.zelinqa.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Authentification, idempotence et concurrence

> Protégez les clés et rendez chaque mutation sûre à rejouer.

## Authentification

```http theme={null}
Authorization: Bearer nbq_live_xxx
```

La clé détermine le tenant, le NBQ et les scopes. Les en-têtes `x-tenant-id`, `x-nbq-id` ou `x-scopes` envoyés par un client ne constituent jamais une identité fiable.

## Idempotency-Key

Toute mutation exige un identifiant unique :

```http theme={null}
Idempotency-Key: 6fc83f15-7f82-44e8-9f91-d06b6f380a62
```

* 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.

## 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`.

<Steps>
  <Step title="Relire">
    Appelez `GET /v1/sessions/{session_id}` après un conflit.
  </Step>

  <Step title="Réévaluer">
    Vérifiez que votre événement est encore pertinent sur le nouvel état.
  </Step>

  <Step title="Réessayer">
    Envoyez une nouvelle `Idempotency-Key` avec la nouvelle `state_version`.
  </Step>
</Steps>

<Warning>
  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.
</Warning>