> ## 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. # Reactivate (reopen) a store > Reopens a closed store by flipping its `active` flag back to `true`, the exact inverse of `POST /stores/{storeId}/deactivate`. It restores exactly one thing: the store's eligibility to receive NEW operations, so it reappears in pickers and may be routed sales and transfers again. It resurrects nothing that was closed while the site was shut — no fiscal period reopens, no register session resumes, no transfer is revived. It never touches a sealed record: the store `id` is inside the NF525 signed body and is the addressing key here, never rewritten, and no `sales_tickets` or `fiscal_signatures` row is read or written. Idempotent: reopening an already-active store is a no-op that returns it unchanged. 404s for an unknown store. Same PERMISSION TRAP as the deactivate route (solya-pos#950): the guard accepts `pos.settings.manage` but the use-case asserts the kernel `config:manage` permission. ## OpenAPI ````yaml /openapi.json post /v1/stores/{storeId}/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/stores/{storeId}/reactivate: post: tags: - Network summary: Reactivate (reopen) a store description: >- Reopens a closed store by flipping its `active` flag back to `true`, the exact inverse of `POST /stores/{storeId}/deactivate`. It restores exactly one thing: the store's eligibility to receive NEW operations, so it reappears in pickers and may be routed sales and transfers again. It resurrects nothing that was closed while the site was shut — no fiscal period reopens, no register session resumes, no transfer is revived. It never touches a sealed record: the store `id` is inside the NF525 signed body and is the addressing key here, never rewritten, and no `sales_tickets` or `fiscal_signatures` row is read or written. Idempotent: reopening an already-active store is a no-op that returns it unchanged. 404s for an unknown store. Same PERMISSION TRAP as the deactivate route (solya-pos#950): the guard accepts `pos.settings.manage` but the use-case asserts the kernel `config:manage` permission. operationId: reactivateStore parameters: - schema: type: string minLength: 1 in: path name: storeId required: true responses: '200': description: 'The reopened store directory record (`active: true`).' content: application/json: schema: type: object properties: id: type: string minLength: 1 name: type: string minLength: 1 city: type: string minLength: 1 region: type: string minLength: 1 active: type: boolean required: - id - name - city - region - active additionalProperties: false description: 'The reopened store directory record (`active: true`).' example: id: store-rivoli name: Boutique Rivoli city: Paris 1er region: Île-de-France 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. ````