> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dify.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# End User Identity

> What the user field identifies, what it scopes, and why it must stay consistent across calls

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](/en/api-reference/workflow-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](/en/api-reference/end-users/get-end-user-info) resolves it.