application/json. Envie cada campo de dinheiro e de taxa como string decimal, nunca como número JSON.
Faça primeiro os Pré-requisitos. Envie o mesmo token bearer nas seis chamadas. O Lender pega o analista do subject do token. Sob o perfil genérico, apenas esse analista pode aprovar e desembolsar a proposta.
Use a jurisdição
XX neste passo a passo. XX é o perfil genérico do Lender e não calcula retenções, o que mantém simples os valores do passo 6. Um empréstimo brasileiro regulado carrega divulgação do CET e consentimento de capitalização. Leia o Pacote regulatório Brasil para esse caminho. Um contrato com desconto em folha pertence ao contexto delimitado do consignado privado. Leia Consignado privado para o vocabulário e os tópicos de ciclo de vida dele.As seis chamadas
1. Crie o produto
POST /api/v1/loan-products
loanType aceita personal, commercial ou card. jurisdictionCode aceita um código que o registro carrega: XX ou BR. Qualquer outro código retorna 422.
A resposta carrega o novo id. O produto fica em draft, que é tudo o que este passo a passo precisa: uma proposta se prende a uma versão, então você não ativa o produto para originar.
2. Crie uma versão
POST /api/v1/loan-products/{productId}/versions
currencynão tem padrão. Forneça um código ISO-4217 válido em maiúsculas. A versão é a fonte da verdade da moeda daqui até o ledger.- Uma versão fixa não carrega vínculo flutuante. Com
rateMode: fixed, omitafloatingRateTableId,floatingSpreadBpserequiresFloatingRate. O Lender rejeita uma versão fixa que carregue qualquer um deles. jurisdictionCodeé obrigatório, e deve bater com o do produto. Uma versão não pode mover um produto para outra jurisdição.
versionId.
3. Prenda um perfil contábil
POST /api/v1/loan-products/{productId}/accounting-profiles
O perfil mapeia cada evento contábil em contas contábeis. O Lender precisa do perfil no desembolso, então prenda o perfil agora.
disbursement, repayment, prepayment, accrual, collection_unapplied, collection_reapply e collection_refund. accrual_tax é a oitava, opcional. Menos de sete regras é rejeitado antes de o handler rodar.
Cada perna declara exatamente um entre role e component, e nenhuma conta aparece nos dois lados da mesma regra. Quatro eventos também carregam um formato fixo de pernas:
collection_reapply aceita unapplied_cash como único débito. Cada crédito que ela carrega deve aparecer também como crédito em repayment ou prepayment, com a mesma conta e o mesmo papel. disbursement e repayment precisam, cada um, de pelo menos um débito e um crédito.
Mantenha a regra disbursement com duas pernas, como acima. O Lender preenche a perna cash com o valor líquido e cada outra perna estrutural com o valor bruto. Uma perna component recebe uma retenção calculada, e o perfil genérico não calcula nenhuma, então a regra de duas pernas é a que balanceia sob XX.
No modo multi-tenant o perfil também precisa de midazOrganizationId e midazLedgerId. Leia Defina um produto de empréstimo para a superfície mais ampla do produto.
4. Crie a proposta
POST /api/v1/loan-applications
requestedInterestRateé a taxa mensal como string decimal na escala 8. Ela deve ser maior que0e não maior que1. O Lender monta o cronograma a partir dessa taxa:"0.01500000"ao mês é1800bps ao ano.requestedInstallmentsfica entre 1 e 600.previewScheduleSnapshotIdé um UUID que você gera para identificar a cotação que você mostrou ao tomador. O Lender registra esse UUID na proposta. Calcule o cronograma que você mostra comPOST /api/v1/loan-applications/preview-schedule. Essa chamada não persiste nada e não retorna identificador. Gere o identificador do seu lado e guarde junto com o seu próprio registro de cotação.- Não existe campo
assignedOfficerId. O Lender define esse dado a partir do subject do token.
pending_approval, carregando o código de jurisdição e a versão de perfil que o Lender resolveu a partir da versão do produto.
5. Aprove
POST /api/v1/loan-applications/{id}/approve
approvedAmount vira o teto de tudo o que você desembolsa. Sob XX, apenas o analista que criou a proposta pode aprová-la. A proposta passa para approved e carrega o registro da decisão.
6. Desembolse
POST /api/v1/loan-applications/{id}/disburse
Envie o header X-Idempotency. O Lender exige esse header. Uma nova tentativa com o mesmo valor repete a primeira resposta, e não registra um segundo desembolso.
loanAccountId é um UUID que você fornece. O Lender não gera esse UUID. Ele identifica a conta de empréstimo sob a qual este contrato é gerido, e é imutável nas tranches posteriores da mesma proposta.
O Lender também confere que:
netDeliveredAmountnão excedegrossRequestedAmount.grossRequestedAmount, e o total corrente entre as tranches, não excedeapprovedAmount.disbursedAtnão é anterior à decisão de aprovação.- A jurisdição e a versão de perfil ainda batem com o par que o Lender resolveu no passo 4.
originationFeeAmount é opcional. Ele carrega metadados de custo que a apropriação lê. O Lender não trata esse campo como retenção, então ele não muda a relação entre líquido e bruto.
Confirme que o empréstimo existe
A resposta do desembolso carrega a proposta em
disbursed com o evento de desembolso dela. Depois, leia a conta de empréstimo:
A resposta também carrega
profileVersion, a versão do perfil de jurisdição, não uma versão de produto. Ela não carrega moeda. O empréstimo usa a currency que você definiu na versão do produto de empréstimo no passo 2. Guarde esse valor junto com o seu próprio registro de produto.
Se você configurou o Midaz, o lançamento de desembolso chega ao ledger assim que o dispatcher do outbox repassa a intenção. Isso acontece logo depois da chamada, não dentro dela.
Próximos passos
Faça a gestão de um empréstimo
Registre pagamentos, antecipe, reprograme e corrija uma conta de empréstimo viva.
Como funciona a apropriação
O reconhecimento de juros roda no agendamento próprio. Comece uma rodada de apropriação, ou habilite o heartbeat.

