> ## Documentation Index > Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt > Use this file to discover all available pages before exploring further. # Redespachar una entrada del outbox > Restablece la fila del outbox transaccional {id} en estado terminal INVALID de vuelta a PENDING para el tenant de la solicitud, de modo que el despachador de relay la republique en su próximo tick. El id de la fila se PRESERVA (el evento nunca se recrea). Idempotente: una fila que no está INVALID se deja intacta y devuelve redispatched=false con su estado actual — una fila PUBLISHED nunca se reenvía. Un id desconocido → 404. Multi-tenant aún no es compatible → 501 (solo mono-tenant hasta la alineación del esquema del outbox). RBAC: outbox:redispatch; el tenant siempre se deriva de la identidad validada de la solicitud, nunca de un valor de ruta o de payload. ## OpenAPI ````yaml es/openapi/v3-current/slc.yaml post /admin/outbox/{id}/redispatch openapi: 3.1.0 info: description: >- API de Lerian SLC — el rail del lado del participante que conecta la institución con la liquidación de tarjetas por neto diferido SLC de Núclea. Cubre la admisión y el ciclo de vida de las operaciones de liquidación, las posiciones de compensación, el registro de participantes y arreglos, los informes generados, la consulta de esquemas XSD integrados, la recuperación de transmisión y la conectividad con Núclea, la importación de clave de firma BYOK Modelo A y los webhooks con alcance al tenant. title: Lerian SLC API version: 1.0.0 servers: - url: https://slc.sandbox.lerian.net security: - BearerAuth: [] tags: - description: >- Ciclo de vida de las operaciones de liquidación — crea, lista, consulta y controla las operaciones de tarjeta rastreadas por NUliquid (NUliquid = el id de 21 posiciones que Núclea asigna a cada operación aceptada) a través de la máquina de estados. name: Operations - description: >- Catálogo de participantes — los adquirentes, subadquirentes, IF Domicílio (banco donde el establecimiento recibe sus ventas) y las IF de liquidación (instituciones financieras) que participan en la liquidación de tarjetas. name: Participants - description: >- Arreglos de tarjeta (configuraciones de bandeira/esquema, p. ej. Visa/Master/Elo) asociados a un participante. name: Arrangements - description: >- Orquestación de transporte regulado hacia Núclea/SILOC (la cámara de compensación privada de tarjetas que opera el sistema de liquidación SILOC) — despacho, recuperación, retransmisión y prueba de conectividad sobre transferencia de archivos gestionada, broker de mensajes y REST. name: Connectivity - description: >- Posiciones de compensación de neteo multilateral — el monto neto que cada participante liquida por ciclo STR (STR = sistema de transferencia de reservas del Banco Central). name: Clearing - description: >- Aprovisionamiento de clave de firma SaaS BYOK (Bring Your Own Key) — importa parámetros y registra el material del certificado ICP-Brasil A1 del cliente (certificado de servidor de la PKI brasileña, validez de 1 año) usado para firmar archivos ASLC; la clave privada nunca sale del HSM/KMS/Vault del cliente. name: SigningKey - description: >- Admisión y estado de archivos ASLC — envío en modo passthrough y estado de procesamiento de los archivos XML oficiales de liquidación de tarjetas de Núclea (ASLC = Arquivo do Sistema de Liquidação de Cartões). name: Files - description: >- Introspección de solo lectura de los esquemas XSD ASLC/RSFN (Red del Sistema Financiero Nacional) integrados de Núclea usados para validar los mensajes salientes y entrantes. name: XSD Schemas - description: >- Informes de liquidación regulatorios, de cumplimiento y operativos, de solo lectura. name: Reports - description: >- Suscripciones a webhooks de eventos de negocio salientes y gestión de entrega para los consumidores (Midaz, ledgers del cliente, Cabine — todos opcionales). name: Webhooks - description: >- Operaciones administrativas — configuración de tiempo de ejecución recargable en caliente, inspección/reenvío de la cola de mensajes muertos y redespacho del outbox. name: Admin paths: /admin/outbox/{id}/redispatch: post: tags: - Admin summary: Redespachar una entrada del outbox description: >- Restablece la fila del outbox transaccional {id} en estado terminal INVALID de vuelta a PENDING para el tenant de la solicitud, de modo que el despachador de relay la republique en su próximo tick. El id de la fila se PRESERVA (el evento nunca se recrea). Idempotente: una fila que no está INVALID se deja intacta y devuelve redispatched=false con su estado actual — una fila PUBLISHED nunca se reenvía. Un id desconocido → 404. Multi-tenant aún no es compatible → 501 (solo mono-tenant hasta la alineación del esquema del outbox). RBAC: outbox:redispatch; el tenant siempre se deriva de la identidad validada de la solicitud, nunca de un valor de ruta o de payload. operationId: redispatchOutboxEntry parameters: - description: Outbox entry id. An unknown id is 404. in: path name: id required: true schema: description: Outbox entry id. An unknown id is 404. examples: - ob-1 type: string responses: '200': content: application/json: schema: $ref: '#/components/schemas/OutboxRedispatchResponse' description: OK default: content: application/problem+json: schema: $ref: '#/components/schemas/Detail' description: Error components: schemas: OutboxRedispatchResponse: additionalProperties: false properties: id: description: >- Outbox entry id (preserved across redispatch; the event is never recreated). examples: - 018f8a3e-4b2c-7c1a-9e5d-2f6a1b3c4d5e type: string redispatched: description: >- True when a terminally-INVALID row was reset to PENDING; false when the row was left untouched. examples: - true type: boolean status: description: Outbox row status after the operation. examples: - PENDING type: string required: - id - redispatched - status type: object Detail: additionalProperties: false properties: code: description: >- Stable, machine-readable domain error code scoped to the emitting service (format: -NNNN). examples: - ERR-0001 type: string detail: description: >- A human-readable explanation specific to this occurrence of the problem. examples: - Property foo is required but is missing. type: string errors: description: Optional list of individual error details items: $ref: '#/components/schemas/ErrorDetail' type: - array - 'null' instance: description: >- A URI reference that identifies the specific occurrence of the problem. examples: - https://example.com/error-log/abc123 format: uri type: string status: description: HTTP status code examples: - 400 format: int64 type: integer title: description: >- A short, human-readable summary of the problem type. This value should not change between occurrences of the error. examples: - Bad Request type: string type: default: about:blank description: A URI reference to human-readable documentation for the error. examples: - https://example.com/errors/example format: uri type: string type: object ErrorDetail: additionalProperties: false properties: location: description: >- Where the error occurred, e.g. 'body.items[3].tags' or 'path.thing-id' type: string message: description: Error message text type: string value: description: The value at the given location type: object securitySchemes: BearerAuth: bearerFormat: JWT description: JWT bearer token issued by the identity provider. scheme: bearer type: http ````