> ## 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 uma entrada do outbox > Redefine a linha do outbox transacional {id} terminalmente INVALID de volta para PENDING para o tenant da requisição, de modo que o relay dispatcher a republique no próximo tick. O id da linha é PRESERVADO (o evento nunca é recriado). Idempotente: uma linha que não está INVALID é deixada intacta e retorna redispatched=false com seu status atual — uma linha PUBLISHED nunca é reenviada. Um id desconhecido → 404. Multi-tenant ainda não é suportado → 501 (apenas single-tenant até o alinhamento do schema do outbox). RBAC: outbox:redispatch; o tenant é sempre derivado da identidade validada da requisição, nunca de um valor no caminho ou no payload. ## OpenAPI ````yaml pt/openapi/v3-current/slc.yaml post /admin/outbox/{id}/redispatch openapi: 3.1.0 info: description: >- API do Lerian SLC — o rail do lado do participante que conecta a instituição à liquidação de cartões por líquido diferido SLC da Núclea. Abrange a admissão e o ciclo de vida das operações de liquidação, as posições de compensação, o registro de participantes e arranjos, os relatórios gerados, a consulta de esquemas XSD incorporados, a recuperação de transmissão e a conectividade com a Núclea, a importação de chave de assinatura BYOK Modelo A e os webhooks com escopo no tenant. title: Lerian SLC API version: 1.0.0 servers: - url: https://slc.sandbox.lerian.net security: - BearerAuth: [] tags: - description: >- Ciclo de vida das operações de liquidação — criar, listar, consultar e controlar as operações de cartão rastreadas por NUliquid (NUliquid = o id de 21 posições que a Núclea atribui a cada operação aceita) através da máquina de estados. name: Operations - description: >- Catálogo de participantes — os credenciadores (acquirers), subcredenciadores (sub-acquirers), o IF Domicílio (banco onde o estabelecimento recebe suas vendas) e as IFs liquidantes (instituições financeiras) que participam da liquidação de cartões. name: Participants - description: >- Arranjos de cartão (configurações de bandeira/scheme, ex. Visa/Master/Elo) vinculados a um participante. name: Arrangements - description: >- Orquestração de transporte regulado para a Núclea/SILOC (a câmara privada de compensação de cartões que opera o sistema de liquidação SILOC) — despacho, recuperação, retransmissão e teste de conectividade sobre transferência gerenciada de arquivos, message broker e REST. name: Connectivity - description: >- Posições de compensação por compensação multilateral (netting) — o valor líquido que cada participante liquida por ciclo do STR (STR = sistema de transferência de reservas do Banco Central). name: Clearing - description: >- Provisionamento de chave de assinatura BYOK (Bring Your Own Key) em SaaS — parâmetros de importação e registro do material de certificado ICP-Brasil A1 do cliente (certificado de servidor da PKI brasileira, validade de 1 ano) usado para assinar arquivos ASLC; a chave privada nunca sai do HSM/KMS/Vault do cliente. name: SigningKey - description: >- Ingestão e status de arquivos ASLC — submissão em passthrough e status de processamento dos arquivos XML oficiais de liquidação de cartões da Núclea (ASLC = Arquivo do Sistema de Liquidação de Cartões). name: Files - description: >- Introspecção somente-leitura dos schemas XSD ASLC/RSFN (Rede do Sistema Financeiro Nacional) da Núclea incorporados, usados para validar mensagens de saída e de entrada. name: XSD Schemas - description: >- Relatórios de liquidação regulatórios, de conformidade e operacionais, somente-leitura. name: Reports - description: >- Assinaturas de webhook de eventos de negócio de saída e gerenciamento de entrega para consumidores (Midaz, ledgers do cliente, Cabine — todos opcionais). name: Webhooks - description: >- Operações administrativas — configuração de runtime recarregável a quente (hot-reload), inspeção/reenvio da fila de cartas mortas (dead-letter queue) e redespacho do outbox. name: Admin paths: /admin/outbox/{id}/redispatch: post: tags: - Admin summary: Redespachar uma entrada do outbox description: >- Redefine a linha do outbox transacional {id} terminalmente INVALID de volta para PENDING para o tenant da requisição, de modo que o relay dispatcher a republique no próximo tick. O id da linha é PRESERVADO (o evento nunca é recriado). Idempotente: uma linha que não está INVALID é deixada intacta e retorna redispatched=false com seu status atual — uma linha PUBLISHED nunca é reenviada. Um id desconhecido → 404. Multi-tenant ainda não é suportado → 501 (apenas single-tenant até o alinhamento do schema do outbox). RBAC: outbox:redispatch; o tenant é sempre derivado da identidade validada da requisição, nunca de um valor no caminho ou no 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 ````