Dify 的 workflow 模式，对的 AI 应用发布和管理非常友好：
当我们在 Dify 的工作台上完成Workflow的创建后，可以发布成 API，提供外部服务给其他的项目。
正好这段时间，项目上有一个 WorfFlow的 API要打包发布给其他的项目使用，顺手就整理一下对应的 API发布和调用方式文档。
通过这个文档，可以清晰了解 API发布方法、流式和块状调用、获取执行情况方式。
为了方便演示，我在 Dify 上搭建了一个极简的Workflow，输入是三个字段的内容，返回的结果是字段拼接后的字符串。
Workflow全貌
输入内容
包含字符、数字和选项三种类型的输入。
输出节点
直接返回三种类型输入拼接后的字符串。
需要留意的是：在开始 API 调用之前，该 Workflow 必须处于发布状态。
准备工作完成后，我们逐一进行 API发布和调用方式的说明。
Base URL
点击“访问 API”，查看 API 服务器地址：
这里有一个需要注意的，官方给的 BaseURL 是不带端口号的。
按照我们实际项目实操经验来看，不带端口号无法调通。所以，这里务必增加端口号。
比如，我这个项目的 IP 服务器地址是：http://10.30.14.104/v1
那我在调用的时候，就得把对应的 8098 端口号补上。
http://10.30.14.104:8098/v1
Authentication鉴权
Dify Service API 使用 API-Key 进行鉴权。
接下来，创建 APIKey。在 Dify 中，API的创建方式也很简单，右上角点击“API密钥”后，即可创建。
所有 API 请求都应在 Authorization HTTP Header 中包含 API-Key，如下所示：
Authorization: Bearer {API\_KEY}
执行 workflow
POST/workflows/run
再次敲重点，执行 workflow，没有已发布的 workflow，不可执行。
Request
curl -X POST 'http://10.30.14.104:8098/v1/workflows/run' \
--header 'Authorization: Bearer {api\_key}' \
--header 'Content-Type: application/json' \
--data-raw '{ "inputs": {}, "response\_mode": "streaming", "user": "abc-123"}'
这里最关键的 input 请求内容，是一个json 字符串，根据该 WorkFlow 的实际情况发起。
根据我的 Demo workflow，我的 Request 内容是这样的：
以及 Header 的鉴权内容：
Request Body说明
- inputs (object) Required 允许传入 App 定义的各变量值。 inputs 参数包含了多组键值对（Key/Value pairs），每组的键对应一个特定变量，每组的值则是该变量的具体值。这里为了简化演示，我只示范了文字类型（Json）的访问示例。
对应的代码内容如下：
{ "inputs": {"string":"这是一段测试文本","num":10000,"list":"list\_b"}, "response\_mode": "blocking", "user": "木乐乐"}
这部分跟我的 WorkFlow input 内容是一一对应的。
我把文本和下拉选项两个输入变量的创建模式贴出来：
-
response_mode (string) Required 返回响应模式，支持两种模式：blocking 和 steaming。
blocking 阻塞模式
等待执行完毕后返回结果。（请求若流程较长可能会被中断）。 由于 Cloudflare 限制，请求会在 100 秒超时无返回后中断。
streaming 流式模式
如果要实现逐字吞吐的模式，可以把 response_mode 改成 streaming，流式模式。基于 SSE（Server-Sent Events）实现类似打字机输出方式的流式返回。
这个是返回的内容：
对于Workflow 而言，streaming 返回的模式，是输出了每个节点的处理记录。
我们回顾一下 demo workflow的三个节点：开始->code->end。
这个是我用 apifox 解析后的 streaming timeline：
Start：
Code：
End:
- user (string) Required 用户标识
用于定义终端用户的身份，方便检索、统计。 由开发者定义规则，需保证用户标识在应用内唯一。
我这里对应的是：木乐乐，有什么用呢？当我们做用户回归测试的时候，可以在 Dify 里筛选user 记录，锁定指定用户的请求内容。
CompletionResponse返回数据
返回完整的 App 结果，Content-Type 为 application/json 。
Blocking
Streaming（最后一个 sequence）
这里对几个核心参数做说明：
- workflow_run_id (string) workflow 执行 ID
- task_id (string) 任务 ID，用于请求跟踪和下方的停止响应接口
- data (object) 详细内容
-
id (string) workflow 执行 ID
-
workflow_id (string) 关联 Workflow ID
-
status (string) 执行状态, running / succeeded / failed / stopped
-
outputs (json) Optional 输出内容
-
error (string) Optional 错误原因
-
elapsed_time (float) Optional 耗时(s)
-
total_tokens (int) Optional 总使用 tokens
-
total_steps (int) 总步数（冗余），默认 0
-
created_at (timestamp) 开始时间
-
finished_at (timestamp) 结束时间
报错代码Errors
如果workflow 运行失败，会有不同的报错码返回。如下是对照表：
-
400，invalid_param，传入参数异常
-
400，app_unavailable，App 配置不可用
-
400，provider_not_initialize，无可用模型凭据配置
-
400，provider_quota_exceeded，模型调用额度不足
-
400，model_currently_not_support，当前模型不可用
-
400，workflow_request_error，workflow 执行失败
-
500，服务内部异常
以上是 Dify 的 workflow api 调用的方法和说明。更多细节，可以翻阅官方文档，路径如下：
更多 Dify 相关教程，可以查看如下列表：
Dify RAG知识库优化实战｜双知识库+意图路由，实现 ChatBI精度与速度双提升
Agent 开发者重大利好！Dify 知识库 RAG 升级 Knowledge pipeline
手把手教程｜在 Dify 中手搓一个 AIAgent 智能体
在 Dify 上配置 MCP 智能体｜高德地图 MCP 路径规划为例
别只羡慕Manus了！顶级AI Agent的4个核心策略，Dify和LangChain开发者都能偷师
Dify v1.5.0 版本深度解读：开发者必看核心特性与升级全解析