Skip to main content
Lead is the lender of record, so every loan your program originates starts on Lead’s balance sheet. A receivable is Lead’s claim on that loan: the amount of Lead’s balance sheet the loan is using. How long a receivable stays on Lead’s books depends on how the loan was originated. That is set by balance_sheet_model on the user account. See The User Account Object.
  • Originate to sell (held_for_sale). The receivable waits out your program’s hold period, then joins a receivable sale that you buy. The receivable sale is what you pay for.
  • On-sheet (held_for_investment). Lead keeps the receivable on its balance sheet.
Use the Receivables API to see what you will buy and when, and to break each receivable sale down into the loans it contains. A receivable is not your customer’s loan balance. The user credit balance tracks what the borrower owes, as reported by you. The receivable tracks what Lead holds. They start from the same origination but answer different questions.
The Receivables API is currently in preview with a planned beta release in January 2027. 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.

​
Which receivables you can see

Today the API returns receivables for loans originated to sell. Each one has held_for: sale and a receivable_sale_details.request_date. Receivables for on-sheet loans are not returned yet. When they are added, they will carry held_for: investment, and their amounts can change over time as you report activity on the loan. An on-sheet receivable can also move to held_for: sale, for example when on-sheet loans are marked for sale. Build your integration to accept held_for values other than sale.

​
Where receivables come from

Lead creates every receivable. You never create one.

​
How receivables relate to the rest of the model

  • Fundings. Each posted funding produces one user_credit_balance receivable. See Funding.
  • User credit balances and transactions. A user_credit_balance receivable names the user credit balance and the user credit transaction it came from.
  • Card network settlements. A card_network_settlement receivable names the network, settlement date, and settlement reporting ID it came from.
  • Receivable sales. On its request_date, each receivable is grouped into that business day’s receivable sale. receivable_sale_details.receivable_sale_id then points to it. See Receivable Sale.

​
What you can do

Common reads:
  • What is in a receivable sale: GET /v2/receivables?receivable_sale_id={id}
  • What you will buy on a given day: GET /v2/receivables?request_date=2026-10-08
  • What you will buy over the next week: GET /v2/receivables?request_date[on_or_after]=2026-10-08&request_date[on_or_before]=2026-10-14

​
Authentication

  • receivable/read_write for the sandbox simulation endpoint. Also grants read access.
  • receivable/read for the GET endpoints. Use it when your integration only needs to read receivables.

​
What you cannot do

  • Create, change, or delete a receivable. The API is read only.
  • Choose which receivables to buy. Every receivable that reaches its request_date joins that day’s receivable sale.
  • See receivables Lead holds on its own balance sheet. When on-sheet receivables are added, they will carry held_for: investment.
  • Subscribe to receivable webhooks. Receivables do not emit events. Use the receivable sale webhooks, then list the sale’s receivables.

​
Availability

Funding programs need user credit balances to use the Receivables API. Card programs that buy their card receivables can use it with card network settlements alone.

​
In this section