add docs for trigger environment variable (#525)

* add docs for trigger environment variable

* add saas-related content & fix schedule trigger testing content

---------

Co-authored-by: Riskey <riskey47@dify.ai>
This commit is contained in:
Riskey
2025-11-20 21:43:41 +08:00
committed by GitHub
parent 151a12d540
commit fb91df937e
19 changed files with 156 additions and 75 deletions

View File

@@ -24,6 +24,12 @@ The front-end URL of the console web interface. This is used to construct front-
The Service API URL, used to display Service API Base URL in the front-end. If left empty, it defaults to the same domain as the application. Example: `https://api.dify.ai`
### TRIGGER_URL
The base URL prefix used for the webhook callback URLs in both webhook triggers and plugin triggers.
Ensure it points to a public domain or IP address accessible to external systems.
### APP_API_URL
The WebApp API backend URL, used to specify the backend URL for the front-end API. If left empty, it defaults to the same domain as the application. Example: `https://app.dify.ai`

View File

@@ -25,7 +25,7 @@ For example, suppose you have installed a GitHub trigger plugin. It provides a l
2. Select an existing subscription or [create a new one](#create-a-new-subscription).
<Tip>
You can view how many workflows is using a specific subscription from the plugin's details panel under **Plugins**.
View how many workflows are using a specific subscription from the plugin's details panel under **Plugins**.
</Tip>
3. Configure any other required settings.
@@ -71,7 +71,7 @@ Dify supports the following two methods for creating subscriptions (webhooks), b
On Dify Cloud, many popular trigger plugins are pre-configured with default OAuth clients so you can authorize Dify with a single click.
In self-hosted environments, only the custom OAuth client option is available, meaning that you need to create the OAuth application yourself in the external system.
For self-hosted deployments, only the custom OAuth client option is available, meaning that you need to create the OAuth application yourself in the external system.
<Tabs>
<Tab title="Default OAuth Client">
@@ -123,9 +123,9 @@ Dify supports the following two methods for creating subscriptions (webhooks), b
</Tabs>
<Info>
The **Callback URL** displayed on the subscription configuration page is used internally by Dify to create the webhook in the external system on your behalf.
You don't need to take any action with this URL.
The displayed **Callback URL** is used internally by Dify to create the webhook in the external system on your behalf, so you don't need to take any action with this URL.
For self-hosted deployments, you can change the URL's base prefix via the `TRIGGER_URL` environment variable. Ensure it points to a public domain or IP address accessible to external systems.
</Info>
</Tab>
@@ -144,9 +144,9 @@ Dify supports the following two methods for creating subscriptions (webhooks), b
4. Click **Create**.
<Info>
The **Callback URL** displayed on the subscription configuration page is used internally by Dify when it creates the webhook in the external system on your behalf.
You don't need to take any action with this URL.
The displayed **Callback URL** is used internally by Dify to create the webhook in the external system on your behalf, so you don't need to take any action with this URL.
For self-hosted deployments, you can change the URL's base prefix via the `TRIGGER_URL` environment variable. Ensure it points to a public domain or IP address accessible to external systems.
</Info>
</Tab>
@@ -157,6 +157,12 @@ Dify supports the following two methods for creating subscriptions (webhooks), b
2. Specify the subscription name and use the provided callback URL to manually create a webhook in the external system.
<Info>
For self-hosted deployments, you can change the callback URL's base prefix via the `TRIGGER_URL` environment variable.
Ensure the prefix points to a public domain or IP address accessible to external systems.
</Info>
3. (Optional) Test the created webhook.
<Info>

View File

@@ -98,9 +98,9 @@ A cron expression is a string that defines the schedule for executing your workf
## Test a Schedule Trigger
When you test a schedule trigger (whether by clicking **Run this step** or selecting it for a workflow test run), the trigger runs immediately, ignoring the configured schedule.
- **Run this step**: The schedule trigger runs immediately, ignoring the configured schedule.
However, when you click **Test Run** > **Run all triggers** to test a workflow with multiple triggers, the schedule trigger will wait for its next scheduled execution time instead of running instantly.
- **Test Run**: The schedule trigger waits for its next scheduled execution time.
{/*
Contributing Section

View File

@@ -1,22 +1,22 @@
---
title: Start
sidebarTitle: "Overview"
sidebarTitle: Overview
---
Start nodes serve as the entry points for workflows and chatflows.
Start nodes serve as the entry points for Workflows and Chatflows.
There are two types of Start nodes, each initiating your application in a different way.
- **[User Input](/en/guides/workflow/node/user-input)**: The application is initiated by direct user interaction or API calls.
- **[Trigger](/en/guides/workflow/node/trigger)** (for workflows only): The application runs automatically on a schedule or in response to a specific third-party event.
<Note>
Only applications that start with a User Input node can be published as standalone web apps or MCP servers, exposed through backend service APIs, or used as tools in other Dify applications.
</Note>
<Note>
Only applications that start with a User Input node can be published as standalone web apps or MCP servers, exposed through backend service APIs, or used as tools in other Dify applications.
</Note>
- **[Trigger](/en/guides/workflow/node/trigger)** (for Workflows only): The application runs automatically on a schedule or in response to a specific third-party event.
<Info>
The User Input node and trigger are mutually exclusive—they cannot be used in the same canvas.
The User Input node and trigger are mutually exclusive—they cannot be used in the same canvas.
To switch between them, right-click the current start node > **Change Node**. Alternatively, delete the current start node and add a new one.
</Info>

View File

@@ -1,6 +1,6 @@
---
title: Trigger
sidebarTitle: "Overview"
sidebarTitle: Overview
---
## Introduction
@@ -15,9 +15,18 @@ Triggers are ideal for automating repetitive tasks or integrating your workflow
A workflow can have multiple triggers running in parallel. You can also build several independent workflows on the same canvas, each starting with its own triggers.
<Info>
The Sandbox plan supports up to 2 triggers per workflow. [Upgrade](https://dify.ai/pricing) to add more.
</Info>
The trigger source for each workflow execution is displayed in the **Logs** section.
<img src="/images/trigger.png" alt="Trigger" width="450" />
<Info>
On Dify Cloud, trigger events (workflow executions initiated by triggers) are subject to a quota that varies by plan. For details, see the [Plan Comparison](https://dify.ai/pricing).
The workspace owner and admins can check the remaining quota in **Settings** > **Billing**.
</Info>
## Trigger Types

View File

@@ -12,16 +12,22 @@ A webhook allows one system to automatically send real-time data to another. Whe
Following the same mechanism, webhook triggers enable your workflow to run in response to third-party events. Here's how you work with it:
1. When you add a webhook trigger to your workflow, a unique webhook URL is generated—a dedicated endpoint that listens for external HTTP requests.
1. When you add a webhook trigger to your workflow, a unique webhook URL is generated—a dedicated endpoint that listens for external HTTP requests.
<Info>
For self-hosted deployments, you can change the base prefix of this URL via the `TRIGGER_URL` environment variable.
Ensure it points to a public domain or IP address accessible to external systems.
</Info>
2. You use this URL to create a webhook subscribing to the events you want to monitor in an external system. Then you configure the webhook trigger to define how it processes incoming requests and extracts request data.
3. When a subscribed event occurs, the external system sends an HTTP request with the event data to that provided webhook URL. Once the request is received and processed successfully, your workflow is triggered, and the specified event data is extracted into variables that can be referenced by downstream nodes.
<Note>
For testing purposes, always use the test webhook URL to keep test data separate from production data.
<img src="/images/test_webhook_url.png" alt="Test Webhook URL" width="563" />
</Note>
<Note>
For testing purposes, always use the test webhook URL to keep test data separate from production data.
<img src="/images/test_webhook_url.png" alt="Test Webhook URL" width="563" />
</Note>
3. When a subscribed event occurs, the external system sends an HTTP request with the event data to that provided webhook URL. Once the request is received and processed successfully, your workflow is triggered, and the specified event data is extracted into variables that can be referenced by downstream nodes.
<Tip>
If there's a ready-made trigger plugin for your target external system, we recommend using the [plugin trigger](/en/guides/workflow/node/plugin-trigger) instead.
@@ -32,7 +38,9 @@ Following the same mechanism, webhook triggers enable your workflow to run in re
On the workflow canvas, right-click and select **Add Node** > **Start** > **Webhook Trigger**.
<Tip>
- A workflow can have multiple webhook triggers running in parallel. When the parallel branches contain identical consecutive nodes, you can add a [Variable Aggregator](/en/guides/workflow/node/variable-aggregator) node to merge the branches before the common section, without duplicating the same nodes across each branch.
A workflow can have multiple webhook triggers running in parallel.
When the parallel branches contain identical consecutive nodes, you can add a [Variable Aggregator](/en/guides/workflow/node/variable-aggregator) node to merge the branches before the common section, without duplicating the same nodes across each branch.
</Tip>
## Configure a Webhook Trigger

View File

@@ -24,6 +24,12 @@ title: 環境変数の説明
サービスAPIのURLです。**フロントエンド**にサービスAPIのベースURLを表示するために使用されます。空の場合は同じドメインになります。例`https://api.dify.ai`
### TRIGGER_URL
WebhookトリガーおよびプラグイントリガーのWebhookコールバックURLで使用されるベースURLプレフィックスです。
プレフィックスは外部システムからアクセス可能な公開ドメインまたはIPアドレスを指定してください。
### APP_API_URL
WebアプリAPIのバックエンドURLです。**フロントエンド**APIのバックエンドアドレスを宣言するために使用されます。空の場合は同じドメインになります。例`https://app.dify.ai`

View File

@@ -2,7 +2,7 @@
title: プラグイントリガー
---
## 概要
## はじめに
<Info>
トリガーは workflow アプリケーションでのみ利用可能です。
@@ -123,9 +123,9 @@ Dify は以下の 2 つの方法でサブスクリプションWebhook
</Tabs>
<Info>
サブスクリプション設定ページに表示される**コールバック URL** は、Dify が外部システムで Webhook を作成する際に内部的に使用されます
この URL に対して何か操作を行う必要はありません
表示されている**コールバック URL**は、Difyが外部システムでWebhookを作成する際に内部的に使用されるため、ユーザー側でこのURLに対して何か操作を行う必要はありません
セルフホスティング環境では、`TRIGGER_URL`環境変数でURLのベースプレフィックスを変更できます。プレフィックスは外部システムからアクセス可能な公開ドメインまたはIPアドレスを指定してください
</Info>
</Tab>
@@ -144,9 +144,9 @@ Dify は以下の 2 つの方法でサブスクリプションWebhook
4. **作成**をクリックします。
<Info>
サブスクリプション設定ページに表示される**コールバック URL** は、Dify が外部システムで Webhook を作成する際に内部的に使用されます
この URL に対して何か操作を行う必要はありません
表示されている**コールバック URL**は、Difyが外部システムでWebhookを作成する際に内部的に使用されるため、ユーザー側でこのURLに対して何か操作を行う必要はありません
セルフホスティング環境では、`TRIGGER_URL`環境変数でURLのベースプレフィックスを変更できます。プレフィックスは外部システムからアクセス可能な公開ドメインまたはIPアドレスを指定してください
</Info>
</Tab>
@@ -157,6 +157,12 @@ Dify は以下の 2 つの方法でサブスクリプションWebhook
2. サブスクリプション名を指定し、提供されたコールバック URL を使用して外部システムで手動で Webhook を作成します。
<Info>
セルフホスティング環境では、`TRIGGER_URL`環境変数でコールバックURLのベースプレフィックスを変更できます。
プレフィックスは外部システムからアクセス可能な公開ドメインまたはIPアドレスを指定してください。
</Info>
3. (オプション)作成した Webhook をテストします。
<Info>

View File

@@ -2,7 +2,7 @@
title: スケジュールトリガー
---
## 概要
## はじめに
<Info>
トリガーは workflow アプリケーションでのみ利用可能です。
@@ -99,9 +99,9 @@ Cron 式は、workflow の実行スケジュールを定義する文字列です
## スケジュールトリガーのテスト
スケジュールトリガーをテストする場合(**このステップ実行**をクリックするか、workflow のテスト実行で選択するかにかかわらず)、トリガーは設定されたスケジュールを無視して即座に実行されます。
- **このステップ実行**:スケジュールトリガーは設定されたスケジュールを無視して即座に実行されます。
ただし、**テスト実行** > **すべてのトリガーを実行**をクリックして workflow のすべてのトリガーを同時にテストする場合、スケジュールトリガーは即座に実行されるのではなく、次のスケジュールされた実行時刻を待ちます。
- **テスト実行**:スケジュールトリガーは次回の予定実行時刻まで待機します。
{/*
Contributing Section

View File

@@ -1,20 +1,20 @@
---
title: 開始
version: '日本語'
sidebarTitle: "概要"
sidebarTitle: 概要
---
開始ノードは、workflow および chatflow のエントリーポイントとして機能します。
開始ノードは、Workflow および Chatflow のエントリーポイントとして機能します。
開始ノードには 2種類があり、それぞれ異なる方法でアプリケーションを開始します。
- **[ユーザー入力](/ja-jp/guides/workflow/node/user-input)**:ユーザーによる直接的な操作や API 呼び出しによって、アプリケーションが開始されます。
- **[トリガー](/ja-jp/guides/workflow/node/trigger)**workflow のみ):アプリケーションはスケジュールに従って、または特定のサードパーティイベントに応じて自動的に実行されます。
<Note>
ユーザー入力ノードで開始するアプリケーションのみ、単体の Web アプリや MCP サーバーとして公開でき、バックエンドサービス API を通じて外部に公開したり、他の Dify アプリケーション内でツールとして利用したりできます。
</Note>
<Note>
ユーザー入力ノードで開始するアプリケーションのみ、単体の Web アプリや MCP サーバーとして公開でき、バックエンドサービス API を通じて外部に公開したり、他の Dify アプリケーション内でツールとして利用したりできます。
</Note>
- **[トリガー](/ja-jp/guides/workflow/node/trigger)**Workflow のみ):アプリケーションはスケジュールに従って、または特定のサードパーティイベントに応じて自動的に実行されます。
<Info>
ユーザー入力ノードとトリガーは相互に排他的であり、同じキャンバス上に共存することはできません。

View File

@@ -1,9 +1,9 @@
---
title: トリガー
sidebarTitle: "概要"
sidebarTitle: 概要
---
## 概要
## はじめに
<Info>
トリガーは workflow アプリケーションでのみ利用可能です。
@@ -15,9 +15,17 @@ sidebarTitle: "概要"
1 つの workflow は、並行して実行される複数のトリガーを持つことができます。また、同じキャンバス上に複数の独立した workflow を構築し、それぞれが独自のトリガーで開始することもできます。
<Info>
Sandbox プランでは、workflow あたり 2 つのトリガーのみがサポートされています。追加するには[アップグレード](https://dify.ai/jp/pricing)してください。
</Info>
各 workflow 実行のトリガーソースは、**ログ**セクションに表示されます。
<img src="/images/trigger.png" alt="Trigger" width="450" />
<Info>
Dify Cloud では、トリガーイベント(トリガーによって開始される workflow 実行)はプランごとに異なる上限が設定されています。詳細は[プラン比較](https://dify.ai/jp/pricing)をご覧ください。
ワークスペースのオーナーおよび管理者は、**設定** > **請求**で残りのクォータを確認できます。
</Info>
## トリガータイプ

View File

@@ -2,7 +2,7 @@
title: ユーザー入力
---
## 概要
## はじめに
ユーザー入力ノードは開始ノードの一種で、エンドユーザーがアプリケーションを実行する際に収集する情報を定義できます。

View File

@@ -2,7 +2,7 @@
title: Webhook トリガー
---
## 概要
## はじめに
<Info>
トリガーは workflow アプリケーションでのみ利用可能です。
@@ -14,14 +14,20 @@ Webhook を使用すると、あるシステムが別のシステムにリアル
1. workflow に Webhook トリガーを追加すると、一意の Webhook URL が生成されます。これは、外部 HTTP リクエストをリッスンする専用エンドポイントです。
<Info>
セルフホスティング環境では、`TRIGGER_URL`環境変数でこのURLのベースプレフィックスを変更できます。
プレフィックスは外部システムからアクセス可能な公開ドメインまたはIPアドレスを指定してください。
</Info>
2. この URL を使用して、外部システムで監視したいイベントをサブスクライブする Webhook を作成します。次に、Webhook トリガーを設定して、受信リクエストの処理方法とリクエストデータの抽出方法を定義します。
3. サブスクライブしたイベントが発生すると、外部システムはイベントデータを含む HTTP リクエストを提供された Webhook URL に送信します。リクエストが正常に受信および処理されると、workflow がトリガーされ、指定されたイベントデータが変数として抽出され、ダウンストリームノードで参照できるようになります。
<Note>
テスト目的では、常にテスト Webhook URL を使用して、テストデータを本番データから分離してください。
<img src="/images/test_webhook_url.png" alt="Test Webhook URL" width="563" />
</Note>
<Note>
テスト目的では、常にテスト Webhook URL を使用して、テストデータを本番データから分離してください。
<img src="/images/test_webhook_url.png" alt="Test Webhook URL" width="563" />
</Note>
3. サブスクライブしたイベントが発生すると、外部システムはイベントデータを含む HTTP リクエストを提供された Webhook URL に送信します。リクエストが正常に受信および処理されると、workflow がトリガーされ、指定されたイベントデータが変数として抽出され、ダウンストリームノードで参照できるようになります。
<Tip>
対象の外部システムに既製のトリガープラグインがある場合は、代わりに[プラグイントリガー](/ja-jp/guides/workflow/node/plugin-trigger)を使用することをお勧めします。
@@ -32,7 +38,9 @@ Webhook を使用すると、あるシステムが別のシステムにリアル
workflow キャンバスで右クリックし、**ブロックを追加** > **始める** > **Webhook トリガー**を選択します。
<Tip>
1 つの workflow は、並行して実行される複数の Webhook トリガーで開始できます。並行分岐に同一の連続したノードが含まれている場合、共通セクションの前に[変数集約](/ja-jp/guides/workflow/node/variable-aggregator)ノードを追加して分岐をマージできます。これにより、各分岐で同じノードを個別に重複して追加することを回避できます。
1 つの workflow は、並行して実行される複数の Webhook トリガーで開始できます。
並行分岐に同一の連続したノードが含まれている場合、共通セクションの前に[変数集約](/ja-jp/guides/workflow/node/variable-aggregator)ノードを追加して分岐をマージできます。これにより、各分岐で同じノードを個別に重複して追加することを回避できます。
</Tip>
## Webhook トリガーの設定

View File

@@ -24,6 +24,12 @@ title: 环境变量说明
Service API URL用于 **前端** 展示 Service API Base URL传空则为同域。范例`https://api.dify.ai`
### TRIGGER_URL
用作 Webhook 触发器和插件触发器的 webhook 回调 URL 的基础前缀。
需确保其指向外部系统可访问的公共域名或 IP 地址。
### APP_API_URL
WebApp API 后端 URL用于声明 **前端** API 后端地址,传空则为同域。范例:`https://app.dify.ai`

View File

@@ -25,7 +25,7 @@ title: 插件触发器
2. 选择一个现有订阅或 [创建新订阅](#创建新订阅)。
<Tip>
在 **插件** 页面的插件详情面板中,你可以查看某个特定订阅正在被多少个 Workflow 使用。
在 **插件** 页面的插件详情面板中,查看某个特定订阅正在被多少个 Workflow 使用。
</Tip>
3. 配置其他必需设置。
@@ -71,7 +71,7 @@ Dify 支持通过以下两种方法创建订阅webhook但每个插件
在 Dify Cloud 上,许多主流触发器插件都有预配置的默认 OAuth 客户端,一键即可授权 Dify。
自托管环境中,只能通过自定义 OAuth 客户端进行授权,即你需要在外部系统中自行创建 OAuth 应用。
对于自托管部署,只能通过自定义 OAuth 客户端进行授权,即你需要在外部系统中自行创建 OAuth 应用。
<Tabs>
<Tab title="默认 OAuth 客户端">
@@ -125,9 +125,9 @@ Dify 支持通过以下两种方法创建订阅webhook但每个插件
</Tabs>
<Info>
订阅配置页面上显示的 **回调 URL** 由 Dify 用于代表你在外部系统中创建 webhook。
订阅配置页面上显示的 **回调 URL** 由 Dify 用于代表你在外部系统中创建 webhook。你无需对此 URL 执行任何操作。
你无需对此 URL 执行任何操作
对于自托管部署,可通过 `TRIGGER_URL` 环境变量更改回调 URL 的基础前缀。需确保其指向外部系统可访问的公共域名或 IP 地址
</Info>
</Tab>
@@ -146,9 +146,9 @@ Dify 支持通过以下两种方法创建订阅webhook但每个插件
4. 点击 **创建**。
<Info>
订阅配置页面上显示的 **回调 URL** 由 Dify 用于代表你在外部系统中创建 webhook。
订阅配置页面上显示的 **回调 URL** 由 Dify 用于代表你在外部系统中创建 webhook。你无需对此 URL 执行任何操作。
你无需对此 URL 执行任何操作
对于自托管部署,可通过 `TRIGGER_URL` 环境变量更改回调 URL 的基础前缀。需确保其指向外部系统可访问的公共域名或 IP 地址
</Info>
</Tab>
@@ -159,6 +159,10 @@ Dify 支持通过以下两种方法创建订阅webhook但每个插件
2. 指定订阅名称,并使用提供的回调 URL 在外部系统中手动创建 webhook。
<Info>
对于自托管部署,可通过 `TRIGGER_URL` 环境变量更改回调 URL 的基础前缀。需确保其指向外部系统可访问的公共域名或 IP 地址。
</Info>
3. (可选)测试已创建的 webhook。
<Info>

View File

@@ -96,11 +96,12 @@ Cron 表达式是一段可用于定义 Workflow 运行计划的字符串,由
| 每月最后一天下午 5 点 | `0 17 L * *` |
| 每月最后一个星期五晚上 10 点 | `0 22 * * 5L` |
## 测试定时触发器
当你测试一个定时触发器时(无论是点击 **运行此步骤** 还是指定其用于 Workflow 的测试运行),触发器会立即运行,忽略已配置的时间表
- **运行此步骤**:定时触发器会忽略已配置的计划,立即运行
然而,当你点击 **测试运行** > **运行所有触发器** 来测试包含多个触发器的 Workflow 时,其中的定时触发器会等待其下一个计划运行时间,而不会立即运行
- **测试运行**定时触发器会等待其下一个计划运行时间。
{/*
Contributing Section

View File

@@ -1,6 +1,6 @@
---
title: 开始
sidebarTitle: "概述"
sidebarTitle: 概述
---
开始节点是 Workflow 和 Chatflow 的起点。
@@ -9,11 +9,11 @@ Dify 支持两种类型的开始节点,可分别以不同的方式启动你的
- **[用户输入](/zh-hans/guides/workflow/node/user-input)**:通过用户交互或 API 调用启动应用。
- **[触发器](/zh-hans/guides/workflow/node/trigger)**(仅适用于 Workflow应用定时运行或当特定的第三方事件发生时自动运行。
<Note>
只有以用户输入节点为起点的应用,才能被发布为独立的 Web App 或 MCP 服务器、对外暴露为后端服务 API或作为工具在其他 Dify 应用中使用。
</Note>
<Note>
只有以用户输入节点为起点的应用,才能被发布为独立的 Web App 或 MCP 服务器、对外暴露为后端服务 API或作为工具在其他 Dify 应用中使用。
</Note>
- **[触发器](/zh-hans/guides/workflow/node/trigger)**(仅适用于 Workflow应用定时运行或当特定的第三方事件发生时自动运行。
<Info>
用户输入节点与触发器互斥,不能共存于同一画布中。

View File

@@ -1,6 +1,6 @@
---
title: 触发器
sidebarTitle: "概述"
sidebarTitle: 概述
---
## 简介
@@ -15,9 +15,18 @@ sidebarTitle: "概述"
一个 Workflow 可同时拥有多个并行的触发器。你也可以在同一画布上构建多个独立的、以不同触发器作为起点的 Workflow。
每次 Workflow 执行的触发源将显示在 **日志** 中。
<Info>
对于 Sandbox 套餐,每个 Workflow 最多可添加 2 个触发器。[升级](https://dify.ai/zh/pricing) 以添加更多。
</Info>
每次 Workflow 运行的触发源将显示在 **日志** 中。
<Info>
在 Dify Cloud 上,触发器事件(由触发器启动的 Workflow 运行)受套餐配额限制。详见 [套餐对比](https://dify.ai/zh/pricing)。
工作区所有者和管理员可在 **设置** > **账单** 页面查看剩余配额。
</Info>
<img src="/images/trigger.png" alt="Trigger" width="450" />
## 触发器类型

View File

@@ -14,17 +14,21 @@ Webhook 允许一个系统自动向另一个系统发送实时数据。当某个
1. 在 Workflow 中添加 Webhook 触发器后,系统将自动生成一个 webhook URL 作为监听外部 HTTP 请求的专用端点。
<Info>
对于自托管部署,可通过 `TRIGGER_URL` 环境变量更改此 URL 的基础前缀。需确保其指向外部系统可访问的公共域名或 IP 地址。
</Info>
2. 你使用此 URL 在外部系统中创建一个 webhook订阅期望关注的事件。然后在 Dify 中配置 Webhook 触发器,定义其如何处理接收到的请求并提取请求中的事件数据。
<Note>
在测试场景中,请始终使用测试专用的 webhook URL以分离测试与生产数据。
<img src="/images/test_webhook_url.png" alt="Test Webhook URL" width="563" />
</Note>
3. 当订阅的事件发生时,外部系统会将包含事件数据的 HTTP 请求发送到先前提供的 webhook URL。一旦请求被成功接收和处理你的 Workflow 会被触发,而提取到的事件数据也将成为下游节点可引用的变量。
<Note>
在测试场景中,请始终使用测试专用的 webhook URL以分离测试与生产数据。
<img src="/images/test_webhook_url.png" alt="Test Webhook URL" width="563" />
</Note>
<Tip>
若目标外部系统有可用的触发器插件,我们推荐用 [插件触发器](/zh-hans/guides/workflow/node/plugin-trigger)。
若目标外部系统有可用的触发器插件,推荐使用 [插件触发器](/zh-hans/guides/workflow/node/plugin-trigger)。
</Tip>
## 添加 Webhook 触发器