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

> How Lerian SISBAJUD integrates — the ledger balance events it consumes to drive permanent-block reattempts, the operational business events it emits, its Midaz ledger connector, and its idempotency and delivery semantics.

Lerian SISBAJUD is event-first where it meets the ledger. It **consumes** balance-change events from Midaz to drive permanent blocks, and it **emits** operational business events that other systems can observe. It has **no external webhook consumers** — its edges are the ledger and its own administrative surface.

## Ledger events it consumes

***

The integration subscribes to Midaz **balance-change events**. It treats these as a **trigger, not a rule**: an event does not by itself decide anything, it wakes the permanent-block logic to re-evaluate a monitored account and attempt the still-outstanding block. This is how a *reiteração* captures funds that arrive after the first attempt.

Each event carries the **tenant identity**, so a balance change is correlated only to orders belonging to 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 it opens a dedicated block account for an order — an operational signal, not a money or PII carrier.
* A **key-rotated** event when an institution's master encryption key is rotated.

These events are for observability and coordination; the money movements themselves live in the Midaz ledger, not in the event payloads.

## Midaz boundary

***

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

* **blocks** and **unblocks** funds by moving them between the customer account and the per-order block account;
* **creates** and **archives** a dedicated block account per order;
* **resolves** an account by its fiscal-identifier token;
* **reads** the available balance of a monitored account; and
* **reconciles** monitoring orders against ledger balance snapshots.

All ledger writes are **idempotent by a unique code**, so a retried order never double-posts.

## Delivery semantics

***

* **Idempotent writes.** Every write operation is keyed by a unique code; replaying it is a no-op.
* **At-least-once events.** Consumed events are delivered at least once and **deduplicated by event identifier**, so a redelivered balance change does not trigger a duplicate reattempt.
* **Tenant on every event.** The institution identity travels with each event, keeping per-institution isolation intact end to end.
* **No external webhooks.** Lerian SISBAJUD does not push to third-party webhook consumers; integration is through the ledger and the administrative API.

## File transport

***

Judicial files enter and leave over BACEN's file-exchange channel — the client-owned integration documented in [Lerian STA](/en/rails/native/sta/what-is-lerian-sta). Lerian SISBAJUD is a **source-product consumer** of that transport: Lerian STA delivers the inbound remittance file and its integrity claim-check, and Lerian SISBAJUD parses, fulfils, and returns the result files.