> ## Documentation Index > Fetch the complete documentation index at: https://developers.meshapi.ai/llms.txt > Use this file to discover all available pages before exploring further. # Revive Expired Items > Give every lapsed preference and fact in this memory a fresh deadline. Retention is enforced on READ (see ``resolver`` — it filters on ``expires_at``), so a lapsed item is already invisible to the gateway while its row survives until the sweeper hard-deletes it. This is how it comes back, and it is memID-WIDE on purpose: a partial revival would leave someone believing a rule or fact was restored when only some of them were. ``now() + retention_days``, NOT the ``created_at``-based re-stamping ``update_memory`` does. That difference is the entire point: re-dating a 41-day-old fact under a 30-day policy from its creation puts the new deadline 11 days in the PAST, so it would expire again the instant it was written and the button would look broken while doing exactly what it said. Retention itself is untouched — the revived items get a fresh window under the SAME policy and can lapse again. Reviving must not silently rewrite a retention policy someone chose. Guardrails are excluded, as everywhere else: they never carry a deadline, so there is nothing of theirs to revive. Mutation, so ``admin_ok=False`` — an org admin's extra powers are read and delete, not authoring. No vector work. Fact search resolves its hits against the rows this UPDATE touches, so an eligible row is retrievable again with nothing to re-embed. ## OpenAPI ````yaml /api/openapi.json post /v1/memories/{slug_or_id}/items/revive-expired openapi: 3.1.0 info: title: MeshAPI description: One key, all AI models. version: 0.1.0 servers: - url: https://api.meshapi.ai security: - BearerAuth: [] paths: /v1/memories/{slug_or_id}/items/revive-expired: post: tags: - Memory summary: Revive Expired Items description: >- Give every lapsed preference and fact in this memory a fresh deadline. Retention is enforced on READ (see ``resolver`` — it filters on ``expires_at``), so a lapsed item is already invisible to the gateway while its row survives until the sweeper hard-deletes it. This is how it comes back, and it is memID-WIDE on purpose: a partial revival would leave someone believing a rule or fact was restored when only some of them were. ``now() + retention_days``, NOT the ``created_at``-based re-stamping ``update_memory`` does. That difference is the entire point: re-dating a 41-day-old fact under a 30-day policy from its creation puts the new deadline 11 days in the PAST, so it would expire again the instant it was written and the button would look broken while doing exactly what it said. Retention itself is untouched — the revived items get a fresh window under the SAME policy and can lapse again. Reviving must not silently rewrite a retention policy someone chose. Guardrails are excluded, as everywhere else: they never carry a deadline, so there is nothing of theirs to revive. Mutation, so ``admin_ok=False`` — an org admin's extra powers are read and delete, not authoring. No vector work. Fact search resolves its hits against the rows this UPDATE touches, so an eligible row is retrievable again with nothing to re-embed. operationId: revive_expired_items parameters: - name: slug_or_id in: path required: true schema: type: string title: Slug Or Id - in: header name: X-Mesh-Version required: false schema: type: string enum: - 2026-08 default: 2026-08 example: 2026-08 description: >- Dated version of the API contract to pin this request to. Omit it and the request is served under `2026-08` — the oldest supported version, so an existing integration is never moved by a release. A malformed or unsupported value is rejected with `400 invalid_api_version` rather than falling back silently. The version actually served is echoed as `X-Mesh-Version` on every response, including errors. responses: '200': description: Successful Response content: application/json: schema: $ref: '#/components/schemas/ReviveExpiredResponse' '401': description: Missing or invalid credentials '404': description: Memory not found or not owned by caller '422': description: Validation Error content: application/json: schema: $ref: '#/components/schemas/HTTPValidationError' security: - BearerAuth: [] components: schemas: ReviveExpiredResponse: properties: revived: type: integer title: Revived default: 0 expires_at: anyOf: - type: string - type: 'null' title: Expires At retention_days: anyOf: - type: integer - type: 'null' title: Retention Days type: object title: ReviveExpiredResponse description: >- Outcome of a memID-wide revive. ``expires_at`` is the deadline every revived item now carries — null when the memory keeps items forever. ``retention_days`` echoes the policy that was applied, unchanged: reviving does not rewrite it, so the caller can see that the same window is now counting from today. HTTPValidationError: properties: detail: items: $ref: '#/components/schemas/ValidationError' type: array title: Detail type: object title: HTTPValidationError ValidationError: properties: loc: items: anyOf: - type: string - type: integer type: array title: Location msg: type: string title: Message type: type: string title: Error Type input: title: Input ctx: type: object title: Context type: object required: - loc - msg - type title: ValidationError securitySchemes: BearerAuth: type: http scheme: bearer description: >- Enter your MeshAPI key (`rsk_...`) — sent as `Authorization: Bearer `. ````