Changelog

Ce changelog suit les changements qui affectent les intégrations : l'API publique, les canaux, l'authentification et la compatibilité. Pour les changements produit côté administrateur, voir les Notes de version Admin.

2026-10-01 - Une seule route d'écriture publique et des limites par canal

Modifications incompatibles

• /execute est la seule route d'écriture du canal API. POST /public/v1/api/conversations et POST /public/v1/api/conversations/{session_id}/messages sont supprimées. Utilisez POST /public/v1/api/execute pour démarrer, poursuivre ou répondre à un nœud Question. Les routes GET restent disponibles.
• L'exécution utilise session_id. Les requêtes et réponses JSON ainsi que l'événement SSE data-run utilisent session_id avec run_id ; remplacez conversation_id dans les clients du canal API. Les fichiers utilisent désormais GET /public/v1/api/execute/{session_id}/artifacts/{artifact_id}.
• 429 utilise l'enveloppe d'erreur standard avec error.code: "rate_limit_exceeded" et Retry-After, au lieu de {"detail":"Too many requests"}.

Ajouts

• Limites par canal pour API et Webchat (3000/minute par défaut), et par IP pour les clés publiques (60/minute par défaut ; 0 pour désactiver). Les clés serveur n'utilisent pas la sous-limite par IP. Voir Limitation de débit.

2026-09-25 - Fichiers générés et durcissement des accès publics

Ajouté

• Téléchargement des fichiers générés (désormais lié à la session ; voir le changement du 2026-10-01) : les fichiers sont conservés 1 heure. Voir Fichiers générés.
• Guide Intégrer le widget webchat.

Modifié (cassant)

• GET /public/v1/api/conversations exige une clé serveur. Une clé nx_pub_ reçoit 403 server_key_required : une clé publique, extractible d'une application, ne peut plus énumérer ni rechercher les conversations du canal. La lecture d'une conversation connue (résumé, historique) reste possible.
• Suppression de GET /public/livechat/conversations/{id} et POST /public/livechat/conversations/{id}/abandon. Ces routes non documentées n'exigeaient aucune authentification et n'étaient utilisées par aucun client.
• Messages d'erreur internes génériques. Les erreurs execution_failed et les événements SSE error imprévus ne renvoient plus le texte brut de l'exception (Flow execution failed, HITL resume failed, Execution failed). Utilisez X-Request-ID pour le support.

Corrigé (documentation)

• missing_api_key n'est jamais renvoyé : une clé absente produit 401 invalid_api_key. La clé d'un canal non-API sur /execute produit 403 http_error, pas wrong_channel_type.
• Une reprise inter-canal (même tenant) retourne 403 conversation_forbidden, pas 404.
• Le champ error de premier niveau vaut toujours null dans une réponse 200 ; l'échec se lit dans status et output.error.
• Nouvelles sections : version du flow exécutée, réponse à un nœud Question, codes payload_validation_error, files_not_enabled, no_published_version, limitation de débit et 429, contrat complet de l'API Widget.

2026-09 - Contrat de payload structuré du canal API

Modifié (cassant)

• payload est maintenant un objet JSON. Il est optionnel et vaut {} par défaut. La clé réservée user_message fournit l'entrée conversationnelle lorsque le flow l'attend ; toutes les autres clés deviennent des variables de flow, comme {{ candidate_name }}.
• Les metadata au niveau de la requête sont supprimées. Placez plutôt les entrées d'exécution personnalisées dans payload. Les métadonnées de réponse sous output.metadata restent inchangées.
• La validation du schéma est conditionnelle. Lorsqu'un schéma de payload est configuré sur le canal, l'objet est validé par rapport à ce schéma. Sans schéma configuré, les champs du payload sont transmis tels quels.
• Les requêtes JSON et multipart utilisent le même contrat de payload. Pour multipart/form-data, envoyez l'objet payload encodé en JSON dans la partie payload ; les fichiers restent des parties séparées.

2026-08-24 - Fiabilisation du canal API

Modifié

• La sélection du transport est explicite. POST /public/v1/api/execute utilise maintenant le HTTP JSON ordinaire par défaut ; ?stream=true sélectionne le SSE et ?stream=false le JSON de façon autoritaire. Le champ historique du corps reste compatible uniquement si le paramètre de requête est omis.
• La sortie assistant repose sur les publications. output.messages[] a maintenant la forme stable {id, role: "assistant", content}. Le même identifiant logique est utilisé par les blocs de publication SSE et le publication_id de l'historique automation ; les contenus identiques ne sont pas dédupliqués.
• L'attente livechat conserve le flux SSE ouvert. WAITING_HUMAN émet immédiatement data-status, envoie des commentaires keepalive et livre l'automatisation reprise sur la même connexion. La déconnexion arrête l'observation sans annuler l'exécution.
• L'envoi d'un message de conversation était une commande. Cette route de compatibilité a été supprimée le 2026-10-01 ; utilisez désormais /execute.

Ajouté

• Gestion persistée de Idempotency-Key pour /execute et les commandes de message, avec rejeu des publications SSE terminées, récupération des requêtes abandonnées et réponses 409 idempotency_conflict / idempotency_in_progress. Cette gestion déduplique l'opération API nAIxus ; elle ne rend pas exactly-once les effets arbitraires produits par les outils ou le code en aval.
• Diagnostics publics cohérents. Le CORS navigateur accepte Idempotency-Key, X-Request-ID et les en-têtes de signature, et expose X-Request-ID ; les réponses 500 non gérées utilisent l'enveloppe stable internal_error.
• Historique fusionné chronologiquement. L'automatisation, le livechat et l'automatisation reprise sont ordonnés avant l'attribution finale de turn_index ; l'historique automation peut inclure un publication_id nullable.

Disponibilité

• L'implémentation du fournisseur OpenAI a été corrigée mais reste désactivée jusqu'à activation explicite. Cette entrée n'annonce pas sa disponibilité.

2026-08 - nAIxus v2 (canary)

Modifié (cassant)

• Le champ origin: "agent" des messages devient origin: "automation". GET .../conversations/{session_id}/messages utilisait auparavant "agent" pour les messages produits par le moteur d'automatisation/process (un nœud AI Agent, un nœud Direct Message, ou tout autre nœud émetteur de message), ce qui entrait en collision avec le sens distinct de sender: "agent" côté Livechat (un opérateur humain Livechat). Mettez à jour toute intégration qui teste origin === "agent" pour tester origin === "automation".
• run_id est maintenant nullable. POST /public/v1/api/execute et GET .../conversations/{session_id}/messages (via le champ run_id des messages d'origine automation) retournent maintenant run_id: null au lieu de la chaîne vide "" lorsqu'aucune exécution automation n'a été créée pour la réponse (par ex. un court-circuit Livechat). Une chaîne vide n'est pas un UUID valide ; null représente fidèlement « aucune exécution ».

Corrigé

• GET .../conversations/{session_id}/messages retourne maintenant 404 pour un session_id qui n'a jamais existé, avec la même réponse non énumérante que pour les tentatives cross-tenant/cross-canal (aujourd'hui {"error":{"code":"http_error","message":"No conversation found for session ..."}}). Retournait auparavant 200 avec un tableau messages vide, ce qui ne correspondait pas au comportement documenté dans cette référence.
• Les erreurs de validation 422 publiques utilisent l'enveloppe d'erreur standard. Les requêtes rejetées par la validation du corps sur /public/v1/api/conversations/* retournent maintenant {"error": {"code": "validation_error", "message": "..."}} comme toute autre erreur de l'API publique, au lieu d'une forme brute {"detail": [...]}.
• Les flux SSE du canal API préservent maintenant les limites de publication. Si un flow produit plusieurs publications assistant, chaque publication possède un bloc indépendant text-start / text-delta* / text-end, identifié par son identifiant stable de publication. Aucun delta synthétique de ligne vide n'est inséré. Voir Recevoir les réponses en SSE.
• Les conversations utilisant un nœud AI Agent n'accumulent plus d'entrées d'historique dupliquées. La récupération de l'historique via GET .../messages sur une conversation multi-tour pouvait auparavant retourner plusieurs fois les mêmes messages assistant/tool à mesure que la conversation grandissait ; chaque tour est maintenant enregistré exactement une fois.
• Un nœud AI Agent avec Send response to channel désactivé ne fuit plus dans l'historique de conversation. Sa réponse est toujours générée et disponible pour les nœuds en aval, mais n'apparaît plus dans GET .../messages ni dans output.messages[] du seul fait que le nœud a produit du texte - seul un message réellement publié le fait désormais.

Ajouté

• En-tête de réponse X-Request-ID sur chaque réponse de l'API publique - succès, 4xx et 5xx, JSON ou SSE. Renvoie l'en-tête X-Request-ID fourni par l'appelant s'il est présent et au format attendu, sinon en génère un nouveau. Voir la référence d'API.

2026-07 - nAIxus v2 (canary)

Ajouté

• Canal API - POST /public/v1/api/execute pour l'exécution de flow serveur à serveur et depuis le navigateur. La clé d'API identifie de façon unique le tenant et le canal (pas d'identifiant de canal dans l'URL). Supporte les réponses JSON et le streaming SSE inline avec le protocole Vercel AI SDK UI Message Stream.
• Préflighting CORS - OPTIONS /public/v1/api/execute retourne les en-têtes autorisés fixes sans nécessiter de token Bearer.
• Identifiants des conversations multi-tours - les identifiants d'exécution et de session ont été ajoutés aux réponses JSON et à data-run (renommés session_id le 2026-10-01).
• Signature HMAC des requêtes - mode require_signature optionnel par canal avec en-tête X-Naixus-Signature: t=<ts>,v1=<hex> (HMAC-SHA256, tolérance ±300 s).
• Champ historique stream du corps - introduit comme sélecteur de transport au niveau de la requête. Il reste rétrocompatible lorsque le paramètre de requête est omis ; les règles de priorité actuelles sont documentées dans l'entrée du 24 août 2026.
• Points d'accès de cycle de vie du secret de signature - POST /api/v1/channels/{id}/rotate-signing-secret, activer/désactiver via PATCH /api/v1/channels/{id}.
• Point d'accès de rotation de clé d'API - POST /api/v1/channels/{id}/rotate-key.
• API Widget - GET /public/widget/config et POST /public/widget/chat en streaming pour les widgets navigateur utilisant des clés publiques nx_pub_ avec contrôle des origines autorisées.

Authentification

• Clés d'API Bearer par canal : nx_live_ (production), nx_test_ (hors production), nx_pub_ (clients navigateur/natifs publics).
• Les clés sont limitées par canal ; une clé du canal A ne peut pas exécuter le canal B.
• Application de l'environnement : les clés nx_live_ fonctionnent uniquement sur les canaux de production ; les clés nx_test_ uniquement sur les canaux dev/staging.
• Les clés publiques appliquent une liste d'origines autorisées configurée par canal.

Notes de compatibilité

• Les points d'accès d'administration (flows, tenants, secrets, gestion des canaux) sont internes et ne font pas partie du contrat d'intégration public.
• Les seuils de limitation de débit et la pagination ne font pas encore partie du contrat public vérifié ; ne dépendez pas de valeurs précises.