> ## 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. # Re-onboard a team member (restore sign-in) > RESTORES an offboarded staff account by flipping its `active` flag back to `true`, which RE-ENABLES sign-in and makes the member assignable again. It is the exact inverse of `deactivateTeamMember`, and the reason offboarding is safe to prefer over deletion: an offboard made in error costs a click rather than a lost history. Like the deactivate route it takes no body — the path `memberId` is the whole input. It restores ONLY assignability and sign-in: it re-grants no role, re-opens no register session and revives no document. Role grants survive an offboard untouched (they live in `role_assignments`, not the directory row), so a reactivated member returns with the grants they had and nothing more. This GRANTS system access, so surface the request to a human and never restore an account autonomously. Idempotent: reactivating an already-active account is a no-op that returns it unchanged. 404s for an unknown member. PERMISSION TRAP (solya-pos#950): `x-required-permissions` says `pos.team.manage`, and that is what the router gate checks — but the use-case behind it additionally asserts the kernel permission `config:manage`, and the scope-to-kernel table (`SCOPE_KERNEL_PERMISSIONS`) maps `pos.team.manage` to NOTHING. A token-authenticated actor holding exactly the documented scope therefore passes the gate and then fails with a bare 403 from inside the use-case. Read a 403 here as a server-side grant gap, not as a malformed request, and do not retry it with a different body. ## OpenAPI ````yaml /openapi.json post /v1/team/{memberId}/reactivate 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/team/{memberId}/reactivate: post: tags: - Team summary: Re-onboard a team member (restore sign-in) description: >- RESTORES an offboarded staff account by flipping its `active` flag back to `true`, which RE-ENABLES sign-in and makes the member assignable again. It is the exact inverse of `deactivateTeamMember`, and the reason offboarding is safe to prefer over deletion: an offboard made in error costs a click rather than a lost history. Like the deactivate route it takes no body — the path `memberId` is the whole input. It restores ONLY assignability and sign-in: it re-grants no role, re-opens no register session and revives no document. Role grants survive an offboard untouched (they live in `role_assignments`, not the directory row), so a reactivated member returns with the grants they had and nothing more. This GRANTS system access, so surface the request to a human and never restore an account autonomously. Idempotent: reactivating an already-active account is a no-op that returns it unchanged. 404s for an unknown member. PERMISSION TRAP (solya-pos#950): `x-required-permissions` says `pos.team.manage`, and that is what the router gate checks — but the use-case behind it additionally asserts the kernel permission `config:manage`, and the scope-to-kernel table (`SCOPE_KERNEL_PERMISSIONS`) maps `pos.team.manage` to NOTHING. A token-authenticated actor holding exactly the documented scope therefore passes the gate and then fails with a bare 403 from inside the use-case. Read a 403 here as a server-side grant gap, not as a malformed request, and do not retry it with a different body. operationId: reactivateTeamMember parameters: - schema: type: string minLength: 1 in: path name: memberId required: true description: The team-member id to act on, e.g. `user-julie`. responses: '200': description: 'The restored account, active again with `active: true`.' content: application/json: schema: type: object properties: id: type: string minLength: 1 name: type: string minLength: 1 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,}$ role: type: string minLength: 1 store: type: string minLength: 1 active: type: boolean required: - id - name - email - role - store - active additionalProperties: false description: 'The restored account, active again with `active: true`.' example: id: user-julie name: Julie Ferrand email: julie.ferrand@rivoli-retail.fr role: manager store: Boutique Bastille active: true '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' '404': description: No resource matches the addressed identifier. 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. ````