> ## 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 SPI > Mensajes entrantes del BACEN, backbone dirigido por eventos, integración con el ledger y convenciones de API para construir sobre Lerian SPI. Lerian SPI está dirigido por eventos. Las operaciones y los cambios de liquidación fluyen como eventos de dominio sobre el backbone de streaming de la plataforma. Los sistemas dependientes reaccionan a estos cambios sin sondeo. El riel nativo no tiene consumidores de webhook orientados al cliente. Su coordinación es interna a la plataforma. ## Entrante desde el BACEN *** El consumidor ICOM recibe mensajes ISO 20022 firmados del BACEN por la RSFN y los pasa a la entrada interna autenticada del riel. Un mensaje de transferencia de crédito (`pacs.008`) transporta un Pix entrante. Una respuesta de estado (`pacs.002`) informa de un pago que enviaste. Un mensaje de devolución (`pacs.004`) transporta una devolución. El riel valida cada mensaje entrante antes de aplicarlo. Un pago saliente permanece abierto hasta que llega su `pacs.002`; esa respuesta aplica `COMPLETED` o `REJECTED`. Un `pacs.008` entrante se registra como pendiente y se completa o se rechaza mediante la decisión de fondeo del cliente autenticado. El riel registra los campos del BACEN de forma literal. ## Flujo de eventos *** Cada contexto del riel publica y consume los eventos que le pertenecen: * El contexto **BR Code** publica eventos de cobro y los eventos de la familia recurrente (Pix Automático). Consume eventos de liquidación para cerrar un cobro después de que su Pix se liquida. * El contexto **Core** consume eventos de confirmación de participante y eventos de finalización y terminación de liquidación. Mantiene el estado de participantes y operaciones en sincronía con el BACEN. ## Integración con el ledger *** Lerian SPI no mantiene ninguna posición contable propia. El riel emite eventos de liquidación sobre el backbone de streaming, y el consumidor de tu ledger registra la posición correspondiente. El riel transmite cada valor liquidado de forma literal. Cada evento de liquidación lleva un `ce-id` estable que identifica la liquidación; la entrega es al menos una vez, así que el consumidor de tu ledger debe deduplicar las reentregas por el `ce-id`. ## Convenciones de API *** * **La autenticación** sigue el esquema estándar de token bearer de la plataforma. * **Los pagos llevan un end-to-end ID.** Lees un pago y su historial mediante el E2EID. * **Las devoluciones son subrecursos.** Creas y lees una devolución bajo el pago padre entrante que revierte. Debe solicitarse dentro de 90 días de la liquidación de ese pago y no puede llevar la suma de las devoluciones del Pix más allá del valor del propio Pix. La contraparte emite la devolución de un Pix que envió tu cliente, y llega como mensaje entrante. * **Una devolución saliente concluye con la respuesta de BACEN.** Un `pacs.004` de salida que el riel despachó permanece en curso hasta que BACEN lo responda. Una solicitud duplicada de una devolución ya en curso se responde como en curso, y un identificador de devolución en colisión se responde como conflicto —nunca como un recibo. * **Los mensajes entrantes del riel se validan por firma.** El riel no aplica un mensaje que falla la validación.