Skip to main content
An application is your report of a final underwriting decision for a credit or lending product. When your underwriting reaches an outcome of approved, declined, or canceled, you submit it to Lead with the Applications API. Lead uses it to meet Regulation B (Reg B) and fair lending obligations. An approved application’s application_id is required to open a user account with the credit_with_underwriting feature. The decision happens in your system, and the application record is how you communicate that decision to Lead. See Executing vs. Reporting. Products without an underwriting decision, like courtesy overdraft, do not need an application. Most credit and lending products do.
The Applications 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 applications fit in onboarding

  1. Entity API. Create an entity for each applicant, authorized signer, and authorized user. Successful creates return an entity_id.
  2. Applications API. Report the final decision, referencing those entity IDs. Successful creates return an application_id.
  3. User Accounts API. For an approved application, create the user account with the credit_with_underwriting feature, referencing the application_id.

​
Report every outcome

You submit an application only once you know the outcome, so every application is created in a final status: approved, declined, or canceled. There is no in-progress status. Report all three outcomes. Lead needs declined and canceled applications in order to monitor for fair lending compliance even though no user account is opened for them. See Application Statuses.

​
Entities on an application

Every entity must exist before you reference it on the application. Create entities with the Entity API, then use their entity_id values in entities.account_holders, entities.authorized_signers, and entities.authorized_users. Lead accepts authorized_users on create but does not return them on the application. List them with GET /v2/applications/{id}/entity_relationships. Lead derives entities.account_holder_type from the account holders: consumer when they are individuals, and commercial when they are businesses or sole proprietorships. Every account holder must be in the same category. Business and sole proprietorship entities can be combined, but an individual cannot be combined with either. An approved commercial application needs at least one authorized signer.

​
How applications relate to the rest of the model

  • Entities. Every applicant, authorized signer, and authorized user on an application is an entity. On an approved application, each must be eligible for the relationship type you give it. See Entity Eligibility.
  • User accounts. A user account with the credit_with_underwriting feature references an approved application by application_id. Its account holders, authorized signers, and account_holder_type must match the application’s when you create the user account.
  • Files. Each entry in documents references a file you uploaded with the Files API.

​
What you can do

  • POST /v2/applications: Create an application in its final status.
  • GET /v2/applications/{id}: Retrieve an application.
  • GET /v2/applications?client_application_id={client_application_id}: Retrieve an application by the client_application_id you assigned in an Application file. Use this to find the id of applications you reported through files if you are moving to the API.
  • PATCH /v2/applications/{id}: Update the details, decision, documents, or metadata on an application.
  • GET /v2/applications/{id}/entity_relationships: List the account holders, authorized signers, and authorized users on an application, with their relationship type. Paginated with limit (default 25, maximum 100) and starting_after.
  • POST and PATCH require an Idempotency-Key header. A request without one returns 400 idempotency_key_missing. See Idempotency.

​
Authentication

  • application/read_write for POST and PATCH. Also grants read access.
  • application/read for the GET endpoints only. Use it when your integration only needs to read applications.

​
What you cannot do

  • Create an application before the decision. There is no in-progress status.
  • Change an application’s status. You set the status at creation. See Application Statuses.
  • Change the entities after creation. No endpoint adds or removes entities on an application.
  • Use a declined or canceled application to open a user account. Only an approved application can be referenced as application_id.
  • Subscribe to application webhooks. There are no application webhook events. Your system sets every status, so read the application with GET when you need it.

​
In this section