Most app endpoints take a user field: your own identifier for the end user a call acts on behalf of. Dify never authenticates it, so pick a stable value per person, such as an account ID, and send it consistently.
Dify starts tracking a new user the first time it appears, and one app key serves any number of end users.
What user Scopes
user controls what each call can see and do:
-
Conversations: listing, history, renaming, and deletion all operate on that user’s conversations only.
-
Files: an upload belongs to the uploading user, and referencing it under a different
user fails.
-
Stopping generation: the chat-family stop endpoints act only when
user matches the one that started the reply. A mismatch is silently ignored—the call succeeds either way, so it isn’t detectable from the response.
Workflow’s Stop Workflow Task does not check user.
-
Resuming runs: Stream Workflow Events returns a 404 when
user doesn’t match the run’s creator.
Keep one user per person across every call in a flow—upload, send, stop, and resume all check it.
API Users and WebApp Users Stay Separate
Traffic through the API and Dify’s hosted WebApp keep separate identities: conversations your API users create never appear in the WebApp, and WebApp conversations never appear through the API.
Resolve an End-User ID
Some responses carry an end-user ID instead of full details, such as created_by in the Upload File response. Get End User Info resolves it. Last modified on July 9, 2026
