チャットメッセージを送信
対象アプリ：Chatflow。
デプロイした Chatflow アプリにメッセージを送信し、ブロッキングまたはストリーミングで回答を返します。
標準 API の対応する操作：チャットメッセージを送信。相違点は次のとおりです。
workflow_idとauto_generate_nameは無視されます。trace_idとtrace_session_idを受け付けます。- ストリームに TTS、モデレーション、アノテーション、Agent のイベントは含まれません。
- エラーコードが異なります。
承認
すべてのリクエストは 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でChatCompletionResponseオブジェクトを返します。response_modeがstreamingの場合、text/event-streamでサーバー送信イベントのストリームを返します。
常に message です。
この実行のタスク ID です。ブロッキングモードでは最後のボディにのみ含まれます。そのため チャットメッセージの生成を停止 が実用的なのは、ストリーミングの場合だけです。
メッセージ ID。
メッセージ ID です（id と同じ値）。
このターンが属する会話です。conversation_id を省略した場合は、新しい会話の ID が返ります。
常に advanced-chat です。
回答の全文です。
実行のメタデータです。トークン数、料金、レイテンシを含む usage が入ります。
実行の開始時刻（Unix タイムスタンプ、秒）です。