user フィールドを受け取ります。呼び出しがどのエンドユーザーの代理かを示す、自前の識別子です。Dify はこれを認証しません。アカウント ID など、1 人につき 1 つの安定した値を選び、常に同じ値を送ってください。
新しい user は初めて登場した時点で Dify が追跡を始め、1 つのアプリキーで任意の数のエンドユーザーに対応できます。
user が制御する範囲
user は、各呼び出しが何を参照でき、何を実行できるかを決めます。
- 会話：一覧、履歴、名前の変更、削除はいずれも、そのユーザーの会話だけを対象とします。
-
ファイル：アップロードしたファイルはアップロードしたユーザーに属し、別の
userで参照すると失敗します。 -
生成の停止：チャット系の停止エンドポイントは、
userが返信を開始したユーザーと一致する場合にのみ機能します。一致しない場合は黙って無視されます。呼び出し自体はどちらでも成功するため、レスポンスからは判別できません。 ワークフローの「ワークフロータスクを停止」はuserを確認しません。 -
実行の再開：
userが実行の作成者と一致しない場合、ワークフローイベントをストリーム は 404 を返します。
user を使い続けてください。アップロード、送信、停止、再開のすべてがこの値を確認します。
API ユーザーと WebApp ユーザーの分離
API 経由のトラフィックと Dify がホストする WebApp では、ユーザーの識別が別々に管理されます。API ユーザーが作成した会話は WebApp に表示されず、WebApp の会話も API からは取得できません。エンドユーザー ID の解決
一部のレスポンスは、詳細情報の代わりにエンドユーザー ID を含みます。「ファイルをアップロード」のレスポンスにあるcreated_by などです。エンドユーザー取得 でこの ID を解決できます。