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