ワークフローを実行
対象アプリ：Workflow。
デプロイした Workflow のバージョンを、ブロッキングまたはストリーミングで実行します。
標準 API の対応する操作：ワークフローを実行。相違点は次のとおりです。
workflow_idとボディの未知のフィールドは無視されます。trace_idとtrace_session_idを受け付けます。- リクエストボディの上限は 8 MiB です。
- ストリームに TTS、人間の入力、エージェントログ、検索ソースのイベントは含まれません。人間の入力が必要な手順に達した実行は失敗します。
- エラーコードが異なります。
承認
すべてのリクエストは API キーで認証します：Authorization: Bearer {API_KEY}。アプリのエンドポイントにはアプリの API キーを、ナレッジのエンドポイントにはナレッジベースの API キーを使用します（Dify API クイックスタート）。
キーはサーバーサイドで保管し、クライアントコードには決して埋め込まないでください。キーが欠落または無効なリクエストは HTTP 401（unauthorized）で失敗します。
ヘッダー
ボディの trace_id と同じです。最初に読み取られます。
ボディの trace_session_id と同じです。最初に読み取られます。
クエリパラメータ
ボディの trace_id と同じです。ヘッダーの次に読み取られます。
ボディの trace_session_id と同じです。ヘッダーの次に読み取られます。
ボディ
アプリの入力変数の値を、変数名をキーとして指定します。対象環境に現在デプロイされているバージョンの入力変数に従って値を渡してください。
単一ファイル変数にはファイルオブジェクトを、ファイルリスト変数にはその配列を渡します。各オブジェクトの構造は files の各要素と同じです。
エンドユーザーの識別子。アプリ側で定義し、アプリ内で一意にします。データアクセスをスコープします。ワークフロー実行とそのファイルは、同じ user を持つ後続のリクエストにのみ表示されます。エンドユーザーの識別 を参照してください。
レスポンスをどう返すかを指定します。
streaming：実行が生成したイベントが順次届きます。短い応答以外はこちらを使います。blocking：実行の完了後に 1 つのレスポンスを返します。
streaming, blocking ワークフローに渡すファイルです。ローカルファイルの場合は、まず ファイルをアップロード でアップロードし、返された id を upload_file_id として transfer_method: local_file で指定します。
受け付けるかどうかは、許可するタイプや個数など、ワークフロー自身のファイル設定で決まります。ファイルを受け付けないワークフローでは、これらの項目は無視されます。
可観測性データに伝播されるトレース識別子です。英数字、ハイフン、アンダースコアを 128 文字まで使用できます。条件に合わない値は、エラーにならず読み飛ばされます。
可観測性データに伝播されるトレースセッション識別子です。前後の空白を除いて 1〜200 文字です。
1 - 200レスポンス
コンテンツタイプと構造はリクエストの response_mode パラメータに依存します。
response_modeがblockingの場合、application/jsonでWorkflowBlockingResponseオブジェクトを返します。response_modeがstreamingの場合、text/event-streamでChunkWorkflowEventオブジェクトのストリームを返します。
この実行のタスク ID です。ブロッキングモードでは最後のボディにのみ含まれます。そのため ワークフロータスクを停止 が実用的なのは、ストリーミングの場合だけです。
このワークフロー実行の ID です。