> ## 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. # Eventos do Lender > Assine a jornada de crédito: o source fixo de CloudEvents, os formatos de tópico e de ce-type, os 21 eventos da jornada documentada, a garantia de durabilidade do outbox e o que um payload carrega. O Lender publica um evento de negócio sempre que um produto, uma solicitação, uma conta de empréstimo ou um registro regulatório brasileiro muda de estado. Assine esses eventos e o seu serviço reage a cada mudança à medida que ela acontece, sem loop de polling. Cada evento é respaldado pelo outbox e tem escopo por tenant. Esta página cobre o lado do consumidor: o que chega no wire, quais eventos existem e como deixar um handler seguro. ## Ative a publicação *** Publicar eventos é uma decisão de implantação. A originação funciona sem ela. | Configuração | Valor | | ------------------------------ | ------------------------------------------------------------------------------- | | `STREAMING_ENABLED` | `true` | | `STREAMING_BROKERS` | Os endereços do RedPanda. | | `STREAMING_CLOUDEVENTS_SOURCE` | `lender`. O Lender exige exatamente este valor e o valida na inicialização. | | `OUTBOX_ENABLED` | `true`. Cada evento é respaldado pelo outbox, então publicar precisa do outbox. | O Lender se recusa a iniciar quando a publicação está ativa e algo disso está errado, então uma implantação mal configurada falha na inicialização em vez de perder eventos em silêncio. ## O contrato do wire *** O source de CloudEvents é o literal fixo `lender`, e o source também serve de namespace para cada tópico. Assim, um assinante lê: | Elemento do wire | Valor | | ------------------- | ------------------------------------------------------------- | | Tópico Kafka | `lender..` | | Header `ce-source` | `lender` | | Header `ce-type` | `studio.lerian..` | | Header `ce-subject` | O identificador do registro que mudou. | | Chave de partição | O tenant, para que os eventos de um tenant mantenham a ordem. | Para um desembolso isso resolve para: ``` tópico lender.loan_application.disbursed ce-type studio.lerian.loan_application.disbursed ``` As mensagens viajam no modo binário do CloudEvents, versão 1.0. Os atributos de contexto viajam como headers da mensagem: `ce-specversion`, `ce-id`, `ce-source`, `ce-type`, `ce-time`, `ce-schemaversion`, `ce-resourcetype` e `ce-eventtype` em cada mensagem, mais `ce-subject`, `ce-datacontenttype` e `ce-tenantid` quando o Lender tem um valor para eles. `ce-schemaversion` é `1.0.0` para cada evento do catálogo. O tópico não carrega sufixo de versão nesta versão de esquema, então assine o nome de tópico simples. **Assine por tópico.** O tópico é o endereço, e ele se compõe do resource type e do event type — não de um nome interno de catálogo. Leia a coluna de tópico nas tabelas abaixo em vez de derivar um a partir da descrição de um evento. ## Os eventos *** Esta página cobre os **21 eventos da jornada de crédito documentada**. Eles se agrupam pela parte da jornada que reportam. O manifesto de streaming declara o catálogo inteiro da sua implantação, que pode carregar mais definições do que esta página lista. ### Produtos | Tópico | Emitido quando | | -------------------------------------- | --------------------------------------------------------------------- | | `lender.loan_product.created` | Um produto é criado como definição em rascunho. | | `lender.loan_product.activated` | Um produto passa a ativo e fixa a versão atual. | | `lender.loan_product_version.created` | Um snapshot de versão é acrescentado como termos imutáveis. | | `lender.accounting_profile.configured` | Um perfil e suas regras de posting ficam vinculados a uma versão. | | `lender.loan_charge.applied` | Um encargo de versão de produto é aplicado a uma conta de empréstimo. | ### Originação | Tópico | Emitido quando | | ----------------------------------- | --------------------------------------------------------------------------------- | | `lender.loan_application.submitted` | Uma solicitação é aceita e fica esperando aprovação. | | `lender.loan_application.approved` | Uma solicitação é aprovada, com os fatos da decisão. | | `lender.loan_application.rejected` | Uma solicitação é rejeitada, com os fatos da decisão. | | `lender.loan_application.withdrawn` | Uma solicitação pendente é retirada. | | `lender.loan_application.disbursed` | Uma solicitação aprovada é desembolsada e uma conta de empréstimo entra em vigor. | ### Servicing | Tópico | Emitido quando | | ----------------------------------------- | ----------------------------------------------------------- | | `lender.repayment.recorded` | Um pagamento é registrado, com a sua alocação de caixa. | | `lender.repayment_reversal.recorded` | Uma reversão é registrada como transação compensatória. | | `lender.loan_schedule.prepayment_applied` | Um pré-pagamento produz uma versão sucessora do cronograma. | | `lender.loan_schedule.rescheduled` | Uma repactuação produz uma versão sucessora do cronograma. | ### Pacote Brasil | Tópico | Emitido quando | | -------------------------------------------- | ----------------------------------------------------------------------------------------- | | `lender.loan_account.pdd_stage_transitioned` | Uma transição ou cura de estágio de PDD é registrada, com a elegibilidade de apropriação. | | `lender.prepayment_quote.created` | Uma cotação de pré-pagamento imutável é criada. | | `lender.prepayment_settlement.recorded` | Uma cotação aceita é liquidada, com o detalhamento final. | ### Consignado privado | Tópico | Emitido quando | | ---------------------------------------------- | ---------------------------------------------------------------------------------------- | | `lender.consignado_exclusao.requested` | O Lender pede ao rail de folha o cancelamento de uma averbação. | | `lender.consignado_redirecionamento.requested` | O Lender pede ao rail de folha o redirecionamento da cobrança para outro vínculo. | | `lender.payroll_deduction.refund_required` | Chegou caixa confirmado de folha após a quitação e o tomador tem um reembolso a receber. | | `lender.guarantee_recovery_cash.allocated` | Um recebimento confirmado de recuperação de garantia é alocado. | A jornada de consignado também **consome** fatos do gateway de desconto em folha, nos tópicos daquele produto. Veja [Consignado privado](/pt/lender/consignado-privado). ## Durabilidade e entrega *** Cada evento do catálogo carrega a mesma política de entrega. Nada publica direto no broker. O Lender escreve o evento num outbox transacional na **mesma transação de banco de dados** que a mudança de estado, e um dispatcher o transmite depois. O evento portanto sobrevive a uma queda, e sobrevive a uma queda do broker enquanto o dispatcher tenta de novo. O orçamento de tentativas é limitado. O dispatcher dá a um evento as tentativas de `OUTBOX_MAX_DISPATCH_ATTEMPTS`, e o valor padrão é `10`. Ele espera `OUTBOX_RETRY_WINDOW_SEC` segundos entre tentativas, e o valor padrão é `300`. Passado esse orçamento o dispatcher para de tentar o evento. Aumente o orçamento quando você esperar quedas mais longas que a janela padrão. Os eventos viajam pelo mesmo outbox que o relay do ledger, então a mudança de estado local e o evento são confirmados juntos numa única transação de banco de dados. A intenção de posting se junta a eles quando a mudança produz uma. A contabilização no ledger chega depois. Leia [Contabilidade e rotinas de apropriação](/pt/lender/accounting-and-accrual-runs). **A entrega é ao menos uma vez.** Um evento pode chegar mais de uma vez, e uma reentrega carrega os mesmos fatos. Deixe cada handler idempotente sobre o identificador do registro no payload, que também viaja em `ce-subject`. ## O que um payload carrega *** O body é JSON e carrega os fatos da mudança, não um diff. Um body de `loan_application.disbursed`: ```json theme={null} { "loanApplicationId": "018f2a1c-7d40-7b31-9d40-2f1e8c5a4b77", "loanProductVersionId": "8f2c1a9e-4b30-4c02-9a1b-2d5e6f7a1c33", "borrowerId": "borrower-0001", "assignedOfficerId": "officer-0007", "status": "disbursed", "loanAccountId": "7c9e6679-7425-40de-944b-e07fc1f90ae7", "disbursementEventId": "019826f4-6a9c-7b31-8a02-11c3d4e5f678", "grossRequestedAmount": "48000.00", "netDeliveredAmount": "48000.00", "disbursedAt": "2026-08-01T13:00:00Z", "previewJurisdictionCode": "XX", "updatedAt": "2026-08-01T13:00:00Z" } ``` **Dinheiro e taxas viajam como strings decimais**, nunca como números JSON, igual ao que acontece sobre REST. Faça o parse com um tipo decimal. Os timestamps são RFC 3339 em UTC. Cada evento carrega os fatos que o próprio registro guarda, então leia o formato do evento que você assina. Um evento brasileiro acrescenta o que a regulação dele precisa: uma transição de PDD carrega o estágio e a elegibilidade de apropriação, e uma cotação de pré-pagamento carrega o desconto e a reconciliação de IOF. ## Confira o contrato na inicialização *** `GET /api/v1/streaming/manifest` devolve o manifesto do catálogo: cada definição de evento com seu resource type, event type, versão de esquema e política de entrega. Ele pede um token bearer com `streaming_manifest` `read`. Ele reporta o catálogo declarado inteiro da implantação, não a visão de um tenant. Leia-o quando o seu consumidor iniciar. Compare cada evento ao qual você assina com o manifesto: o resource type, o event type e a versão de esquema. Isso detecta um desencontro de nome ou de versão na inicialização em vez de em tempo de execução. ## Próximos passos *** O caminho base, autenticação, idempotência e as operações por trabalho. As partes do serviço, a rota do outbox e o trabalho por tempo. Onde o Lender fica ao lado do Midaz, do Access Manager e do backbone de streaming. A jornada de desconto em folha e os fatos que ela consome.