# uip user

> Syntax and options for `uip user`, which shows identity information about the currently logged-in session.

`uip user` shows who the current session is authenticated as — a `whoami` for `uip`. It takes no arguments and no options beyond the global ones.

## Synopsis

```
uip user
```

`uip user` honors the [global options](./global-options.md) (`--output`, `--output-filter`, `--log-level`, `--log-file`). Exit codes follow the [standard contract](./exit-codes.md).

## Arguments

None.

## Options

None beyond the global options.

## Example

```bash
uip user
```

## Data shape (--output json)

```json
{
  "Code": "User",
  "Data": {
    "UserId": "a1b2c3d4-0000-0000-0000-000000000001",
    "Name": "Jane Doe",
    "Username": "jane.doe@my-org",
    "Email": "jane.doe@my-org.com",
    "FirstName": "Jane",
    "LastName": "Doe"
  }
}
```

The fields are parsed straight out of the session's access token claims. When the active session is an **application (client-credentials) session** rather than a human user, there is no person behind it — `UserId`/`Name`/`Username`/`Email`/`FirstName`/`LastName` come back as empty strings, but the response also includes `IdentityType` (identifying it as an application identity) and `ClientId`, so a script can distinguish "no user data" from "not actually a user."

## Failure behavior

- Not logged in: `AuthenticationError`, exit code `2`, with `Instructions` pointing to `uip login`.
- Session present but the login-status check itself fails (for example, a corrupted credentials file): `ConfigError`, exit code `1`.

## Related

- [uip login](./uip-login.md) — start the session `uip user` reports on.
- [uip login status](./uip-login-status.md) — session-level detail (org, tenant, expiration) rather than user identity.
- [Authentication](./authentication.md) — the credential model behind the session.

## See also

- [Global options](./global-options.md)
- [Exit codes](./exit-codes.md)