# Stabilité et versions

Votre intégration doit pouvoir tourner des années sans être retouchée. C'est la règle que nous nous imposons.

## Notre engagement sur la v1

Dans `/api/v1`, nous pouvons seulement **ajouter** :

- un nouveau champ dans une réponse ;
- une nouvelle valeur dans une liste de référence (`document_types`, `final_checks`) ;
- un nouveau code d'erreur ;
- un nouveau paramètre facultatif ;
- une nouvelle route ou un nouvel évènement de webhook.

Nous ne ferons **jamais** dans la v1 : renommer ou retirer un champ, changer son type, changer le sens d'une valeur, retirer une valeur de `verdict` ou de `status`, déplacer une route, rendre obligatoire un paramètre facultatif.

## Ce que votre code doit accepter

- Des champs qu'il ne connaît pas : ignorez-les.
- Une valeur de `document_type` qu'il ne connaît pas : traitez-la comme `autre_document`.
- Un code d'erreur qu'il ne connaît pas : traitez-le selon son statut HTTP.

## Si une rupture devient nécessaire

Elle se fera dans une **nouvelle version** (`/api/v2`). La v1 restera servie pendant la transition, et son arrêt sera annoncé par e-mail aux comptes qui l'utilisent.

## Journal des versions

| Date | Changement |
|---|---|
| 2026-09-28 | Première version publique : envois (fichiers, archives, JSON base64, dossiers), vérifications, rapport PDF, suppression, compte, référentiels, webhooks signés, clés live et test. |
