> ## Documentation Index
> Fetch the complete documentation index at: https://docs.bridgelinepf.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Applications

> Every deal your agency has in progress, with one status and one list of what's left.

The API has two objects with two jobs:

* **Quote:** *a priced, indicative offer.* A frozen snapshot of what we offered, when, and under which rules. Its options, inputs and eligibility never change; a changed input means a new quote. What people do with it, such as your client's interest, is recorded on it afterwards.
* **Application:** *a deal in progress toward a signed PFA and loan.* It appears in your broker's portal pipeline. Documents, requirements, the agreement and the loan accrue on it.

You can read every application your agency owns with [`GET /v1/applications`](/api-reference/applications/list) and [`GET /v1/applications/{id}`](/api-reference/applications/retrieve), including the ones your brokers started in the Bridgeline portal and the ones that came in by email. Today your broker creates and finishes the application in the portal; accepting a quote to open one through the API is on the [roadmap](/roadmap).

Reading applications needs the `applications:read` scope. Test keys don't see applications yet.

## Status

Each application has one coarse `status`. The detail lives in [`requirements`](#requirements).

| `status` | What it means |
| - | - |
| `processing` | Your broker has started the application and we're reading its documents |
| `requires_information` | An item in `requirements.blocking` holds the finance agreement back |
| `ready_for_agreement` | Nothing holds the agreement back: your broker can send it from the portal |
| `awaiting_signature` | The finance agreement was sent and the borrower hasn't signed yet |
| `pending_activation` | The borrower signed. The loan goes live once the down payment settles and the agreement is countersigned |
| `active` | The loan is active. Final |
| `canceled` | The deal was canceled. Final |

```
processing → requires_information → ready_for_agreement → awaiting_signature → pending_activation → active
```

* Use `status` for the badge and `requirements` for the detail. During `processing`, `blocking` already lists what we know is missing. From `awaiting_signature` on, `blocking` is empty.
* If the borrower **declines** before anyone has signed, the application goes back to `ready_for_agreement` (or `requires_information`), and your broker can send a new agreement. If a signature was already on it, the application stays `requires_information` with `AGREEMENT_DECLINED`, and Bridgeline follows up.
* `active` and `canceled` are final. An `active` application can still owe items in `requirements.outstanding`, such as a policy number after signing.
* New statuses may be added. Treat one you don't recognize as "in progress".

## Requirements

`requirements` answers "what's left?" in two lists, split by when each item is owed:

```json theme={null}
"requirements": {
  "blocking": [
    {
      "code": "MISSING_POLICY_NUMBER",
      "param": "policies[pol_2o9fj1oLkchQ9qNzyigGf8].policy_number",
      "description": "This policy has no usable policy number. ...",
      "due_by": null
    }
  ],
  "outstanding": []
}
```

* **`blocking`** holds the finance agreement back, except the [shown-early](#shown-early) codes, which are listed for visibility. When nothing else is in it and the agreement hasn't gone out, the status is `ready_for_agreement`.
* **`outstanding`** is owed after signing, by `due_by`, and never holds up the agreement. For a missing policy number or document, `due_by` is 30 days after the agreement is executed (the deadline for the carrier notice), and `null` until then. `CARRIER_UNMATCHED` and `INSURED_ADDRESS_INCOMPLETE` have no deadline of their own, so their `due_by` is `null`.
* `param` says where the fix goes: a policy field (`policies[pol_…].policy_number`), `insured.address`, `signer.borrower` or `pricing`, or `null` when no single field applies.
* Branch on `code`. Codes are never renamed, and new ones may be added: show `description` for a code you don't recognize.

| `code` | List | What's needed |
| - | - | - |
| `BROKER_REVIEW_REQUIRED` | blocking | Your broker hasn't finished reviewing the policy details in the portal |
| `NO_POLICIES` | blocking, during review | The application has no policies yet |
| `AM_BEST_UNRESOLVED` | blocking, during review | We don't have the carrier's AM Best rating yet |
| `CARRIER_NOT_ELIGIBLE` | blocking, during review | The carrier is rated below what we can finance |
| `MINIMUM_EARNED_UNCONFIRMED` | blocking, during review | The policy's minimum earned premium hasn't been confirmed |
| `POLICY_DATES_MISMATCH` | blocking, during review | Policies financed together must share the same effective and expiration dates |
| `MISSING_POLICY_NUMBER` | blocking, then outstanding | A binder or policy without a usable policy number ("TBD" doesn't count) |
| `QUOTE_ONLY_DOCUMENT` | blocking, then outstanding | The policy is only quoted, not bound |
| `CARRIER_UNMATCHED` | shown early, then outstanding | We haven't matched the carrier to our carrier records yet. Bridgeline resolves this |
| `INSURED_ADDRESS_INCOMPLETE` | shown early, then outstanding | The insured's mailing address needs a street, city, state and ZIP code |
| `PRICING_REQUIRED` | blocking | Your broker hasn't priced the application in the portal yet |
| `SIGNER_MISSING` | blocking | The borrower's signer (name and email) is missing |
| `SIGNER_CONFLICT` | blocking | The borrower's email, or the signer's, is the same as the broker signatory's |
| `AGREEMENT_DECLINED` | blocking | The borrower declined and the application hasn't gone back to pricing (for example, a signature was already on the agreement). Bridgeline follows up |

"During review" means while the application is in `processing` or your broker is still reviewing the policy details: these are the checks the portal makes before pricing, and they're settled once the deal reaches pricing.

### Missing policy numbers

A finance agreement can go out before the carrier binds. `MISSING_POLICY_NUMBER` and `QUOTE_ONLY_DOCUMENT` start in `blocking`; once your broker confirms in the portal that the binder will follow, they move to `outstanding`, and they clear when the binder or policy arrives and we verify it. These are the same codes a quote's [binding readiness](/concepts/binding-readiness) uses.

### Shown early

`CARRIER_UNMATCHED` and `INSURED_ADDRESS_INCOMPLETE` are listed in `blocking` as soon as they're true, but the portal doesn't stop the agreement for them yet, so they don't hold the status back: an application with only these open is `ready_for_agreement`. Once the agreement is sent, any still open move to `outstanding`. They still matter after signing, because carrier and insured notices wait for them.

## Pricing and the quote

* **`pricing`** is the terms your broker has priced in the portal: the ones the finance agreement will carry, and once it's sent, the agreement's own terms. It's `null` until the application reaches pricing. `total_of_payments` is the amount financed plus the finance charge, exactly as on the agreement. `selected_by` is `broker` when your broker picked the terms, `system` when they kept our recommendation.
* **`created_via`** says where the deal came from: `api`, `portal` or `email`.
* **`quote_id`, `accepted_option_id`, `client_reference_id` and `metadata`** are set when a deal starts from a quote you accept through the API. Accepting isn't available yet, so today every application was started in the portal or by email, and these are `null` (and `metadata` is `{}`). To match a deal to a record in your system for now, use the insured's name and the policies' `policy_number`.

## Following changes

There's no `updated_at` on an application yet, so to keep a panel current, re-list on an interval and compare:

1. Every few minutes, page through [`GET /v1/applications`](/api-reference/applications/list) with `limit=100`. 500 deals is 5 requests, well under the [rate limit](/guides/rate-limits).
2. Compare each application's `status` and `requirements` with your copy, and update what changed.
3. Keep following `active` applications: their `outstanding` items can still clear or change.

Events that tell you when something changed, and a filter on update time, are on the [roadmap](/roadmap).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.