> ## 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. # Set or rotate the calling actor's own elevation PIN > Enrols (or rotates) the elevation PIN of the AUTHENTICATED caller. The subject is taken from the bearer token and is not a field you can send, so there is no request that sets somebody else's PIN — that is the property the whole channel rests on: an elevation must prove who was physically present. DO NOT CALL THIS AS AN AGENT. A PIN is a human's second-factor credential for authorising money off a sale; an automated caller that writes one has either invented a secret nobody knows or been handed one it must not hold, and a rotation silently invalidates the PIN the real owner is using at the till. If a manager needs to enrol or rotate, they do it themselves. It is listed here so the surface is described, not so it is driven. Behaviour, for completeness: the PIN must be at least six digits and not trivial (sequences and repeats are refused); a refusal is a 422 whose message names the RULE that failed (`too_short`, `trivial`, …) and NEVER echoes the submitted value. Success is 204 with no body. A rotation also clears any lockout on the account. The route rides the ordinary till scope `pos.checkout.operate`, which is deliberate and not a hole: a PIN on an account that holds no elevating scope elevates nothing. 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 put /v1/auth/elevation/pin 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/elevation/pin: put: tags: - Auth summary: Set or rotate the calling actor's own elevation PIN description: >- Enrols (or rotates) the elevation PIN of the AUTHENTICATED caller. The subject is taken from the bearer token and is not a field you can send, so there is no request that sets somebody else's PIN — that is the property the whole channel rests on: an elevation must prove who was physically present. DO NOT CALL THIS AS AN AGENT. A PIN is a human's second-factor credential for authorising money off a sale; an automated caller that writes one has either invented a secret nobody knows or been handed one it must not hold, and a rotation silently invalidates the PIN the real owner is using at the till. If a manager needs to enrol or rotate, they do it themselves. It is listed here so the surface is described, not so it is driven. Behaviour, for completeness: the PIN must be at least six digits and not trivial (sequences and repeats are refused); a refusal is a 422 whose message names the RULE that failed (`too_short`, `trivial`, …) and NEVER echoes the submitted value. Success is 204 with no body. A rotation also clears any lockout on the account. The route rides the ordinary till scope `pos.checkout.operate`, which is deliberate and not a hole: a PIN on an account that holds no elevating scope elevates nothing. 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: setElevationPin requestBody: required: true content: application/json: schema: type: object properties: pin: type: string required: - pin example: pin: '489217' responses: '204': description: The PIN was accepted and stored. No body is returned. content: application/json: schema: description: The PIN was accepted and stored. No body is returned. '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. ````