> ## 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
Cada campo de dinero y de tasa viaja como string JSON, nunca como número JSON. El dinero lleva dos decimales, y una tasa lleva ocho:
```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
Cada falla responde `application/problem+json`. Ramifica según `status`. Para un `422`, lee el arreglo `errors`: cada entrada nombra el campo que falló en `location`, con un `message` y el `value` que Lender recibió. Mapea esas ubicaciones a tus propios campos de formulario y el usuario ve qué dato corregir.
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, 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.
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.
[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, y ese cuerpo lleva el `loanApplicationId` y, una vez desembolsada la solicitud, el `loanAccountId`.
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 lee el oficial asignado desde el subject del token, no desde algún campo del request. Ese subject es lo que registra el rastro de auditoría, así que un único token de servicio compartido hace que cada préstamo parezca del mismo oficial. Lender también autoriza cada transición contra el oficial al que está asignada la solicitud. El mismo subject por lo tanto lleva una solicitud desde la creación hasta el desembolso.
**Mantén una credencial por tenant**. El tenant viene de la identidad validada, nunca de un encabezado, un parámetro de consulta o un campo del cuerpo. En modo multi-tenant 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**. Lender publica un evento de negocio cada vez que un producto, una solicitud o una cuenta de préstamo cambia de estado. Suscríbete y tu servicio reacciona a medida que ocurre cada cambio, sin un bucle de polling contra las lecturas de servicing. 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`, y el asiento en el ledger llega después. 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.