> ## 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. # Record an age-verification attestation > Appends ONE row to the durable age-verification compliance trail: that a check was performed, by which operator, for which transaction, when, and with what outcome. This is the record a merchant produces to a regulator, so only ever call it as the immediate consequence of a real check a human performed at the till. It is APPEND-ONLY: no endpoint amends or deletes a row, and a wrong one stays in the trail forever. Never call it to 'backfill' history, to satisfy a workflow, or on anyone else's behalf. Fields. `transactionRef` links the check to the sale it belongs to. `outcome` is the decision the till acted on: `pass` (the customer was old enough and was served), `block` (they were not and the sale was refused) or `needs_check` (the proof was inconclusive) — report what actually happened, never what would be convenient. `at` is optional and defaults to the server clock; send the till's own ISO instant when the check ran offline and is only now syncing, so the record keeps its true time. `id` is optional and only exists for idempotency — omit it and a deterministic one is derived; supply the SAME id to make a retry safe rather than duplicating the row. PRIVACY, and it is enforced, not advisory: the body is STRICT and carries no customer identity. There is no field for a date of birth, a name or a document number, and a body containing one is rejected with a 400 rather than stored — so a retry that 'adds the proof' will always fail. `operatorId` is likewise NOT accepted: it is re-derived from the authenticated actor, so the trail always names the credential that called, and a body carrying it is a 400. Whatever token you hold is the operator the record will blame. Gating: the router rides the till scope `pos.checkout.operate` and the use-case additionally asserts the kernel `sale:create` — which that scope does imply, so the two agree here. Returns 201 with the stored row. ## OpenAPI ````yaml /openapi.json post /v1/age-attestations 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/age-attestations: post: tags: - Compliance summary: Record an age-verification attestation description: >- Appends ONE row to the durable age-verification compliance trail: that a check was performed, by which operator, for which transaction, when, and with what outcome. This is the record a merchant produces to a regulator, so only ever call it as the immediate consequence of a real check a human performed at the till. It is APPEND-ONLY: no endpoint amends or deletes a row, and a wrong one stays in the trail forever. Never call it to 'backfill' history, to satisfy a workflow, or on anyone else's behalf. Fields. `transactionRef` links the check to the sale it belongs to. `outcome` is the decision the till acted on: `pass` (the customer was old enough and was served), `block` (they were not and the sale was refused) or `needs_check` (the proof was inconclusive) — report what actually happened, never what would be convenient. `at` is optional and defaults to the server clock; send the till's own ISO instant when the check ran offline and is only now syncing, so the record keeps its true time. `id` is optional and only exists for idempotency — omit it and a deterministic one is derived; supply the SAME id to make a retry safe rather than duplicating the row. PRIVACY, and it is enforced, not advisory: the body is STRICT and carries no customer identity. There is no field for a date of birth, a name or a document number, and a body containing one is rejected with a 400 rather than stored — so a retry that 'adds the proof' will always fail. `operatorId` is likewise NOT accepted: it is re-derived from the authenticated actor, so the trail always names the credential that called, and a body carrying it is a 400. Whatever token you hold is the operator the record will blame. Gating: the router rides the till scope `pos.checkout.operate` and the use-case additionally asserts the kernel `sale:create` — which that scope does imply, so the two agree here. Returns 201 with the stored row. operationId: recordAgeAttestation requestBody: required: true content: application/json: schema: type: object properties: transactionRef: type: string minLength: 1 outcome: type: string enum: - pass - block - needs_check at: type: string minLength: 1 format: date-time description: ISO-8601 instant the check was performed at. id: type: string minLength: 1 required: - transactionRef - outcome additionalProperties: false example: transactionRef: sale-42 outcome: pass at: '2026-07-16T09:00:00.000Z' responses: '201': description: >- The appended attestation, with the operator stamped from the caller's own token. content: application/json: schema: type: object properties: id: type: string operatorId: type: string transactionRef: type: string at: 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))$ outcome: type: string enum: - pass - block - needs_check required: - id - operatorId - transactionRef - at - outcome additionalProperties: false description: >- The appended attestation, with the operator stamped from the caller's own token. example: id: corr-8f21:ageVerification:sale-42:2026-07-16T09:00:00.000Z operatorId: user-camille transactionRef: sale-42 at: '2026-07-16T09:00:00.000Z' outcome: pass '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' '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. ````