Modifier l'API Gratuit

Name: Modifier l'API
Price: Gratuit EUR
Availability: InStock
Author: LangGenius, Inc.

Développeur LangGenius, Inc.

Site officiel https://dify.ai

L'API Dify est la couche de service API RESTful de la plate-forme , qui ouvre le flux de travail d'IA visuel RAG récupération de la base de connaissances Appel d'agent et capacités de passerelle de modèle en tant qu'interface programmable. Les développeurs peuvent intégrer les capacités d'orchestration LLM de Dify dans leurs propres systèmes via l'API REST sans se connecter à la console Dify. La prise en charge des opérations de base telles que l'exécution synchrone/asynchrone des flux de travail, la gestion des sessions, le téléchargement et la récupération de documents et la gestion des applications constitue l'infrastructure clé permettant à Dify de passer d'un « outil interne » à une « plate-forme ».

API Dify : capacités d'orchestration d'applications Open LLM en tant qu'interface programmable

Paramètres et statistiques de base

L'API Dify n'est pas un service cloud indépendant, mais la couche de service API de la plate-forme Dify - elle expose les capacités du moteur de flux de travail visuel de Dify, du générateur d'agents de base de connaissances RAG et de la passerelle de modèle vers les appels système externes via une interface RESTful. Du point de vue de la forme du produit, l'API Dify est le pont clé permettant à Dify de passer des « outils d'orchestration internes » à « l'infrastructure de plate-forme ».

Projets	Informations publiques
Positionnement officiel	Couche de service API RESTful de la plateforme Dify
Protocole d'interface	REST (HTTP/HTTPS) + JSON
Méthode d'authentification	Clé API (niveau application) + jeton (niveau session)
Couverture des points de terminaison de base	Exécution de workflow, gestion de sessions, récupération de base de connaissances, téléchargement de documents, gestion d'applications
Mode d'exécution	Synchrone (attente bloquante) / asynchrone (rappel ou interrogation)
Documentation API	Spécification OpenAPI 3.0 (mise à jour avec la version de la plateforme)
Prise en charge des SDK	Python, JavaScript/TypeScript (communauté + maintenance officielle)
Limite de taux	Divisé par niveau de forfait (version gratuite 200 messages par jour, version professionnelle illimitée)
Méthode de déploiement	La version Cloud est automatiquement activée / la version auto-hébergée doit configurer la passerelle API
Synchronisé avec la version plateforme	Conforme au numéro de version de la plateforme Dify (actuellement v1.14.2)

Différence de positionnement : la relation entre l'API Dify et la console Web Dify est similaire à celle de l'API Stripe et du tableau de bord Stripe : la première est une couche d'orchestration pour les appels de programme et la seconde est une interface graphique pour les opérations humaines. Les deux partagent le même moteur de workflow et le même pipeline de base de connaissances, et la seule différence réside dans l'entrée d'interaction. La principale raison pour laquelle les développeurs choisissent les API plutôt que les consoles est « l'intégration automatisée » : intégrer les flux de travail d'IA dans les systèmes d'entreprise existants au lieu de laisser les utilisateurs passer à l'interface Dify pour les opérations.

Différence de mode d'utilisation : L'API Dify prend en charge les modes d'exécution synchrone et asynchrone. Le mode synchrone convient aux scénarios simples de questions et réponses (la demande-réponse est terminée dans les 30 secondes) ; Le mode asynchrone convient aux flux de travail de longue durée (tels que les tâches d'agent en plusieurs étapes, la récupération et la génération RAG à grande échelle), et les résultats finaux sont obtenus via des rappels Webhook ou des interrogations. Cette conception bimode couvre deux exigences typiques : une faible latence en ligne et un traitement par lots hors ligne.

Reconnaissance des utilisateurs et du marché

Le groupe d'utilisateurs de l'API Dify recoupe fortement celui de la plateforme Dify, mais son profil technique présente une fonctionnalité « orientée développeur » plus forte.

Données d'adoption : parmi la base communautaire de la plate-forme Dify GitHub 143K+ Stars et 22K+ Forks, les utilisateurs d'API représentent une certaine proportion de développeurs actifs - cela peut être confirmé par les problèmes d'intégration d'API qui apparaissent fréquemment dans les problèmes GitHub, le nombre d'étoiles dans l'entrepôt du SDK et le nombre de téléchargements npm/PyPI. Dans la version Dify Cloud de l'espace de travail enregistré, la proportion d'applications créées via des API plutôt que via la console Web est estimée (selon les discussions de la communauté) entre 20 et 30 %, et est en augmentation.

Scénarios d'intégration typiques : des cas publics montrent que les modèles typiques d'utilisation de l'API Dify par les entreprises clientes incluent : l'intégration du flux de travail d'IA dans les systèmes CRM/ERP existants, la connexion d'applications de base de connaissances auto-construites via l'API et l'intégration de robots de questions et réponses d'IA dans WeChat/Feishu/DingTalk d'entreprise. La caractéristique commune de ces scénarios est de « laisser le système d'origine inchangé et d'ajouter uniquement une couche d'orchestration d'IA » : l'API Dify agit comme une couche de colle entre l'ancien et le nouveau système.

Comparaison avec les API concurrentes : dans le segment des « API d'orchestration LLM programmable », les produits d'analyse comparative directe de l'API Dify incluent l'API Coze (ByteDance), l'API Flowise et l'API LangFlow. La principale différence de l'API Dify réside dans « l'exhaustivité de la plate-forme » : les trois autres nécessitent des capacités RAG externes (Flowise/LangFlow) ou ne peuvent pas être auto-hébergées (Coze), tandis que l'API Dify satisfait en même temps aux trois dimensions du déploiement intégré, auto-hébergé et de la passerelle de modèle RAG.

Comparer les dimensions	Modifier l'API	API Coze	API Flowise	API LangFlow
API de la base de connaissances RAG	✅ Point de terminaison de recherche intégré et complet	✅ Intégré	❌ Nécessite un plug-in externe	❌ Nécessite un plug-in externe
API d'exécution de flux de travail	✅ Synchrone + Asynchrone	✅ Synchrone	✅ Synchrone	✅ Synchrone
API de passerelle de modèle	✅ Gestion Unifiée + Routage	❌ Aucun	❌ Aucun	❌ Aucun
Déploiement auto-hébergé	✅ Version communautaire gratuite à construire	❌ Cloud uniquement	✅ Docker	✅ Docker
Spécification de la documentation API	OpenAPI 3.0	Personnalisé	Personnalisé	Personnalisé
Transparence des limites de taux	Système de packages, pas de limite supérieure pour la version professionnelle	Il y a une limite mensuelle	Aucune limite officielle	Aucune limite officielle

Conclusion de reconnaissance du marché : L'API Dify est bien positionnée à l'intersection de "nécessite un auto-hébergement + RAG intégré + orchestration complète du flux de travail". Pour les équipes qui créent déjà des applications à l'aide de la console Web Dify, l'API est une extension naturelle des fonctionnalités, avec une faible courbe d'apprentissage et aucun besoin de changer de pile technologique.

Avantage de coût

L'analyse des coûts de l'API Dify doit être liée à la tarification globale de la plateforme Dify : l'API elle-même n'est pas facturée séparément, et son quota d'appels et sa limite de débit sont déterminés par le package Dify. Cela signifie que le coût marginal de l’API est proche de zéro : puisque vous avez déjà payé pour la plateforme, les appels d’API sont une fonctionnalité à valeur ajoutée incluse.

Développeurs côté C et individuels :

Coût explicite : la version gratuite Cloud a un quota de messages quotidien de 200, et les appels d'API sont pris en compte dans le même quota de messages. Après avoir dépassé la limite, le package doit être mis à niveau. L'auto-hébergement de la version communautaire est entièrement gratuit et ne supporte que le coût du serveur (instance minimum 2 cœurs de 4 Go, les frais mensuels sont d'environ 50 à 200 ¥).
Coûts cachés : configuration du déploiement de la passerelle API lorsqu'elle est auto-hébergée (gestion des clés API du certificat HTTPS du proxy inverse Nginx) ; le délai de réponse de l'API de la version Cloud est affecté par les conditions du réseau et l'accès transfrontalier peut nécessiter des solutions d'accélération supplémentaires.
Chemin recommandé : Utilisez la version gratuite Cloud pendant la période de vérification du prototype ; les développeurs individuels disposant de budgets sensibles et de certaines capacités d'exploitation et de maintenance choisissent la version communautaire pour l'auto-hébergement.

Développeurs d'API et petites équipes :

Coût explicite : Dify Cloud Pro 59 $/mois/espace de travail, aucune limite d'appels API. Les frais de l'API du modèle sont supplémentaires (le développeur paie directement le fournisseur du modèle et Dify ne prend pas de commission). Payez annuellement et bénéficiez d'une réduction d'environ 15 à 20 %.
Coûts cachés : lors de la mise à niveau de la version gratuite vers la version professionnelle, vous devez reconfigurer la clé API et les autorisations ; La migration des API de la version communautaire vers la version Cloud implique l'export des données.
Chemin recommandé : lorsqu'une équipe de 3 à 10 personnes ne dispose pas d'opérations et de maintenance à temps plein, le coût de Cloud Professional Edition à 59 $/mois est inférieur à celui de l'infrastructure auto-hébergée + investissement en main d'œuvre d'exploitation et de maintenance.

Déploiement de privatisation d'entreprise :

Coût explicite : le prix de la version entreprise nécessite une confirmation commerciale (estimé entre 2 000 et 20 000 $/an selon les pratiques du secteur). Le service API lui-même est inclus dans le package de déploiement Enterprise Edition.
Coûts cachés : coûts d'exploitation et de maintenance de l'API dans le cadre d'un déploiement privatisé (configuration de la passerelle API haute disponibilité, surveillance des alarmes, collecte des journaux, tests de compatibilité des mises à niveau) ; gouvernance de la sécurité des API internes de l'entreprise (rotation des clés API, audit des accès).
Chemin recommandé : les secteurs réglementés tels que la finance, la médecine et les affaires gouvernementales donnent la priorité à l'évaluation de la version entreprise : sa valeur de conformité (souveraineté des données + journaux d'audit) est supérieure à la fonction API pure elle-même.

Comparaison des coûts à trois niveaux :

Dimensions des coûts	API communautaire (auto-hébergée)	API Cloud professionnelle	API d'entreprise
Frais de licence API	0 $	Inclus dans le forfait à 59 $/mois	Inclus dans le contrat Entreprise
Coûts d'infrastructure	10-30$/mois (serveur)	Inclus dans l'abonnement	Payant ou inclus dans le contrat
Frais d'API modèle	Supplémentaire	Supplémentaire	Peut être regroupé et négocié
Personnel d'exploitation et de maintenance des API	Doit être préparé par l'équipe	Pas besoin	Dépend du mode de déploiement
Limite de taux	Aucun (automatique)	Illimité	Personnalisé
Souveraineté des données	Entièrement autonome	Hébergé sur Dify Cloud	Cloud privé/sur site

Fonctions principales

Les fonctions principales de l'API Dify tournent autour de l'objectif « d'ouvrir les capacités de la plateforme Dify en tant qu'interfaces programmables ». Au lieu de simplement mapper les boutons de la console Web aux points de terminaison REST, la sémantique de l'API pour chaque fonctionnalité est conçue pour les scénarios d'intégration.

API Workflow Execution : Déclenchez l'exécution du workflow IA via les points de terminaison POST /workflows/run et POST /workflows/run-async, prenant en charge la transmission des variables et du contexte initiaux. Synergies : l'API Workflow partage le même environnement d'exécution avec le moteur d'orchestration visuelle de Dify : les workflows débogués sur la console Web se comportent exactement de la même manière lorsqu'ils sont appelés via l'API, éliminant ainsi le besoin d'une orchestration distincte pour les scénarios d'intégration d'API. Le modèle « organiser une fois, appeler à plusieurs endroits » évite le problème de séparation du « les tests ont un contexte et la production a un contexte » dans l'intégration traditionnelle.
API de gestion de sessions : créez et gérez des sessions de conversation via le point de terminaison « POST /chat-messages », prenant en charge la maintenance automatique des contextes de conversation à plusieurs tours. Synergie : l'API de gestion de session et l'API de workflow peuvent être utilisées en série : une tâche complexe en plusieurs étapes peut être décomposée en un cycle de "contexte de persistance de session -> exécution de workflow -> écriture du résultat dans la session" pour obtenir un processus d'interaction d'IA avec état.
API de récupération de base de connaissances : récupérez les fragments de documents pertinents de la base de connaissances spécifiée via le point de terminaison POST /datasets/:id/retrieve, prenant en charge trois modes de récupération vectorielle, de récupération de texte intégral et de récupération hybride. Synergie : L'API de récupération peut être utilisée indépendamment des appels LLM : le système externe appelle d'abord l'API de récupération pour obtenir le fragment de connaissances, puis décide lui-même si et comment transmettre le fragment à LLM. Ce mode « séparation récupération-génération » est très pratique dans les scénarios qui nécessitent un contrôle fin de la construction rapide.
API de gestion de documents : fournit des points de terminaison de téléchargement de documents (POST /datasets/:id/document), de suppression, de mise à jour et de requête d'état. Synergie : l'API de gestion de documents et l'API de récupération coopèrent pour réaliser une « mise à jour à chaud » de la base de connaissances : le système externe télécharge progressivement de nouveaux documents via l'API, et la fin de la récupération prend effet immédiatement, sans qu'il soit nécessaire d'actualiser manuellement l'index de la base de connaissances.
API de gestion et de configuration des applications : gérez le cycle de vie des applications Dify (créer, interroger, mettre à jour, supprimer) via la série de points de terminaison GET/POST /apps, y compris l'obtention des paramètres d'application, la mise à jour des paramètres d'application et la gestion des clés API. Synergie : l'API de gestion des applications permet à l'équipe DevOps d'intégrer la création et la configuration d'applications Dify dans le pipeline CI/CD - créer automatiquement des applications, configurer des modèles et définir des clés API lors de nouveaux déploiements de limites, réduisant ainsi le risque d'omissions dans la configuration manuelle.
API de génération de texte : appelez directement le nœud LLM dans le workflow Dify via le point de terminaison POST /completion-messages pour terminer la tâche de génération de texte. Il convient à la traduction, au résumé, à la génération de rédaction et à d'autres scénarios qui ne nécessitent pas le maintien de plusieurs cycles de dialogue.
API de téléchargement de fichiers : prend en charge le téléchargement de fichiers tels que des images et des documents via POST /files/upload et référence les fichiers téléchargés dans l'exécution du flux de travail ou les messages de conversation. Les fichiers téléchargés sont automatiquement classés dans les bases de connaissances associées ou saisis en tant que nœuds de flux de travail.

Présentation de la synergie : la valeur de l'API Dify ne réside pas dans la fonctionnalité des points de terminaison individuels, mais dans la capacité de les combiner. Par exemple, un lien d'intégration typique de « service client intelligent » : API de gestion de documents (télécharger le manuel du produit) → API de récupération de base de connaissances (index de construction) → API d'exécution de flux de travail (récupération + génération LLM + appel à l'outil d'agent) → API de gestion de session (maintenir plusieurs cycles de contexte de conversation). La combinaison de quatre points de terminaison complète un système de questions et réponses intelligent de bout en bout, et chaque point de terminaison peut servir indépendamment d'autres scénarios.

Evolution du modèle et de la version

La version de l'API Dify est liée à la version de la plateforme Dify et le rythme d'itération de l'API suit la version principale de la plateforme. De la version officielle de la v1.0 à la v1.14.x actuelle, la couche API a connu une évolution de « fondamentalement disponible » à « couverture complète ».

Contexte de la version de l'API

v1.0 (01/01/2025) : version Milestone. En synchronisation avec la plateforme Dify v1.0, la couche API est officiellement entrée dans la phase de production. Fournit trois points de terminaison principaux : l’exécution du flux de travail, la gestion des sessions et la récupération de la base de connaissances. Publication du document de spécification OpenAPI 3.0 et de la première version du SDK Python/JS.
v1.5 (2025-06) : Ajout d'un point de terminaison d'exécution de workflow asynchrone (/workflows/run-async) pour prendre en charge la notification de rappel Webhook des résultats d'exécution. L'API de recherche dans la base de connaissances ajoute des paramètres de recherche hybrides (champ search_method). L'API de téléchargement de fichiers est en ligne.
v1.10 (2025-12) : les points de terminaison de la série d'API de gestion des applications sont en ligne, prenant en charge la création et la gestion d'applications Dify via l'API. L'API de génération de texte (/completion-messages) est publiée indépendamment et peut effectuer une seule tâche de génération de texte sans dépendre du contexte de session.
v1.14.0 (2026-04-29) : les points de terminaison liés à l'orchestration de l'agent sont mis à jour avec la mise à niveau de l'architecture de l'agent de la plateforme ; l'API ajoute des améliorations au format de retour des résultats des appels d'outils aux nœuds d'agent. La stratégie de limite de débit est optimisée et la limite supérieure des appels d'API est annulée pour Professional Edition et versions ultérieures.
v1.14.1 (2026-05-12) : Renforcement de la sécurité - Amélioration du mécanisme de rotation des clés API, amélioration de la vérification de la signature des demandes. Améliorations de la stabilité de l'API Workflow : la gestion des délais d'attente est plus prévisible et les formats de réponse aux erreurs sont standardisés.
v1.14.2 (2026-05-19) : améliorations continues de la sécurité et corrections de bugs. L'architecture sous-jacente de l'agent est améliorée (pour ouvrir la voie à des fonctionnalités avancées ultérieures de l'agent) et le niveau de l'API se reflète dans l'optimisation structurelle de la sortie du nœud de l'agent.

Résumé des fonctionnalités de la version

Verrouillé avec le numéro de version de la plateforme : la version de l'API n'est pas numérotée indépendamment et est cohérente avec la version de la plateforme Dify. Cela réduit la complexité de la gestion des versions, mais signifie que les modifications au niveau de l'API peuvent inclure des mises à jour des fonctionnalités de la plateforme plutôt que de pures modifications de l'API.
Les capacités RAG mûrissent en premier : l'API de récupération de base de connaissances possède l'itération la plus rapide parmi tous les points de terminaison, reflétant l'accent stratégique de Dify sur les scénarios de « gestion des connaissances ».
Les capacités asynchrones se complètent progressivement : De l'exécution synchrone de la v1.0 à la prise en charge asynchrone de la v1.5, puis aux mécanismes de webhook et d'interrogation ultérieurs, le mode d'exécution de l'API a progressivement mûri.
La sécurité et la gouvernance sont améliorées version par version : La série v1.14.x mentionne à plusieurs reprises le renforcement de la sécurité, indiquant que la couche API passe de « fonctionnalités disponibles » à « sécurité de niveau entreprise ».

Avantages techniques

L'avantage technique de l'API Dify ne réside pas dans le leadership d'un seul algorithme, mais dans « l'unité architecturale » et la « profondeur d'ingénierie » - elle unifie le moteur de flux de travail complexe RAG pipeline Agent runtime et la passerelle de modèle de la plate-forme Dify dans un ensemble d'API REST sémantiquement cohérentes.

Runtime d'exécution unifié

Lorsque l'API Dify est appelée, la requête entre dans le moteur de workflow de Dify, qui est un framework d'exécution basé sur un Directed Graph (DAG). Les paramètres de la requête API sont mappés aux variables d'entrée du flux de travail et le moteur les exécute séquentiellement dans une topologie de nœud prédéfinie, sérialisant finalement la sortie dans une réponse JSON. La valeur fondamentale de cette conception est la suivante : La console Web et le chemin d'exécution de l'API sont totalement cohérents - une fois que le même flux de travail a réussi le test sur le canevas, le comportement via l'appel d'API devrait théoriquement être reproduit à 100 %.

Mécanisme -> Effet -> Scénario : L'exécution unifiée du runtime élimine le risque de « performances incohérentes entre le contexte de test et le contexte de production ». Pour les équipes intégrant l'API Dify dans des systèmes orientés client (par exemple, des robots de service client, des générateurs de rapports), cela signifie que les orchestrateurs de flux de travail (peut-être dans des rôles non techniques) et les ingénieurs d'intégration d'API peuvent travailler en parallèle, chacun validant les résultats dans leurs propres chaînes d'outils, pour finalement s'intégrer de manière transparente dans les environnements de production.

Conception en couches de l'API REST

L'API Dify est architecturalement divisée en trois couches logiques :

Couche d'accès (API Gateway) : gère l'authentification des demandes (vérification de la clé API), la limite de débit, les journaux de demandes et la configuration inter-domaines. Dans les déploiements auto-hébergés, cette couche est généralement implémentée par Nginx ou Kubernetes Ingress.
Couche d'orchestration (Workflow Engine) : analyse les paramètres de demande d'API, instancie le contexte d'exécution du flux de travail et planifie la séquence d'exécution des nœuds DAG. Cette couche est au cœur de l'API Dify : elle convertit la sémantique des requêtes RESTful en sémantique d'exécution du workflow.
Couche de ressources (adaptateurs de service) : connectez-vous à des ressources externes telles que l'API du fournisseur de modèles, la base de données vectorielles et le stockage de fichiers. Les appelants d’API ne perçoivent pas directement l’existence de ces ressources backend, et toute la logique d’adaptation est encapsulée sous la couche d’orchestration.

Mécanisme -> Effet -> Scénario : la conception en couches permet aux appelants d'API de se concentrer uniquement sur "les paramètres transmis et les résultats obtenus", sans se soucier du modèle connecté au backend ou de la base de données vectorielles utilisée. Lorsque les ressources backend sont basculées (par exemple d'OpenAI vers DeepSeek), les points de terminaison de l'API et les formats de réponse restent complètement inchangés, sans aucun changement pour l'appelant.

Implémentation technique de l'API de récupération RAG hybride

Derrière le point de terminaison de recherche de la base de connaissances de l'API Dify se trouve le moteur de recherche hybride de Dify, qui prend en charge trois stratégies de recherche :

Récupération de vecteurs (dense) : utilisez le modèle d'intégration pour mapper les requêtes et les fragments de documents dans l'espace vectoriel sémantique et calculer la similarité cosinus. Il convient aux scénarios de correspondance sémantique, mais n'est pas sensible à la correspondance exacte de termes professionnels.
Recherche en texte intégral (Sparse/BM25) : méthode traditionnelle de recherche d'informations basée sur la correspondance de mots clés. Adapté à des scénarios de frappe précis, mais insensible aux variations sémantiques.
Récupération hybride (Hybrid) : fusionnez les résultats de recherche de Dense et Sparse selon des poids configurables, puis affinez les résultats de fusion via le modèle Rerank.

Mécanisme -> Effet -> Scénario : la recherche hybride est exposée à l'appelant au niveau de l'API via un paramètre search_method. Pour des scénarios tels que la récupération de contrats juridiques où « la compréhension sémantique + les mots-clés précis » sont tous deux importants, le choix du mode hybride + le réglage « dense_weight=0,6, sparse_weight=0,4 » améliore généralement le premier taux de réussite de 15 à 25 % par rapport au mode de recherche unique. L'étape Rerank consomme un délai supplémentaire d'environ 100 à 300 ms. Dans les scénarios de questions et réponses en temps réel sensibles aux retards, il peut être activé ou désactivé en fonction des besoins.

Modifier la liste ouverte des outils API

L'API Dify expose les points de terminaison principaux (c'est-à-dire les « ensembles d'outils ») à l'appelant, chaque point de terminaison correspondant à une interaction API complète :

Chemin du point de terminaison	Méthode HTTP	Description du comportement	Scénarios correspondants
`/messages-de-chat`	POSTER	Envoyer des messages de conversation pour déclencher le flux de travail ou la réponse de l'agent	Questions et réponses intelligentes, robot de service client
`/workflows/run`	POSTER	Déclencher l'exécution synchrone du workflow, bloquer et attendre le retour	Tâches déterministes (génération d'articles, rapports)
`/workflows/run-async`	POSTER	Déclenchez l'exécution asynchrone du workflow, retournez task_id	Tâches à long terme (traitement par lots, analyse approfondie)
`/workflows/tâches/:id`	OBTENIR	Interroger l'état et les résultats de l'exécution des tâches asynchrones	Suivi de la progression des tâches asynchrones
`/datasets/:id/retrieve`	POSTER	Récupérer des fragments de documents pertinents de la base de connaissances	RAG Q&A, récupération de connaissances
`/datasets/:id/document`	POSTER	Télécharger des documents vers la base de connaissances	Construction par lots de la base de connaissances
`/datasets/:id/document/:doc_id`	SUPPRIMER	Supprimer un document de la base de connaissances	Mise à jour et maintenance de la base de connaissances
`/messages-d'achèvement`	POSTER	Génération de texte unique, pas de maintenance de session	Traduction, résumé, génération de rédaction
`/files/upload`	POSTER	Télécharger des fichiers (images, documents) pour référence ultérieure	Saisie multimodale, traitement de documents
`/applications`	OBTENIR/POST	Requête de liste d'applications / Création d'une nouvelle application	Gestion du cycle de vie des applications
`/apps/:id/api-keys`	OBTENIR/POST	Gestion des clés API	Gouvernance de la sécurité et rotation des clés

Description de l'interaction : Un processus d'intégration typique de « questions et réponses sur le document » est complété par des appels en chaîne de points de terminaison d'API - POST /files/upload (télécharger le manuel du produit) → POST /datasets/:id/document (incorporé dans la base de connaissances) → POST /chat-messages (questions des utilisateurs, appel interne du workflow /datasets/:id/retrieve récupération + LLM pour générer des réponses) → Retourner la réponse finale. L'ensemble du processus est terminé dans l'interface utilisateur du système externe sans que l'utilisateur ait à toucher la console Dify.

Guide des pièges d'ingénierie

Sur la base des fonctionnalités architecturales de l'API Dify et des commentaires de la communauté, voici les problèmes typiques et les stratégies de réponse dans l'intégration de production :

Délai d'expiration de l'API et temps d'exécution du workflow hors de contrôle : Une seule exécution d'un workflow complexe (plusieurs appels de chaîne de nœuds LLM + récupération de la base de connaissances + appel à l'outil Agent) peut dépasser 60 secondes, déclenchant un timeout et une déconnexion de la passerelle API. Solution : utilisez le mode asynchrone (/workflows/run-async) de manière uniforme pour les scénarios susceptibles d'expirer et définissez une URL de rappel Webhook raisonnable ; le mode synchrone n'est utilisé que pour des workflows simples avec des temps de réponse prévisibles (il est recommandé de définir un seuil de temps d'exécution <30 secondes). Au niveau de la conception du workflow, la limite supérieure de « max_tokens » peut être définie sur les nœuds LLM clés pour empêcher un seul nœud de consommer trop de jetons et de prolonger le temps d'exécution.
Fuite de clé API et autorisation transfrontalière : L'intégration directe de Dify API Key dans les applications clientes (telles que les frontaux Web et les applications mobiles) implique un risque de fuite de clé. Les attaquants peuvent utiliser la clé divulguée pour épuiser le quota gratuit ou déclencher des appels de modèle coûteux. Solution : La clé API Dify doit être conservée dans le service backend ; la demande du client atteint d'abord le backend auto-construit, puis le backend transporte la clé API pour appeler l'API Dify. Pour les points de terminaison impliquant des opérations d’écriture ou de suppression (suppression de documents, modification de la configuration de l’application), définissez des journaux de confirmation secondaires ou d’audit des opérations au niveau de la couche métier. Dify Cloud Professional Edition et versions ultérieures prennent en charge les restrictions de liste blanche IP et de portée de clé API.
Résultats de récupération de la base de connaissances incohérents : la même requête appelle /datasets/:id/retrieve sur la même base de connaissances à différents moments pour renvoyer des résultats différents, ce qui peut être dû à des index non synchronisés dans les mises à jour de documents, à des retards de cohérence de la base de données vectorielle ou à un changement de version du modèle d'intégration. Solution : Une fois le document mis à jour, appelez le point de terminaison de la requête d'état du document pour confirmer l'état de l'index (le champ indexing_status est completed) avant d'effectuer la récupération ; activer le mode d'indexation synchrone de la base de connaissances pour les scénarios sensibles à la cohérence (les opérations de mise à jour sont bloquées en attendant la fin de l'indexation) ; enregistrez le session_id du résultat renvoyé par l'API de récupération pour revenir en arrière lors du dépannage des incohérences.

Démarrez rapidement en 3 minutes

Le moyen le plus rapide de démarrer avec l'API Dify (en prenant la version Cloud comme exemple) :

Connectez-vous à https://cloud.dify.ai, créez une application et obtenez une clé API (Paramètres de l'application → Clé API → Créer une clé).
Utilisez curl pour envoyer le premier message de conversation :

curl -X POST "https://api.dify.ai/v1/chat-messages" \
  -H "Autorisation : Porteur <VOTRE_API_KEY>" \
  -H "Type de contenu : application/json" \
  -d '{
    "entrées": {},
    "query": "Bonjour, veuillez vous présenter",
    "response_mode": "blocage",
    "user": "utilisateur démo"
  }'

Vérifiez le champ « réponse » dans le résultat renvoyé, qui est le contenu de la réponse de l'IA.

L'adresse du point de terminaison de l'API pour le déploiement auto-hébergé est « http:///v1 » et les autres paramètres restent inchangés. Pour une documentation détaillée de l'API et l'utilisation du SDK, veuillez vous référer à la documentation officielle de Dify et au README de GitHub.

Comment utiliser

L'accès à l'API Dify diffère selon la méthode de déploiement, mais la méthode d'authentification et le mode d'appel principal restent les mêmes.

Matrice d'entrée :

Utilisation	Adresse de base du point de terminaison de l'API	Scénarios applicables	Méthode d'authentification
Version cloud	`https://api.dify.ai/v1`	Vérification de prototypes, production en petite équipe	Clé API (jeton du porteur)
Version communautaire auto-hébergée	`http://<votre-domaine>/v1`	Scénarios sensibles aux données, déploiement en production	Clé API (jeton du porteur)
Édition Entreprise Privatisée	Fourni par le service informatique de l'entreprise	Scénarios avec des exigences de conformité strictes	Clé API + Authentification configurable

Processus de certification API :

Créez une application dans la console Dify → entrez dans la page "Accès API".
Cliquez sur « Créer une clé » pour générer une clé API commençant par « app- ».
Portez « Autorisation : Bearer » dans l'en-tête HTTP de toutes les requêtes API.
(Facultatif) Générez un jeton de session indépendant (paramètre « utilisateur ») pour chaque utilisateur final afin de faciliter le suivi de l'utilisation par latitude utilisateur dans le panneau de surveillance.

Étapes d'intégration typiques :

Créez des workflows d'IA avec une orchestration visuelle dans la console Dify.
Publiez l'application et obtenez la clé API.
Appelez l'API Dify via le client HTTP dans le système externe, en transmettant les entrées utilisateur et les variables de contexte.
Sélectionnez l'attente synchrone (blocage) ou le rappel asynchrone (streaming/callback) en fonction du paramètre Response_mode.
Analysez la réponse JSON renvoyée par l'API et affichez les résultats dans votre propre interface utilisateur.

Prise en charge du SDK (en prenant Python comme exemple) :

demandes d'importation

API_KEY = "<VOTRE_API_KEY>"
BASE_URL = "https://api.dify.ai/v1"

en-têtes = {
    "Autorisation": f"Porteur {API_KEY}",
    "Content-Type": "application/json"
}

# Envoyer un message de conversation
réponse = requêtes.post(
    f"{BASE_URL}/messages-de-chat",
    en-têtes=en-têtes,
    json={
        "entrées": {},
        "query": "Quelles sont les nouvelles aujourd'hui ?",
        "response_mode": "blocage",
        "utilisateur": "utilisateur-123"
    }
)

print(response.json()["réponse"])

Astuce : Les commandes d'installation spécifiques et les signatures de méthodes complètes du SDK sont soumises au référentiel GitHub officiel de Dify et à la page PyPI/npm. Lorsque l'édition Community est auto-hébergée, assurez-vous que la passerelle API est configurée avec un certificat HTTPS et que les règles de proxy inverse sont correctes.

Prix des produits

L'API Dify n'est pas facturée séparément et son prix est inclus dans le package de la plateforme Dify. Cela signifie que les quotas d'appels d'API sont liés aux plafonds de volume de messages/appels au niveau du plan.

Édition communautaire (Open Source auto-hébergée) :

Frais API : 0 $
Limitations : Aucune limite d'appels API (limitée par les performances du serveur auto-déployé)
Prérequis : Vous devez configurer vous-même la gestion des clés API du certificat HTTPS de la passerelle API
Applicable à : les équipes techniques ayant des capacités d’exploitation et de maintenance

Édition gratuite Cloud :

Frais API : 0 $
Limites : 200 messages par jour (quota partagé API + console Web), maximum 5 applications
Applicable : vérification personnelle, développement de prototypes

Cloud Pro (59 $/mois/espace de travail) :

Frais API : inclus dans l'abonnement
Limitations : Aucune limite de messages, 50 applications, support technique prioritaire
Adapté pour : une utilisation en production par de petites équipes

Édition Cloud Team (à partir de 159 $/mois) :

Frais API : inclus dans l'abonnement
Limites : collaboration multi-membres, gestion avancée des autorisations, davantage de quotas d'applications et de bases de connaissances
Applicable à : Équipes de taille moyenne exécutant plusieurs scénarios en parallèle

Édition Entreprise (devis personnalisé) :

Frais API : inclus dans le contrat Enterprise Edition
Limitations : limites de débit d'API personnalisées, SLA dédié, intégration SSO, journaux d'audit
Applicable aux : secteurs réglementés tels que la finance, les soins médicaux, les affaires gouvernementales, etc.

Frais supplémentaires : les frais d'appel d'API du modèle pour tous les packages sont payés directement par le développeur au fournisseur du modèle (tel que OpenAI, DeepSeek, Anthropic), et il n'y a aucune commission supplémentaire pour la plateforme Dify et la couche API. Il est recommandé d'inclure à la fois les « frais du package de modification + les frais de l'API du modèle » dans le budget de l'estimation des coûts.

Scénarios d'application

Les scénarios d'application de l'API Dify peuvent être résumés comme « l'intégration de capacités d'IA dans des systèmes existants » : dans tout scénario dans lequel des capacités d'orchestration d'IA doivent être introduites sans remplacer la pile technologique existante, l'API Dify a la possibilité d'intervenir.

Extension des fonctions d'IA des systèmes existants : intégrez des capacités d'IA dans les systèmes CRM, ERP, de bons de travail et de gestion de contenu, et appelez le flux de travail Dify via des API pour effectuer des tâches telles que des questions et réponses intelligentes, la génération de contenu et la classification des données. Avantages de mise en œuvre : Intrusion minimale dans les systèmes existants - pas besoin de modifier l'architecture du système, ajoutez simplement des appels HTTP à la logique métier. Les déductions montrent qu'une fois qu'un backend de commerce électronique de taille moyenne est connecté à l'API du service client AI, le taux de réponse automatique pour les ordres de travail de premier niveau peut atteindre 55 à 70 % et le volume de traitement manuel du service client est réduit à 40 % de l'original.
Application de questions-réponses de base de connaissances auto-construite : téléchargez des documents internes d'entreprise par lots via le point de terminaison de gestion de documents de l'API Dify, implémentez la récupération contextuelle de questions-réponses via le point de terminaison de recherche et maintenez plusieurs séries de conversations via le point de terminaison de gestion de session. Avantages de mise en œuvre : dans un scénario typique de base de connaissances RH, le temps nécessaire aux employés pour interroger en libre-service sur le processus d'intégration, la politique de congé et d'autres problèmes courants est réduit d'une moyenne de 10 minutes (parcourir des documents + demander à des collègues) à moins de 30 secondes.
Pipeline de production de contenu automatisé : organisez le flux de travail Dify dans un pipeline de production de contenu (sélection de sujet → collecte de données → génération du premier brouillon → révision → publication) et connectez-vous au système CMS via l'API. Avantages de mise en œuvre : pour les équipes opérationnelles des nouveaux médias, le temps de production de la première ébauche d'un article de compte public standard est réduit de 60 à 90 minutes à 10 à 15 minutes, mais la révision manuelle doit être conservée pour garantir l'exactitude des faits et la cohérence de la tonalité de la marque.
Intégration inter-systèmes de l'agent IA : via le point de terminaison du flux de travail de l'agent de l'API Dify, des tâches d'IA complexes sont orchestrées entre plusieurs systèmes d'entreprise - par exemple, un « agent de traitement des plaintes clients » peut : appeler l'API CRM pour interroger les informations client → appeler la base de connaissances pour récupérer les cas de réclamation pertinents → appeler le LLM pour générer des suggestions de réponse → appeler le système d'ordre de travail pour créer un ordre de travail de traitement. Avantages de mise en œuvre : traitement automatisé en lien complet des plaintes simples, les plaintes complexes génèrent automatiquement des projets de suggestions de traitement pour examen manuel, et le temps de traitement d'une seule plainte est réduit de quelques heures à quelques minutes.
Amélioration de l'IA de la chaîne d'outils interne de l'entreprise : intégrez l'API Dify dans les plates-formes de bureau telles que WeChat d'entreprise, Feishu et DingTalk pour fournir des robots assistants IA. Grâce aux capacités de gestion de session de l'API, le partage du contexte de conversation multiplateforme peut être réalisé : les utilisateurs peuvent continuer à poser des questions sur Feishu dans WeChat Enterprise. Limite applicable : le partage de contexte multiplateforme nécessite la prise en charge d'un système de gestion de session externe, et le mode API pur ne résout pas directement le problème de routage des messages.

Déduction quantitative de la réduction des coûts et de l'amélioration de l'efficacité (estimation basée sur les fonctionnalités de l'API Dify)

Rôles professionnels	Tâches typiques	Cela prend du temps de manière traditionnelle	Prend beaucoup de temps après l'intégration de l'API	Amélioration de l'efficacité	Instructions de déduction
Spécialiste du service à la clientèle	Demander le processus de retour et d'échange standard	3 à 5 minutes (retournement de documents)	10-15 secondes (Questions et réponses sur l'API)	12 à 30 fois	Lien API RAG basé sur la recherche dans la base de connaissances + génération LLM
Opérations de contenu	Générer une copie d'introduction du produit	60-90 minutes	10-15 minutes (première ébauche)	4-6 fois	L'API Workflow déclenche un pipeline de production de contenu en plusieurs étapes
Assistante Juridique	Examen préliminaire des termes du contrat	2-4 heures	15-30 minutes (pré-révision)	4 à 8 fois	Combinaison API de workflow + API de recherche dans la base de connaissances pour compléter la comparaison des termes
Ingénieur de Développement	Intégrer les questions et réponses sur l'IA dans les systèmes existants	2-3 jours (pipeline LLM auto-construit)	2 à 4 heures (amarrage API)	6 à 12 fois	L'API Dify élimine le besoin d'accès au modèle, de construction de RAG, de gestion de session, etc.

Les données ci-dessus sont une déduction théorique basée sur les caractéristiques fonctionnelles de l'API Dify et ne constituent pas un engagement officiel. L'amélioration réelle dépend de la complexité du flux de travail, de la qualité de la base de connaissances, de la sélection du modèle et du temps de réponse de l'API.

Limite de la collaboration homme-machine

Les capacités d'automatisation de l'API Dify varient en termes de profondeur d'intervention dans différentes sections :

100% automatisé et sectionné : récupération de la base de connaissances, classification des documents, synthèse de textes, génération de rapports formatés, classification et routage automatique des bons de travail. Ces résultats structurés sont vérifiables et ne causeront pas de dommages irréversibles en cas d'échec.
Articles pour lesquels des points de confirmation manuelle doivent être définis : conclusions de l'examen des termes du contrat, plans de traitement des réclamations des clients, instructions de paiement/remboursement, publication de contenu en ligne et toute sortie d'IA impliquant des effets juridiques ou des opérations financières. Le nœud « Branchement conditionnel » du flux de travail Dify peut configurer un chemin de « révision manuelle » dans de tels scénarios : l'IA génère des suggestions, puis les achemine vers la file d'attente de confirmation manuelle, puis effectue les opérations suivantes après confirmation.

Personnes concernées

L'API Dify cible une population très pertinente pour la plateforme Dify, mais il existe des différences significatives en termes de compétences requises et de niveaux d'autorisation.

Développeurs Backend/Full Stack : groupe d'utilisateurs principaux. Les développeurs qui doivent intégrer des fonctionnalités d'IA dans les systèmes existants sont préoccupés par la réactivité des API, l'exhaustivité de la documentation, les mécanismes de gestion des erreurs et la qualité du SDK. Valeur d'adaptation : L'API Dify permet aux développeurs d'obtenir des capacités complètes d'orchestration d'IA via des appels HTTP sans créer leur propre pipeline LLM (le modèle est connecté à RAG pour créer l'orchestration d'agent). Ne correspond pas aux limites : Si le projet ne nécessite qu'un seul appel LLM simple (comme la traduction d'un morceau de texte), appeler directement l'API du fournisseur de modèles est plus simple que de passer par l'API Dify, dont la couche d'orchestration est ici trop abstraite.
Ingénieurs DevOps/Platform : l'équipe responsable des déploiements auto-hébergés Dify et des opérations de passerelle API. Ils se soucient de la stabilité de l'API, de l'observabilité (journaux, surveillance, alarmes), de l'évolutivité et de la configuration de la sécurité. Valeur d'adaptation : le mode d'exécution asynchrone de l'API Dify et le mécanisme de rappel Webhook réduisent la complexité d'exploitation et de maintenance des tâches à long terme ; les journaux d’audit de la version entreprise et l’intégration SSO répondent aux exigences de conformité. Ne convient pas aux limites : pour les équipes disposant de ressources GPU limitées ou n'ayant aucune expérience en déploiement conteneurisé, le coût d'exploitation et de maintenance de l'API Dify auto-hébergée peut être supérieur aux frais d'abonnement à la version cloud. Il est recommandé de comparer le coût de la main d’œuvre et le coût économique avant de prendre une décision.
Chef de produit technique/architecte de solutions : le décideur qui conçoit des solutions d'intégration d'IA pour des scénarios commerciaux. Ils s'inquiètent des limites des capacités des API, de la compatibilité avec les piles technologiques existantes, du risque de dépendance vis-à-vis d'un fournisseur et de la souveraineté des données. Valeur d'adaptation : le modèle « une orchestration, plusieurs appels » de l'API Dify réduit le coût de la construction dupliquée de fonctions d'IA entre plusieurs systèmes ; la fonctionnalité open source et d'auto-hébergement élimine les problèmes de dépendance vis-à-vis du fournisseur. Limite inadéquate : si l'exigence commerciale est d'acheter un produit SaaS prêt à l'emploi plutôt que d'intégrer des fonctionnalités d'IA, l'API Dify n'est pas un choix approprié. Pour le moment, la priorité doit être donnée à l'application Web de Dify Cloud ou à des produits SaaS similaires.
AI Application Entrepreneurship Team : une première équipe qui vérifie rapidement les idées de produits d'IA. Valeur d'adaptation : L'API Dify fournit une infrastructure d'orchestration d'IA prête à l'emploi, afin que les équipes puissent concentrer leurs ressources sur la logique métier et l'expérience utilisateur. Non applicable : lorsque le nombre d'utilisateurs augmente au point où une optimisation extrême des performances de l'API (telle qu'une réponse au niveau de la milliseconde) ou un comportement profondément personnalisé du moteur de flux de travail est requis, la couche d'abstraction de l'API Dify peut devenir un goulot d'étranglement. À ce moment-là, il est nécessaire d'évaluer s'il est nécessaire de migrer vers un pipeline auto-construit.

Résumé et Outlook

L'API Dify est la couche de produit clé permettant à la plate-forme Dify de passer des « outils d'orchestration internes » à « l'infrastructure de plate-forme ». Sa principale compétitivité réside dans la combinaison « runtime d'exécution unifié + couverture complète des API + open source et auto-hébergement » - les développeurs n'ont pas besoin de choisir entre « fonctions complètes mais fermées » (API Coze) et « fonctions open source mais dispersées » (Flowise/LangFlow).

Principaux avantages : L'API Dify et la console Web partagent le même moteur d'exécution, éliminant ainsi les incohérences entre les tests et la production ; Les points de terminaison de l'API couvrent l'ensemble des liens de gestion du flux de travail RAG, Agent et modèle, et une plate-forme unique répond à la plupart des besoins d'orchestration de l'IA ; la version communautaire open source peut être auto-hébergée, avec une souveraineté des données illimitée.

Limites actuelles : Les fonctions de gestion avancées au niveau de l'API (RBAC à granularité fine, isolation multi-tenant, politiques tarifaires personnalisées) ne sont disponibles que dans la version entreprise, et il existe un écart de gouvernance de sécurité entre la version communautaire et la version Cloud ; l'API de gestion de documents ne prend pas en charge les opérations atomiques pour les téléchargements par lots et la synchronisation incrémentielle, et la construction d'une base de connaissances à grande échelle nécessite une orchestration externe ; le SDK a une couverture limitée des langages (seuls Python et JS sont officiellement maintenus), et d'autres langages dépendent des contributions de la communauté.

Points d'observation de suivi : après la mise à niveau de l'architecture de l'agent, si la couche API publiera indépendamment les points de terminaison spécifiques à l'agent ; si l'API de la version entreprise ajoutera la prise en charge de GraphQL pour répondre à des scénarios de requêtes complexes multi-sources de données ; si la spécification OpenAPI de l'API peut être mise à jour de manière synchrone avec la version de la plateforme (il y a actuellement un certain décalage).

Évaluation des risques d'approvisionnement/d'adoption : lors de la phase de sélection de la technologie, il est recommandé d'utiliser d'abord Cloud Free Edition pour vérifier si les capacités de l'API et la latence de réponse répondent aux besoins de l'entreprise. Après avoir réussi la vérification, vous pouvez décider d'utiliser l'édition Cloud Professional ou l'édition Community auto-hébergée. Pour les moyennes et grandes entreprises ayant des exigences de conformité strictes, elles doivent se concentrer sur la vérification des conditions suivantes avant de signer un contrat de version entreprise : étendue de la garantie API SLA (telle que le temps de disponibilité mensuel, le mécanisme de nouvelle tentative d'expiration, l'objectif de temps de récupération en cas d'échec), l'emplacement de stockage des données et la politique de suppression des données. Mécanisme de partage des responsabilités après une fuite de clé API. Pour les équipes entrepreneuriales, la conscience budgétaire de « l'API Dify est la couche d'orchestration, et les frais de l'API du modèle sont le coût principal » devrait être établie - à mesure que l'utilisation augmente, les frais d'appel du modèle dépasseront de loin les frais du package Dify, et des stratégies de sélection de modèle et d'optimisation des coûts doivent être planifiées à un stade précoce (comme l'utilisation de modèles rentables pour gérer des tâches simples et la réduction des coûts d'entrée répétés grâce à la mise en cache contextuelle).

Outils associés : ÉquipageAI, langchain

Informations de version

Modifier l'API v1.14.2 ：Renforcement de la sécurité et correction des bogues, amélioration de l'architecture sous-jacente de l'agent, amélioration de la fiabilité des API de flux de travail et optimisation du déploiement auto-hébergé. Le niveau API se synchronise avec les améliorations de stabilité de la plateforme v1.14.2. （2026-05-19）
Modifier l'API v1.14.1 ：Renforcement de la sécurité, améliorations de la stabilité des API de flux de travail et nettoyage du déploiement auto-hébergé. （2026-05-12）
Modifier l'API v1.14.0 ：La fonction de version principale a été mise à jour et les points de terminaison liés à l'orchestration d'agent ont été ajoutés simultanément au niveau de l'API. Veuillez vous référer au journal des modifications officiel. （2026-04-29）
Dify API v1.0 version officielle ：Dans cette version marquante, la couche API est officiellement entrée dans la phase de production, fournissant une couverture complète de l'API REST et une documentation sur les spécifications OpenAPI. （2025-01-01）

Avis des utilisateurs

Chargement des avis...