EMISSION_REQUIRED tem padrão false. Eventos duráveis do plano de controle são entregues aos webhooks registrados. settlement.* e spb.ldl.* são entregues apenas pelo backbone de streaming. Os sistemas a jusante leem o estado de liquidação pelos eventos settlement.* de streaming e não fazem polling.
Famílias de eventos
Integração com o ledger
O consumidor do seu ledger deve receber as duas famílias,
str.operation.* e settlement.*, pelo backbone de streaming. O str.operation.accepted sinaliza a aceitação do despacho, não a liquidação do BACEN; use-o para registrar um lançamento pendente. Registre a posição final a partir dos fatos settlement.* do backbone de streaming: a transição de negócio por trás de settlement.settled acontece quando a R-leg de entrada move a operação para CONFIRMED, mas a entrega pelo broker é at-least-once e pode reenviar o fato; o ce-id é determinístico, então deduplique pelo par (ce-source, ce-id). O settlement.failed é emitido quando o BACEN rejeita a operação ou um cancelamento reverte uma original nunca liquidada; o settlement.returned é emitido quando uma devolução confirmada reverte uma original liquidada. Uma devolução segue o mesmo padrão: o str.operation.returnRequested sinaliza a aceitação do despacho da devolução, e o lançamento pai é revertido com o settlement.returned. O Lerian SPB não mantém nenhuma posição contábil. O trilho transporta a mensagem e o seu estado de liquidação, e o seu ledger registra o dinheiro.
Entrada a partir do BACEN
O Lerian SPB consome as respostas de liquidação de entrada do STR (as R-legs) e os avisos da família GEN. Ambos chegam do BACEN pela RSFN. Uma operação enviada permanece aberta até que a sua R-leg chegue. Em seguida, a R-leg move a operação para
CONFIRMED ou REJECTED. O Lerian SPB projeta literalmente os campos de liquidação do BACEN.
Webhooks
Os consumidores de webhooks se autorregistram sobre as constantes canônicas de eventos. Eles negociam os formatos de payload a partir de um catálogo de eventos compartilhado. A entrega é durável. Você pode reprocessar manualmente uma entrega que falhou. Uma rota de dead-letter trata as entregas que esgotam as suas tentativas.
Convenções da API
- A autenticação é um bearer token.
- As escritas são idempotentes por meio de uma chave de idempotência. Um envio reprocessado não despacha duas vezes.
- As leituras nunca vazam payloads de protocolo em bruto. Você lê uma única mensagem pelo seu NUOp. O trilho reconstrói uma visão XML no momento da leitura. Ele não retém separadamente os bytes literais enviados.
- Os ids desconhecidos retornam um not-found uniforme. A resposta nunca revela se existe uma operação que a sua instituição não possui.