> ## Documentation Index > Fetch the complete documentation index at: https://docs.lead.bank/llms.txt > Use this file to discover all available pages before exploring further. # Applications: Reporting Your Underwriting Decisions > What an application is, where it fits in onboarding, the final-outcome reporting model, and how applications relate to entities and user accounts. 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](/core-concepts/platform/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](/core-concepts/platform/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](/v2/products/applications/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](/v2/products/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](/api-reference/using-the-api/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](/v2/products/applications/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 * [The Application Object](/v2/products/applications/application-object) * [Application Statuses](/v2/products/applications/statuses) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.