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

# Contrato de API e de eventos do Lender

> A referência do Lender agora publica 122 operações em vez de 52, três eventos novos, um contrato de idempotência corrigido e a retirada dos eventos dormentes de margem e de proposta do Consignado.

20 de setembro de 2026Atualização de documentaçãoAção necessária

## Afeta

***

Times que integram com a API do Lender, consomem seus eventos ou dependem do comportamento de idempotência documentado antes.

## O que mudou

***

A referência da API do Lender foi regerada a partir do produto e agora publica 122 operações em vez de 52. As setenta que faltavam incluem toda a família de cessão de recebíveis (fundos, lotes, elegibilidade, arquivos de oferta, termos de endosso, registro na registradora, exceções e dossiês), recebíveis de pagamento devolvido, versões de produto e promoção de versão com seu apelido Brasil, modelos de documento para produtos e fundos, tabelas de taxa flutuante, instrumentos de crédito, escadas de estágio de PDD, painéis da carteira, perfis contábeis com sucessão de plano de contas, as leituras de execução de accrual e a retentativa de execução de accrual, e as superfícies de cobrança extraordinária do consignado.

Três operações voltam à referência publicada porque o produto agora as implementa: `POST /api/v1/accrual-runs/{id}/retry` reenvia ao razão os reconhecimentos que ele não confirmou, e as duas leituras de painel respondem a partir do retrato diário da carteira que um produtor agendado agora escreve. A varredura diária de promoção de PDD constrói esse retrato antes de varrer e vem habilitada, então um deploy padrão tem um.

O catálogo de eventos tem 37 definições, 34 delas com emissor em produção. Três são novas: `returned_payment_receivable.opened` e `returned_payment_receivable.collected` descrevem a dívida separada do tomador que um pagamento final estornado abre quando o contrato que ele encerrou já não pode receber o dinheiro de volta, e `loan_product.current_version_promoted` informa que um produto ativo foi reapontado para outra de suas versões. `accounting_profile.configured` passa para o schema `1.1.0` e carrega `effective_from`, o dia civil em que seu plano de contas passa a valer. `loan_product_version.created` ganhou uma faixa opcional de taxa anual mínima e máxima.

`consignado.margin.requested`, `consignado.margin.fetched` e `consignado.proposal.accepted` foram retirados do catálogo. `consignado.margin.fetched` foi o único que esta referência chegou a listar, e ele saiu; `consignado.proposal.accepted` agora é nomeado apenas para dizer que o Lender não o registra. `consignado.averbacao.confirmed` segue catalogado, e nada o emite e nenhum consumidor do Lender assina ele, então ele está marcado assim em vez de listado como integração.

O contrato de idempotência documentado foi corrigido em três pontos. Ele cobre 27 operações, não sete, em duas classes: 24 impostas na borda por um header `X-Idempotency` obrigatório, e três cuja marca de repetição é confirmada na mesma transação de banco de dados que o dinheiro. Ele falha fechado, não aberto: um deploy sem armazenamento de idempotência acessível não sobe, e um armazenamento que fica inacessível faz uma operação protegida responder `503` em vez de executar desprotegida. Uma chave enviada com uma grafia que o Lender não lê, `Idempotency-Key` ou `X-Idempotency-Key`, responde `400` com o código `IDEMPOTENCY_KEY_HEADER_UNKNOWN` em vez de rodar o comando desprotegido.

Estas entradas alinham a documentação pública ao contrato implementado; elas não anunciam um release de runtime.

## Impacto

***

**Classificação: Ação necessária.** A correção de idempotência muda o que seu cliente precisa fazer durante uma indisponibilidade do armazenamento de idempotência, e quem assina um evento retirado do Consignado não recebe nada.

## O que você precisa fazer

***

**Step 1**

Revise seu tratamento de idempotência contra o contrato corrigido: assuma falha fechada e decida pelos códigos de recusa, não só pelo status.

**Step 2**

Confira que toda chamada protegida envia `X-Idempotency` com essa grafia exata, e não `Idempotency-Key` ou `X-Idempotency-Key`.

**Step 3**

Remova qualquer assinatura de `consignado.margin.requested`, `consignado.margin.fetched` ou `consignado.proposal.accepted`, e não construa em cima de `consignado.averbacao.confirmed`.

**Step 4**

Leia `ce-schemaversion` em `accounting_profile.configured` e use `effective_from` para decidir qual plano de contas vale em uma competência.

**Step 5**

Habilite o job de retrato da carteira no seu deploy se você pretende ler as operações de painel.

### Prazo

Conclua a revisão de idempotência e de assinaturas de evento antes do seu próximo deploy do Lender ou release de integração.

## Recursos

***

* [API REST do Lender](https://docs.lerian.studio/pt/products/lender/lender-rest-api.md)
* [Eventos do Lender](https://docs.lerian.studio/pt/reference/events/lender.md)
* [Lista de erros do Lender](https://docs.lerian.studio/pt/reference/products/lender/lender-error-list.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.