> ## 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.

# Roles and permissions

> How Solya POS authenticates users and authorizes actions — Keycloak sign-in, scope-based permissions, roles, and till elevation.

Every action in Solya POS is gated by a **permission**. Who you are decides which
screens you see and which API calls succeed; a call you are not entitled to make
returns `403`.

## Authentication

The Centrale and the Caisse sign users in through **Keycloak** (the identity
provider). A signed-in session carries a token that the backend verifies on every
request. For automated clients, the API also accepts an opaque POS token — see
[Authentication](/en/developers/authentication) in the Developers guides.

## Permissions are scopes

Authorization is **scope-based**. Each permission is a string of the form
`pos.<domain>.<action>`, for example `pos.catalog.manage`,
`pos.inventory.read` or `pos.settings.manage`. The backend annotates each
endpoint with the scopes it requires, and the full catalogue is available at
`GET /v1/permissions/manifest`.

<Note>
  Scopes are grouped by **domain** (catalogue, inventory, finance, settings, …) and
  by **action** (typically `read` vs `manage`). A read scope lets you view a
  screen; a manage scope lets you create, edit or advance records in it.
</Note>

## Roles

A role is a named bundle of scopes assigned to a user. Typical roles:

| Role                          | Where they work | What they can do                                                                                                                 |
| ----------------------------- | --------------- | -------------------------------------------------------------------------------------------------------------------------------- |
| **Manager**                   | Centrale        | Run the back-office: catalogue, stock, orders, transfers, procurement, finance-read, pricing, promotions, loyalty and reporting. |
| **Buyer**                     | Centrale        | Focus on procurement — suppliers, purchase orders and returns-to-vendor.                                                         |
| **Cashier / sales associate** | Caisse          | Ring up sales, take payment, handle returns, gift cards and the daily cash session.                                              |
| **Administrator**             | Both            | Manage the network, team, devices and settings.                                                                                  |

You manage team members and inspect their permissions from the Centrale
**Team** screen — see the [Team guide](/en/centrale/equipe). The
permissions panel there resolves each member's effective scopes.

## Elevation at the till

Some sensitive till actions (large discounts, certain overrides) require
**elevation** — a manager confirms with a PIN before the action proceeds
(`POST /v1/auth/elevate`, PIN managed via `PUT /v1/auth/elevation/pin`). This
keeps day-to-day cashier accounts low-privilege while still allowing supervised
exceptions.

## Checking your own access

Call `GET /v1/auth/whoami` to see the identity and scopes attached to the current
session — useful when a screen or an API call is unexpectedly denied.

## Next

See [Navigation](/en/getting-started/navigation) to find your way around, or jump
into the [Centrale guides](/en/centrale/overview).