> ## 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 TED Lerian > Integración con Lerian SPB: familias de eventos de operación del STR, integración con el ledger, entrega de webhooks 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. Los webhooks registrados reciben eventos durables del plano de control. Las familias `settlement.*` y `spb.ldl.*` van solo al backbone de streaming. Los sistemas downstream leen el estado de liquidación de los eventos de streaming `settlement.*` 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` exactamente 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`, `sent`, `submitted`, `failed`, `rejected` | | `str.emoney.transferAdvised` | Se registra un nuevo aviso de dinero electrónico de terceros (`SME0001R2`, `SME0002R2` o `SME0004R2`). Se entrega por streaming y por los webhooks registrados | | `spb.ldl.*` | Hechos de aviso de depósito y de comando de depósito de SILOC, incluidos `deposit-commanded`, `deposit-confirmed` y `deposit-failed`. Se entregan solo en el backbone de streaming, no en webhooks | | `settlement.*` | La posición final de liquidación: `settled` una vez que la pata R entrante confirma una operación, `returned` cuando un retorno confirmado revierte un original liquidado, `failed` ante un rechazo o ante la cancelación de un original que nunca liquidó. Se entrega solo en el backbone de streaming, no en webhooks | ## Integración con el ledger *** Tu consumidor de ledger debe recibir tanto la familia `str.operation.*` como la `settlement.*` 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 la operación 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)`. El evento `settlement.failed` se dispara cuando BACEN rechaza la operación o cuando una cancelación revierte un original que nunca liquidó. El evento `settlement.returned` se dispara cuando un retorno confirmado revierte un original liquidado. Un retorno sigue el mismo patrón: `str.operation.returnRequested` señala la aceptación del despacho del retorno, y el asiento padre se revierte con `settlement.returned`. 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. ## Webhooks *** Los consumidores de webhooks se autorregistran en las constantes canónicas de eventos. Negocian las formas de payload desde un catálogo de eventos compartido. La entrega es durable. Puedes reintentar manualmente una entrega fallida. Un camino dead-letter atiende las entregas que agotan sus reintentos. ## Convenciones de la API *** * **La autenticación** es un Bearer token. * **Las escrituras son idempotentes** mediante una clave de idempotencia. 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.