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

# Integrating with Lerian SISBAJUD

> Integrating with Lerian SISBAJUD: Midaz balance events that drive permanent-block reattempts, business events emitted, ledger connector, and delivery semantics.

Lerian SISBAJUD is event-first where it meets the ledger. It **consumes** balance-change events from Midaz to drive permanent blocks. It **emits** operational business events that other systems can observe. It sends no outbound webhooks to third-party consumers. Its interfaces are the Midaz ledger, Lerian STA, the remittance-delivery notification endpoint, and its administrative surface.

## Ledger events it consumes

***

The integration subscribes to Midaz **balance-change events**. It treats each event as a **trigger**. An event decides nothing by itself. The integration matches the event's account against the accounts that earlier blocks drew from. It then runs the block logic for the open orders of that account's holder.

A permanent block uses this path to capture funds that arrive after the first attempt. After a partial initial traditional block, a credit later that day can also trigger complementary attempts.

## Business events it emits

***

Lerian SISBAJUD emits operational business events with **no personal data** in their payloads:

* A **block-account-created** event when an execution creates a block holding. It is an operational signal, not a money or PII carrier.
* A **key-rotated** event (`kek.rotated`) when an operator rotates an institution's key-encryption key with Vault as the key provider.

These events serve observability and coordination. The money movements live in the Midaz ledger, not in the event payloads.

## Midaz boundary

***

**Midaz** is the ledger connector. Through it, Lerian SISBAJUD:

* **submits** block and unblock operations for the relevant customer accounts and block holdings
* **creates** and **archives** block holdings as an execution needs them
* **decrypts** the CPF/CNPJ to query CRM for the defendant's accounts. It does not resolve an account by token alone
* **reads** the available balance of a monitored account
* **reconciles** monitoring orders against ledger balance snapshots

## Delivery semantics

***

* **Deduplicated block writes.** The service deduplicates block writes by institution and block code in its own store before it calls the ledger.
* **At-least-once events.** Under normal cache operation, Lerian SISBAJUD suppresses duplicate event identifiers. If the cache is unavailable, deduplication fails open and the event proceeds.
* **Tenant scope.** Consumed balance-change events carry the institution identity. The integration correlates each balance change only to orders of the same institution.
* **No outbound third-party webhooks.** Lerian SISBAJUD does not push to third-party webhook consumers. It also exposes an operational remittance-delivery notification endpoint. That endpoint is not an order-entry API.

## File transport

***

Judicial files enter and leave over BACEN's file-exchange channel. [Lerian STA](/en/rails/sta/what-is-lerian-sta) documents this client-owned integration. Lerian SISBAJUD is a **source product** of that transport:

* **Inbound.** With `STA_CONSUMER_ENABLED` on, the service consumes the file events that Lerian STA publishes. Each event names the stored object and its SHA-256 digest. The service reads the object and checks the digest before it parses the file. `POST /remittance-files/notifications` also receives and parses an object that is already stored.
* **Outbound.** With `STA_TRANSFERS_ENABLED` on, the service submits each response file through Lerian STA. When it is off, the service generates response files but does not submit them.
* **Dead letter.** The consumer sends an event that a retry cannot fix to a dead-letter topic. Acknowledging an event does not remove it. The topic keeps events for its retention period. `POST /admin/sta-dlq/{eventId}/acknowledge` records how an operator treated a dead-lettered event in the audit trail.


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