Jev API n8n : appeler l'API REST sans Worker

Appeler Jev depuis n8n ou Make sans passer par un Worker : le principe

Sur Cloudflare Workers AI, le modèle typesafe/jev se déclare le plus souvent dans un Worker : un fichier de configuration, un binding AI, du code déployé. C'est la voie mise en avant dans notre guide d'implémentation Worker.

Ce que fait un Worker aujourd'hui

Un Worker reçoit une requête, appelle env.AI.run avec l'identifiant typesafe/jev, lit la réponse et déclenche une action. Il porte à la fois le code d'appel et la logique métier qui suit.

Ce que l'appel direct change concrètement

La même fiche modèle documente un second chemin : un appel REST classique, avec le compte Cloudflare comme seule dépendance. n8n et Make savent tous deux poser un appel HTTP authentifié. Aucun Worker à écrire ni à déployer : le scénario existant reçoit un nœud ou un module de plus.

Ce guide ne part pas d'un formulaire précis. Il documente l'appel générique : un scénario qui reçoit un ticket, un email ou un enregistrement CRM le pose de la même façon, quel que soit le déclencheur en amont.

Authentification : la clé API Cloudflare, sans compte TypeSafe

Le modèle typesafe/jev est un modèle tiers routé par Cloudflare. Aucune inscription chez TypeSafe AI n'est nécessaire : un compte Cloudflare avec Workers AI activé suffit, avec un identifiant de compte et un jeton API.

Ce jeton se crée dans le tableau de bord, rubrique Workers AI, page « Use REST API ». Il porte les permissions Workers AI - Read et Workers AI - Edit. Il s'utilise ensuite dans l'en-tête Authorization, sous la forme Bearer suivi du jeton.

Un jeton porte les mêmes droits que celui utilisé dans un Worker : le stocker en clair dans un scénario partagé revient à l'exposer à toute l'équipe qui y a accès. n8n et Make proposent chacun un emplacement dédié pour ce type de secret, séparé du corps de la requête.

Le corps de la requête : state et questions typées, identiques au Worker

L'endpoint REST attend un corps JSON avec deux clés : model, qui vaut « typesafe/jev », et input. input porte lui-même state, le texte ou l'objet à évaluer, et questions, un objet de questions typées.

Trois types de question existent : noul pour une probabilité, choice pour une option parmi plusieurs, score pour une position sur une échelle. Chaque question porte des instructions et des critères. La fiche Cloudflare fournit un exemple complet, repris ci-dessous sans modification.

Le state accepte aussi un objet plutôt qu'une chaîne, quand la décision dépend de plusieurs sources : un message, une commande, une règle interne. Les instructions des questions peuvent alors désigner les champs de cet objet, comme le montre l'exemple structuré de notre guide Worker.

Les critères d'une question choice ou score gagnent à rester courts et mutuellement exclusifs. Une consigne floue ou deux catégories qui se recoupent produisent des probabilités difficiles à trancher ensuite dans le scénario.

Lire la réponse : l'enveloppe Cloudflare et les réponses de Jev

Comme tout appel à l'API REST Cloudflare, la réponse arrive dans une enveloppe commune : un champ result, un champ success à true ou false, et des tableaux errors et messages.

Le contenu utile de Jev se trouve dans result : le nom du modèle, un objet answers avec une entrée par question posée, et un champ usage qui compte les tokens consommés. Un scénario n8n ou Make doit descendre dans result avant de lire les réponses.

Un scénario n8n peut brancher sur result.answers.department.choice avec un nœud Switch, ou sur result.answers.is_urgent.noul avec un nœud If. Dans Make, un module Router lit les mêmes champs dans le corps renvoyé par le module HTTP.

Le champ confidence, présent sur les questions choice et score, indique la certitude du modèle sur sa réponse. Une valeur basse signale un cas ambigu, à traiter comme les autres : par une règle de seuil dans le scénario, pas par un chiffre isolé lu à l'œil.

Configurer l'appel dans n8n

Dans un scénario n8n, un seul nœud pose cet appel : HTTP Request. Il remplace la fonction que jouerait un Worker, sans code à écrire ni à déployer. Le détail des réglages suit.

Un test depuis le bouton d'exécution du nœud affiche la réponse complète, y compris l'enveloppe result. C'est le moment de vérifier que le chemin result.answers correspond aux questions posées, avant de brancher un nœud Switch ou If derrière. Le nœud propose aussi un réglage de délai d'attente, sous l'onglet Options : une valeur généreuse absorbe un pic de latence sans bloquer tout le scénario.

Configurer l'appel dans Make

Dans un scénario Make, le module HTTP « Effectuer une requête » (Make a request) joue le même rôle. Les réglages sont proches de ceux de n8n, avec un vocabulaire propre à Make.

Un clic sur « Run once » exécute le module seul et affiche la sortie dans le panneau de droite. Les modules suivants du scénario accèdent ensuite aux champs de la réponse par la carte de données habituelle de Make, sans configuration supplémentaire. Le module propose un réglage de délai d'attente équivalent, dans son onglet avancé.

Erreurs, limites de débit et fenêtre de contexte à connaître

Trois limites documentées méritent d'être connues avant de brancher ce scénario sur un volume réel. Elles ne dépendent pas de n8n ni de Make : elles s'appliquent à tout appel à l'API Cloudflare.

La fenêtre de contexte de typesafe/jev est fixée à 32 000 tokens : un state trop long doit être résumé avant l'appel. Le débit de l'API Cloudflare est plafonné à 1 200 requêtes par compte, toutes les cinq minutes ; au-delà, une réponse HTTP 429 bloque les appels suivants pour la période.

Concrètement, un historique de conversation ou un long fil d'emails dépasse vite cette limite de contexte. Un nœud ou un module de résumé, placé avant l'appel à Jev, ramène le state à l'essentiel sans changer la structure des questions.

Le tarif du modèle typesafe/jev sur Cloudflare n'est pas public : il s'affiche dans le tableau de bord du compte, pas sur la fiche modèle. n8n et Make proposent chacun une option de nouvelle tentative sur le nœud ou le module HTTP, utile pour une erreur ponctuelle, mais elle ne remplace pas la lecture du tableau de bord si les erreurs 429 deviennent fréquentes.

Avant de brancher ce scénario en production

Le nœud ou le module HTTP fonctionne, mais un scénario qui agit sur un volume réel mérite les mêmes garde-fous qu'un Worker : secret hors du code, journal des réponses, seuil de confiance.

La confiance renvoyée par Jev reste une probabilité, pas une décision. C'est au scénario n8n ou Make de fixer le seuil à partir duquel il agit seul, et de transmettre les cas sous ce seuil à une personne.

Un scénario qui trie des tickets ou des leads en continu mérite le même regard qu'un Worker en production : qui a accès au jeton, qui relit les cas transmis, à quelle fréquence le seuil est réévalué avec l'équipe métier. La démo publique askjev.ai, décrite dans notre guide Worker, donne un ordre de grandeur de latence utile pour fixer un délai d'attente réaliste, sans remplacer une mesure sur vos propres appels.

Pour aller plus loin

Pour le détail du modèle Jev et sa place face à un modèle de langage, direction notre article sur le modèle Jev. Pour l'appel depuis un Worker Cloudflare, avec les mêmes exemples de code, lisez le guide d'implémentation Worker.

Pour comparer un modèle de décision à un LLM sur un cas concret, consultez modèle de décision ou LLM. Pour une vue d'ensemble de l'automatisation sans code, lisez notre article sur l'automatisation des tâches. Pour cadrer ce type d'automatisation avec ses garde-fous, le parcours IA de La Refonte en présente le programme.

Retenez l'essentiel : le nœud ou le module HTTP remplace le Worker pour l'appel lui-même, pas pour la décision qui suit. Cette décision, avec son seuil et sa relecture humaine, reste à écrire dans le scénario, où qu'il tourne.