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