> ## 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. # Request a single-use manager elevation grant > PRIVILEGE ESCALATION. Presents a manager's subject and PIN and, on success, mints a short-lived SINGLE-USE token carrying exactly ONE `pos.*` scope, to be spent as the `x-elevation-token` header on one later `POST /v1/checkout/finalize`. The cashier's session is never touched: no token is re-issued and no scope is added to it. DO NOT CALL THIS AS AN AGENT. It requires a human's PIN, and the correct actor is the till that has a manager standing in front of it. An automated caller either does not have the PIN (and every attempt burns a failure against that manager's account, locking them out of their own till after a few tries) or has been given one it should never hold. Issuing cannot be undone: there is no revoke endpoint, and the minted grant stays spendable for its ~5-minute window. If a sale needs manager approval, surface that to a human and stop. Parameters, in domain terms: `managerSubject` is the approving manager's identity, `pin` their own enrolled PIN, `operation` the governed act (`discount.line` for a single line, `discount.ticket` for the whole ticket), and `amountCents` / `percentBps` how big the till BELIEVES the reduction is. That magnitude is a UX input only — it decides whether approval is demanded, never what the sale may be: `finalizeSale` re-prices the cart server-side, so understating it yields no token and overstating it yields a token for the same single scope. Reading the outcome: 201 returns the grant — `scope` is a SINGLE string (a grant that could carry a list is a grant that can accumulate), `expiresAt` an ISO instant. 401 `INVALID_CREDENTIAL` covers BOTH a wrong PIN and an unknown manager, deliberately, so the endpoint does not confirm which subjects exist — never treat it as 'that manager does not exist'. 403 means the PIN was right but that manager cannot exercise the authority (`MISSING_AUTHORITY`) or their cached scopes are stale (`GRANTS_STALE`). 422 means the policy says no elevation is needed at this size (`NO_ELEVATION_REQUIRED`) or the channel is unavailable — in the first case just finalize the sale without a token. 429 is a lockout or the per-manager rate limiter; honour `Retry-After` and do not retry sooner. ERROR-ENVELOPE TRAP: the failure bodies keep the usual `{ error: { code, message, statusCode } }` shape, but `code` here is a CHANNEL vocabulary, not the kernel `ResultCode` enum the shared `ErrorResponse` component lists. Expect values the schema does not enumerate and branch on them as opaque strings. A 429 is also reachable and is NOT in the documented response set. ## OpenAPI ````yaml /openapi.json post /v1/auth/elevate 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/elevate: post: tags: - Auth summary: Request a single-use manager elevation grant description: >- PRIVILEGE ESCALATION. Presents a manager's subject and PIN and, on success, mints a short-lived SINGLE-USE token carrying exactly ONE `pos.*` scope, to be spent as the `x-elevation-token` header on one later `POST /v1/checkout/finalize`. The cashier's session is never touched: no token is re-issued and no scope is added to it. DO NOT CALL THIS AS AN AGENT. It requires a human's PIN, and the correct actor is the till that has a manager standing in front of it. An automated caller either does not have the PIN (and every attempt burns a failure against that manager's account, locking them out of their own till after a few tries) or has been given one it should never hold. Issuing cannot be undone: there is no revoke endpoint, and the minted grant stays spendable for its ~5-minute window. If a sale needs manager approval, surface that to a human and stop. Parameters, in domain terms: `managerSubject` is the approving manager's identity, `pin` their own enrolled PIN, `operation` the governed act (`discount.line` for a single line, `discount.ticket` for the whole ticket), and `amountCents` / `percentBps` how big the till BELIEVES the reduction is. That magnitude is a UX input only — it decides whether approval is demanded, never what the sale may be: `finalizeSale` re-prices the cart server-side, so understating it yields no token and overstating it yields a token for the same single scope. Reading the outcome: 201 returns the grant — `scope` is a SINGLE string (a grant that could carry a list is a grant that can accumulate), `expiresAt` an ISO instant. 401 `INVALID_CREDENTIAL` covers BOTH a wrong PIN and an unknown manager, deliberately, so the endpoint does not confirm which subjects exist — never treat it as 'that manager does not exist'. 403 means the PIN was right but that manager cannot exercise the authority (`MISSING_AUTHORITY`) or their cached scopes are stale (`GRANTS_STALE`). 422 means the policy says no elevation is needed at this size (`NO_ELEVATION_REQUIRED`) or the channel is unavailable — in the first case just finalize the sale without a token. 429 is a lockout or the per-manager rate limiter; honour `Retry-After` and do not retry sooner. ERROR-ENVELOPE TRAP: the failure bodies keep the usual `{ error: { code, message, statusCode } }` shape, but `code` here is a CHANNEL vocabulary, not the kernel `ResultCode` enum the shared `ErrorResponse` component lists. Expect values the schema does not enumerate and branch on them as opaque strings. A 429 is also reachable and is NOT in the documented response set. operationId: requestElevation requestBody: required: true content: application/json: schema: type: object properties: managerSubject: type: string minLength: 1 pin: type: string minLength: 1 operation: type: string enum: - discount.line - discount.ticket amountCents: default: 0 type: integer minimum: 0 maximum: 9007199254740991 percentBps: default: 0 type: integer minimum: 0 maximum: 9007199254740991 required: - managerSubject - pin - operation example: managerSubject: manager-1 pin: '489217' operation: discount.line amountCents: 180 percentBps: 1000 responses: '201': description: 'The issued grant: one manager, one scope, one operation, one use.' content: application/json: schema: type: object properties: token: type: string scope: type: string operation: type: string enum: - discount.line - discount.ticket expiresAt: type: string format: date-time pattern: >- ^(?:(?:\d\d[2468][048]|\d\d[13579][26]|\d\d0[48]|[02468][048]00|[13579][26]00)-02-29|\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\d|30)|(?:02)-(?:0[1-9]|1\d|2[0-8])))T(?:(?:[01]\d|2[0-3]):[0-5]\d(?::[0-5]\d(?:\.\d+)?)?(?:Z))$ managerSubject: type: string required: - token - scope - operation - expiresAt - managerSubject additionalProperties: false description: >- The issued grant: one manager, one scope, one operation, one use. example: token: b3f1c0a7d4e28956 scope: pos.price.override operation: discount.line expiresAt: '2026-07-16T09:05:00.000Z' managerSubject: manager-1 '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' '403': description: The actor is authenticated but lacks the required `pos.*` scope. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '422': description: The request is well-formed but violates a domain rule. 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. ````