> ## 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 Lerian SPB > Las familias de eventos, la integración con el ledger, la entrega por webhooks y las convenciones de la API para construir sobre Lerian SPB. Lerian SPB está orientado a eventos. La emisión de eventos no se garantiza para cada operación ni cambio de ciclo de vida: algunos emisores son opcionales o de mejor esfuerzo, y `EMISSION_REQUIRED` tiene por defecto `false`. Los eventos duraderos del plano de control se entregan a los webhooks registrados. `settlement.*` y `spb.ldl.*` se entregan solo por el backbone de streaming. Los sistemas aguas abajo leen el estado de liquidación desde los eventos `settlement.*` de streaming y no hacen polling. ## 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 disponibilidad 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 es `opened` o `resolved` | | `str.schedule.changed` | Cambian las franjas de la ventana operativa | | `str.message.*` | A nivel de mensaje: `received`, `sent`, `submitted`, `failed`, `rejected` | | `spb.ldl.*` | Hechos de avisos y comandos de depósito SILOC, incluidos `deposit-commanded`, `deposit-confirmed` y `deposit-failed`. Se entrega solo por el backbone de streaming, no por webhooks | | `settlement.*` | La posición final de liquidación: `settled` cuando la R-leg entrante confirma una operación, `returned` cuando una devolución confirmada revierte una original liquidada, `failed` ante un rechazo o la cancelación de una original nunca liquidada. Se entrega solo por el backbone de streaming, no por webhooks | ## Integración con el ledger *** El consumidor de tu ledger debe recibir las dos familias, `str.operation.*` y `settlement.*`, por el backbone de streaming. `str.operation.accepted` señala la aceptación del despacho, no la liquidación del BACEN, así que úsalo para registrar un asiento pendiente. Registra la posición final desde los hechos `settlement.*` del backbone de streaming: `settlement.settled` se emite exactamente una vez cuando la R-leg entrante mueve la operación a `CONFIRMED`; `settlement.failed` se emite cuando el BACEN rechaza la operación o una cancelación revierte una original nunca liquidada; `settlement.returned` se emite cuando una devolución confirmada revierte una original liquidada. Una devolución sigue el mismo patrón: `str.operation.returnRequested` señala la aceptación del despacho de la devolución, 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. ## Entrante desde el BACEN *** Lerian SPB consume las respuestas de liquidación entrantes del STR (las R-legs) y los avisos de la familia GEN. Ambos llegan desde el BACEN a través de la RSFN. Una operación enviada permanece abierta hasta que llega su R-leg. Luego la R-leg mueve la operación a `CONFIRMED` o `REJECTED`. Lerian SPB proyecta literalmente los campos de liquidación del BACEN. ## Webhooks *** Los consumidores de webhooks se autorregistran sobre las constantes canónicas de eventos. Negocian las formas de payload desde un catálogo de eventos compartido. La entrega es duradera. Puedes reintentar manualmente una entrega fallida. Una ruta de dead-letter maneja 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 nunca filtran payloads de protocolo en crudo.** Lees un solo mensaje por su NUOp. El riel reconstruye una vista XML al momento de la lectura. 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.