> ## 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 y de eventos de Lender

> La referencia de Lender ahora publica 122 operaciones en lugar de 52, tres eventos nuevos, un contrato de idempotencia corregido y el retiro de los eventos dormidos de margen y de propuesta de Consignado.

<Badge stroke icon="calendar-days" iconType="regular">20 de septiembre de 2026</Badge> <Badge stroke icon="file-code" iconType="regular">Actualización de documentación</Badge> <Badge color="red" size="lg" stroke icon="triangle-exclamation" iconType="regular">Acción requerida</Badge>

## Afecta a

***

Equipos que integran con la API de **Lender**, consumen sus eventos o dependen del comportamiento de idempotencia documentado antes.

## Qué cambió

***

La referencia de la API de Lender se regeneró desde el producto y ahora publica **122 operaciones en lugar de 52**. Las setenta que faltaban incluyen toda la familia de cesión de cuentas por cobrar (fondos, lotes, elegibilidad, archivos de oferta, términos de endoso, registro en la registradora, excepciones y expedientes), cuentas por cobrar de pago devuelto, versiones de producto y promoción de versión con su alias de Brasil, plantillas de documento para productos y fondos, tablas de tasa flotante, instrumentos de crédito, escaleras de etapa de PDD, paneles de cartera, perfiles contables con sucesión de plan de cuentas, las lecturas de corrida de devengo y el reintento de corrida de devengo, y las superficies de cobro extraordinario del consignado.

Tres operaciones vuelven a la referencia publicada porque el producto ahora las implementa: `POST /api/v1/accrual-runs/{id}/retry` reenvía al ledger los reconocimientos que no confirmó, y las dos lecturas de panel responden desde la instantánea diaria de cartera que ahora escribe un productor programado. El barrido diario de promoción de PDD construye esa instantánea antes de barrer y viene habilitado, así que un despliegue por defecto tiene una.

El catálogo de eventos tiene **37 definiciones, 34 de ellas con emisor en producción**. Tres son nuevas: `returned_payment_receivable.opened` y `returned_payment_receivable.collected` describen la deuda separada del prestatario que un pago final revertido abre cuando el contrato que cerró ya no puede recibir el dinero de vuelta, y `loan_product.current_version_promoted` informa que un producto activo fue reapuntado a otra de sus versiones. `accounting_profile.configured` pasa al esquema `1.1.0` y lleva `effective_from`, el día civil en que su plan de cuentas empieza a regir. `loan_product_version.created` ganó una banda opcional de tasa anual mínima y máxima.

`consignado.margin.requested`, `consignado.margin.fetched` y `consignado.proposal.accepted` se retiraron del catálogo. `consignado.margin.fetched` fue el único que esta referencia llegó a listar, y ya no está; `consignado.proposal.accepted` ahora se nombra solo para decir que Lender no lo registra. `consignado.averbacao.confirmed` sigue catalogado, y nada lo emite y ningún consumidor de Lender se suscribe a él, así que está marcado como tal en lugar de listado como integración.

El contrato de idempotencia documentado se corrigió en tres puntos. Cubre **27 operaciones, no siete**, en dos clases: 24 impuestas en el borde por un header `X-Idempotency` obligatorio, y tres cuya marca de repetición se confirma en la misma transacción de base de datos que el dinero. **Falla cerrado, no abierto**: un despliegue sin almacén de idempotencia accesible no arranca, y un almacén que queda inaccesible hace que una operación protegida responda `503` en lugar de ejecutar sin protección. Una clave enviada con una grafía que Lender no lee, `Idempotency-Key` o `X-Idempotency-Key`, responde `400` con el código `IDEMPOTENCY_KEY_HEADER_UNKNOWN` en lugar de correr el comando sin protección.

Estas entradas alinean la documentación pública con el contrato implementado; no anuncian un lanzamiento de runtime.

## Impacto

***

**Clasificación: Acción requerida.** La corrección de idempotencia cambia lo que tu cliente debe hacer durante una caída del almacén de idempotencia, y quien se suscribe a un evento retirado de Consignado no recibe nada.

## Qué necesitas hacer

***

<Steps>
  <Step>Revisa tu manejo de idempotencia contra el contrato corregido: asume falla cerrada y decide por los códigos de rechazo, no solo por el estado.</Step>
  <Step>Comprueba que cada llamada protegida envía `X-Idempotency` con esa grafía exacta, y no `Idempotency-Key` ni `X-Idempotency-Key`.</Step>
  <Step>Quita cualquier suscripción a `consignado.margin.requested`, `consignado.margin.fetched` o `consignado.proposal.accepted`, y no construyas sobre `consignado.averbacao.confirmed`.</Step>
  <Step>Lee `ce-schemaversion` en `accounting_profile.configured` y usa `effective_from` para decidir qué plan de cuentas rige en una competencia.</Step>
  <Step>Habilita el job de instantánea de cartera en tu despliegue si piensas leer las operaciones de panel.</Step>
</Steps>

### Fecha límite

Completa la revisión de idempotencia y de suscripciones de evento antes de tu próximo despliegue de Lender o lanzamiento de integración.

## Recursos

***

* [API REST de Lender](/es/products/lender/lender-rest-api)
* [Eventos de Lender](/es/reference/events/lender)
* [Lista de errores de Lender](/es/reference/products/lender/lender-error-list)


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