Dify en Russie : API compatible OpenAI et premier workflow

Dify peut se connecter à une API externe via son fournisseur de modèles officiel OpenAI-API-compatible. Vous avez besoin de votre propre API Key, d’une Base URL compatible et d’un Model ID actuel. Pour vérifier la configuration, créez un workflow avec une entrée texte, un seul nœud LLM et une sortie texte ; exécutez-le une fois, puis rapprochez le résultat de l’enregistrement du fournisseur.

Vous avez besoin de votre propre API Key pour ce workflow ? Créer un compte BetterToken

Pour tester Dify avec un seul workflow, sans action externe, utilisez une clé de test BetterToken distincte, puis ouvrez le guide Dify à jour. Il concerne l’accès à l’API de modèles. L’installation de Dify, le Marketplace, les plugins tiers, les agents et les outils restent des couches distinctes.

Ce qu’il faut préparer

• une instance Dify Cloud fonctionnelle ou une installation Dify auto-hébergée ;
• l’accès à Integrations/Marketplace et à Model Providers ;
• votre propre API Key BetterToken ;
• un Model ID actuel depuis la model plaza BetterToken ;
• un nouveau workflow de test, sans outils ni actions externes.

Depuis la Russie, vous pouvez vous connecter à l’endpoint API BetterToken sans VPN. Cela ne garantit pas l’accès à Dify Cloud, au Marketplace, à GitHub, à un registre Docker ou à des plugins tiers.

1. Installer le fournisseur officiel

Dans Dify, ouvrez Integrations ou Marketplace, puis Model Providers. Recherchez le fournisseur officiel OpenAI-API-compatible et installez-le s’il n’est pas déjà disponible.

Vérifiez l’auteur et la fiche dans le Marketplace officiel de Dify. N’utilisez pas un plugin au nom approchant : les champs et la gestion des credentials peuvent différer.

2. Ajouter un modèle BetterToken

Ouvrez les réglages du fournisseur et ajoutez un nouveau modèle LLM. Renseignez :

1. Model Type: LLM.
2. Model Name / ID: le Model ID actuel, exactement.
3. API Key: votre propre API Key BetterToken.
4. API Base URL: https://www.bettertoken.ai/v1.
5. Completion mode: Chat, si le fournisseur et le modèle sélectionnés l’exigent.

N’ajoutez pas /chat/completions à la Base URL : le fournisseur construit lui-même le chemin complet. Ne copiez jamais de credentials réels dans un export d’application, une capture d’écran ou une issue.

Si l’interface demande la taille de contexte, max tokens, des paramètres de vision ou de streaming, utilisez uniquement les valeurs de la documentation actuelle du modèle. Le premier test n’a pas besoin de fonctionnalités supplémentaires.

3. Enregistrer et valider le credential

Dify valide le credential lors de l’enregistrement. Cela confirme seulement que le fournisseur a pu effectuer sa procédure d’authentification ; le workflow complet n’est pas encore validé.

Après une erreur, ne conservez que des éléments de diagnostic sûrs :

• nom et version du fournisseur ;
• Model ID ;
• Base URL sans la clé ;
• type d’erreur bref et statut HTTP ;
• heure de la tentative.

N’enregistrez ni l’API Key ni une réponse sensible complète.

4. Créer un workflow minimal

Créez une nouvelle application de type Workflow. Ajoutez seulement trois éléments :

1. Start avec une variable texte appelée question.
2. LLM utilisant le modèle BetterToken ajouté.
3. End avec le texte de réponse du LLM.

Utilisez ce modèle de prompt LLM simple :

Réponds sur une seule ligne. Entrée : {{question}}

Reliez Start → LLM → End. N’ajoutez ni outils HTTP, ni base de données, ni recherche de connaissances, ni boucle d’agent, ni publication. Ces éléments rendent le premier échec plus difficile à isoler.

5. Lancer un test

Envoyez cette entrée :

Retourne DIFY_OK et le nombre 4 comme somme de 2 + 2.

La configuration est confirmée lorsque :

• Dify affiche le texte attendu ;
• le nœud LLM se termine sans erreur de credential, de modèle ou d’endpoint ;
• le Dashboard BetterToken affiche un enregistrement avec le modèle et le statut attendus ;
• le Dashboard affiche les tokens d’entrée, de sortie, de cache le cas échéant, ainsi que le débit correspondant.

Le rapprochement entre l’exécution Dify et le Dashboard permet d’écarter un workflow qui aurait silencieusement utilisé un autre fournisseur ou modèle.

Distinguer les erreurs

Le fournisseur ou le plugin ne s’installe pas

Le problème relève de la couche Dify Marketplace/plugin-daemon. Dans un environnement auto-hébergé, vérifiez la version de Dify, l’accès réseau du plugin daemon, HTTPS et la chaîne de certificats. Modifier l’API Key BetterToken ne résoudra pas ce problème.

ToolProviderCredentialValidationError ou 401

Saisissez de nouveau la clé, vérifiez l’absence d’espaces et contrôlez le fournisseur sélectionné. Assurez-vous que le credential appartient au modèle et non à un plugin d’outil sans rapport.

404

Vérifiez la Base URL :

https://www.bettertoken.ai/v1

Supprimez un éventuel /chat/completions ajouté manuellement si le champ attend une API Base URL.

model not found

Copiez l’ID actuel depuis la model plaza. Vérifiez que cet ID est disponible pour la nouvelle clé et le fournisseur compatible OpenAI sélectionné.

Le credential est enregistré, mais le workflow échoue

Testez le nœud LLM seul. Retirez les outils, le streaming et la sortie structurée, puis répétez le court test texte-en-entrée/texte-en-sortie. S’il réussit, réintroduisez les nœuds supplémentaires un par un.

Périmètre de cette configuration

Le premier workflow confirme une requête de modèle par le fournisseur officiel OpenAI-API-compatible. Il ne prouve pas la compatibilité avec tous les agents Dify, plugins communautaires, outils ou services externes. Créez un test distinct pour toute action ayant un effet de bord et exigez une confirmation explicite de l’utilisateur.

Les champs et limites actuels figurent dans les Docs BetterToken pour Dify. Vérifiez les Model IDs et les prix dynamiques le jour de la configuration.