Skip to main content
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.