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

# Lender API and event contract

> The Lender reference now publishes 122 operations instead of 52, three new events, a corrected idempotency contract, and the retirement of the dormant Consignado margin and proposal events.

<Badge stroke icon="calendar-days" iconType="regular">September 20, 2026</Badge> <Badge stroke icon="file-code" iconType="regular">Documentation update</Badge> <Badge color="red" size="lg" stroke icon="triangle-exclamation" iconType="regular">Action required</Badge>

## Affects

***

Teams integrating with the **Lender** API, consuming its events, or relying on the previously documented idempotency behaviour.

## What changed

***

The Lender API reference is regenerated from the product and now publishes **122 operations instead of 52**. The seventy that were missing include the whole assignment-of-receivables family (funds, sets, eligibility, offer files, endorsement terms, registry registration, exceptions and dossiers), returned-payment receivables, loan-product versions and version promotion with its Brazil alias, document templates for products and funds, floating-rate tables, credit instruments, PDD stage ladders, portfolio dashboards, accounting profiles with chart supersession, the accrual-run reads and the accrual-run retry, and the consignado extraordinary-collection surfaces.

Three operations return to the published reference because the product now implements them: `POST /api/v1/accrual-runs/{id}/retry` re-posts the recognitions the ledger has not acknowledged, and the two dashboard reads answer from the daily portfolio snapshot a scheduled producer now writes. The daily PDD promotion sweep builds that snapshot before it scans and ships enabled, so a default deployment has one.

The event catalog has **37 definitions, 34 of them with a production emitter**. Three are new: `returned_payment_receivable.opened` and `returned_payment_receivable.collected` describe the separate borrower debt a reversed final payment opens when the contract it closed can no longer take the money back, and `loan_product.current_version_promoted` reports a live product repointed at another of its versions. `accounting_profile.configured` moves to schema `1.1.0` and carries `effective_from`, the civil day its chart starts governing. `loan_product_version.created` gained an optional minimum and maximum annual-rate band.

`consignado.margin.requested`, `consignado.margin.fetched` and `consignado.proposal.accepted` are retired from the catalog. `consignado.margin.fetched` was the only one this reference ever listed, and it is gone; `consignado.proposal.accepted` is now named only to say Lender does not register it. `consignado.averbacao.confirmed` stays cataloged, and nothing emits it and no Lender consumer subscribes to it, so it is marked as such rather than listed as an integration.

The documented idempotency contract is corrected in three ways. It covers **27 operations, not seven**, in two classes: 24 enforced at the edge by a required `X-Idempotency` header, and three whose replay marker commits in the same database transaction as the money. It is **fail-closed, not fail-open**: a deployment with no reachable idempotency store does not start, and a store that becomes unreachable makes a guarded operation answer `503` rather than execute unprotected. A key sent under a spelling Lender does not read, `Idempotency-Key` or `X-Idempotency-Key`, answers `400` with the code `IDEMPOTENCY_KEY_HEADER_UNKNOWN` instead of running the command unprotected.

These entries align the public documentation with the implemented contract; they do not announce a runtime release.

## Impact

***

**Classification: Action required.** The idempotency correction changes what your client must do during an idempotency-store outage, and a subscriber to a retired Consignado event receives nothing.

## What you need to do

***

<Steps>
  <Step>Review your idempotency handling against the corrected contract: assume fail-closed, and branch on the refusal codes rather than on the status alone.</Step>
  <Step>Check that every guarded call sends `X-Idempotency` under that exact spelling, not `Idempotency-Key` or `X-Idempotency-Key`.</Step>
  <Step>Remove any subscription to `consignado.margin.requested`, `consignado.margin.fetched` or `consignado.proposal.accepted`, and do not build against `consignado.averbacao.confirmed`.</Step>
  <Step>Read `ce-schemaversion` on `accounting_profile.configured` and use `effective_from` to decide which chart governs an accounting period (a competência).</Step>
  <Step>Enable the portfolio snapshot job in your deployment if you intend to read the dashboard operations.</Step>
</Steps>

### Deadline

Complete the idempotency and event-subscription review before your next Lender deployment or integration release.

## Resources

***

* [Lender REST API](/en/products/lender/lender-rest-api)
* [Lender events](/en/reference/events/lender)
* [Lender error list](/en/reference/products/lender/lender-error-list)


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