> ## 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 ledger, 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. It wakes the permanent-block logic to re-evaluate a monitored account and attempt the outstanding block. A *reiteração* 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.

Each event carries the **tenant identity**. The integration correlates each balance change only to orders of the same institution. Per-institution isolation holds across the event boundary.

## 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 when an institution rotates its master encryption key.

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 only for the CRM query and never logs it. It does not resolve an account by token alone
* **reads** the available balance of a monitored account
* **reconciles** monitoring orders against ledger balance snapshots

The downstream block code makes block writes **idempotent**. A retried block does not double-post.

## Delivery semantics

***

* **Idempotent block writes.** The downstream block code keys each block write. A replay does not double-post.
* **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. Downstream block-code idempotency is the backstop against duplicate block application.
* **Tenant scope.** Consumed balance-change events carry the institution identity. In multi-tenant deployments, emitted events also carry it. In single-tenant deployments, a block-account-created event may omit the CloudEvents `ce-tenantid` extension when the runtime context is empty.
* **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 consumer** of that transport. Lerian STA delivers the inbound remittance object and its integrity claim-check. `POST /remittance-files/notifications` then synchronously receives and parses the already-delivered object. Lerian SISBAJUD executes the order and returns the result files.