Skip to main content
A funding is your instruction to Lead to disburse loan principal. You name the user credit balance the loan draws against and the account number the money goes to. Lead moves the principal from its own general ledger to that account number and records the disbursement on the user credit balance for you. A funding is an executing call: it moves money. Most of the other lending APIs are for reporting. You use them to tell Lead what happened in your ledger. A funding asks Lead to make something happen. A funding is not a payment to your customer. It moves principal into an account your program controls. You then send it on to the borrower or merchant over any payment rail, or keep it there.
The Fundings API is currently in preview with a planned beta release in December 2026. Preview APIs are not yet available in sandbox or production and can change before beta. Use these pages to plan an integration, not to build one. Once released in beta, it will be available to all partners in sandbox, and in production for select programs. Beta APIs may change without a version increment, and changes will be announced in advance. See Versioning and backwards compatibility.

​
Where a funding fits

  1. User account. Open a user account with a credit feature for the borrower. See User Account.
  2. Application. Report the results of an application for credit. Required for credit with underwriting. See Application.
  3. User credit balance. Create the user credit balance that carries the loan’s terms. Creating it does not automatically move any money. See User Credit Balance.
  4. Funding. Create a funding against that user credit balance. Lead disburses the principal to your account number.
  5. Onward payment. Pay the borrower or merchant from that account number using ACH, wires, instant payments, or an internal transfer.
  6. Servicing. Report accruals, fees, and payments as user credit transactions. See User Credit Transaction.
A non_revolving user credit balance, such as a term loan, usually has one funding. A revolving user credit balance, such as a line of credit, takes one funding per draw and can have multiple.

​
How fundings relate to the rest of the model

  • User credit balance. Every funding draws against exactly one user credit balance. On a non_revolving user credit balance, the total of all processing and posted fundings cannot exceed details.max_funding_amount.
  • Account number. The destination. The account number must be active, belong to your program, and sit on a core balance that Lead has enabled to receive fundings.
  • Core transaction. When the money moves, Lead creates a core transaction on the destination core balance. The funding’s core_transaction_id points to it.
  • User credit transaction. After the funding posts, Lead posts a funding user credit transaction on the user credit balance and sets its funding_id. Do not post your own user credit transaction for the same disbursement.
  • Receivable. The disbursed principal becomes a receivable on Lead’s books. If your program buys its loans, that receivable is grouped into a future receivable sale. See Receivable.

​
What you can do

​
Authentication

  • funding/read_write to create a funding and, in sandbox, to advance one. Also grants read access.
  • funding/read for the GET endpoint only. Use it when your integration only needs to read fundings.

​
What you cannot do

  • List fundings. There is no list endpoint. To reconcile, list the user credit transactions with a funding_id, or store each funding ID when you create it.
  • Cancel or change a funding. Once Lead accepts a funding, it moves to posted.
  • Split principal or pass fees on the funding. A v2 funding carries one amount. Report a borrower origination fee as a fee user credit transaction with fee_type borrower_origination and the funding’s ID in funding_id, which is required for that fee type. See The Funding Object.
  • Retrieve a v0 funding on the v2 endpoint, or the reverse. Each version only returns the fundings created through it.

​
In this section