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-03

  • 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).