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

<Badge stroke icon="calendar-days" iconType="regular">20 de setembro de 2026</Badge> <Badge stroke icon="file-code" iconType="regular">Atualização de documentação</Badge> <Badge color="red" size="lg" stroke icon="triangle-exclamation" iconType="regular">Ação necessária</Badge>

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

***

<Steps>
  <Step>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>
  <Step>Confira que toda chamada protegida envia `X-Idempotency` com essa grafia exata, e não `Idempotency-Key` ou `X-Idempotency-Key`.</Step>
  <Step>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>
  <Step>Leia `ce-schemaversion` em `accounting_profile.configured` e use `effective_from` para decidir qual plano de contas vale em uma competência.</Step>
  <Step>Habilite o job de retrato da carteira no seu deploy se você pretende ler as operações de painel.</Step>
</Steps>

### 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](/pt/products/lender/lender-rest-api)
* [Eventos do Lender](/pt/reference/events/lender)
* [Lista de erros do Lender](/pt/reference/products/lender/lender-error-list)


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