> ## 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. # Origine um empréstimo > Leve uma proposta de empréstimo pelo ciclo de vida dela (ver a prévia do cronograma, enviar, decidir e desembolsar) e veja a conta de empréstimo que ela produz. A originação é a jornada de "um tomador quer crédito" até "existe uma conta de empréstimo e o desembolso está registrado". O Lender modela essa jornada como um ciclo de vida explícito de proposta. O ciclo de vida guarda um registro de cada decisão, e torna cada desembolso rastreável. ## O ciclo de vida da proposta *** Uma proposta passa por estados nomeados. Cada transição é uma operação distinta, e cada uma guarda um registro de decisão ou de desembolso: ``` submit ─────► pending_approval ── approve ──► approved ── disburse ──► loan account │ │ │ reject withdraw withdraw ``` ## Passos *** **1. Veja a prévia do cronograma (opcional)** `POST /api/v1/loan-applications/preview-schedule` calcula o cronograma de amortização para termos em estudo **sem originar nada**. Quando registra a cotação como oferta, ele retorna o `scheduleOfferSnapshotId` da oferta, que a proposta pode citar. Use para mostrar parcelas e divulgações antes de alguém se comprometer. **2. Envie a proposta** `POST /api/v1/loan-applications` cria a proposta contra a versão atual do produto. Ela traz o CPF ou o CNPJ e o nome do tomador, não um id de tomador. O documento define o tipo do tomador, e o Lender busca ou registra o tomador como titular no CRM do Midaz. A taxa solicitada deve ficar dentro da faixa de taxa da versão. Informe exatamente um entre o principal, o líquido que o tomador recebe ou a parcela que cabe, e opcionalmente a primeira data de vencimento. **3. Decida** Resolva a proposta com exatamente uma destas opções: * `POST /api/v1/loan-applications/{id}/approve`: aceite a proposta, com um registro de decisão. * `POST /api/v1/loan-applications/{id}/reject`: recuse a proposta, com um registro de decisão. * `POST /api/v1/loan-applications/{id}/withdraw`: retire a proposta enquanto ela aguarda aprovação ou, depois da aprovação, antes do desembolso. **4. Desembolse** `POST /api/v1/loan-applications/{id}/disburse` registra os fundos entregues. Ele recebe a chave `X-Idempotency` que toda escrita desta página recebe. Uma repetição com a mesma chave, portanto, repete a primeira resposta e não registra um segundo desembolso. Uma transação de banco de dados faz commit do evento de desembolso, do cronograma de originação e de uma intenção de lançamento balanceada. Quando a chamada retorna, o empréstimo é uma **conta de empréstimo** ativa que você passa a gerir daqui em diante. O lançamento no ledger não está nessa transação. Um despachante do outbox repassa a intenção ao Midaz logo após a resposta, pelo perfil contábil do produto. Veja [o caminho de lançamento](https://docs.lerian.studio/pt/products/lender/lender-in-the-platform.md). ## Toda escrita recebe uma chave de idempotência *** Criar uma proposta e movê-la (aprovar, recusar, desistir, desembolsar) exigem todas o cabeçalho `X-Idempotency`. O Lender lê a chave nessa grafia e em nenhuma outra. Ele recusa `Idempotency-Key` e `X-Idempotency-Key` pelo nome, para que um cliente nunca fique desprotegido em silêncio por ter adivinhado o cabeçalho. Enviar uma dessas junto com o cabeçalho do contrato não é problema. A recusa só dispara quando `X-Idempotency` está ausente. | O que você envia | O que você recebe | | - | - | | Nenhuma chave | `400`, e nada roda. | | A mesma chave, o mesmo corpo | A primeira resposta, repetida. Nada roda uma segunda vez. | | A mesma chave, um corpo diferente | `422`. A chave já está gasta em outra instrução. | A guarda falha **fechada**. Quando o armazenamento de idempotência não consegue responder, o Lender recusa o pedido com `503` em vez de deixá-lo passar adiante desprotegido. Criar custa uma chave de propósito: sem ela, um cliente que estoura o tempo na criação e chama de novo cria uma segunda proposta para o mesmo tomador. É a duplicata mais barata de produzir no serviço e a mais cara de desfazer. Ela é cara porque as duas cópias parecem legítimas e só uma pessoa sabe dizer qual é a verdadeira. > [!NOTE] > > Nas quatro escritas de ciclo de vida, você pode conciliar um pedido que termina sem resolução e reenviá-lo sob uma chave **nova**. Leia a proposta por id e pergunte se ela já está no estado que você queria. O desembolso é a exceção, onde uma chave nova não é uma recuperação segura de jeito nenhum. Uma segunda liberação legítima declara a tranche dela. ## O produto precisa estar ativo *** A originação lê o status de ativação do produto de empréstimo e recusa um produto que não está ativo, com `LENDER-0225` e um `422`. A recusa fica nos três passos que decidem crédito novo: criar a proposta, aprovar e liberar o dinheiro pela API. Um produto desligado depois de a proposta ter sido registrada, portanto, segura essa proposta antes de o dinheiro sair. Criar uma proposta também precisa nomear a versão **corrente** do produto, ou o Lender a recusa com `LENDER-0226` e um `422`. Essa checagem roda na criação e em lugar nenhum mais, porque uma proposta fica a vida inteira na versão em que nasceu. Promover uma versão nova nunca mata, portanto, as propostas paradas na anterior, e cada uma delas contabiliza na versão que nomeou. Veja [Defina um produto de empréstimo](https://docs.lerian.studio/pt/products/lender/define-a-loan-product.md). Dois caminhos ficam fora deste portão de propósito: * A esteira do **consignado**, que registra um contrato que os sistemas do próprio cliente já averbaram na folha. Recusar um fato que já aconteceu deixaria o livro negando um contrato que o tomador tem na mão. * Uma **renegociação substancial**, cujo contrato de substituição herda a versão de produto do contrato que ele substitui. O contrato de substituição herda essa versão esteja esse produto ativo ou não e seja essa versão a corrente ou não. Renegociar é servicing de crédito já escrito. Só uma proposta nova é crédito novo. O Lender não cerca nada depois da originação. Recusa, desistência, servicing e contabilidade seguem funcionando contra um produto aposentado anos depois. ## O que você recebe *** O desembolso produz uma **conta de empréstimo**, a visão de gestão do contrato vivo, carregando o cronograma, as transações, os encargos e o histórico de auditoria dela. Continue em [Faça a gestão de um empréstimo](https://docs.lerian.studio/pt/products/lender/service-a-loan.md). ## O que acontece downstream *** O ciclo de vida emite `loan_application.submitted`, `loan_application.approved`, `loan_application.rejected`, `loan_application.withdrawn` e `loan_application.disbursed`, cada um na versão de schema `2.0.0`. O desembolso registra uma intenção de lançamento durável e a repassa ao ledger. Leia [o caminho de lançamento](https://docs.lerian.studio/pt/products/lender/lender-in-the-platform.md). > [!NOTE] > > A originação brasileira adiciona passos regulados (divulgação do CET e consentimento de capitalização) cobertos no [Pacote regulatório Brasil](https://docs.lerian.studio/pt/products/lender/brazil-regulatory-pack.md). O fluxo de **consignado** com desconto em folha forma um contexto delimitado brasileiro próprio. Veja [Consignado privado](https://docs.lerian.studio/pt/products/lender/consignado-privado.md). ## Próximos passos *** > [card] [Faça a gestão de um empréstimo](https://docs.lerian.studio/pt/products/lender/service-a-loan.md) > > Registre pagamentos, antecipe, reprograme e corrija uma conta de empréstimo ativa. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.