> ## 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.
# SDK de Lender e integración embebida
> Integra Lender desde tu propio software: la superficie REST que lleva cada operación, lo que tu cliente debe manejar en dinero, errores, reintentos y paginación, y el patrón para ejecutar Lender detrás de un producto que tus usuarios ya usan.
**La API REST de Lender es toda la superficie de cliente.** Productos, solicitudes, cuentas de préstamo, ejecuciones de devengo y los registros regulatorios brasileños son todos llamadas HTTP bajo `/api/v1`. Nada existe solo dentro de una biblioteca cliente.
Llama a Lender con el cliente HTTP que tu stack ya tiene. No hay una biblioteca cliente de Lender que instalar, así que la API es el contrato contra el que escribes. Esta página cubre lo que tu cliente debe manejar y lo que conviene guardar de tu lado. Después cubre cómo colocar Lender detrás de un producto con el que tus usuarios ya hablan. Lee [API REST de Lender](/es/lender/lender-rest-api) para las operaciones en sí.
Los documentos OpenAPI de este portal son fuentes de renderizado para las páginas de referencia. No son contratos de cliente, y no son base para generar un cliente ni un SDK.
## Lo que tu cliente debe manejar
***
Cuatro reglas cubren la mayor parte del código que escribes contra Lender.
### El dinero viaja como string decimal
Los importes monetarios son strings decimales JSON, normalmente con dos decimales. Las tasas decimales como `requestedInterestRate` son strings con ocho decimales; `fixedAnnualRateBps`, `floatingSpreadBps` y `annualRateBps` son puntos básicos enteros:
```json theme={null}
{
"requestedPrincipalAmount": "50000.00",
"requestedInterestRate": "0.01500000"
}
```
Envía el string, y parsea el string con el tipo decimal de tu lenguaje. Un float binario pierde centavos, y un número JSON invita a uno. Las marcas de tiempo son RFC 3339 en UTC.
### Los errores responden problem+json
La mayoría de los errores de operación y fallback responden `application/problem+json`; no lo supongas para respuestas 401/403 de lib-auth. Ramifica por `status` y tipo de contenido. Un `422` de validación de schema puede incluir un arreglo `errors`, mientras que la validación del handler o del dominio puede devolver solo `detail` de nivel superior.
Trata `detail` como texto para una persona, no como una clave contra la que tu código compara. Una falla del lado del servidor responde con un detalle genérico a propósito, así que ninguna causa interna llega a un cliente. Registra el status y tu propio identificador de correlación, y deja que las trazas de Lender lleven el resto.
### Reintenta las escrituras de dinero con tu propia clave
Desembolso, cargos de producto, prepago, prepago bajo el paquete Brasil, reprogramación, pago y reversión aceptan cada uno una clave de idempotencia que tú generas. Derívala de tu propio identificador de request, y un reintento no cuesta nada mientras el almacenamiento de idempotencia está disponible.
Las cinco operaciones que exigen `X-Idempotency` repiten una llamada completada con `X-Idempotency-Replayed: true` en la respuesta. Responden `409` mientras la primera llamada sigue en vuelo. El pago y la reversión se apoyan en `X-Request-ID`, y caen de vuelta a `X-Idempotency` cuando ese falta: un reintento con los mismos datos repite, y el mismo id con datos distintos responde `409`. Así que ramifica sobre el cuerpo de la respuesta, nunca sobre la presencia del header de repetición. El middleware falla abierto durante una indisponibilidad del almacenamiento de idempotencia, así que una falla ambigua puede haber ejecutado la operación; confirma el resultado antes de reintentar una escritura de dinero en esa ventana.
[API REST de Lender](/es/lender/lender-rest-api#idempotencia) lista qué encabezado toma cada una de esas operaciones, y cuánto vive una clave.
### Pagina con filtros, no con offsets profundos
La paginación es por operación. Las lecturas de lista de productos toman `limit` y `offset`. El historial de auditoría toma solo `limit`. Un valor fuera del rango declarado responde `422` en lugar de una página reducida en silencio. Lee la página de referencia de la operación que llamas, y acota la consulta en vez de recorrer un offset largo.
## Guarda los identificadores que devuelven tus escrituras
***
Las operaciones de originación son comandos: crear, aprobar, rechazar, retirar y desembolsar. Cada una responde con el cuerpo completo de la solicitud. Su `id` identifica la solicitud de préstamo; después del desembolso, `disbursementEvent.loanAccountId` identifica la cuenta de préstamo.
Guarda los dos de tu lado a medida que avanzas. Tu propio registro entonces vincula a tu prestatario con la cuenta de préstamo. Cada lectura de servicing parte de un identificador que ya tienes, porque el cronograma, las transacciones, los cargos y el historial de auditoría se indexan por la cuenta de préstamo.
## Integrar Lender detrás de tu propio producto
***
Lender es un servicio que despliegas, no una biblioteca que enlazas. Para ponerlo detrás de una aplicación que tus clientes ya usan, guarda las credenciales de tu lado y llama a Lender de servidor a servidor. Cuatro reglas mantienen limpio ese límite.
**Nunca entregues un token de Lender a un navegador ni a una app móvil**. Tu servicio autentica a tu usuario y decide si ese usuario puede actuar. Después llama a Lender con un token propio.
**Emite el token para la persona que actúa**. Lender deriva el actor HTTP del subject del token, nunca de un campo del request. En el flujo humano genérico, el oficial asignado aprueba y rechaza; el prestatario o el oficial asignado pueden retirar. La política de actor de la jurisdicción fijada gobierna aprobación y desembolso, así que no supongas que un mismo subject humano hace cada transición.
**Mantén una credencial por tenant**. En modo single-tenant Lender usa `DEFAULT_TENANT_ID`. En modo multi-tenant el tenant viene de la identidad validada, nunca de un encabezado, un parámetro de consulta o un campo del cuerpo: cada token lleva un claim `tenantId`, así que tu servicio guarda una credencial por cada tenant al que sirve. Lee [Multi-tenancy](/es/multi-tenancy).
**Entérate de los cambios de estado por eventos**. Cuando el streaming está habilitado y hay un broker configurado, Lender publica eventos de negocio mediante su outbox. Cuando el streaming está deshabilitado, usa un emisor no-op; cuando el streaming está habilitado sin un broker configurado, Lender se niega a arrancar en lugar de recurrir al emisor no-op. Habilita y configura streaming antes de tratar la entrega de eventos como contrato de integración. Lee [Eventos de Lender](/es/lender/lender-events).
Un desembolso registra su intención de asiento en la misma transacción de base de datos que mueve la solicitud a `disbursed`. Lender la transmite a Midaz solo cuando el relay del ledger está configurado; de lo contrario, la intención queda en el outbox. No trates un `200` en el desembolso como prueba de que el ledger ya lleva el asiento. Lee [Contabilidad y ejecuciones de devengo](/es/lender/accounting-and-accrual-runs).
## Próximos pasos
***
La ruta base, la autenticación, la idempotencia y las operaciones por trabajo.
El contrato del wire y los eventos a los que puedes suscribirte.
Seis llamadas desde una base de datos vacía hasta un préstamo desembolsado.
Los servicios, las migraciones y la configuración que necesita una primera llamada.