application/json. Envía cada campo de dinero y de tasa como una cadena decimal, nunca como un número JSON.
Completa primero los Requisitos previos. Envía el mismo Bearer token en las seis llamadas. Lender toma al oficial del sujeto del token. Bajo el perfil genérico, solo ese oficial puede aprobar y desembolsar la solicitud.
Usa la jurisdicción
XX para este recorrido. XX es el perfil genérico de Lender, y no calcula retenciones, lo que mantiene simples los montos del paso 6. Un préstamo brasileño regulado lleva divulgación de CET y consentimiento de capitalización. Lee el Paquete regulatorio de Brasil para ese camino. Un contrato con descuento en nómina pertenece al contexto delimitado de consignado privado. Lee Consignado privado para su vocabulario y sus temas de ciclo de vida.Las seis llamadas
1. Crear el producto
POST /api/v1/loan-products
loanType toma personal, commercial o card. jurisdictionCode toma un código que lleva el registro: XX o BR. Cualquier otro código devuelve 422.
La respuesta lleva el nuevo id. El producto está en draft, que es todo lo que necesita este recorrido: una solicitud se vincula a una versión, así que no activas el producto para originar.
2. Crear una versión
POST /api/v1/loan-products/{productId}/versions
currencyno tiene valor predeterminado. Aporta un código ISO-4217 válido en mayúsculas. La versión es la fuente de verdad de la moneda desde aquí hasta el ledger.- Una versión fija no lleva vínculo flotante. Con
rateMode: fixed, omitefloatingRateTableId,floatingSpreadBpsyrequiresFloatingRate. Lender rechaza una versión fija que lleve alguno de ellos. jurisdictionCodees obligatorio, y debe coincidir con el del producto. Una versión no puede mover un producto a otra jurisdicción.
versionId.
3. Vincular un perfil contable
POST /api/v1/loan-products/{productId}/accounting-profiles
El perfil mapea cada evento contable a cuentas contables generales. Lender lo necesita en el desembolso, así que vincúlalo ahora.
disbursement, repayment, prepayment, accrual, collection_unapplied, collection_reapply y collection_refund. accrual_tax es la octava opcional. Menos de siete reglas se rechaza antes de que corra el handler.
Cada pata declara exactamente uno de role o component, y ninguna cuenta aparece en ambos lados de la misma regla. Cuatro eventos también llevan una forma de pata fija:
collection_reapply toma unapplied_cash como su único débito. Cada crédito que lleva debe aparecer también como crédito en repayment o prepayment, con la misma cuenta y el mismo rol. disbursement y repayment necesitan cada uno al menos un débito y un crédito.
Mantén la regla disbursement en dos patas, como arriba. Lender llena la pata cash con el monto neto y cada otra pata estructural con el monto bruto. Una pata component toma una retención calculada, y el perfil genérico no calcula ninguna, así que la regla de dos patas es la que balancea bajo XX.
En modo multi-tenant el perfil también necesita midazOrganizationId y midazLedgerId. Lee Definir un producto de préstamo para la superficie de producto más amplia.
4. Crear la solicitud
POST /api/v1/loan-applications
requestedInterestRatees la tasa mensual como cadena decimal a escala 8. Debe ser mayor que0y no mayor que1. Lender construye el cronograma a partir de esta tasa:"0.01500000"al mes es1800bps al año.requestedInstallmentsestá entre 1 y 600.previewScheduleSnapshotIdes un UUID que generas tú para identificar la cotización que le mostraste al prestatario. Lender lo registra en la solicitud. Calcula el cronograma que muestras conPOST /api/v1/loan-applications/preview-schedule. Esa llamada no persiste nada y no devuelve ningún identificador. Acuña el identificador de tu lado y consérvalo con tu propio registro de cotización.- No hay campo
assignedOfficerId. Lender lo define desde el sujeto del token.
pending_approval, con el código de jurisdicción y la versión de perfil que Lender resolvió desde la versión de producto.
5. Aprobar
POST /api/v1/loan-applications/{id}/approve
approvedAmount se vuelve el techo de todo lo que desembolsas. Bajo XX, solo el oficial que creó la solicitud puede aprobarla. La solicitud pasa a approved y lleva el registro de decisión.
6. Desembolsar
POST /api/v1/loan-applications/{id}/disburse
Envía el header X-Idempotency. Lender lo requiere. Un reintento con el mismo valor repite la primera respuesta, y no registra un segundo desembolso.
loanAccountId es un UUID que aportas tú. Lender no lo acuña. Identifica la cuenta de préstamo bajo la que se administra este contrato, y es inmutable a lo largo de tramos posteriores de la misma solicitud.
Lender también verifica que:
netDeliveredAmountno excedagrossRequestedAmount.grossRequestedAmount, y el total acumulado de todos los tramos, no excedaapprovedAmount.disbursedAtno sea anterior a la decisión de aprobación.- La jurisdicción y la versión de perfil todavía coincidan con el par que Lender resolvió en el paso 4.
originationFeeAmount es opcional. Lleva metadatos de costo que lee el devengo. Lender no lo trata como una retención, así que no cambia la relación entre neto y bruto.
Confirmar que el préstamo existe
La respuesta del desembolso lleva la solicitud en
disbursed con su evento de desembolso. Luego lee la cuenta de préstamo:
La respuesta también lleva
profileVersion, la versión del perfil de jurisdicción, no una versión de producto. No lleva moneda. El préstamo usa el currency que definiste en la versión de producto de préstamo en el paso 2. Conserva ese valor con tu propio registro de producto.
Si configuraste Midaz, el asiento de desembolso llega al ledger una vez que el despachador del outbox transmite la intención. Eso pasa poco después de la llamada, no dentro de ella.
Próximos pasos
Administrar un préstamo
Registra pagos, anticipa, reprograma y corrige una cuenta de préstamo viva.
Cómo funciona el devengo
El reconocimiento de intereses corre con su propia programación. Inicia una ejecución de devengo, o habilita el heartbeat.

