Saltar al contenido principal
Lerian SPB está orientado a eventos. Cada operación y cada cambio de ciclo de vida emite un evento de dominio, entregado tanto a los webhooks registrados como al backbone de streaming de la plataforma, de modo que los sistemas aguas abajo reaccionan al estado de liquidación sin hacer polling.

Familias de eventos


FamiliaSe emite en
str.operation.*Ciclo de vida de la operación — accepted, received, confirmed, sent, submitted, observed, progress
str.readiness.changedCambia el estado de disponibilidad del riel
str.certificate.*Certificado de firma rotated o expiring
str.approval.*Una emisión en cola es signed o denied
str.reconciliation.*Un caso de conciliación es opened o resolved
str.schedule.changedCambian las franjas de la ventana operativa
str.message.*A nivel de mensaje: received, sent, submitted, failed, rejected

Punto de contacto con Midaz


El plugin de ledger de Midaz se suscribe a la familia str.operation.* y basa sus asientos contables en ella —str.operation.accepted es el disparador del asiento—. Lerian SPB no mantiene ninguna posición contable; la posición vive por completo en Midaz. El riel transporta el mensaje y su estado de liquidación, y Midaz 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 desde el BACEN a través de la RSFN. Una operación enviada permanece abierta hasta que llega su R-leg y la mueve a SETTLED o REJECTED, con los campos de liquidación del BACEN proyectados literalmente.

Webhooks


Los consumidores de webhooks se autorregistran sobre las constantes canónicas de eventos y negocian las formas de payload desde un catálogo de eventos compartido. La entrega es duradera: una entrega fallida puede reintentarse manualmente, y 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, de modo que un envío reintentado no despacha dos veces.
  • Las lecturas nunca filtran payloads de protocolo en crudo. Un mensaje puede leerse por su NUOp, con una vista XML reconstruida al momento de la lectura; los bytes literales enviados no se retienen por separado.
  • Los ids desconocidos devuelven un not-found uniforme, que nunca revela si existe una operación que tu institución no posee.