> ## 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.

# Integración con Lerian SISBAJUD

> Integración con Lerian SISBAJUD: eventos de saldo de Midaz que impulsan los reintentos de bloqueo permanente, eventos de negocio emitidos, conector del ledger y semántica de entrega.

Lerian SISBAJUD es event-first en su punto de contacto con el ledger. **Consume** eventos de cambio de saldo de Midaz para impulsar los bloqueos permanentes. **Emite** eventos operativos de negocio que otros sistemas pueden observar. No envía webhooks salientes a consumidores de terceros. Sus interfaces son el ledger de Midaz, Lerian STA, el endpoint de notificación de entrega de remesas y su superficie administrativa.

## Eventos del ledger que consume

***

La integración se suscribe a los **eventos de cambio de saldo** de Midaz. Trata cada evento como un **disparador**. Un evento no decide nada por sí mismo. La integración compara la cuenta del evento con las cuentas de las que retiraron montos los bloqueos anteriores. Luego ejecuta la lógica de bloqueo para las órdenes abiertas del titular de esa cuenta.

Un bloqueo permanente usa esta ruta para capturar fondos que llegan después del primer intento. Después de un bloqueo tradicional inicial parcial, un crédito posterior ese mismo día también puede activar intentos complementarios.

## Eventos de negocio que emite

***

Lerian SISBAJUD emite eventos operativos de negocio **sin datos personales** en sus payloads:

* Un evento **block-account-created** cuando una ejecución crea una retención de bloqueo. Es una señal operativa, no un portador de dinero ni de PII.
* Un evento **key-rotated** (`kek.rotated`) cuando un operador rota la clave de cifrado de claves de una institución con Vault como proveedor de claves.

Estos eventos sirven para la observabilidad y la coordinación. Los movimientos de dinero residen en el ledger de Midaz, no en los payloads de los eventos.

## Límite con Midaz

***

**Midaz** es el conector del ledger. A través de él, Lerian SISBAJUD:

* **envía** operaciones de bloqueo y desbloqueo para las cuentas de cliente relevantes y las retenciones de bloqueo
* **crea** y **archiva** retenciones de bloqueo según las necesita una ejecución
* **descifra** el CPF/CNPJ para consultar en el CRM las cuentas del demandado. No resuelve una cuenta únicamente por token
* **lee** el saldo disponible de una cuenta monitoreada
* **concilia** las órdenes en monitoreo contra instantáneas de saldo del ledger

## Semántica de entrega

***

* **Escrituras de bloqueo deduplicadas.** El servicio deduplica las escrituras de bloqueo por institución y código de bloqueo en su propio almacén antes de llamar al ledger.
* **Eventos al menos una vez.** En operación normal de la caché, Lerian SISBAJUD suprime los identificadores de evento duplicados. Si la caché no está disponible, la deduplicación falla en modo fail-open y el evento continúa.
* **Ámbito de tenant.** Los eventos de cambio de saldo consumidos contienen la identidad de la institución. La integración correlaciona cada cambio de saldo solo con las órdenes de la misma institución.
* **Sin webhooks salientes a terceros.** Lerian SISBAJUD no envía datos a consumidores de webhooks de terceros. También expone un endpoint operativo de notificación de entrega de remesas. Ese endpoint no es una API de ingreso de órdenes.

## Transporte de archivos

***

Los archivos judiciales entran y salen a través del canal de intercambio de archivos de BACEN. [Lerian STA](/es/rails/sta/what-is-lerian-sta) documenta esta integración de propiedad del cliente. Lerian SISBAJUD es un **producto fuente** de ese transporte:

* **Entrada.** Con `STA_CONSUMER_ENABLED` activado, el servicio consume los eventos de archivo que publica Lerian STA. Cada evento indica el objeto almacenado y su digest SHA-256. El servicio lee el objeto y verifica el digest antes de analizar el archivo. `POST /remittance-files/notifications` también recibe y analiza un objeto que ya está almacenado.
* **Salida.** Con `STA_TRANSFERS_ENABLED` activado, el servicio envía cada archivo de respuesta a través de Lerian STA. Cuando está desactivado, el servicio genera los archivos de respuesta, pero no los envía.
* **Dead letter.** El consumidor envía a un tópico de dead letter un evento que un reintento no puede corregir. Confirmar un evento no lo elimina. El tópico conserva los eventos durante su período de retención. `POST /admin/sta-dlq/{eventId}/acknowledge` deja constancia en el registro de auditoría de cómo un operador trató un evento en dead letter.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.