> ## Documentation Index > Fetch the complete documentation index at: https://docs-pos.solya.app/llms.txt > Use this file to discover all available pages before exploring further. # Resolve the authenticated actor's identity and effective POS scopes > Returns WHO the calling credential is and WHAT it may do: the caller's own team-directory row and the `pos.*` scopes it currently holds. This is the discovery entry point: call it FIRST, once, before planning any other work, and use the answer to decide what to attempt. THE IDENTITY HALF. `data.identity` is the `GET /v1/team` directory row whose id IS `data.actorId` — one identifier, no mapping table, and the same `user-*` id every sale is attributed to through `SaleTicket.sellerId`. It is `null` whenever the acting actor names no directory member: a machine principal, one of the local-dev app subjects (`caisse-ui` / `centrale-ui` / `staff-ui` — apps, not people), or a Keycloak subject that has not been linked to a member yet. `null` is a real answer meaning 'this account is nobody in the directory' — render the absence, never a placeholder name, and do not treat it as a failed read. Use `data.actorId` as the `sellerId` when reading your own day figures (`GET /v1/me/day-summary` needs no id at all, and is the safer call). HOW TO USE THE RESULT. Every documented operation carries an `x-required-permissions` array. If an entry of that array is missing from `effectivePermissions`, the router gate refuses the call with 403 before the handler runs — do not attempt it, and do not retry it with a different body, because nothing about the request can change the outcome. Match the scope EXACTLY (`pos.team.view` does not satisfy `pos.team.manage`) and match it PER OPERATION, not per resource: most routers gate reads on a `.view` scope and writes on a `.manage` one, so holding `pos.customers.view` lets you list customers and NOT edit them. NECESSARY, NOT SUFFICIENT (solya-pos#950). Holding the advertised scope only gets you past the router gate. Several use-cases additionally assert a kernel permission that the scope does not imply, so a call can pass the gate and still return a bare 403 from inside the handler — known cases include the team writes (`pos.team.manage`) and recording a customer consent decision (`pos.customers.manage`, solya-pos#949). Treat a 403 on an operation whose scope you DO hold as a server-side grant gap to report, not as something to work around. Some operations also demand a second, human authority on top of any scope — see `POST /v1/auth/elevate`. READING THE PAYLOAD. The answer is wrapped: `{ data: { actorId, identity, effectivePermissions } }`. That envelope is specific to this operation — nearly every other operation returns its payload raw — so read `data.effectivePermissions`, not the root. The array is sorted and de-duplicated, which makes it stable enough to cache for the lifetime of the credential and to diff between two tokens. An EMPTY array is a valid, successful answer: the caller is authenticated but holds no POS scope, so every scope-gated operation will 403 and only this endpoint and the unauthenticated reads (`GET /v1/permissions/manifest`, `GET /v1/fiscal-keys`) will work. SCOPE AND LIMITS. This describes the CALLER and nobody else — there is no way to ask what another actor holds, and the `role` label on a team-directory row is a display string that answers no authorization question. It needs no scope of its own (any authenticated actor may introspect itself) and it is a pure read: it grants nothing, refreshes nothing and does not extend the session. Because it is the cheapest authenticated call in the API, it doubles as the credential check — a 401 means the bearer token is missing, malformed or expired, and re-authentication is the only fix. One code path serves both credential kinds: a Keycloak access token's `scope` claim and an opaque POS session's server-derived scopes resolve to the same vocabulary. ## OpenAPI ````yaml /openapi.json get /v1/auth/whoami openapi: 3.0.3 info: title: Solya POS API version: 1.0.0 description: >- The Solya POS backend HTTP surface. Every documented operation is agent-ready: it carries an `operationId`, an agent-facing `description`, the `pos.*` scopes it enforces (`x-required-permissions`) and an `x-agent-tier`. Success responses return the payload as raw JSON; failures return the `ErrorResponse` envelope (`{ error: { code, message, statusCode } }`). servers: - url: / description: The backend, relative to its deployed origin. security: [] paths: /v1/auth/whoami: get: tags: - Auth summary: Resolve the authenticated actor's identity and effective POS scopes description: >- Returns WHO the calling credential is and WHAT it may do: the caller's own team-directory row and the `pos.*` scopes it currently holds. This is the discovery entry point: call it FIRST, once, before planning any other work, and use the answer to decide what to attempt. THE IDENTITY HALF. `data.identity` is the `GET /v1/team` directory row whose id IS `data.actorId` — one identifier, no mapping table, and the same `user-*` id every sale is attributed to through `SaleTicket.sellerId`. It is `null` whenever the acting actor names no directory member: a machine principal, one of the local-dev app subjects (`caisse-ui` / `centrale-ui` / `staff-ui` — apps, not people), or a Keycloak subject that has not been linked to a member yet. `null` is a real answer meaning 'this account is nobody in the directory' — render the absence, never a placeholder name, and do not treat it as a failed read. Use `data.actorId` as the `sellerId` when reading your own day figures (`GET /v1/me/day-summary` needs no id at all, and is the safer call). HOW TO USE THE RESULT. Every documented operation carries an `x-required-permissions` array. If an entry of that array is missing from `effectivePermissions`, the router gate refuses the call with 403 before the handler runs — do not attempt it, and do not retry it with a different body, because nothing about the request can change the outcome. Match the scope EXACTLY (`pos.team.view` does not satisfy `pos.team.manage`) and match it PER OPERATION, not per resource: most routers gate reads on a `.view` scope and writes on a `.manage` one, so holding `pos.customers.view` lets you list customers and NOT edit them. NECESSARY, NOT SUFFICIENT (solya-pos#950). Holding the advertised scope only gets you past the router gate. Several use-cases additionally assert a kernel permission that the scope does not imply, so a call can pass the gate and still return a bare 403 from inside the handler — known cases include the team writes (`pos.team.manage`) and recording a customer consent decision (`pos.customers.manage`, solya-pos#949). Treat a 403 on an operation whose scope you DO hold as a server-side grant gap to report, not as something to work around. Some operations also demand a second, human authority on top of any scope — see `POST /v1/auth/elevate`. READING THE PAYLOAD. The answer is wrapped: `{ data: { actorId, identity, effectivePermissions } }`. That envelope is specific to this operation — nearly every other operation returns its payload raw — so read `data.effectivePermissions`, not the root. The array is sorted and de-duplicated, which makes it stable enough to cache for the lifetime of the credential and to diff between two tokens. An EMPTY array is a valid, successful answer: the caller is authenticated but holds no POS scope, so every scope-gated operation will 403 and only this endpoint and the unauthenticated reads (`GET /v1/permissions/manifest`, `GET /v1/fiscal-keys`) will work. SCOPE AND LIMITS. This describes the CALLER and nobody else — there is no way to ask what another actor holds, and the `role` label on a team-directory row is a display string that answers no authorization question. It needs no scope of its own (any authenticated actor may introspect itself) and it is a pure read: it grants nothing, refreshes nothing and does not extend the session. Because it is the cheapest authenticated call in the API, it doubles as the credential check — a 401 means the bearer token is missing, malformed or expired, and re-authentication is the only fix. One code path serves both credential kinds: a Keycloak access token's `scope` claim and an opaque POS session's server-derived scopes resolve to the same vocabulary. operationId: whoami responses: '200': description: >- The caller's own directory identity (or `null`) plus their effective POS scopes, sorted and de-duplicated, under a `data` envelope. content: application/json: schema: type: object properties: data: type: object properties: actorId: nullable: true description: >- The acting principal's id (a Keycloak `sub` or a session subject). type: string identity: nullable: true description: >- The caller's own team-directory row, or `null` when the actor id names no member — a machine principal, a local-dev app subject, or an unlinked Keycloak subject. `null` means 'this account is nobody in the directory'; it is never a stand-in. type: object properties: id: type: string description: The directory member id — identical to `actorId`. name: type: string description: Display name. email: type: string format: email pattern: >- ^(?!\.)(?!.*\.\.)([A-Za-z0-9_'+\-\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\-]*\.)+[A-Za-z]{2,}$ description: Contact email. role: type: string description: >- The primary RBAC role LABEL (a display string, not a grant). store: type: string description: >- The store or network the account is scoped to, as a label. active: type: boolean description: Whether the account may sign in. required: - id - name - email - role - store - active additionalProperties: false effectivePermissions: type: array items: type: string description: >- The `pos.*` scopes the caller holds — sorted, de-duplicated. required: - actorId - identity - effectivePermissions additionalProperties: false required: - data additionalProperties: false description: >- The caller's own directory identity (or `null`) plus their effective POS scopes, sorted and de-duplicated, under a `data` envelope. example: data: actorId: user-camille identity: id: user-camille name: Camille Roy email: camille.roy@rivoli-retail.fr role: cashier store: Boutique Rivoli active: true effectivePermissions: - pos.catalog.view - pos.checkout.operate '400': description: >- The request failed schema validation; `error.fieldErrors` lists the fields. content: application/json: schema: $ref: '#/components/schemas/ValidationErrorResponse' '401': description: No valid credential was presented — send a bearer token. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '500': description: An unexpected server error — safe to retry idempotent requests. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' security: - bearerAuth: [] components: schemas: ValidationErrorResponse: type: object required: - error additionalProperties: false description: >- A `VALIDATION_FAILED` envelope carrying the offending fields in `fieldErrors`. properties: error: type: object required: - code - message - statusCode additionalProperties: false properties: code: type: string enum: - VALIDATION_FAILED message: type: string statusCode: type: integer fieldErrors: type: array description: >- One entry per rejected field: the field path and why it was rejected. items: type: object required: - field - message additionalProperties: false properties: field: type: string description: Dot-path of the offending field. message: type: string description: Why the field was rejected. ErrorResponse: type: object required: - error additionalProperties: false description: The uniform failure envelope every non-2xx response returns. properties: error: type: object required: - code - message - statusCode additionalProperties: false properties: code: type: string enum: - VALIDATION_FAILED - UNAUTHORIZED - FORBIDDEN - NOT_FOUND - CONFLICT - BUSINESS_RULE_VIOLATION - INTERNAL_ERROR description: >- Machine-readable kernel `ResultCode` — branch on this, not on `message`. message: type: string description: >- Human-readable explanation. Safe to surface; never leaks server internals. statusCode: type: integer description: >- The HTTP status, mirrored into the body so a client need not read headers. securitySchemes: bearerAuth: type: http scheme: bearer bearerFormat: JWT description: >- `Authorization: Bearer `. Accepts EITHER a Keycloak access token (scopes-in-token) OR an opaque POS session token; both resolve to the same `pos.*` scope vocabulary the route guards enforce. ````