/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 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:Los errores responden problem+json
Cada falla respondeapplication/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 exigenX-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 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 tomanlimit 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.
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.
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.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 del wire 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.
Prerrequisitos
Los servicios, las migraciones y la configuración que necesita una primera llamada.