Skip to main content

​
Introduction

The Applications API must be used for any underwritten lending or credit product built on Lead. When your underwriting process reaches a final outcome — approved, declined, or canceled — you submit that decision here. Lead uses this data to satisfy Reg B and fair lending obligations, and the resulting application_id is required to create Accounts for underwritten credit products downstream. This is a reporting API (Executing vs. Reporting): the underwriting decision happens in your system; the Application is your report of it.
Certain credit-like products that do not have an underwriting process and decision (e.g., courtesy overdraft) do not need to have an Application object created. The vast majority of credit or lending products do need to have an Application object created via this API.
The API sits between the Entity API and the Accounts API in the onboarding sequence:
1

Entity API

Create entity records for each applicant. Lead validates KYC/KYB data at this step.
2

Applications API

Submit the underwriting outcome, referencing the entity IDs from step 1. An approved application returns an application_id.
3

Accounts API

Create the account for the credit or lending product, referencing the application_id from step 2.
Applications are always submitted in a terminal state — there is no in-progress state. Every POST /v0/applications request represents a final underwriting decision, and all three outcomes must be reported: declined and canceled applications are required for fair lending compliance even though no account is created for them.

​
Authentication

The Applications API uses two OAuth scopes (authentication):
  • application/read_write — required for POST and PATCH requests.
  • application/read — sufficient for GET requests.
Use the least-privileged scope appropriate to your operation.

​
Endpoints

Full request and response schemas: API Reference.

​
Key Concepts

Terminal-Only Status Model You must know the underwriting outcome before calling POST /v0/applications. If a status was reported incorrectly, correct it with PATCH /v0/applications/{id} — the corrected status is subject to the same validations as creation, so a correction to declined must also carry details.adverse_action_notice. Consumer vs. Commercial Account Holder Types The entities.account_holder_type field in the response (consumer or commercial) is derived automatically from the entity types you supply — it is not set directly. Individual entities produce consumer; business or sole proprietor entities produce commercial. All entries in account_holders must share the same category — every entry an individual, or every entry a business or sole proprietor. Mixing an individual entity with a business or sole proprietor entity is not permitted, but business and sole proprietor entities may be combined within the same application. The application response returns the entity IDs in each role on entities.account_holders and entities.authorized_signers; for the full relationship records, including authorized users set on the application, call GET /v0/applications/{id}/entity_relationships. Entity Prerequisites Entities must exist in Lead’s system before you can reference them in an application. Call the Entity API first to create entity records, then use the entity_-prefixed IDs returned from that API in the entities.account_holders, entities.authorized_signers, and entities.authorized_users arrays of your application request.

​
In This Section

The Application Object — every field, the terminal statuses, and an example payload · Validation Rules and Errors · Best Practices · Troubleshooting