> ## 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.
# Originar un préstamo
> Recorre una solicitud de préstamo por su ciclo de vida (vista previa del cronograma, envío, decisión y desembolso) y conoce la cuenta de préstamo que produce.
La originación es el recorrido desde "un prestatario quiere crédito" hasta "existe una cuenta de préstamo y el desembolso quedó registrado". Lender lo modela como un ciclo de vida explícito de la solicitud. El ciclo de vida guarda un registro de cada decisión y hace que cada desembolso sea rastreable.
## El ciclo de vida de la solicitud
***
Una solicitud pasa por estados con nombre. Cada transición es una operación distinta, y cada una guarda un registro de decisión o de desembolso:
```
submit ─────► pending_approval ── approve ──► approved ── disburse ──► loan account
│ │ │
reject withdraw withdraw
```
## Pasos
***
`POST /api/v1/loan-applications/preview-schedule` calcula el cronograma de amortización para términos propuestos **sin originar nada**. Cuando registra la cotización como oferta, devuelve el `scheduleOfferSnapshotId` de la oferta, que la solicitud puede citar. Úsalo para mostrar cuotas y divulgaciones antes de que alguien se comprometa.
`POST /api/v1/loan-applications` crea la solicitud contra la versión actual del producto. Declara el tipo de prestatario, y la tasa solicitada debe caer dentro de la banda de tasa de la versión.
Resuelve la solicitud con exactamente una de las siguientes:
* `POST /api/v1/loan-applications/{id}/approve`: acéptala, con un registro de decisión.
* `POST /api/v1/loan-applications/{id}/reject`: recházala, con un registro de decisión.
* `POST /api/v1/loan-applications/{id}/withdraw`: retírala mientras está pendiente de aprobación o, después de la aprobación, antes del desembolso.
`POST /api/v1/loan-applications/{id}/disburse` registra los fondos entregados. Toma la clave `X-Idempotency` que toma toda escritura de esta página. Por eso, un reintento con la misma clave repite la primera respuesta y no registra un segundo desembolso.
Una sola transacción de base de datos confirma el evento de desembolso, el cronograma de originación y una intención de asiento balanceada. Cuando la llamada retorna, el préstamo es una **cuenta de préstamo** activa que administras de aquí en adelante.
La contabilización en el ledger no está dentro de esa transacción. Con el relay del ledger configurado, un despachador del outbox transmite la intención a Midaz poco después de la respuesta, a través del perfil contable del producto. De lo contrario, la intención permanece en el outbox. Consulta [la ruta de asiento](/es/products/lender/lender-in-the-platform).
## Toda escritura toma una clave de idempotencia
***
Crear una solicitud y moverla (aprobar, rechazar, desistir, desembolsar) exigen todas el encabezado `X-Idempotency`. Lender lee la clave con esa grafía y con ninguna otra. Rechaza `Idempotency-Key` y `X-Idempotency-Key` por nombre, para que un cliente nunca quede desprotegido en silencio por haber adivinado el encabezado. Enviar una de esas junto con el encabezado del contrato no es problema. El rechazo solo se dispara cuando `X-Idempotency` está ausente.
| Lo que envías | Lo que obtienes |
| - | - |
| Ninguna clave | `400`, y nada corre. |
| La misma clave, el mismo cuerpo | La primera respuesta, repetida. Nada corre una segunda vez. |
| La misma clave, un cuerpo distinto | `422`. La clave ya está gastada en otra instrucción. |
La guarda falla **cerrada**. Cuando el almacén de idempotencia no puede responder, Lender rechaza el pedido con `503` en vez de dejarlo pasar sin protección.
Crear cuesta una clave a propósito: sin ella, un cliente que agota el tiempo al crear y llama de nuevo abre una segunda solicitud para el mismo prestatario. Es el duplicado más barato de producir en el servicio y el más caro de deshacer. Es caro porque las dos copias se ven legítimas y solo una persona sabe decir cuál es la verdadera.
En las cuatro escrituras de ciclo de vida, puedes conciliar un pedido que termina sin resolverse y reenviarlo bajo una clave **nueva**. Lee la solicitud por id y pregunta si ya sostiene el estado que querías. El desembolso es la excepción, donde una clave nueva no es una recuperación segura en absoluto. Una segunda liberación legítima declara su tramo.
## El producto tiene que estar activo
***
La originación lee el estado de activación del producto de préstamo y rechaza un producto que no está activo, con `LENDER-0225` y un `422`. El rechazo se ubica en los tres pasos que deciden crédito nuevo: crear la solicitud, aprobarla y liberar el dinero por la API. Por eso, un producto apagado después de presentada la solicitud la detiene antes de que salga el dinero.
Crear una solicitud también tiene que nombrar la versión **vigente** del producto, o Lender la rechaza con `LENDER-0226` y un `422`. Esa comprobación corre en la creación y en ningún otro lado, porque una solicitud se queda de por vida en la versión en que nació. Promover una versión nueva nunca mata entonces las solicitudes detenidas en la anterior, y cada una sigue contabilizando en la versión que nombró. Mira [Definir un producto de préstamo](/es/products/lender/define-a-loan-product).
Dos caminos quedan fuera de esta puerta a propósito:
* El carril del **consignado**, que registra un contrato que los sistemas del propio cliente ya inscribieron en la nómina. Rechazar un hecho que ya ocurrió dejaría al libro negando un contrato que el prestatario tiene en la mano.
* Una **renegociación sustancial**, cuyo contrato de reemplazo hereda la versión de producto del contrato al que reemplaza. El contrato de reemplazo hereda esa versión esté ese producto activo o no y sea esa versión la vigente o no. Renegociar es servicing de crédito ya escrito. Solo una solicitud nueva es crédito nuevo.
Lender no cerca nada posterior a la originación. Rechazo, desistimiento, servicing y contabilidad siguen funcionando contra un producto retirado años después.
## Lo que obtienes
***
El desembolso produce una **cuenta de préstamo**, la vista de administración del contrato vivo, que lleva su cronograma, sus transacciones, sus cargos y su historial de auditoría. Continúa en [Administrar un préstamo](/es/products/lender/service-a-loan).
## Lo que ocurre downstream
***
El ciclo de vida emite `loan_application.submitted`, `loan_application.approved`, `loan_application.rejected`, `loan_application.withdrawn` y `loan_application.disbursed`, cada uno en la versión de esquema `2.0.0`. El desembolso registra una intención de asiento durable y la transmite al ledger solo cuando configuras el relay del ledger. Consulta [la ruta de asiento](/es/products/lender/lender-in-the-platform).
La originación brasileña agrega pasos regulados (divulgación de CET y consentimiento de capitalización) que cubre el [Paquete regulatorio de Brasil](/es/products/lender/brazil-regulatory-pack). El flujo de **consignado** con descuento en nómina forma su propio contexto delimitado brasileño. Consulta [Consignado privado](/es/products/lender/consignado-privado).
## Próximos pasos
***
Registra pagos, anticipa, reprograma y corrige una cuenta de préstamo activa.