Référence

Journal des modifications

Modifications notables de l'API AYETO.

Afficher en Markdown

Les modifications qui concernent les clients de l'API sont listées ici, des plus récentes aux plus anciennes. Les ajouts qui ne changent pas le comportement existant (un nouveau champ facultatif, un nouvel endpoint) sont listés aussi, pour que vous voyiez ce qui est devenu disponible.

2026-10-06

  • Le catalogue des modèles (/ai_model/get_all) a un nouveau champ is_recommended : les modèles recommandés par les administrateurs.
  • Le stream du chat avec runner_version "2" a une nouvelle phase de statut conversation_named (data.name) : une nouvelle conversation est nommée d'après son premier message pendant la génération de la première réponse, et non plus après. Le nom est enregistré quand l'événement arrive.
  • find et count refusent avec 422 les filters et le sort_key portant sur des champs internes stockés avec un enregistrement (par exemple des secrets) ; auparavant, de telles conditions étaient acceptées.

2026-10-05

  • Les conversations ont deux nouveaux champs, booster_panel_id et panel_user_id : conversations des utilisateurs connectés de vos panneaux booster avec vos assistants. /conversation/find les renvoie avec vos autres conversations (filtrez-les avec ["panel_user_id", "==", null]) ; /chat répond 403 pour elles, seul l'utilisateur du panneau les poursuit.
  • Les enregistrements de la base de données booster ont un nouveau champ owner (UUID ou null) : l'utilisateur du panneau qui a créé l'enregistrement, sur les panneaux avec des comptes utilisateurs. find et count acceptent owner dans les filtres et comme sort_key. Les enregistrements créés via l'API ont owner: null. Quand un compte utilisateur du panneau est supprimé définitivement, les enregistrements qu'il a créés le sont aussi.
  • Les règles de collection ont deux nouveaux niveaux, user et owner. Comme les autres niveaux sauf none, ils autorisent les requêtes faites via l'API, sur tous les enregistrements.
  • POST /ai_model/get_all peut renvoyer des modèles du nouveau type google_video_gen (génération de vidéos). Les vidéos générées dans le chat sont listées dans attachments de la réponse, comme les images générées.
  • Dans le chat via l'API, les actions d'outils que l'application AYETO fait confirmer par l'utilisateur dans le chat (par exemple la création d'un panneau booster ou d'un workflow depuis le chat) sont refusées : l'appel d'outil se termine par une erreur et le modèle poursuit sa réponse.
  • POST /ai_tool/get_all renvoie deux outils de plus, BoosterStudioStartFunctionTool (crée un panneau booster à partir d'un modèle) et WorkflowStudioStartFunctionTool (crée un workflow). Vous pouvez les donner à vos assistants ; ils demandent la confirmation de l'utilisateur dans le chat de l'application AYETO, donc dans le chat via l'API ils sont refusés comme décrit ci-dessus.
  • Nouvellement documenté : POST /booster/panel/info, qui renvoie le nom d'un panneau, son organisation et l'utilisateur de la clé, et vérifie l'accès au panneau. L'endpoint lui-même ne change pas.

2026-10-04

  • Les outils renvoyés par POST /ai_tool/get_all ont un nouveau champ companion_of_groups (tableau de noms de groupes) : comme companion_of_group, pour un outil d'aide qui accompagne plusieurs groupes.

2026-10-03

  • Les outils renvoyés par POST /ai_tool/get_all ont deux nouveaux champs : vision (l'outil montre des images au modèle et n'est proposé qu'avec les modèles qui voient les images) et outbound (l'outil peut envoyer des données hors d'AYETO, par exemple des requêtes web ou des e-mails).
  • Les requêtes de liste mal formées sont refusées avec 422 et un detail explicite au lieu de 500 : une condition qui n'a pas 3 ou 4 éléments, un élément de filters qui n'est ni un tableau ni un objet, un objet de groupe sans clé ou avec plusieurs clés, un groupe AND / OR dont la valeur n'est pas un tableau non vide, des groupes imbriqués sur plus de 32 niveaux, un limit_from négatif et un limit_to inférieur à limit_from.
  • Les réponses 429 du limiteur de débit ont le corps {"detail": "Too many requests"} comme toutes les autres erreurs (la clé reason a disparu) ; Retry-After est inchangé.
  • Une portée de clé API manquante reçoit partout la réponse 401 API key is invalid.
  • Les endpoints .../get et .../delete acceptent aussi l'identifiant dans un corps JSON {"id": "<uuid>"} ; le paramètre de requête entity_id fonctionne toujours. L'absence des deux, ou deux identifiants différents, donne 422. Un corps qui leur est envoyé doit être du JSON.
  • Nouveaux POST /user_credit/get_self et POST /version (GET fonctionne toujours et partage la limite de débit) ; /version est limité au niveau statique (1 200 requêtes par minute).
  • POST /ai_tool/get_all ne renvoie plus les outils masqués ou obsolètes.
  • Nouveau POST /conversation/count (portée ayeto.conversation, même corps que /conversation/find).
  • Le coût d'une conversation (POST /usage/cost/conversation) est la somme des crédits réellement débités, et non un recalcul aux prix actuels ; il inclut les tokens texte des modèles d'image et n'échoue plus avec 404 pour les modèles supprimés depuis.
  • Le chat avec un modèle qui ne peut pas streamer enregistre la réponse et la renvoie (auparavant, la réponse était perdue et la réponse HTTP renvoyait le message de l'utilisateur).
  • Les pièces jointes du chat sont vérifiées et enregistrées avant toute autre chose : une pièce jointe refusée avec 422 (file is too large, un quota de stockage, des données invalides) ne laisse plus derrière elle le message de l'utilisateur. Un base64 mal formé renvoie 422 invalid base64 data in attachment '<filename>' (ou invalid data URI in attachment '<filename>') au lieu de 500. Le champ size des pièces jointes n'est plus obligatoire et est ignoré.
  • Un message de suite dans une conversation créée dans une organisation s'exécute dans cette organisation lorsque la requête n'en indique aucune (facturé là, appartenance requise) ; indiquer une autre organisation renvoie 422 the conversation belongs to another organization. La conversation d'un autre utilisateur est refusée avec 403 avant l'enregistrement de toute pièce jointe.
  • Le stream structuré du chat (runner_version "2") n'envoie plus le champ inutilisé iteration.
  • Base de données booster : créer un enregistrement avec une clé qui existe déjà renvoie 422 a record with key '<key>' already exists au lieu de 500 ; limit_from sans limit_to renvoie jusqu'à 100 enregistrements à partir de limit_from (limit_from doit être inférieur à 1000) ; les filtres AND / OR mal formés renvoient 422 au lieu de 500.
  • Conversion de fichier en texte : les types de fichiers non pris en charge renvoient 422 unsupported file type '<mime>' et ne sont pas facturés.
  • Workflows : un fichier désigné par son identifiant dans l'entrée d'une exécution reste celui de l'utilisateur et n'est plus supprimé avec l'exécution (les fichiers envoyés en base64 appartiennent toujours à l'exécution).

2026-10-02

  • Les règles de collection de la base de données booster ne s'appliquent qu'aux panneaux en mode base de données publique ; en mode privé, elles sont ignorées. Les utilisateurs avec qui un panneau est partagé en lecture seule peuvent désormais écrire ses enregistrements et prendre des verrous (dans les deux modes).
  • POST /tts/mp3 exige la nouvelle portée ayeto.tts et POST /data-loader/load la nouvelle portée ayeto.data_loader. Les clés API existantes ont reçu les deux portées ; les clés créées par l'association d'un client de bureau (ayeto.connector uniquement) ne peuvent plus appeler ces endpoints.
  • POST /tts/mp3 et POST /data-loader/load acceptent un organization_id facultatif : la requête s'exécute dans l'organisation et est facturée sur le crédit de l'utilisateur dans celle-ci (administrateurs et membres uniquement ; les invités et les non-membres reçoivent 403).
  • POST /tts/mp3 renvoie 422 avec not enough user credit / not enough organization credit lorsque le crédit est épuisé, au lieu de 500 Failed to generate audio.
  • Le chat refuse un modèle désactivé par les administrateurs (demandé directement ou comme modèle de l'assistant) avec 422 model is disabled, et un modèle automatique sans modèle disponible avec 422 model is not available ; model is deprecated est renvoyé avant que la conversation ne soit modifiée.
  • Lire la conversation d'un autre utilisateur avec /conversation/get (refusé avec 404) ne met plus à jour son champ accessed.
  • L'en-tête language d'une requête API ne change plus la langue préférée de l'utilisateur dans l'application AYETO (auparavant, chaque requête l'enregistrait, et une requête sans l'en-tête la remettait en anglais).
  • POST /assistant/avatar/get accepte les clés API avec la nouvelle portée ayeto.assistant, qui peut désormais être sélectionnée lors de la création d'une clé (elle couvre aussi /assistant/find).
  • Nouvelle documentation de l'API v3, qui remplace les notes bêta précédentes.
  • Les workflows sont disponibles dans l'API : lecture, exécution, exécutions en streaming, approbations, modification, publication, export et import (ayeto.workflow, ayeto.workflow.write).
  • API privée de la base de données booster avec ses propres portées (ayeto.booster.database, ayeto.booster.database.write).