> For the complete documentation index, see [llms.txt](https://boundaryai.gitbook.io/boundaryai-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://boundaryai.gitbook.io/boundaryai-docs/boundaryai-docs-fr/api-et-webhooks/changelog.md).

# Journal des modifications de l'API

Ce qui a changé dans l'API, et ce que nous promettons en matière de compatibilité.

La surface de l’API est versionnée (la version actuelle se trouve dans la `info.version` et servie à `/api/v1/openapi.json`). Cette page suit les changements du contrat sur le fil et énonce les règles de compatibilité sur lesquelles votre intégration peut s’appuyer.

***

### Promesse de compatibilité

Nous appliquons le versionnement sémantique à la surface de l’API :

* **Spécialité** Les changements (cassants) déplacent le préfixe d’URL (`/api/v1/` à `/api/v2/`) et sont précédés de `Dépréciation : true` + `Sunset : <date>` dans les en-têtes des anciens endpoints pendant au moins un cycle de publication complet. Aucun n’a encore eu lieu.
* **Mineur** Les changements sont des ajouts compatibles ascendante : nouveaux endpoints, nouveaux champs de requête facultatifs, nouveaux champs de réponse, nouveaux événements webhook.
* **Correctif** Les changements ne sont que des clarifications.

Ce que nous ne ferons jamais sans version majeure : supprimer ou renommer un champ ou une opération, restreindre le type d’un champ, modifier un code de statut de succès, ou réduire un enum.

**Ce que votre client doit faire :** ignorer les champs de réponse inconnus, tolérer les nouveaux types d’événements webhook, et considérer les `code` valeurs (et non les messages) comme le contrat lisible par machine.

{% hint style="info" %}
**À propos des `Deprecation` et `Sunset` en-têtes que vous voyez aujourd’hui.** Chaque réponse 2xx de l’Input API les contient actuellement. Ils annoncent la **migration de l’enveloppe de réponse** uniquement : à la date de fin de vie, les charges utiles de succès passent de la forme brute montrée dans les exemples à la `{"data": ...}` enveloppe déclarée par les schémas. Aucun endpoint n’est déprécié. Lisez la charge utile à partir de `data` lorsque cette clé est présente, et à partir de la racine sinon, et votre client fonctionne correctement des deux côtés du basculement.
{% endhint %}

***

### Septembre 2026 : hôte publié, push groupé synchrone

* **La référence nomme désormais l’hôte qui sert l’Input API.** Chaque opération de l’Input API porte `https://boundaryai-ingest-279197672085.europe-west9.run.app` comme serveur. L’hôte du tableau de bord (`app.*`) sert l’application web et répond aux chemins API avec une page HTML et HTTP 200 ; les clients générés à partir de la référence précédente analysaient cette page comme un corps de succès. Régénérez à partir de la référence actuelle, ou pointez votre URL de base vers l’hôte d’ingestion. Les deux vocabulaires et toutes les routes sont inchangés.
* **Push groupé synchrone.** `POST /feedback/push/bulk` (et `/content/push/bulk`) accepte `"sync": true` et renvoie le résultat terminé avec **200** au lieu d’un identifiant de tâche avec 202, pour des lots allant jusqu’à 50 éléments répartis sur jusqu’à 20 champs. Chaque ligne doit comporter un `external_id` (`SYNC_REQUIRES_EXTERNAL_ID`, 400) ; les lots plus volumineux et les périodes de forte charge retombent sur le chemin asynchrone 202. Un lot dans lequel aucun champ n’a accepté quoi que ce soit renvoie 400 `PUSH_FAILED` ; un lot qui dépasse son budget de 60 secondes renvoie 504 `SYNC_PUSH_TIMEOUT`. Voir [Envoi des retours](/boundaryai-docs/boundaryai-docs-fr/api-et-webhooks/pushing-feedback.md).
* `source_reference` sur les pushes groupés est désormais stocké sur chaque ligne (il était validé puis supprimé ; les pushes unitaires n’étaient pas affectés).
* `GET /me` a gagné `org_name`, le libellé lisible par l’humain de l’organisation à laquelle appartient la clé.
* **Serveur MCP** : un septième outil, `get_theme_verbatims`, lit les commentaires derrière un thème groupé ; et les utilisateurs de Claude ou ChatGPT peuvent se connecter en s’authentifiant depuis l’assistant, avec approbation par connexion, au lieu de manipuler une clé. Voir [Connecter les assistants IA](/boundaryai-docs/boundaryai-docs-fr/api-et-webhooks/mcp.md).

### 1.3.1 : lecture de l’analyse pour les groupes suivis dans le temps (septembre 2026, correction de comportement)

Aucun changement de schéma ; `analysis_id` était toujours nullable. `GET /sources/{id}/analysis` pour une source dont le groupe de feedback suit les retours dans le temps renvoyait auparavant `analysis_status: "none"` avec des valeurs entièrement nulles même lorsque chaque période était analysée, car une telle source n’a pas une seule exécution globale. Elle renvoie désormais `analysis_status: "available"` avec la répartition des sentiments et les thèmes agrégés sur chaque période analysée (le même corpus que la vue Globale du tableau de bord) et `analysis_id: null`. Les clients qui se basent sur « cette source est-elle analysée » sur `analysis_id` doivent se baser sur `analysis_status`, le contrat documenté depuis 1.1.0. Le MCP `list_themes` outil lit lui aussi désormais le groupement affiché par le tableau de bord et accepte un `period_key`.

### 1.3.0 : ajouts aux études qualitatives (août 2026)

Changements additifs apportés à l’API des études qualitatives (analyse d’entretiens) utilisée par le workflow qualitatif propre à la plateforme : exécutions avec transcription uniquement, et `.txt` / `.docx` des téléversements de transcriptions en plus des enregistrements. Cette surface ne fait pas partie de la référence d’intégration publiée ; l’Input API, les invitations et les webhooks sont inchangés dans cette version.

### 1.2.1 : corrections d’audit pour les intégrateurs (juillet 2026, correctif)

Un audit à froid de l’intégrateur par rapport à la référence publique. Aucune forme d’endpoint n’a changé ; chaque élément corrige soit la référence pour correspondre au fil, soit un comportement qui violait le contrat documenté.

Corrections de comportement :

* **Les fenêtres de limitation de débit sont fixes**, ancrées à la première requête. Auparavant, chaque requête, y compris celles rejetées, prolongeait la fenêtre, si bien qu’un client interrogeant plus vite que la fenêtre ne s’en remettait jamais ; `Retry-After` est désormais exact.
* **Conflits d’idempotence (409)** sur les routes à clé API utilisent l’enveloppe d’erreur de l’Input API.
* **Les erreurs de validation sur les routes recommandées** emploient le vocabulaire recommandé (`champ`, et non le classique `question`).
* **`numérique` valeurs dans `GET /feedback`** sont des nombres JSON (ils étaient sérialisés en chaînes) ; le contenu numérique non fini est rejeté à l’ingestion.

Corrections de la référence : exemples de requête et de réponse pour chaque opération ; chaque opération d’écriture précise l’autorisation de clé qu’elle requiert ; les `progression` documentée comme un pourcentage (0-100) ; les réponses de push documentent `rows_accepted` et les identifiants de groupe/source, avec `aps_deducted` comme alias hérité ; `GET /me` les crédits entièrement typés ; le catalogue de webhooks à 9 événements avec des schémas de charge utile ; la note de migration d’enveloppe ci-dessus.

### 1.2.0 : distribution des invitations d’enquête (juillet 2026)

Déclenchez depuis l’API des e-mails d’invitation à l’enquête personnalisés, en utilisant le modèle conçu dans la plateforme.

* `GET /sources/{id}/invite-template` : présence du modèle, variables, état du domaine d’expédition, utilisation du quota.
* `POST /sources/{id}/invites` : envoi transactionnel, de 1 à 1 000 destinataires par appel, avec par destinataire `variables`, `dry_run` aperçus, et un `renvoi` désactivation du comportement par défaut de ne jamais inviter deux fois.
* `GET /invites/{id}` et `/invites/{id}/recipients` : statut de distribution et résultats par destinataire, y compris le statut de livraison.
* Nouveau **`send` autorisation de clé** ; les envois via l’API exigent le propre domaine d’expédition vérifié de votre organisation.
* Nouveaux événements webhook : `invites.completed`, `invite.bounced`.

### 1.1.0 : série d’améliorations de l’Input API (juillet 2026)

* **Vocabulaire recommandé** : l’API parle désormais `feedback_group` / `source` / `champ` aux côtés de l’original `survey_series` / `survey` / `question`. Mêmes handlers, les deux ensembles de clés sont acceptés ; les routes classiques sont inchangées et non dépréciées. Voir [Concepts et nomenclature](/boundaryai-docs/boundaryai-docs-fr/api-et-webhooks/concepts-and-naming.md).
* **Éléments de contenu structurés** sur push : `{text, external_id, customer_id, channel, language, rating, occurred_at}`. `external_id` déduplique les pushes réessayés ; `occurred_at` attribue rétroactivement les éléments à la bonne période de suivi.
* **Lecture de l’analyse** via `GET /sources/{id}/analysis` : répartition des sentiments, thèmes, correspondances de surveillance.
* **Nouveaux événements webhook**: `analysis.completed`, `flag.raised`, `report.ready`.
* **Contrôles des données**: `POST /feedback/erase` (effacement en masse par `external_id` ou `customer_id`), `GET /feedback` (listage par curseur des éléments poussés via l’API), `POST /feedback/upload` (ingestion asynchrone CSV/XLSX), `GET /me` (introspection de clé).
* `feedback_type` à la création de la source (`survey`, `call_transcript`, `app_review`, `support_ticket`, `chat`, `e-mail`, `social_media`, `review`, `other`).
* Les listes sont devenues paginées (`limit` 50 par défaut, 200 maximum, avec un `pagination` écho) ; une source peut comporter jusqu’à 100 champs par appel de création.

### 1.0.0 : première spécification publique (mai 2026)

Première description OpenAPI 3.1 publiée de la surface d’intégration : push de contenu (unitaire + groupé), création et publication de groupes/sources/champs, authentification par clé API avec autorisations à portée, clés d’idempotence, pagination par curseur, en-têtes de limitation de débit, et les quatre premiers événements webhook (`content.pushed`, `series.created`, `survey.created`, `survey.published`) avec des livraisons signées.