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

# Eventos e integración con el ledger

> Integración con Lerian SPB: familias de eventos de operación del STR, integración con el ledger y convenciones de la API.

Lerian SPB es orientado a eventos. La emisión de eventos no está garantizada para cada operación o cambio de ciclo de vida: algunos emisores son opcionales o best effort, y `EMISSION_REQUIRED` tiene `false` como valor predeterminado. Define `EMISSION_REQUIRED=true` en un despliegue cuyos sistemas downstream dependan de estos eventos. Entonces el bootstrap falla cerrado a menos que la emisión de eventos esté conectada por completo.

Lerian SPB publica todas las familias de eventos en el backbone de streaming. Los sistemas downstream leen el estado de liquidación de los eventos de streaming `settlement.*` y `spb.ldl.*` y no hacen sondeo.

## Familias de eventos

***

| Familia | Se emite en |
| - | - |
| `str.operation.*` | Ciclo de vida de la operación: `accepted`, `received`, `returnRequested`, `cancelRequested` |
| `str.readiness.changed` | Cambia el estado de readiness del riel |
| `str.certificate.*` | Ciclo de vida del certificado: `rotated`, `expiring`, `counterpartyChanged`, `activationRequested` |
| `str.approval.*` | Una aprobación en cola emite `signed` o `denied`; cuando alcanza el quórum y cambia de `PENDING_APPROVAL` a `SUBMITTED`, emite `quorumReached` una vez |
| `str.reconciliation.*` | Un caso de conciliación pasa a `opened` o `resolved` |
| `str.schedule.changed` | Cambian las grillas de la ventana de operación |
| `str.message.*` | En el nivel del mensaje: `received`, `submitted`, `rejected` |
| `str.emoney.transferAdvised` | Se registra un nuevo aviso de dinero electrónico de terceros (`SME0001R2`, `SME0002R2` o `SME0004R2`) |
| `spb.ldl.*` | Hechos de aviso de depósito y de comando de depósito de SILOC, incluidos `deposit-commanded`, `deposit-confirmed` y `deposit-failed`. Hechos de liquidación LDL y LTR: `settlement-confirmed`, `settlement-failed` y `third-party-settlement-received` |
| `settlement.*` | La posición final de liquidación: `settled` una vez que la pata R entrante confirma la transferencia, `failed` ante un rechazo o ante la cancelación de un original que nunca liquidó |

Los avisos entrantes de BACEN también publican eventos dedicados. Consulta [Mensajería entrante desde BACEN](https://docs.lerian.studio/es/rails/spb/spb-inbound-messaging.md).

## Integración con el ledger

***

Tu consumidor de ledger debe recibir las familias `str.operation.*`, `settlement.*` y `spb.ldl.*` en el backbone de streaming. El evento `str.operation.accepted` señala la aceptación del despacho, no la liquidación en BACEN, así que úsalo para registrar un asiento pendiente.

Registra la posición final a partir de los hechos `settlement.*` del backbone de streaming. La transición de negocio detrás de `settlement.settled` ocurre cuando la pata R entrante mueve el mensaje STR de la transferencia a `CONFIRMED`. La entrega del broker es al menos una vez y puede reenviar el hecho. El `ce-id` es determinista, así que deduplica por el par `(ce-source, ce-id)`.

Las liquidaciones LDL, los depósitos LDL0022, el pago LTR0004 y los avisos LDL y LTR0005R2 no solicitados no tienen hecho `settlement.*`. Regístralos a partir de los hechos `spb.ldl.*`:

* La respuesta R1 a tu comando: `deposit-confirmed` o `deposit-failed` para un depósito OT, y `settlement-confirmed` o `settlement-failed` para todos los demás comandos.
* Un crédito LDL0020R2 que corresponde a un crédito OT esperado: `credit-received`.
* Todos los demás avisos: `third-party-settlement-received`.

Un crédito entrante que no responde a ninguna operación tuya llega como `str.operation.received`, así que registra ese crédito a partir de este evento. Un retorno de una TED que enviaste llega de la misma forma. Su campo `numCtrlSTROr` contiene el número de control de tu TED original.

Un retorno devuelve un crédito TED que recibiste, como una transferencia propia. `str.operation.returnRequested` señala la aceptación del despacho del retorno, y el `settlement.settled` o el `settlement.failed` del propio retorno da su posición final. Lerian SPB no mantiene ninguna posición contable. El riel transporta el mensaje y su estado de liquidación, y tu ledger registra el dinero.

## Convenciones de la API

***

* **La autenticación** es un Bearer token.
* **Las escrituras son idempotentes** mediante el header `X-Idempotency`. Un envío reintentado no despacha dos veces.
* **Las lecturas del log de mensajes no exponen el frame firmado que viajó por la red.** Lees un solo mensaje por su NUOp para obtener datos estructurados. Cuando el riel retuvo un frame, lee su XML reconstruido por la ruta de frame dedicada y autorizada por separado. No retiene por separado los bytes literales enviados.
* **Los ids desconocidos devuelven un not-found uniforme.** La respuesta nunca revela si existe una operación que tu institución no posee.


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