Skip to main content
La API REST de Lender es toda la superficie de cliente. Los productos, las solicitudes, las cuentas de préstamo, las ejecuciones de devengo y los registros regulatorios brasileños son todos llamadas HTTP bajo /api/v1. Nada existe solo dentro de una biblioteca de cliente. Llama a Lender con el cliente HTTP que ya tiene tu stack. No hay una biblioteca de cliente de Lender para 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 conservas de tu lado. Luego cubre cómo colocar Lender detrás de un producto con el que tus usuarios ya hablan. Lee API REST de Lender para las operaciones en sí.
Los documentos OpenAPI de este portal son fuentes de render para las páginas de referencia. No son contratos de cliente, y no son base para la generación de clientes ni de SDK.

​
Lo que tu cliente debe manejar

Cuatro reglas cubren la mayor parte del código que escribes contra Lender.

​
El dinero viaja como cadena decimal

Los montos de dinero son cadenas decimales JSON, normalmente con dos decimales. Las tasas decimales como requestedInterestRate son cadenas con ocho decimales. Los campos fixedAnnualRateBps, floatingSpreadBps y annualRateBps son puntos base enteros:
Envía la cadena, y parsea la cadena 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 de respaldo responden application/problem+json. No supongas eso para las respuestas 401/403 de lib-auth. Ramifica por status y tipo de contenido. Un 422 de validación de esquema puede incluir un arreglo errors con detalles de campo, 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 hace coincidencias. Una falla del lado del servidor responde con un detalle genérico a propósito, así ninguna causa interna llega a un cliente. Registra el estado 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

El desembolso, los cargos de producto, el pago anticipado, el pago anticipado del paquete de Brasil, la reprogramación, el pago y la reversión aceptan cada uno una clave de idempotencia que generas tú. Derívala de tu propio identificador de solicitud, y un reintento no cuesta nada mientras el almacén de idempotencia está disponible. Las cinco operaciones que requieren 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 basan en X-Request-ID, y recurren a X-Idempotency cuando no está. Un reintento con los mismos hechos repite. El mismo id con hechos distintos responde 409. Así que ramifica por el body de la respuesta, nunca por la presencia del header de repetición. El middleware falla en modo abierto durante una caída del almacén de idempotencia. Una falla ambigua puede haber ejecutado ya la operación. Confirma el resultado antes de reintentar una escritura de dinero en esa ventana. API REST de Lender lista qué header 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 limit solo. 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 lugar de recorrer un offset largo.

​
Conserva los identificadores que devuelven tus escrituras

Las operaciones de originación son comandos: crear, aprobar, rechazar, retirar y desembolsar. Cada una responde con el body 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 ambos de tu lado a medida que avanzas. Tu propio registro entonces vincula a tu prestatario con la cuenta de préstamo. Cada lectura de administración parte de un identificador que ya tienes. El cronograma, las transacciones, los cargos y el historial de auditoría se basan todos en la cuenta de préstamo.

​
Incrustar 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, conserva 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. Luego llama a Lender con un token propio. Acuña el token para la persona que actúa. Lender deriva el actor HTTP del sujeto del token, nunca de un campo de la solicitud. En el flujo humano genérico, el oficial asignado aprueba y rechaza. El prestatario o el oficial asignado pueden retirar. La política de actores de la jurisdicción fijada rige la aprobación y el desembolso, así que no supongas que un solo sujeto 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 header, un parámetro de query ni un campo del body. Cada token lleva un claim tenantId, así que tu servicio mantiene una credencial por cada tenant al que sirve. Lee Multi-tenancy. Entérate de los cambios de estado por los eventos. Cuando el streaming está habilitado y hay un broker configurado, Lender publica eventos de negocio a través de su outbox. Cuando el streaming está deshabilitado, usa un emisor no-op. Cuando el streaming está habilitado sin broker configurado, Lender se niega a arrancar en lugar de recurrir al emisor no-op. Habilita y configura el streaming antes de tratar la entrega de eventos como un contrato de integración. Lee Eventos de Lender.
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 permanece 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.

​
Próximos pasos

API REST de Lender

La ruta base, la autenticación, la idempotencia y las operaciones por trabajo.

Eventos de Lender

El contrato de cable y los eventos a los que puedes suscribirte.

Inicio rápido

Seis llamadas desde una base de datos vacía hasta un préstamo desembolsado.

Requisitos previos

Los servicios, las migraciones y la configuración que necesita una primera llamada.