1
Créer la session
POST /v1/sessions crée un session_id et renvoie versions.state_version: 0. La session est attachée à la configuration publiée active.2
Demander une première question
POST /v1/sessions/{session_id}/next avec state_version: 0 renvoie une décision et des candidats ordonnés.3
Envoyer le tour suivant
Renvoyez la nouvelle
state_version et, si vous les avez, decision_id, question_id, le texte réellement posé et la réponse du visiteur.4
Appliquer des informations externes
/events ajoute un résumé, des messages manqués ou une donnée connue du CRM sans sélectionner immédiatement une question.5
Lire ou reprendre
GET /v1/sessions/{session_id} restitue l’état public. Vous pouvez reprendre après une interruption avec la dernière state_version.6
Déclarer le résultat
/feedback enregistre un succès, un échec ou une autre issue métier. Il remplace la notion limitée de « conversion » de la bêta 0.9.Deux identifiants à conserver
decision_id et question_id améliorent la corrélation du tour, mais restent optionnels : NBQ peut retrouver la décision en attente à partir des messages observés.
Arrêts souples
max_turns est une limite souple. Lorsque cette limite est atteinte, NBQ peut encore retourner la meilleure question disponible avec un avertissement. Votre application décide alors de continuer ou d’arrêter. action: stop signifie qu’aucune question identifiable n’est disponible.