# MCP
Source: https://docs.axle.insure/advanced/mcp

Set up Axle's MCP to grant AI tools the knowledge of Axle docs

If you use AI-powered development tools like Cursor, VS Code, or Claude Desktop to build your Axle integrations, you can now link these tools directly to the Axle docs for faster integration building!

You can do this by installing the Axle Docs [Model Context Protocol](https://modelcontextprotocol.io/introduction) (MCP) Server.

# Installation Instructions

<Note>
  This is an early alpha feature, so these instructions and the functionality of Axle's MCP tools may change due to updates from Axle's docs provider (Mintlify) or from MCP clients (Cursor, VS Code, Claude, etc.).
</Note>

## Installation Requirements:

You must have `npm` installed on your machine. If not, start by [installing npm](https://docs.npmjs.com/downloading-and-installing-node-js-and-npm).

We also recommend installing an MCP compatible IDE or Chatbot tool before you begin this setup process. As of May 2025, these primarily include Visual Studio Code, Cursor, and Claude Desktop.

### MCP Installation:

1. In any directory on your machine, run **`npm i -g @mintlify/mcp` to install the Mintlify MCP Generator**
2. In the same directory where you ran the previous command, run `npx @mintlify/mcp@latest add axle` .
3. This will open a CLI tool which will walk you through generating a copy of the Axle Docs MCP on your machine. Follow the instructions which appear to complete your setup. If you have Cursor or Claude Desktop installed, you will be prompted here for which MCP Clients you’d like to enable - Cursor, Claude or Both.

### Additional Instructions For VS Code:

The Mintlify MCP generator doesn’t currently support VS Code as a setup option, but VS Code will read in MCPs from Cursor’s MCP config, so you should select Cursor as your installation option.

When you open VS Code after installing an MCP in Cursor, you may see a prompt like “Would you like to use Cursor MCPs?”. Answer yes.

If you need more information about setting up this MCP with VS Code, read their official guide to [MCP Servers](https://code.visualstudio.com/docs/copilot/chat/mcp-servers).

## Using the MCP

Once you’ve completed the MCP installation, ensure the `axle-mcp-server` is enabled and then you can simply ask your chatbot of choice a questions about the Axle docs.

For example:

* “Walk me through implementing the first steps of the Axle ‘Getting Started’ guide”
* “What options are available to check collision coverage using Axle's policy validation API?”
* “Write a function which makes a request to Axle’s ‘Start Ignition’ endpoint which takes in a `userId` , `first name` and `last name` as arguments.”


# The Account object
Source: https://docs.axle.insure/api-reference/accounts/account

An Account represents an account with an insurance carrier and includes high-level account information (e.g. name) and any Policy objects associated with the Account.

<Tip>
  All fields are nullable and required unless otherwise specified. See [API
  overview](/api-reference/overview) for more details.
</Tip>

## Fields

<br />

<ParamField type="string">
  Unique identifier for the Account object.
</ParamField>

<ParamField type="string">
  Insurance carrier that is the source for the Account data.
</ParamField>

<ParamField type="string">
  First name of insurance account owner.
</ParamField>

<ParamField type="string">
  Last name of insurance account owner.
</ParamField>

<ParamField type="string">
  Primary phone number of insurance account owner.
</ParamField>

<ParamField type="string">
  Primary email address of insurance account owner.
</ParamField>

<ParamField type="array[string]">
  List of unique identifiers of Policy objects associated with the Account
</ParamField>

<ParamField type="Connection">
  <Expandable title="Connection">
    <ResponseField name="status" type="string">
      The Account connection status represents if Axle can actively request new Account and Policy data from the insurance carrier.

      Connection status `inactive` used when the Account was created from an Ignition completion with result `manual`. See [Account events](/guides/account-events) for more details on the other statuses.
      <br />Available options: `active`, `retrying`, `credentials-expired`, `mfa-expired`, `account-disabled`, `account-inaccessible`, `lienholder-required`, `comp-coll-required`, `policy-summary-only`, `inactive`
    </ResponseField>

    <ResponseField name="updatedAt" type="string">
      ISO 8601 timestamp at which the Account connection status was updated.
    </ResponseField>
  </Expandable>
</ParamField>

<ParamField type="enum<string>">
  Identifies the process that describes how each Ignition was completed in detail.

  Available options:

  1. `basic`
  2. `credit-card-form`
  3. `document-ai-declarations-page`
  4. `document-ai-id-card`
  5. `document-ai-push-through`
  6. `manual-form`
  7. `policy-lookup`
  8. `policy-lookup-no-comp-coll`
  9. `policy-lookup-no-lienholder`
  10. `policy-lookup-summary`
  11. `user-portal-login`

  Additional information and definitions for the above options can be found at <a href="/guides/completion-types#resultdetail">Axle Ignition Result Detail Types</a>.
</ParamField>

<ParamField type="string">
  ISO 8601 timestamp at which the Account object was generated via Axle.
</ParamField>

<ParamField type="string">
  ISO 8601 timestamp at which the Account object was modified via Axle. The
  Account object is modified only when there are differences between the current
  Account and new Account data requested from the carrier.
</ParamField>

<ParamField type="string">
  ISO 8601 timestamp at which the Account object was refreshed via Axle. The
  Account object is refreshed only when Axle successfully requests new Account
  data from the insurance carrier.

  <Info>
    If the `refreshedAt` date does not update daily, we're working on re-establishing the connection with the
    insurance carrier to retrieve updated account data. Please keep an eye on the `refreshedAt` field to
    confirm it's active and up-to-date.
  </Info>
</ParamField>

<RequestExample>
  ```json The Account object theme={null}
  {
    "id": "acc_gM2wn_gaqUv76ZljeVXOv",
    "carrier": "state-farm",
    "firstName": "John",
    "lastName": "Smith",
    "email": "john.smith@grr.la",
    "policies": ["pol_CbxGmGWnp9bGAFCC-eod2"],
    "connection": {
      "status": "active",
      "updatedAt": "2022-01-01T00:00:00.000Z"
    },
    "resultDetail": "user-portal-login",
    "createdAt": "2022-01-01T00:00:00.000Z",
    "modifiedAt": "2022-01-01T00:00:00.000Z",
    "refreshedAt": "2022-01-01T00:00:00.000Z"
  }
  ```
</RequestExample>


# Get Account
Source: https://docs.axle.insure/api-reference/accounts/get-account

GET /accounts/{id}
The Get Account endpoint will return an Account object including high-level account information (e.g., connection status) and any children objects (e.g., Policies) associated with the Account.
Please note that this endpoint will NOT refresh the Account object with new data from the insurance carrier.



# Get Carrier
Source: https://docs.axle.insure/api-reference/carriers/get-carrier

GET /carriers/{id}
The Get Carrier endpoint returns a Carrier object that include additional details (such as image) about an Axle-supported insurance carrier.

The `id` path parameter accepts either the Axle carrier ID or the carrier's NAIC code. For example, `/carriers/state-farm` and `/carriers/10739` are both valid requests.

**Note**: this is only available for carriers that are listed on Account or Policy objects that are generated via Ignition result=`link`.



# Get Carriers
Source: https://docs.axle.insure/api-reference/carriers/get-carriers

GET /carriers
The Get Carriers endpoint returns an array of Carrier objects which include additional details about Axle-supported insurance carriers.



# Proxy Ignition
Source: https://docs.axle.insure/api-reference/ignition/proxy-ignition

POST /ignition/{ignitionToken}/proxy
Proxy insurance information on behalf of your user to Axle for processing and/or verification. This endpoint should ONLY be used when insurance information is gathered when the user is not present (such as a document received from an insurance carrier via mail).

For more details on permitted usage and supported operations, see the [Proxy Ignition](/guides/proxy-ignition) guide.



# Start Ignition
Source: https://docs.axle.insure/api-reference/ignition/start-ignition

POST /ignition
Generate an Ignition session. Returns an ignitionToken and ignitionUri to direct the user to share their insurance information. The ignition session will never expire.

<Info>
  The Axle Team can set up Ignition templates to overwrite the default configuration that is set per client.

  To apply one, pass the template in the [Start Ignition](/api-reference/ignition/start-ignition) request body. The template scopes to that single Ignition session. Contact the Axle team to set up a template.
</Info>


# Overview
Source: https://docs.axle.insure/api-reference/overview

Learn about the Axle API

## API basics

* The Axle API is built on RESTful principles.
* The API operates over HTTPS to ensure the security of data being transferred.
* All requests and responses are sent in JSON.

### Environments

<CodeGroup>
  ```bash Production theme={null}
  https://api.axle.insure
  ```

  ```bash Sandbox theme={null}
  https://sandbox.axle.insure
  ```
</CodeGroup>

### Authentication

Axle API requests are authenticated using an client-id and client-secret (API key) pairing sent in the request headers.

* x-client-id — unique identifier for client
* x-client-secret — api key for client (sensitive)
* x-destination-client-id — unique identifier for the destination client (optional field used by platform integrations on select endpoints)

<Check>Contact the Axle team to acquire these keys.</Check>

When making API requests, API keys must match the base URL for the intended environment (see above); otherwise, the endpoint will return a `401 Unauthorized`.

### Response headers

Every Axle API response includes an `x-axle-request-id` header - a unique identifier generated per invocation.

```http Example response headers theme={null}
HTTP/1.1 200 OK
Content-Type: application/json
x-axle-request-id: req_V1StGXR8_Z5jdHi6B-myT
```

<Tip>
  To get your issue resolved faster, include the `x-axle-request-id` when
  contacting Axle support. It lets us pinpoint your exact request right away.
</Tip>

### Rate limiting

In order to keep systems secure and prevent misuse, all Axle API endpoints have protective rate limiting. The limits should not impact any expected use of the service, but if you are experiencing issues, please reach out to to the Axle team.

If rate limiting does occur, instead of the expected response, the endpoint will return `429 Too Many Requests`.

### Versioning and deprecation

To ensure stability and predictable evolution, Axle follows industry best practices for API versioning and deprecation:

* Versioning: **Axle is current on major version 1, and all minor version changes are backwards-compatible.**
* Deprecation: If needed, older endpoints or configuration are phased out through a defined process — advance notice, migration guides, grace periods, and eventual retirement.
* Consistency: Axle maintains the consistent authentication, response types (JSON), and error states across all endpoints.
* Changelog: All changes are documented in the [changelog](/changelog) using leading practices.

### Null or undefined values

Within the Account or Policy objects, individual fields may return `null` values when the carrier data source supports the field, but no information is present or Axle has determined the information to be incorrect.

Certain fields are *optional*, such as `Policy.coverages["BI"].property` or `Policy.coverages["UMPD"].deductible`. These fields may return `null` or `undefined`:

* `null`: The carrier data source supports the field, but no information is present for the selected Account or Policy.
* `undefined`: The carrier data source supports the field, and data is available that specifies that the field
  does not exist on or does not apply to the Account or Policy.

```json Example Policy theme={null}
{
	"...",
	"policyNumber": "123456789",
	"isActive": true,
	"effectiveDate": null, // No information was available from carrier data source
	"expirationDate": "2023-10-22T04:00:00.000Z",
	"address": {
		"addressLine1": "123 Main St.",
		"addressLine2": null,
		"city": "New York",
		"state": "NY",
		"postalCode": "10014",
		"country": "US",
	},
	"coverages": [
		{
			"code": "PD",
			"label": "Property Damage",
			"limitPerAccident": null, // No information was available from carrier data source
			"deductible": undefined, // The carrier data source specifies that there is no deductible present for this coverage
			"property": undefined // The carrier data source specifies that there is coverage does not apply to a single property on the policy
    	},
		{
			"code": "COLL",
			"label": "Collision",
			"deductible": null, // No information was available from carrier data source
			"property": "prp_83sD63h82bbeu2Dgn"
    	},
		"..."
	],
	"..."
}
```

## Objects and Endpoints

Get started with Axle's core endpoints:

<CardGroup>
  <Card title="Ignition" icon="circle-play" href="/api-reference/ignition/start-ignition">
    Manage Ignition sessions.
  </Card>

  <Card title="Tokens" icon="key" href="/api-reference/tokens/exchange-token">
    Manage and exchange Access Tokens.
  </Card>

  <Card title="Accounts" icon="id-card" href="/api-reference/accounts/get-account">
    Retrieve information about an Account.
  </Card>

  <Card title="Policies" icon="file-contract" href="/api-reference/policies/get-policy">
    Retrieve information about a Policy.
  </Card>

  <Card title="Policy Reports" icon="file-pdf" href="/api-reference/policies/get-policy-report">
    Retrieve Policy Report.
  </Card>

  <Card title="Descope Token" icon="key" href="/api-reference/tokens/descope-token">
    Change the scope of an Access Token.
  </Card>
</CardGroup>


# Create Client
Source: https://docs.axle.insure/api-reference/platform/create-client

POST /platform/clients
Create a destination client associated with your platform client. This request will return a destination client `id` that you can use to make requests to the Axle API on behalf of your destination clients.

See the [Axle for Platforms](/guides/platform-integration) guide for more information on how to use this endpoint and the destination client `id`.



# Create Template
Source: https://docs.axle.insure/api-reference/platform/create-templates

POST /platform/validation/templates
Create a new template for all of your destination clients.

Refer to the [Policy Validation with Templates](/guides/validate/policy-validation-with-template) guide for more details.

⚠️ This endpoint will generate template and add them to **all** of your destination clients. If you want to create a template only for specific client, use [Create Template](/api-reference/validation/templates/create-template) endpoint.



# Get Clients
Source: https://docs.axle.insure/api-reference/platform/get-clients

GET /platform/clients
Get a list of destination clients associated with your platform client. This request will return a list of destination client `id`s that you can use to make requests to the Axle API on behalf of your destination clients.

See the [Axle for Platforms](/guides/platform-integration) guide for more information on how to use this endpoint and the destination client `id`.



# Coverages
Source: https://docs.axle.insure/api-reference/policies/coverages

This page provides additional detail about the Axle Schema's insurance coverage types and highlights key rules and checks used to ensure accurate data. Coverages are provided through the `coverages` array in Policy objects.


Rules applied to all coverages:

1. If both the `limitPerAccident` and `limitPerPerson` values are provided for a coverage, the `limitPerAccident` value must be greater than the `limitPerPerson` value.
2. If a specified coverage is afforded to all properties on the policy, the `property` field will be `undefined`.

<Tip>
  For standardization purposes, Axle performs opinionated data transformation of
  insurance carriers' data into the Axle Schema. As a result, Axle makes certain
  carrier enumeration inferences to map carrier data into the Axle Schema.
</Tip>

## Auto Policy Coverage Types

<Accordion title="Bodily Injury" icon="crutch">
  Rules applied:

  1. If the carrier returns limits combined as `“$50,000 / $100,000”`, the first value represents `limitPerPerson` and the second value represents `limitPerAccident`. If there is only a single limit returned, the limit will be recorded as `limitPerAccident`.
  2. If the policy returns a combined single limit (CSL) for Bodily Injury and Property Damage, the limit will be set as `limitPerAccident` for both Bodily Injury and Property Damage coverages.

  Suppression checks:

  1. `limitPerAccident`, `limitPerPerson`, and `deductible` fields contain certain min / max value thresholds used to suppress inaccurate or nonsensical data.

  ### Fields

  <ResponseField name="code" type="string">
    BI
  </ResponseField>

  <ResponseField name="label" type="string">
    Bodily Injury
  </ResponseField>

  <ResponseField name="limitPerAccident" type="number or null" />

  <ResponseField name="limitPerPerson" type="number or null (optional)" />
</Accordion>

<Accordion title="Property Damage" icon="car-burst">
  Rules applied:

  1. If the carrier returns limits combined as `“$50,000 / $500”`, the first value represents `limitPerAccident` and the second value represents the `deductible`.
  2. If the policy returns a combined single limit (CSL) for Bodily Injury and Property Damage, the limit will be set as `limitPerAccident` for both Bodily Injury and Property Damage coverages.

  Suppression checks:

  1. `limitPerAccident` and `deductible` fields contain certain min / max value thresholds used to suppress inaccurate or nonsensical data.

  ### Fields

  <ResponseField name="code" type="string">
    PD
  </ResponseField>

  <ResponseField name="label" type="string">
    Property Damage
  </ResponseField>

  <ResponseField name="limitPerAccident" type="number or null" />

  <ResponseField name="deductible" type="number or null (optional)" />
</Accordion>

<Accordion title="Uninsured Motorists Bodily Injury" icon="motorcycle">
  Rules applied:

  1. If the carrier returns limits combined as `“$50,000 / $100,000”`, the first value represents `limitPerPerson` and the second value represents `limitPerAccident`. If there is only a single limit returned, the limit will be recorded as `limitPerAccident`.
  2. If the policy returns a combined single limit (CSL) for Uninsured Motorists Bodily Injury and Uninsured Motorists Property Damage, the limit will be set as `limitPerAccident` for both Uninsured Motorists Bodily Injury and Uninsured Motorists Property Damage coverages and `limitPerPerson` will be `undefined`.

  Suppression checks:

  1. `limitPerAccident` and `limitPerPerson` fields contain certain min / max value thresholds used to suppress inaccurate or nonsensical data.

  ### Fields

  <ResponseField name="code" type="string">
    UMBI
  </ResponseField>

  <ResponseField name="label" type="string">
    Uninsured Motorists Bodily Injury
  </ResponseField>

  <ResponseField name="limitPerAccident" type="number or null" />

  <ResponseField name="limitPerPerson" type="number or null (optional)" />
</Accordion>

<Accordion title="Uninsured Motorists Property Damage" icon="motorcycle">
  Rules applied:

  1. If the carrier returns limits combined as `“$50,000 / $500”`, the first value represents `limitPerAccident` and the second value represents the `deductible`.
  2. If the policy returns a combined single limit (CSL) for Uninsured Motorists Bodily Injury and Uninsured Motorists Property Damage, the limit will be set as `limitPerAccident` for both Uninsured Motorists Bodily Injury and Uninsured Motorists Property Damage coverages and `limitPerPerson` will be `undefined`.

  Suppression checks:

  1. `limitPerAccident` and `deductible` fields contain certain min / max value thresholds used to suppress inaccurate or nonsensical data.

  ### Fields

  <ResponseField name="code" type="string">
    UMPD
  </ResponseField>

  <ResponseField name="label" type="string">
    Uninsured Motorists Property Damage
  </ResponseField>

  <ResponseField name="limitPerAccident" type="number or null" />

  <ResponseField name="deductible" type="number or null (optional)" />
</Accordion>

<Accordion title="Underinsured Motorists Bodily Injury" icon="motorcycle">
  Rules applied:

  1. If the carrier returns limits combined as `“$50,000 / $100,000”`, the first value represents `limitPerPerson` and the second value represents `limitPerAccident`. If there is only a single limit returned, the limit will be recorded as `limitPerAccident`.

  Suppression checks:

  1. `limitPerAccident` and `limitPerPerson` fields contain certain min / max value thresholds used to suppress inaccurate or nonsensical data.

  ### Fields

  <ResponseField name="code" type="string">
    UIMBI
  </ResponseField>

  <ResponseField name="label" type="string">
    Underinsured Motorists Bodily Injury
  </ResponseField>

  <ResponseField name="limitPerAccident" type="number or null" />

  <ResponseField name="limitPerPerson" type="number or null (optional)" />
</Accordion>

<Accordion title="Underinsured Motorists Property Damage" icon="motorcycle">
  Rules applied:

  1. If the carrier returns limits combined as `“$50,000 / $500”`, the first value represents `limitPerAccident` and the second value represents the `deductible`.

  Suppression checks:

  1. `limitPerAccident` and `deductible` fields contain certain min / max value thresholds used to suppress inaccurate or nonsensical data.

  ### Fields

  <ResponseField name="code" type="string">
    UIMPD
  </ResponseField>

  <ResponseField name="label" type="string">
    Underinsured Motorists Property Damage
  </ResponseField>

  <ResponseField name="limitPerAccident" type="number or null" />

  <ResponseField name="deductible" type="number or null (optional)" />
</Accordion>

<Accordion title="Uninsured & Underinsured Motorists Bodily Injury" icon="motorcycle">
  Rules applied:

  1. If the carrier returns limits combined as `“$50,000 / $100,000”`, the first value represents `limitPerPerson` and the second value represents `limitPerAccident`. If there is only a single limit returned, the limit will be recorded as `limitPerAccident`.

  Suppression checks:

  1. `limitPerAccident` and `limitPerPerson` fields contain certain min / max value thresholds used to suppress inaccurate or nonsensical data.

  ### Fields

  <ResponseField name="code" type="string">
    UUIMBI
  </ResponseField>

  <ResponseField name="label" type="string">
    Uninsured & Underinsured Motorists Bodily Injury
  </ResponseField>

  <ResponseField name="limitPerAccident" type="number or null" />

  <ResponseField name="limitPerPerson" type="number or null (optional)" />
</Accordion>

<Accordion title="Uninsured & Underinsured Motorists Property Damage" icon="motorcycle">
  Rules applied:

  1. If the carrier returns limits combined as `“$50,000 / $500”`, the first value represents `limitPerAccident` and the second value represents the `deductible`.

  Suppression checks:

  1. `limitPerAccident` and `deductible` fields contain certain min / max value thresholds used to suppress inaccurate or nonsensical data.

  ### Fields

  <ResponseField name="code" type="string">
    UUIMPD
  </ResponseField>

  <ResponseField name="label" type="string">
    Uninsured & Underinsured Motorists Property Damage
  </ResponseField>

  <ResponseField name="limitPerAccident" type="number or null" />

  <ResponseField name="deductible" type="number or null (optional)" />
</Accordion>

<Accordion title="Collision" icon="car-burst">
  Suppression checks:

  1. `limitPerAccident` and `deductible` fields contain certain min / max value thresholds used to suppress inaccurate or nonsensical data.

  ### Fields

  <ResponseField name="code" type="string">
    COLL
  </ResponseField>

  <ResponseField name="label" type="string">
    Collision
  </ResponseField>

  <ResponseField name="limitPerAccident" type="number or null (optional)" />

  <ResponseField name="deductible" type="number or null" />

  <ResponseField name="property" type="string or null" />
</Accordion>

<Accordion title="Comprehensive" icon="car-burst">
  Suppression checks:

  1. `limitPerAccident` and `deductible` fields contain certain min / max value thresholds used to suppress inaccurate or nonsensical data.

  ### Fields

  <ResponseField name="code" type="string">
    COMP
  </ResponseField>

  <ResponseField name="label" type="string">
    Comprehensive
  </ResponseField>

  <ResponseField name="limitPerAccident" type="number or null (optional)" />

  <ResponseField name="deductible" type="number or null" />

  <ResponseField name="property" type="string or null" />
</Accordion>

## Home/Condo/Renters Policy Coverage Types

<Accordion title="Dwelling" icon="house">
  Rules applied:

  1. When the deductible is listed differently based on the type of peril, the deductible associated with covered perils will be returned. This deductible value is often represented as “All Perils”, “All Covered Perils”, or “Other Covered Perils”.

  Suppression checks:

  1. If both the policy `premium` and Dwelling coverage `limitPerAccident` values are defined, the Axle Service will ensure that the premium-to-Dwelling-limitPerAccident ratio falls within our set bounds of reasonability. If this ratio is greater than our upper bound, both the policy `premium` and Dwelling coverage `limitPerAccident` values will be conservatively set to `null`. If a `premium` value exists but no Dwelling `limitPerAccident` value is present, then the `premium` will be conservatively set to `null`.
  2. `limitPerAccident` and `deductible` fields contain certain min / max value thresholds used to suppress inaccurate or nonsensical data.

  ### Fields

  <ResponseField name="code" type="string">
    DW
  </ResponseField>

  <ResponseField name="label" type="string">
    Dwelling
  </ResponseField>

  <ResponseField name="limitPerAccident" type="number or null" />

  <ResponseField name="deductible" type="number or null" />
</Accordion>

<Accordion title="Other Structures" icon="warehouse">
  Rules applied:

  1. When the deductible is listed differently based on the type of peril, the deductible associated with covered perils will be returned. This deductible value is often represented as “All Perils”, “All Covered Perils”, or “Other Covered Perils”.

  Suppression checks:

  1. `limitPerAccident` and `deductible` fields contain certain min / max value thresholds used to suppress inaccurate or nonsensical data.

  ### Fields

  <ResponseField name="code" type="string">
    OS
  </ResponseField>

  <ResponseField name="label" type="string">
    Other Structures
  </ResponseField>

  <ResponseField name="limitPerAccident" type="number or null" />

  <ResponseField name="deductible" type="number or null" />
</Accordion>

<Accordion title="Personal Property" icon="bag-shopping">
  Rules applied:

  1. When the deductible is listed differently based on the type of peril, the deductible associated with covered perils will be returned. This deductible value is often represented as “All Perils”, “All Covered Perils”, or “Other Covered Perils”.

  Suppression checks:

  1. `limitPerAccident` and `deductible` fields contain certain min / max value thresholds used to suppress inaccurate or nonsensical data.

  ### Fields

  <ResponseField name="code" type="string">
    PP
  </ResponseField>

  <ResponseField name="label" type="string">
    Personal Property
  </ResponseField>

  <ResponseField name="limitPerAccident" type="number or null" />

  <ResponseField name="deductible" type="number or null" />
</Accordion>

<Accordion title="Loss of Use" icon="x">
  Rules applied:

  1. When the deductible is listed differently based on the type of claim, the deductible associated with covered perils will be returned. This deductible value is often represented as “All Perils”, “All Covered Perils”, or “Other Covered Perils”.

  Suppression checks:

  1. `limitPerAccident` and `deductible` fields contain certain min / max value thresholds used to suppress inaccurate or nonsensical data.

  ### Fields

  <ResponseField name="code" type="string">
    LOU
  </ResponseField>

  <ResponseField name="label" type="string">
    Loss of Use
  </ResponseField>

  <ResponseField name="limitPerAccident" type="number or null" />

  <ResponseField name="deductible" type="number or null (optional)" />
</Accordion>

<Accordion title="Personal Liability" icon="user-injured">
  Suppression checks:

  1. `limitPerAccident` and `deductible` fields contain certain min / max value thresholds used to suppress inaccurate or nonsensical data.

  ### Fields

  <ResponseField name="code" type="string">
    PL
  </ResponseField>

  <ResponseField name="label" type="string">
    Personal Liability
  </ResponseField>

  <ResponseField name="limitPerAccident" type="number or null" />
</Accordion>

<Accordion title="Medical Expenses" icon="house-chimney-medical">
  Rules applied:

  1. Only a `limitPerAccident` or `limitPerPerson` value can exist on this coverage but not both.

  Suppression checks:

  1. `limitPerAccident` and `deductible` fields contain certain min / max value thresholds used to suppress inaccurate or nonsensical data.

  ### Fields

  <ResponseField name="code" type="string">
    MED
  </ResponseField>

  <ResponseField name="label" type="string">
    Medical Expenses
  </ResponseField>

  <ResponseField name="limitPerAccident" type="number" />

  <ResponseField name="limitPerPerson" type="number" />
</Accordion>

<Accordion title="Wind" icon="wind">
  Rules:

  1. Includes Wind & Hail or Windstorm & Hailstorm perils

  Suppression checks:

  1. `deductible` fields contain certain min / max value thresholds used to suppress inaccurate or nonsensical data.

  ### Fields

  <ResponseField name="code" type="string">
    WIND
  </ResponseField>

  <ResponseField name="label" type="string">
    Wind
  </ResponseField>

  <ResponseField name="deductible" type="number" />
</Accordion>

<Accordion title="Storm" icon="cloud-bolt">
  Rules applied:

  1. Includes Named Windstorm, Hurricane, Cyclone, Typhoon, and Tropical Storm perils

  Suppression checks:

  1. `deductible` fields contain certain min / max value thresholds used to suppress inaccurate or nonsensical data.

  ### Fields

  <ResponseField name="code" type="string">
    STORM
  </ResponseField>

  <ResponseField name="label" type="string">
    Storm
  </ResponseField>

  <ResponseField name="deductible" type="number" />
</Accordion>

## Flood Policy Coverage Types

<Accordion title="Dwelling" icon="house">
  Suppression checks:

  1. `limitPerAccident` and `deductible` fields contain certain min / max value thresholds used to suppress inaccurate or nonsensical data.

  ### Fields

  <ResponseField name="code" type="string">
    DW
  </ResponseField>

  <ResponseField name="label" type="string">
    Dwelling
  </ResponseField>

  <ResponseField name="limitPerAccident" type="number or null" />

  <ResponseField name="deductible" type="number or null" />
</Accordion>

<Accordion title="Personal Property" icon="bag-shopping">
  Suppression checks:

  1. `limitPerAccident` and `deductible` fields contain certain min / max value thresholds used to suppress inaccurate or nonsensical data.

  ### Fields

  <ResponseField name="code" type="string">
    PP
  </ResponseField>

  <ResponseField name="label" type="string">
    Personal Property
  </ResponseField>

  <ResponseField name="limitPerAccident" type="number or null" />

  <ResponseField name="deductible" type="number or null" />
</Accordion>


# Execute Policy Action
Source: https://docs.axle.insure/api-reference/policies/execute-policy-action

POST /policies/{policyId}/actions
Execute an action on a policy on behalf of your user. Once submitted, Axle will process the request.

For more details on supported operations and error codes, see the [Policy Actions](/guides/policy-actions) guide.



# Get Policy
Source: https://docs.axle.insure/api-reference/policies/get-policy

GET /policies/{policyId}
The Get Policy endpoint returns a Policy object. Please refer to the [Policy](/api-reference/policies/policy) object for a detailed description of each field.
Please note that this endpoint will NOT refresh the Policy object with new data from the insurance carrier.



# Get Policy Report
Source: https://docs.axle.insure/api-reference/policies/get-policy-report

GET /policies/{policyId}/report
The Get Policy Report endpoint returns a PDF or image report of the requested Policy object. Please refer to the [Policy](/api-reference/policies/policy) object for a detailed description of each field.



# The Policy object
Source: https://docs.axle.insure/api-reference/policies/policy

A Policy represents a specific policy associated with an Account and includes high-level policy information (e.g. policy number) and any children objects (e.g., coverages) associated with the policy.

<Tip>
  All fields are nullable when not available and present unless otherwise
  specified. See [API overview](/api-reference/overview) for more details.
</Tip>

## Fields

<br />

<ParamField type="string">
  Unique identifier for the Policy object.
</ParamField>

<ParamField type="string">
  Unique identifier for the Account object associated with the Policy.
</ParamField>

<ParamField type="enum<string>">
  Type of insurance policy that the Policy object represents.

  Available options:

  `auto` `motorcycle` `home` `condo` `flood` `renters`

  Rules applied:

  1. `auto` includes non-owned auto insurance policies but does not include commercial or business auto insurance policies.
  2. `home` includes HO-1, HO-2, HO-3, HO-5, HO-7, and HO-8 homeowners insurance policies. It also includes landlord and specialty fire policies. It does not include HO-4 (i.e., renters policies).
  3. `condo` is equivalent to an HO-6 insurance policy.
  4. `renters` includes HO-4 insurance policies.
  5. `flood` includes public NFIP insurance policies and private flood insurance policies.
</ParamField>

<ParamField type="string">
  Insurance carrier that is the source for the Policy data.
</ParamField>

<ParamField type="string or null">
  Identifier of the policy, as specified by the insurance carrier.
</ParamField>

<ParamField type="boolean or null (optional)">
  Active status of the policy, as specified by the insurance carrier. If an
  Ignition session is completed with result: `manual`, this field will be
  undefined.

  Rules applied:

  1. isActive `true` includes policies that are specified as active but may also include policies in pre-effective or pending cancellation statuses that are marked as active by the carrier.
  2. isActive `null` indicates that the insurance carrier did not specify if the policy is active.
</ParamField>

<ParamField type="string or null">
  ISO 8601 timestamp of current term effective date of the policy, as specified
  by the insurance carrier. The effective date may be in the future for policies
  that renew early.

  <Info>
    Axle returns the current term of the policy as specified by the insurance
    carrier. If the policy has been renewed for an future term, this term will
    not be shown ahead of the effective date unless the carrier has specified
    the future term as the current term.
  </Info>
</ParamField>

<ParamField type="string or null">
  ISO 8601 timestamp of current term expiration date of the policy, as specified
  by the insurance carrier.
</ParamField>

<ParamField type="number or null">
  Policy term premium, as specified by the insurance carrier. This value is
  inclusive of discounts and fees but may exclude certain fees due to variation
  in carrier reporting or additional surcharges placed via state policies.
</ParamField>

<ParamField type="Underwriter">
  Underwriter associated with the policy.

  <Expandable title="Underwriter">
    <ResponseField name="name" type="string or null">
      Name of the underwriter associated with the policy.
    </ResponseField>

    <ResponseField name="naicCode" type="string or null">
      NAIC code of the underwriter associated with the policy.
    </ResponseField>
  </Expandable>
</ParamField>

<ParamField type="Address">
  Primary address associated with the policy.

  <Expandable title="Address">
    <ResponseField name="addressLine1" type="string or null">
      First line of the street address, typically including the house number and street name.
    </ResponseField>

    <ResponseField name="addressLine2" type="string or null">
      Additional address details, such as an apartment, suite, or unit number.
    </ResponseField>

    <ResponseField name="city" type="string or null">
      City name of the address.
    </ResponseField>

    <ResponseField name="state" type="string or null">
      State of the address.
    </ResponseField>

    <ResponseField name="postalCode" type="string or null">
      ZIP or postal code of the address.
    </ResponseField>

    <ResponseField name="country" type="string or null">
      Country of the address.
    </ResponseField>
  </Expandable>
</ParamField>

<ParamField type="array[Property]">
  List of properties (such as a vehicle or dwelling) afforded coverage by the policy.

  <Expandable title="Property">
    <ResponseField name="id" type="string">
      Unique identifier for the Property object.
    </ResponseField>

    <ResponseField name="type" type="string">
      The type of the insured property.

      Available options:

      `vehicle` - Represents a motor vehicle (e.g., car, truck, motorcycle, trailer) insured under the policy.

      `dwelling` - Refers to a residential property (e.g., house, apartment) insured under the policy.
    </ResponseField>

    <ResponseField name="data" type="Vehicle or Dwelling">
      Contains specific details related to the insured property.

      <Expandable title="Vehicle">
        <ResponseField name="vin" type="string">
          The Vehicle Identification Number (VIN), a unique code used to identify individual motor vehicles.
        </ResponseField>

        <ResponseField name="model" type="string or null">
          The specific model name of the vehicle, indicating the manufacturer’s designation.
        </ResponseField>

        <ResponseField name="year" type="string or null">
          The model year of the vehicle, representing the year it was manufactured.
        </ResponseField>

        <ResponseField name="make" type="string or null">
          The manufacturer or brand name of the vehicle.
        </ResponseField>

        <ResponseField name="use" type="string or null">
          The “vehicle use” or “primary use” of the vehicle, indicating how the vehicle is predominantly used by the insured. **Note:** This field is only available for select carriers.

          Available options:

          1. `pleasure` - Includes cases when the vehicle use falls under multiple options, such as in "Pleasure/Commute" or "To Work, School or Pleasure". This also includes use related to artisan and collector cars.
          2. `commute` - Includes all vehicle use designations related to work (e.g. "Work 5-10") as well as when mileage is specified (e.g. "10 Miles")
          3. `business` - Includes all designations related to business.
          4. `farm` - Includes all designations related to farming.
        </ResponseField>

        <ResponseField name="bodyStyle" type="string or null (optional)">
          The style of the vehicle's body (e.g., sedan, SUV, coupe), which describes its design and configuration.
        </ResponseField>
      </Expandable>

      <Expandable title="Dwelling">
        <ResponseField name="addressLine1" type="string or null">
          The primary address line of the dwelling, typically including the street number and name.
        </ResponseField>

        <ResponseField name="addressLine2" type="string or null">
          An optional secondary address line for additional information (e.g., apartment number or suite).
        </ResponseField>

        <ResponseField name="city" type="string or null">
          The city where the dwelling is located.
        </ResponseField>

        <ResponseField name="state" type="string or null">
          The state where the dwelling is situated.
        </ResponseField>

        <ResponseField name="postalCode" type="string or null">
          The postal code for the dwelling's address.
        </ResponseField>

        <ResponseField name="country" type="string or null">
          The country where the dwelling is located.
        </ResponseField>

        <ResponseField name="ratedFloodZone" type="string or null (optional)">
          The FEMA designated flood zone that the dwelling resides in. This field is currently only available for flood policies.

          <Expandable title="Available Options">
            1. `A`
            2. `AE`
            3. `A1-A30`
            4. `AH`
            5. `AO`
            6. `AR`
            7. `AR/AE`
            8. `AR/AO`
            9. `AR/A`
            10. `AR/A1-A30`
            11. `A99`
            12. `V`
            13. `VE`
            14. `V1-V30`
            15. `B`
            16. `C`
            17. `X`
            18. `D`
          </Expandable>
        </ResponseField>

        <ResponseField name="replacementCost" type="number or null (optional)">
          The estimated cost of replacing or repairing the damaged property as specified by FEMA. If the FEMA RCV is not available, this field will return the RCV as specified by the carrier. This field is currently only available for flood policies.
        </ResponseField>
      </Expandable>
    </ResponseField>
  </Expandable>
</ParamField>

<ParamField type="array[Coverage]">
  List of coverage types and levels offered by the policy. Refer to [Coverages](/api-reference/policies/coverages) for additional detail about the supported coverage types.

  <Expandable title="Coverage">
    <ResponseField name="code" type="string">
      A coverage code for the type of insurance coverage present. Each code corresponds to a human-readable label.

      Available options for an `auto` or `motorcycle` insurance policy:

      1. `BI` - Bodily Injury
      2. `PD` - Property Damage
      3. `UMBI` - Uninsured Motorists Bodily Injury
      4. `UMPD` - Uninsured Motorists Property Damage
      5. `UIMBI` - Underinsured Motorists Bodily Injury
      6. `UIMPD` - Underinsured Motorists Property Damage
      7. `UUIMBI` - Uninsured & Underinsured Motorists Bodily Injury
      8. `UUIMPD` - Uninsured & Underinsured Motorists Property Damage
      9. `COLL` - Collision
      10. `COMP` - Comprehensive

      Available options for a `home` or `condo` insurance policy:

      1. `DW` - Dwelling
      2. `OS` - Other Structures
      3. `PP` - Personal Property
      4. `LOU` - Loss of Use
      5. `PL` - Personal Liability
      6. `MED` - Medical Expenses
      7. `WIND` - Wind
      8. `STORM` - Storm
    </ResponseField>

    <ResponseField name="label" type="string">
      A human-readable name describing the type of insurance coverage provided by the policy. The labels are provided above next to each corresponding coverage code.
    </ResponseField>

    <ResponseField name="limitPerPerson" type="number or null (optional)">
      The maximum amount the insurance policy will pay for bodily injury or damages sustained by an individual in a covered incident.
    </ResponseField>

    <ResponseField name="limitPerAccident" type="number or null (optional)">
      The maximum amount the insurance policy will pay for a single accident or claim.
    </ResponseField>

    <ResponseField name="deductible" type="number or null (optional)">
      The amount the policyholder must pay out-of-pocket toward a claim before the insurance coverage begins to pay.
    </ResponseField>

    <ResponseField name="property" type="string or null (optional)">
      Unique identifier of Property afforded coverage. If specified coverage is afforded to all properties on the policy, `property` will be `undefined`.
    </ResponseField>

    <Info>
      Within a Policy object, there will only be a single Coverage object per
      coverage `code` per `property`.
    </Info>
  </Expandable>
</ParamField>

<ParamField type="array[Exclusion]">
  List of policy exclusions (i.e., explicit removal of coverage afforded by the policy).

  <Expandable title="Exclusion">
    <ResponseField name="code" type="string">
      A exclusion code for the type of coverage exclusion found on the policy. Each code corresponds to a human-readable label.

      Available options for a `home` or `condo` insurance policy:

      1. `WIND` - Wind Exclusion
    </ResponseField>

    <ResponseField name="label" type="string">
      A human-readable name describing the type of exclusion found on the policy. The labels are provided above next to each corresponding exclusion code.
    </ResponseField>
  </Expandable>
</ParamField>

<ParamField type="array[Insured]">
  List of entities (such as an individuals or businesses) afforded direct coverage by the policy.

  Rules applied:

  1. Excluded drivers are removed from Insureds list for `auto` and `motorcycle` insurance policies.
  2. Entities listed as Additional Insureds are not included within the list of Insureds but are included under the list of Third Parties as an "interest".

  <Expandable title="Insured">
    <ResponseField name="firstName" type="string or null">
      The first name of the insured individual.
    </ResponseField>

    <ResponseField name="lastName" type="string or null">
      The last name of the insured individual.
    </ResponseField>

    <Tip>
      Insurance carriers may represent `firstName` and `lastName` in different ways (such as including middle name in `firstName` or dropping special characters such as `-`).

      If your application requires matching your users against policy insureds, it is recommended to combine `firstName` and `lastName` into a single value and using a "fuzzy" matching algorithm with a strict threshold.
    </Tip>

    <ResponseField name="type" type="string or null">
      The role of the insured individual, indicating whether they are the primary policyholder / user or a secondary insured party. **Note:** this field is in continued development and is subject to modification. Should be used for display purposes only.

      Available options:

      `primary` - The policyholder or primary user of the insured property.

      `secondary` - An additional person insured under the policy, such as an additional driver.

      If the role of the Insured is not specified, type will be `null`.
    </ResponseField>

    <ResponseField name="dateOfBirthYear" type="string or null">
      The birth year of the insured individual. **Note:** This field is only available for select carriers.
    </ResponseField>

    <ResponseField name="licenseNo" type="string or null">
      The driver's license number of the insured individual. **Note:** This field is only available for select carriers.
    </ResponseField>

    <ResponseField name="licenseState" type="string or null">
      The state that issued the insured individual's driver's license. **Note:** This field is only available for select carriers.
    </ResponseField>

    <ResponseField name="dateOfBirth" type="string or null">
      The insured individual's date of birth in a standard date format. **Note:** This field is only available for select carriers.
    </ResponseField>

    <ResponseField name="property" type="string or null (optional)">
      Unique identifier of Property afforded coverage for specified Insured. If Insured is afforded coverage across all properties on the policy, `property` will be `undefined`.
    </ResponseField>
  </Expandable>
</ParamField>

<ParamField type="array[ThirdParty]">
  List of external parties with interest in the policy.

  <Expandable title="ThirdParty">
    <ResponseField name="type" type="string or null">
      The role of the Third Party associated with the insured property.
      **Note:** this field is in continued development and is subject to modification. Should be used for display purposes only.

      The Axle Schema currently supports the following Third Party options. See below for details on Axle's standardization of Third Party type based on data provided by the insurance carrier.

      Available options:

      `lienholder` - A financial institution or individual that holds a legal claim on the insured property. This includes mortgagees.

      `lessor` - The owner or leasing company that leases the insured property to the policyholder under a lease agreement. This includes loss payees if the Third Party is also assessed as an Additional Insured.

      `interest` - Any Third Party with a financial interest in the insured property. This option serves as the conservative default used in the following cases:

      1. The Third Party is specifically listed as an "additional interest".
      2. The Third Party falls across options (e.g. a Third Party that is both an additional insured and an additional interest).

      If the role of the Third Party is not specified, type will be `null`.
    </ResponseField>

    <ResponseField name="name" type="string">
      The name of the Third Party.
    </ResponseField>

    <ResponseField name="address" type="Address">
      The address of the Third Party. **Note:** This field may not be available for all carriers.
    </ResponseField>

    <ResponseField name="property" type="string or null">
      Unique identifier of Property for which the specified Third Party is afforded coverage through this policy.
    </ResponseField>
  </Expandable>
</ParamField>

<ParamField type="array[Document]">
  List of documents (such as declaration pages and policy agreements) associated with the policy. Note that the insurance carrier may not always update documents on the policy to reflect policy changes or term renewals.

  Rules applied:

  1. Only the most recently effective or issued document of each document type will be present in the document list.
  2. There will only be at most one document of each type listed in the documents list.

  <Expandable title="Document">
    <ResponseField name="id" type="string">
      Unique identifier (formatted as filename) for the document.
    </ResponseField>

    <ResponseField name="source" type="string">
      The origin of the document.

      Available options:

      `carrier` - Indicates that the document originated from the insurance carrier.

      `user` - Indicates that the document was uploaded by the user.

      <Tip>
        User-provided documents are not verified by Axle.
      </Tip>
    </ResponseField>

    <ResponseField name="name" type="string">
      The name of the document.
    </ResponseField>

    <ResponseField name="type" type="array[string]">
      The type of information contained in the document, as specified by carrier or user. A document may have multiple types.

      Available options:

      `declaration-page` - A summary document that outlines the key details of the insurance policy, including coverage limits, premiums, and insured parties. This includes renewal policy documents, amended policy documents, and new business documents.

      `policy-agreement` - The formal contract between the insurer and the policyholder that specifies the terms and conditions of the insurance coverage. This includes insurance policy contract documents. Note that this type of document may not always be available.

      `id-card` - An identification card issued by the insurer that serves as proof of insurance coverage and includes relevant policy information for the insured vehicle. This document type is generally only found for auto insurance policies.
    </ResponseField>

    <ResponseField name="url" type="string">
      Pre-signed url to access document.

      <Tip>
        For security, document urls have an expiry of 60 minutes.
      </Tip>
    </ResponseField>

    <ResponseField name="issuedDate" type="string or null">
      If available, ISO 8601 timestamp at which the document was generated or issued by the carrier.
    </ResponseField>

    <ResponseField name="effectiveDate" type="string or null">
      If available, ISO 8601 timestamp at which the document becomes active or goes into effect.
    </ResponseField>

    <ResponseField name="createdAt" type="string">
      ISO 8601 timestamp at which the document was fetched or shared via Axle.
    </ResponseField>
  </Expandable>
</ParamField>

<ParamField type="string">
  ISO 8601 timestamp at which the Policy object was generated via Axle.
</ParamField>

<ParamField type="string">
  ISO 8601 timestamp at which the Policy object was modified via Axle. The
  Policy object is modified only when there are differences between the current
  Policy and new Policy data requested from the carrier.
</ParamField>

<ParamField type="string">
  ISO 8601 timestamp at which the Policy object was refreshed via Axle. The
  Policy object is refreshed only when Axle successfully requests new Policy
  data from the carrier.

  <Info>
    If the `refreshedAt` date does not update daily, we're working on re-establishing the connection with the
    insurance carrier to retrieve updated policy data. Please keep an eye on the `refreshedAt` and `connection` fields to
    confirm they're active and up-to-date.
  </Info>
</ParamField>

<ParamField type="enum<string>">
  Ignition completion type that describes the high-level Policy outcome.

  Available options:

  1. `basic`
  2. `link`
  3. `manual`
  4. `proxy`

  Additional information and definitions for the above options can be found at <a href="/guides/completion-types#result">Axle Ignition Result Types</a>.
</ParamField>

<ParamField type="enum<string>">
  Identifies the process that describes how each Ignition was completed in detail.

  Available options:

  1. `basic`
  2. `credit-card-form`
  3. `document-ai-declarations-page`
  4. `document-ai-id-card`
  5. `document-ai-push-through`
  6. `manual-form`
  7. `policy-lookup`
  8. `policy-lookup-no-comp-coll`
  9. `policy-lookup-no-lienholder`
  10. `policy-lookup-summary`
  11. `user-portal-login`

  Additional information and definitions for the above options can be found at <a href="/guides/completion-types#resultdetail">Axle Ignition Result Detail Types</a>.
</ParamField>

<RequestExample>
  ```json Auto Insurance Policy Object theme={null}
  {
    "id": "pol_CbxGmGWnp9bGAFCC-eod2",
    "account": "acc_gM2wn_gaqUv76ZljeVXOv",
    "type": "auto",
    "carrier": "state-farm",
    "policyNumber": "123456789",
    "isActive": true,
    "effectiveDate": "2021-10-22T00:00:00.000Z",
    "expirationDate": "2022-10-22T00:00:00.000Z",
    "premium": 1500,
    "underwriter": {
      "name": "John Doe",
      "naicCode": "12345"
    },
    "address": {
      "addressLine1": "123 Main St.",
      "addressLine2": "Unit 456",
      "city": "Atlanta",
      "state": "Georgia",
      "postalCode": "30315",
      "country": "USA"
    },
    "properties": [
      {
        "id": "prp_uSdzLVpi8c76H7kl6AQ-F",
        "type": "vehicle",
        "data": {
          "bodyStyle": "sedan",
          "vin": "WDDWJ8EB4KF776265",
          "model": "C 300",
          "year": "2019",
          "make": "Mercedes-Benz",
          "use": "commute"
        }
      },
      {
        "id": "prp_tmGUxLpgHjmW9r6M6WjhS",
        "type": "vehicle",
        "data": {
          "bodyStyle": "minivan",
          "vin": "5FNRL38209B014050",
          "model": "Odyssey",
          "year": "2009",
          "make": "Honda",
          "use": "pleasure"
        }
      }
    ],
    "coverages": [
      {
        "code": "BI",
        "label": "Bodily Injury",
        "limitPerPerson": 250000,
        "limitPerAccident": 500000
      },
      {
        "code": "PD",
        "label": "Property Damage",
        "limitPerAccident": 100000
      },
      {
        "code": "UMBI",
        "label": "Uninsured Bodily Injury",
        "limitPerPerson": 100000,
        "limitPerAccident": 300000
      },
      {
        "code": "COMP",
        "label": "Comprehensive",
        "deductible": 375,
        "property": "prp_uSdzLVpi8c76H7kl6AQ-F"
      },
      {
        "code": "COLL",
        "label": "Collision",
        "deductible": 375,
        "property": "prp_uSdzLVpi8c76H7kl6AQ-F"
      }
    ],
    "exclusions": [],
    "insureds": [
      {
        "type": "primary",
        "firstName": "John",
        "lastName": "Smith",
        "dateOfBirthYear": "1990",
        "licenseNo": "•••••1234"
      },
      {
        "type": "primary",
        "firstName": "Jane",
        "lastName": "Doe",
        "dateOfBirthYear": "1992",
        "licenseNo": "•••••5678"
      }
    ],
    "thirdParties": [
      {
        "property": "prp_tmGUxLpgHjmW9r6M6WjhS",
        "type": "lessor",
        "name": "Super Leasing Trust",
        "address": {
          "addressLine1": "PO Box 123456",
          "country": null,
          "addressLine2": null,
          "state": "GA",
          "city": "Atlanta",
          "postalCode": "30348"
        }
      }
    ],
    "documents": [
      {
        "id": "doc_jd73dw6fn02sj28.pdf",
        "source": "carrier",
        "name": "Declaration Page",
        "type": ["declaration-page"],
        "url": "<signed-url>",
        "issuedDate": "2022-01-01T00:00:00.000Z",
        "effectiveDate": "2022-01-02T00:00:00.000Z",
        "createdAt": "2022-01-01T00:00:00.000Z"
      }
    ],
    "result": "link",
    "resultDetail": "user-portal-login",
    "createdAt": "2022-01-01T00:00:00.000Z",
    "modifiedAt": "2022-01-01T00:00:00.000Z",
    "refreshedAt": "2022-01-01T00:00:00.000Z"
  }
  ```

  ```json Home Insurance Policy Object theme={null}
  {
    "id": "pol_AbcIkNEnp9bFUIee-oir1",
    "account": "acc_gM2wn_gaqUv76ZljeVXOv",
    "type": "home",
    "carrier": "state-farm",
    "policyNumber": "123456789",
    "isActive": true,
    "effectiveDate": "2022-10-22T00:00:00.000Z",
    "expirationDate": "2023-10-22T00:00:00.000Z",
    "premium": 999.99,
    "underwriter": {
      "name": "John Doe",
      "naicCode": "12345"
    },
    "address": {
      "addressLine1": "123 Main St.",
      "addressLine2": "Unit 456",
      "city": "Atlanta",
      "state": "Georgia",
      "postalCode": "30315",
      "country": "USA"
    },
    "properties": [
      {
        "id": "prp_tmGUxLpgHjmW9r6M6WjhS",
        "type": "dwelling",
        "data": {
          "addressLine1": "456 Main St.",
          "addressLine2": "Unit 789",
          "city": "Atlanta",
          "state": "Georgia",
          "postalCode": "30315",
          "country": "USA"
        }
      }
    ],
    "coverages": [
      {
        "code": "DW",
        "label": "Dwelling",
        "limitPerAccident": 45000,
        "deductible": 1000
      },
      {
        "code": "OS",
        "label": "Other Structures",
        "limitPerAccident": 100000,
        "deductible": 1000
      },
      {
        "code": "PL",
        "label": "Personal Liability",
        "limitPerAccident": 100000
      },
      {
        "code": "MED",
        "label": "Medical Expenses",
        "limitPerAccident": 50000
      }
    ],
    "exclusions": [
      {
        "code": "WIND",
        "label": "Wind Exclusion"
      }
    ],
    "insureds": [
      {
        "type": "primary",
        "firstName": "John",
        "lastName": "Smith",
        "dateOfBirthYear": "1990",
        "licenseNo": "•••••1234"
      },
      {
        "type": "secondary",
        "firstName": "Jane",
        "lastName": "Doe",
        "dateOfBirthYear": "1992",
        "licenseNo": "•••••5678"
      }
    ],
    "thirdParties": [
      {
        "property": "prp_tmGUxLpgHjmW9r6M6WjhS",
        "type": "lienholder",
        "name": "Super Credit Union",
        "address": {
          "addressLine1": "PO Box 123456",
          "country": null,
          "addressLine2": null,
          "state": "GA",
          "city": "Atlanta",
          "postalCode": "30348"
        }
      }
    ],
    "documents": [
      {
        "id": "doc_jd73dw6fn02sj28.pdf",
        "source": "carrier",
        "name": "Declaration Page",
        "type": ["declaration-page"],
        "url": "<signed-url>",
        "issuedDate": "2022-01-01T00:00:00.000Z",
        "effectiveDate": "2022-01-02T00:00:00.000Z",
        "createdAt": "2022-01-01T00:00:00.000Z"
      }
    ],
    "result": "link",
    "resultDetail": "user-portal-login",
    "createdAt": "2022-01-01T00:00:00.000Z",
    "modifiedAt": "2022-01-01T00:00:00.000Z",
    "refreshedAt": "2022-01-01T00:00:00.000Z"
  }
  ```

  ```json Renters Insurance Policy Object theme={null}
  {
    "id": "pol_j72ndGEnp9bFUIee-oir1",
    "account": "acc_gM2wn_gaqUv76ZjdyF6EB",
    "type": "renters",
    "carrier": "state-farm",
    "policyNumber": "123456789",
    "isActive": true,
    "effectiveDate": "2024-10-22T00:00:00.000Z",
    "expirationDate": "2025-10-22T00:00:00.000Z",
    "premium": 300,
    "underwriter": {
      "name": "John Doe",
      "naicCode": "12345"
    },
    "address": {
      "addressLine1": "123 Main St.",
      "addressLine2": "Unit 456",
      "city": "Atlanta",
      "state": "Georgia",
      "postalCode": "30315",
      "country": "USA"
    },
    "properties": [
      {
        "id": "prp_tmGUxLpgHjmW9r6M6WjhS",
        "type": "dwelling",
        "data": {
          "addressLine1": "456 Main St.",
          "addressLine2": "Unit 789",
          "city": "Atlanta",
          "state": "Georgia",
          "postalCode": "30315",
          "country": "USA"
        }
      }
    ],
    "coverages": [
      {
        "code": "PP",
        "label": "Personal Property",
        "limitPerAccident": 50000,
        "deductible": 1000
      },
      {
        "code": "LOS",
        "label": "Loss of Use",
        "limitPerAccident": 100000,
        "deductible": 1000
      },
      {
        "code": "PL",
        "label": "Personal Liability",
        "limitPerAccident": 500000
      },
      {
        "code": "MED",
        "label": "Medical Expenses",
        "limitPerPerson": 1000
      }
    ],
    "exclusions": [],
    "insureds": [
      {
        "type": "primary",
        "firstName": "John",
        "lastName": "Smith",
        "dateOfBirthYear": "1990",
        "licenseNo": "•••••1234"
      }
    ],
    "thirdParties": [
      {
        "property": "prp_tmGUxLpgHjmW9r6M6WjhS",
        "type": "interest",
        "name": "Super Real Estate, LLC",
        "address": {
          "addressLine1": "PO Box 123456",
          "country": null,
          "addressLine2": null,
          "state": "GA",
          "city": "Atlanta",
          "postalCode": "30348"
        }
      }
    ],
    "documents": [
      {
        "id": "doc_jd73dw6fnsj7dF4.pdf",
        "source": "carrier",
        "name": "Declaration Page",
        "type": ["declaration-page"],
        "url": "<signed-url>",
        "issuedDate": "2024-01-01T00:00:00.000Z",
        "effectiveDate": "2024-01-02T00:00:00.000Z",
        "createdAt": "2024-01-01T00:00:00.000Z"
      }
    ],
    "result": "link",
    "resultDetail": "user-portal-login",
    "createdAt": "2024-01-01T00:00:00.000Z",
    "modifiedAt": "2024-01-01T00:00:00.000Z",
    "refreshedAt": "2024-01-01T00:00:00.000Z"
  }
  ```

  ```json Flood Insurance Policy Object theme={null}
  {
    "id": "pol_9H_ikFzlY1EAMNbAp4Tul",
    "account": "acc_BxcH9RWoGMfnADAt_4DqD",
    "type": "flood",
    "carrier": "allstate",
    "policyNumber": "123456789",
    "isActive": true,
    "effectiveDate": "2025-01-01T00:00:00.000Z",
    "expirationDate": "2026-01-01T00:00:00.000Z",
    "premium": 1173,
    "underwriter": {
      "name": "John Doe",
      "naicCode": "12345"
    },
    "address": {
      "addressLine1": "123 Main St.",
      "addressLine2": "Unit 456",
      "city": "Atlanta",
      "state": "Georgia",
      "postalCode": "30315",
      "country": "USA"
    },
    "properties": [
      {
        "id": "prp_tmGUxLpgHjmW9r6M6WjhS",
        "type": "dwelling",
        "data": {
          "addressLine1": "456 Main St.",
          "addressLine2": "Unit 789",
          "city": "Atlanta",
          "state": "Georgia",
          "postalCode": "30315",
          "country": "USA",
          "ratedFloodZone": "X",
          "replacementCost": 250000
        }
      }
    ],
    "coverages": [
      {
        "code": "DW",
        "label": "Dwelling",
        "deductible": 1250,
        "limitPerAccident": 250000
      },
      {
        "code": "PP",
        "label": "Personal Property",
        "deductible": 1000,
        "limitPerAccident": 100000
      }
    ],
    "exclusions": [],
    "insureds": [
      {
        "type": "primary",
        "firstName": "John",
        "lastName": "Smith",
        "dateOfBirthYear": "1990",
        "licenseNo": "•••••1234"
      },
      {
        "type": "secondary",
        "firstName": "Jane",
        "lastName": "Doe",
        "dateOfBirthYear": "1992",
        "licenseNo": "•••••5678"
      }
    ],
    "thirdParties": [
      {
        "property": "prp_tmGUxLpgHjmW9r6M6WjhS",
        "type": "lienholder",
        "name": "Super Credit Union",
        "address": {
          "addressLine1": "PO Box 123456",
          "country": null,
          "addressLine2": null,
          "state": "GA",
          "city": "Atlanta",
          "postalCode": "30348"
        }
      }
    ],
    "documents": [
      {
        "id": "doc_jd73dw6fn02sj28.pdf",
        "source": "carrier",
        "name": "Declaration Page",
        "type": ["declaration-page"],
        "url": "<signed-url>",
        "issuedDate": "2025-01-01T00:00:00.000Z",
        "effectiveDate": "2025-01-02T00:00:00.000Z",
        "createdAt": "2025-01-01T00:00:00.000Z"
      }
    ],
    "result": "link",
    "resultDetail": "user-portal-login",
    "createdAt": "2025-01-01T00:00:00.000Z",
    "modifiedAt": "2025-01-01T00:00:00.000Z",
    "refreshedAt": "2025-01-01T00:00:00.000Z"
  }
  ```
</RequestExample>


# Trigger Account event
Source: https://docs.axle.insure/api-reference/sandbox/trigger-account-event

POST /sandbox/accounts/{id}/event
The Account event will be sent to the `webhookUri` specified when generating an Ignition token. 

Refer to the [Sandbox](/guides/sandbox/monitoring-notifications) guide for more details.



# Trigger Policy event
Source: https://docs.axle.insure/api-reference/sandbox/trigger-policy-event

POST /sandbox/policies/{policyId}/event
The Policy event will be sent to the `webhookUri` specified when generating an Ignition token. 

Refer to the [Sandbox](/guides/sandbox/monitoring-notifications) guide for more details.



# Descope Token
Source: https://docs.axle.insure/api-reference/tokens/descope-token

POST /token/descope
Reduce scope for a specified access token. For example, de-scoping `monitoring` will disable Axle monitoring and you will no longer receive notifiations on Account or Policy events.

### When to de-scope monitoring on an access token

After de-scoping monitoring for a given access token, you will no longer receive notifications for Account or Policy events related to the insurance account linked to that access token.

How and when you de-scope depends on what you passed in as `user.id` during Start Ignition:

* If you passed a user ID to `user.id`:

  * De-scope the access token when you want to stop receiving notifications for the user’s insurance account across all entities.

  > For example, if a user offboards from your platform entirely, you should de-scope monitoring on their access token to stop tracking their account across all associated trips, loans, or reservations.

  * De-scope an access token if a returning user connects a new insurance account

  > For example, if a user switches insurance carriers, when they link their new insurance account, a new access token will be generated. You should compare the new access token against
  > the one you have stored for the user, and if they differ, the old access token should be de-scoped.

* If you passed an entity ID (e.g. trip, loan number, reservation) to `user.id`:

  * De-scope the access token when the lifetime of that entity is over, and you no longer want to track insurance for it.

  > For example, if the user’s insurance account was linked for a trip and the trip has ended, you should de-scope the access token associated with that trip.

  * De-scope an access token if a returning user links a new insurance account during the lifetime of the entity

  > For example, if a user switches insurance carriers during the lifetime of a tracked loan, when they link their new insurance account, a new access token will be generated. The old
  > access token should be de-scoped so that you stop receiving monitoring notifications for the old account.


# Exchange Token
Source: https://docs.axle.insure/api-reference/tokens/exchange-token

POST /token/exchange
Exchange an authorization code returned by an `ignition.completed` event for an access token. Follow the [Quickstart](/guides/quickstart) or see [Ignition Events](/guides/ignition-events) for more details.

Auth codes are single-use and expire after 10 minutes, while access tokens do not expire.



# Create Template
Source: https://docs.axle.insure/api-reference/validation/templates/create-template

POST /validation/templates
Create a new template for your client.

Refer to the [Policy Validation with Templates](/guides/validate/policy-validation#validation-templates) guide for more details.

⚠️ This endpoint will generate template only for provided `clientId`, and if provided, for `destinationId`. If you are a platform client
and want to create a template for all of your clients, refer to [create platform templates API](/api-reference/platform/create-templates) endpoint



# Get Template
Source: https://docs.axle.insure/api-reference/validation/templates/get-template

GET /validation/templates/{templateId}
The Get Template endpoint returns template object for provided template ID.



# Get Templates
Source: https://docs.axle.insure/api-reference/validation/templates/get-templates

GET /validation/templates
Get a list of all templates for the provided `clientId` or `destinationId`.

Refer to the [Policy Validation with Templates](/guides/validate/policy-validation#validation-templates) guide for more details.



# Update Template
Source: https://docs.axle.insure/api-reference/validation/templates/update-template

POST /validation/templates/{templateId}
The Update Template endpoint updates a Template object. This endpoint will upsert template for provided `clientId` or `destinationId`.



# Validate Policy
Source: https://docs.axle.insure/api-reference/validation/validate-policy

POST /policies/{policyId}/validate
The Validate Policy endpoint returns the result of a evaluating a series of Rules against the requested policy object. For details about each Rule and their return types, see the [Policy Validation Guide](/guides/validate/policy-validation).



# Validate Policy with Template
Source: https://docs.axle.insure/api-reference/validation/validate-policy-template

POST /policies/{policyId}/validate/{templateId}
The Validate Policy with Template endpoint returns the result of a evaluating a template of Rules against the requested policy object.

**Note**: Providing inputs to the Validate Policy with Template endpoint will overwrite any metadata provided via Start Ignition. For more information, see the [Policy Validation with Templates](/guides/validate/policy-validation-with-template) guide.



# Account Events
Source: https://docs.axle.insure/api-reference/webhooks/account-events

openapi.yaml webhook accountEvents
Sent to your `webhookUri` as Axle monitors an insurance account connected through an Ignition session configured with `monitoring` enabled. See [Account Events](/guides/account-events) for more details.



# Ignition Events
Source: https://docs.axle.insure/api-reference/webhooks/ignition-events

openapi.yaml webhook ignitionEvents
Sent to your `webhookUri` (configured on [Start Ignition](/api-reference/ignition/start-ignition)) as the user progresses through an Ignition session. These events also fire for [Proxy Ignition](/api-reference/ignition/proxy-ignition) operations. See [Ignition Events](/guides/ignition-events) for more details.



# Policy Action Events
Source: https://docs.axle.insure/api-reference/webhooks/policy-action-events

openapi.yaml webhook policyActionEvents
Sent to your `webhookUri` at each stage of a [Policy Action](/guides/policy-actions)'s lifecycle: `policy-action.request-initiated` -> `policy-action.request-succeeded` or `policy-action.request-failed` -> (on success) `policy-action.policy-refresh-succeeded` or `policy-action.policy-refresh-failed`.



# Policy Events
Source: https://docs.axle.insure/api-reference/webhooks/policy-events

openapi.yaml webhook policyEvents
Sent to your `webhookUri` as Axle monitors an insurance policy connected through an Ignition session configured with `monitoring` enabled. See [Policy Events](/guides/policy-events) for more details.



# Start Widget
Source: https://docs.axle.insure/api-reference/widgets/start-widget

POST /widgets
Generate a widget session. Returns a widgetToken and widgetUri to display Axle's embeddable widget experience to the user. Currently, `validation` is the only supported widget type.



# Changelog
Source: https://docs.axle.insure/changelog

Latest updates to the Axle API

You can read more about our product releases on our [blog](https://www.axle.insure/blog)!

<Update label="July 29, 2026">
  **Added:**

  * New `resultDetail` value `policy-lookup-summary`, for carriers that only return a policy summary on a policy lookup. `coverages`, `properties`, `documents`, `thirdParties`, and `exclusions` are not retrieved.
  * New Account `connection.status` value `policy-summary-only`, sent with the `account.disconnected` event for these accounts.
  * See [Completion types](/guides/completion-types#resultdetail) and [Account events](/guides/account-events#account-disconnected) for details.
</Update>

<Update label="July 15, 2026">
  **Changed:**

  * Document AI in Ignition now fires an `ignition.attempted` webhook event for document validation errors (empty document, unsupported or illegible document, unsupported document type, or missing required fields) instead of `ignition.errored`.
  * Only unexpected system errors continue to fire `ignition.errored`.
  * More information can be found in the [Ignition events](/guides/ignition-events) guide.
</Update>

<Update label="July 15, 2026">
  **Added:**

  * User portal link sessions now fire an `ignition.attempted` webhook event for user-actionable login failures (such as incorrect credentials, locked account, or MFA enrollment required).
  * Unlike `ignition.errored`, which indicates a system error, `ignition.attempted` reflects an issue with the provided credentials or login state.
</Update>

<Update label="July 9, 2026">
  **Changed:**

  * For the `process-document` Proxy Ignition operation, document validation errors (empty document, download failure, unsupported or illegible document) now fire an `ignition.attempted` webhook event instead of `ignition.errored`.
  * Only unexpected system errors continue to fire `ignition.errored`.
  * More information can be found in the [Proxy Ignition](/guides/proxy-ignition) guide.
</Update>

<Update label="June 29, 2026">
  * Added account.retrying event to Account Monitoring
  * More information can be found [here](/guides/account-events)
</Update>

<Update label="June 18, 2026">
  **Added:**

  * The Axle [Policy](/api-reference/policies/policy) object now includes `exclusions`, or explicit removal of coverage afforded by the policy.
  * See [Exclusions](/api-reference/policies/policy#param-exclusions)
    for details on supported exclusions.
</Update>

<Update label="May 28, 2026">
  **Added:**

  * [Account](/api-reference/accounts/account) and
    [Policy](/api-reference/policies/policy) objects returned by Get Account and
    Get Policy may include **`result`** and **`resultDetail`** fields.
  * **`result`** is an Ignition completion type that describes the high-level
    Policy outcome. **`resultDetail`** identifies the process that describes how
    each Ignition was completed in detail.
  * See [Completion types](/guides/completion-types#result-and-resultdetail-on-policy-and-account-objects)
    for value definitions.
</Update>

<Update label="May 18, 2026">
  **Added:**

  * Added policy.renewal-available event to Policy Monitoring
  * More information can be found [here](/guides/policy-events)
</Update>

<Update label="April 20, 2026">
  **Added:** - Introduced into Policy APIs new query parameter `term` with 2
  options: `renewal` and `current`. - More information can be found
  [here](/api-reference/policies/get-policy#parameter-term)
</Update>

<Update label="October 27, 2025">
  **Removed:** - Passing in an access token to [Start
  Ignition](/api-reference/ignition/start-ignition) in a Sandbox environment now
  results in a 400 error. - This will be fully deprecated in production starting
  December 01, 2025.
</Update>

<Update label="September 29, 2025">
  **Deprecated:** - The Axle team has deprecated passing in an access token to
  [Start Ignition](/api-reference/ignition/start-ignition). No immediate changes
  are required if you use this feature, but it will no longer have the effect of
  disabling monitoring on the access token. - To disable monitoring for a given
  access token, check out our [Descope
  Token](/api-reference/tokens/descope-token) API.
</Update>

<Update label="August 27, 2025">
  **Added:** - You can now complete Ignition sessions on behalf of users, via
  Axle's Proxy operations. - To learn more, check out our [Proxy
  Ignition](/guides/proxy-ignition) guide.
</Update>

<Update label="July 3, 2025">
  **Added:** - You can now test Axle's integrations with renters (HO-4) policies
  in the Axle Sandbox. - To learn more, check out our [Testing
  Ignition](/guides/sandbox/ignition-completion) guide.
</Update>

<Update label="June 20, 2025">
  **Added:** - You can now access the `third-party-match` rule via Policy
  Validation. - To learn more, check out our [Policy
  Validation](/guides/policy-validation) guide.
</Update>

<Update label="June 18, 2025">
  **Changed:**

  * When testing in the Axle Sandbox, the custom `metadata` object provided when generating a new Ignition session must NOT contain any nested keys. This is to ensure current visualization in the Axle Policy Report, easy search and filtering, and correct Validation Template processing.

  ```json theme={null}
  // Supported
  { "key": "value" } 

  // NOT supported
  { "key": { "key": "value" } }
  ```

  * You can view more details about the `metadata` field in the [Start Ignition](/api-reference/ignition/start-ignition) reference.
  * Before this change is reflected in the production environment, the Axle team will communicate via direct channels to all impacted clients.
</Update>

<Update label="June 13, 2025">
  **Added:** - You can now access the `vehicle-use-meets-requirements` rule via
  Policy Validation. - To learn more, check out our [Policy
  Validation](/guides/policy-validation) guide.
</Update>

<Update label="May 6, 2025">
  **Changed:** - When exchanging a token, 401 and 403 error states now include
  more detailed messaging on why an `authCode` cannot be exchanged for an
  `accessToken`. - You can view more details about these error states in the
  [Exchange Token](/api-reference/tokens/exchange-token) reference.
</Update>

<Update label="April 22, 2025">
  **Added:** - You can now access the following rules via Policy Validation. -
  `bodily-injury-coverage-meets-requirements` -
  `property-damage-coverage-meets-requirements` -
  `uninsured-underinsured-bi-coverage-meets-requirements` -
  `uninsured-underinsured-pd-coverage-meets-requirements` - To learn more, check
  out our [Policy Validation](/guides/policy-validation) guide.
</Update>

<Update label="April 15, 2025">
  **Added:** - For supported carriers, you can now test Ignition completions
  through Axle Policy Lookup in the Axle Sandbox. - To learn more, check out our
  [Testing
  Ignition](guides/sandbox-ignition-completion#using-test-inputs-to-complete-policy-lookup)
  guide.
</Update>

<Update label="April 10, 2025">
  **Added:** - You can now access the `properties-match` rule via Policy
  Validation. - To learn more, check out our [Policy
  Validation](/guides/policy-validation) guide.
</Update>

<Update label="April 7, 2025">
  **Added:** - The Axle Policy object now includes the use of a `type: vehicle`
  property when available. - To learn more, check out our detailed
  [Policy](/api-reference/policies/policy) guide.
</Update>

<Update label="February 18, 2025">
  **Changed:** - When testing in the Axle Sandbox, it is now required to specify
  in `user.id` when generating a new Ignition session, as it is used for metrics
  & reporting, search, and an easier integration with less storage of data. -
  You can view more details about the `user` field in the [Start
  Ignition](/api-reference/ignition/start-ignition) reference. - Before this
  change is reflected in the production environment, the Axle team will
  communicate via direct channels to all impacted clients.
</Update>

<Update label="January 21, 2025">
  **Added:** - You can now access the following rules via Policy Validation. -
  `insureds-match` - `collision-coverage-meets-requirements` -
  `comprehensive-coverage-meets-requirements` - To learn more, check out our
  [Policy Validation](/guides/policy-validation) guide.
</Update>

<Update label="December 20, 2024">
  **Added:** - You can now access the `expiration-date-comparison` rule via
  Policy Validation. - To learn more, check out our [Policy
  Validation](/guides/policy-validation) guide.
</Update>

<Update label="October 2, 2024">
  **Added:** - You can now specify a custom webhook header to be sent on all
  webhook events. - Please contact the Axle team if you would like to configure
  these for your Axle client.
</Update>

<Update label="October 9, 2023">
  **Added:** - The Axle team is rolling out support for platform partners, who
  can now scalably offer Axle's insurance verification services to their
  customers. - Platforms can manage their customers' Axle integrations via the
  new destination clients feature. This includes the ability to create
  destination clients and call other Axle APIs on their behalf. - To learn more,
  check out the new [Axle for Platforms](/guides/platform-integration) guide.
</Update>

<Update label="May 24, 2023">
  **Fixed:**

  * Individual fields now support `null` type in Account and Policy response objects to improve data transparency and actionability
    * Individual fields will return `null` values when:
      * The carrier data source supports the field, but no information is present for the selected Account or Policy.
      * The carrier data source does not support that field.
    * Optional fields, such as `Policy.coverages["BI"].property` or `Policy.coverages["UMPD"].deductible` may return `null` or `undefined`
      * `null` - The carrier data source supports the field, but no information is present for the selected Account or Policy.
      * `undefined` - The carrier data source supports the field and data is available that specifies that the field does not exist on the Account or Policy.
        Example Policy:

  ```json theme={null}
  {
  	"...",
  	"policyNumber": "123456789",
  	"isActive": true,
  	"effectiveDate": null,
  	"expirationDate": "2023-10-22T04:00:00.000Z",
  	"address": {
  		"addressLine1": "123 Main St.",
  		"addressLine2": null,
  		"city": "New York",
  		"state": "NY",
  		"postalCode": "10014",
  		"country": "US",
  	},
  	"coverages": [
  		{
  			"code": "PD",
  			"label": "Property Damage",
  			"limitPerAccident": null, // No information was available from carrier data source
  			"deductible": undefined, // The carrier data source specifies that here is no deductible present for this coverage
  			"property": "prp_83sD63h82bbeu2Dgn"
  		},
  		"..."
  	],
  	"..."
  }
  ```
</Update>


# Account events
Source: https://docs.axle.insure/guides/account-events

This guide will walk you through the various Account events that may occur when monitoring an insurance account.

Once an insurance account is connected through an Ignition session, Axle can monitor that account for updates. These updates will trigger events that are sent from Axle to your systems via webhook or to your organization via communication channels such as email.

<Info>
  Account events are only sent for insurance accounts connected through Axle
  Ignition sessions that are configured with `monitoring` enabled. Please
  contact the Axle team if you would like to enable this feature!
</Info>

## Webhooks

<Tip>
  You must specify a `webhookUri` when generating an Ignition token to receive
  webhook events. See [Start Ignition](/api-reference/ignition/start-ignition)
  for more details.

  Custom webhook headers can be configured to support uses cases like
  authentication. Please contact the Axle team if you would like to configure
  custom webhook headers!
</Tip>

A `POST` request will be sent to the `webhookUri` with the following payload. All events will include `client`, `ref` (Account object identifier), `user` (optionally specified when generating Ignition token), and `metadata` (optionally specified when generating Ignition token).

```json Example webhook payload theme={null}
{
  "id": "<event_id>",
  "type": "account.modified",
  "data": {
    "client": "<client-id>",
    "ref": "acc_Z4ni-JHBvkn9PlKJHPEwk",
    "user": {},
    "metadata": {},
    ...{ parameters }
  },
  "createdAt": "2022-10-05T14:48:00.000Z"
}
```

### account.modified

This event type indicates details on the Account changed. Refer to [Account](/api-reference/accounts/account) for more details on the fields that can be modified.

### account.retrying

This event type indicates that the Account `connection.status` changed from "active" to "retrying", meaning that Axle is trying to re-establish an active connection to the insurance carrier. If connection isn't re-established after multiple attempts, Axle will disconnect the account.

### account.disconnected

This event type indicates the Account `connection.status` is no longer "active" or "retrying", meaning Axle is no longer able to monitor the policies present on the account.

```json Additional data parameters (example) theme={null}
{
  "status": "credentials-expired | mfa-expired | account-disabled | account-inaccessible | lienholder-required | comp-coll-required | policy-summary-only"
}
```

<Card title="credentials-expired">
  <Tabs>
    <Tab title="Common causes">
      For an account with `resultDetail = user-portal-login`, the user has changed their login credentials or their insurance account
      requires a periodic update of their login credentials.

      For an account with `resultDetail = policy-lookup`, the policy number or vin provided for lookup are no longer valid.
    </Tab>

    <Tab title="Recommended messaging">
      Your insurance account cannot be access by Axle due to expired or changed
      credentials. Please complete Axle via \[Ignition URI] to reconnect your
      account.
    </Tab>
  </Tabs>
</Card>

<Card title="mfa-expired">
  <Tabs>
    <Tab title="Common causes">
      The user's insurance account is has re-triggered multi-factor
      authentication, requiring additional authentication for Axle to regain
      access.
    </Tab>

    <Tab title="Recommended messaging">
      Your insurance account requires additional multi-factor authentication
      (MFA). Please complete Axle via \[Ignition URI] to reconnect your account.
    </Tab>
  </Tabs>
</Card>

<Card title="account-disabled">
  <Tabs>
    <Tab title="Common causes">
      The user's insurance account has been disabled due to inactivity, or it
      requires additional steps to be set up for access (e.g. completing
      registration).
    </Tab>

    <Tab title="Recommended messaging">
      Your insurance account is no longer available. Please complete Axle via
      \[Ignition URI] after re-enabling your account or to connect a different
      account.
    </Tab>
  </Tabs>
</Card>

<Card title="account-inaccessible">
  <Tabs>
    <Tab title="Common causes">
      The user's insurance account unexpectedly cannot be accessed by Axle,
      despite multiple attempts to reach the insurance carrier. The Axle team
      has been notified and will immediately escalate for resolution. It is
      recommended to reach out to the user to reconnect their account.
    </Tab>

    <Tab title="Recommended messaging">
      Your insurance account can no longer be accessed by Axle. Please retry
      connecting your account through Axle via \[Ignition URI].
    </Tab>
  </Tabs>
</Card>

<Card title="lienholder-required">
  <Tabs>
    <Tab title="Common causes">
      The user's insurance account is missing a lienholder, and the carrier is limiting
      data access as a result.

      <Info>
        This event type is only applicable for accounts with `resultDetail =
                        policy-lookup`.
      </Info>
    </Tab>

    <Tab title="Recommended messaging">
      Your insurance account can no longer be accessed by Axle because it is missing a lienholder. Please
      add a lienholder and retry connecting your account through Axle via \[Ignition URI].
    </Tab>
  </Tabs>
</Card>

<Card title="comp-coll-required">
  <Tabs>
    <Tab title="Common causes">
      The user's insurance account is missing comprehensive or collision coverages, and
      the carrier is limiting data access as a result.

      <Info>
        This event type is only applicable for accounts with `resultDetail =
                        policy-lookup`.
      </Info>
    </Tab>

    <Tab title="Recommended messaging">
      Your insurance account can no longer be accessed by Axle because it is missing comprehensive or collision coverage. Please
      add the appropriate coverage and retry connecting your account through Axle via \[Ignition URI].
    </Tab>
  </Tabs>
</Card>

<Card title="policy-summary-only">
  <Tabs>
    <Tab title="Common causes">
      The insurance carrier only shares a policy summary for this account, so Axle can't monitor the
      full policy details (`coverages`, `properties`, `documents`, `thirdParties`, and `exclusions`).

      <Info>
        This event type is only applicable for accounts with `resultDetail =
                        policy-lookup-summary`.
      </Info>
    </Tab>

    <Tab title="Recommended messaging">
      Your insurance carrier only shares a summary of your policy, so we can't keep your coverage
      details up to date. Please reconnect your account through Axle via \[Ignition URI] using
      another verification method.
    </Tab>
  </Tabs>
</Card>


# Results
Source: https://docs.axle.insure/guides/completion-types

Understanding the different completion results of an Axle Ignition session.

## Result outcomes

<Columns>
  <Card title="Link (primary)" icon="link">
    A link completion occurs when a user completes Ignition by sharing their policy from a verified data source.

    Typically, this means
    the user has connected their insurance carrier account and Axle has pulled the policy data directly from the insurance carrier, but can also include other methods of direct data access to the insurance carrier.
  </Card>

  <Card title="Manual (backup)" icon="page">
    A manual completion occurs when the user submits their own data, either by uploading documents or entering insurance information directly.

    This can occur when a user cannot connect to their insurance account or the insurance carrier is not supported by Axle.
  </Card>
</Columns>

<Warning>
  **Disabling manual completions**

  Almost all applications choose to enable manual completion to provide a single source of data collection for all of their users.

  It is only recommended to disabling manual if you already require all insurance data to be 100% verified from the insurance carrier (e.g., by phone call) or you are confident that you have no use for user-submitted policy documents.
</Warning>

## Manual configuration choices

<Info>
  The Axle Team can set up Ignition templates to overwrite the default configuration that is set per client.

  To apply one, pass the template in the [Start Ignition](/api-reference/ignition/start-ignition) request body. The template scopes to that single Ignition session. Contact the Axle team to set up a template.
</Info>

There are a few options that can be enabled for manual completions:

1. **Document AI**: The user uploads documents, and then [Axle's Document AI](https://www.axle.insure/product/document-ai) extracts the policy details from the document automatically. Document AI supports the following document types:

   * **ID Cards** typically contain the core policy details, but omit detailed policy information such as coverages and third parties.
   * **Declarations Pages** (which include new business documents, renewal declarations, etc.) typically contain the full policy details, but users may not be familiar with where to locate this document and may need to be guided to their insurance account or an email from their insurance agent.

   It is recommended to enable both ID Cards and Declarations Pages to provide the best experience for your users. However, if your use case absolutely requires coverages and third parties, you can contact the Axle team to only accept Declarations Pages.

   <Info>
     **Document AI Push-through**: After multiple attempts, if we are still
     unable to extract data from the user's uploaded document and unable to
     process it, Axle will use the Document AI push-through flow. The original
     source file is accepted as uploaded. The policy will be created with
     carrier set to "Other" and minimal or no data fields. See the [sandbox
     testing guide](/guides/sandbox/ignition-completion) for details on how to
     test this flow.
   </Info>

2. **Policy Form**: The user manually fills out a short form with key policy details and uploads any necessary documents. This option should only be used when collecting documents that are NOT yet supported by Axle's Document AI (e.g., external rental waivers, commercial documents, non-US insurance carriers).

3. **Credit Card Policy Form**: The user enters information to help locate their credit card-based rental car coverage. This should only be enabled for rental car operators.

<Warning>
  **Document AI callouts**

  **Carrier names are not standardized** — The Axle Policy `carrier` field will not standardize to Axle's [insurance carrier enums](/api-reference/carriers/get-carriers). Instead, the Axle Policy will include the insurance carrier name as it appears on the document (for example `"carrier": "State Farm Indemnity"` instead of `"carrier": "state-farm"`).

  **Missing data returns null or empty values** — If data is not present on the document, the Axle Policy will return a `null` value or empty array for the corresponding field. For example, if the expiration date is not listed on the document, the Policy will include `"expirationDate": null`. If the document does not have a section for third parties (lienholders, mortgagees, additional interests, etc.), the Policy will include `"thirdParties": []`.
</Warning>

## How each manual completion type impacts the Policy object

The fields available on an Axle [Policy](/api-reference/policies/policy) object depend on how the Ignition session was completed. The following sections detail which fields are typically available (or missing) for each manual completion type.

<AccordionGroup>
  <Accordion title="Document AI — ID Card">
    ID cards provide core policy details but **do not** include coverages, third parties, or premium information.

    **Fields typically available:**

    * `carrier`
    * `policyNumber`
    * `isActive`
    * `effectiveDate`
    * `expirationDate`
    * `address`
    * `properties`
    * `insureds`
    * `documents`

    **Fields typically missing (null or empty):**

    * `premium`
    * `coverages`
    * `thirdParties`

    ```json Example Policy theme={null}
    {
      "id": "pol_EkS8nGWnp4bGAFCC-xyz1",
      "account": "acc_hN3xo_hbrVw87AmkfWYPw",
      "type": "auto",
      "carrier": "State Farm Indemnity",
      "policyNumber": "987654321",
      "isActive": null,
      "effectiveDate": "2025-01-15T00:00:00.000Z",
      "expirationDate": "2025-07-15T00:00:00.000Z",
      "premium": null,
      "address": {
        "addressLine1": null,
        "addressLine2": null,
        "city": null,
        "state": "Georgia",
        "postalCode": null,
        "country": "USA"
      },
      "properties": [
        {
          "id": "prp_aBcDeFgHiJkLmNoPq",
          "type": "vehicle",
          "data": {
            "bodyStyle": null,
            "vin": "1HGCM82633A004352",
            "model": "Accord",
            "year": "2020",
            "make": "Honda",
            "use": null
          }
        }
      ],
      "coverages": [],
      "insureds": [
        {
          "type": null,
          "firstName": "John",
          "lastName": "Smith"
        }
      ],
      "thirdParties": [],
      "documents": [
        {
          "id": "doc_abc123def456.png",
          "source": "user",
          "name": "ID Card",
          "type": ["id-card"],
          "url": "<signed-url>",
          "issuedDate": null,
          "effectiveDate": null,
          "createdAt": "2025-01-20T00:00:00.000Z"
        }
      ],
      "createdAt": "2025-01-20T00:00:00.000Z",
      "modifiedAt": "2025-01-20T00:00:00.000Z",
      "refreshedAt": "2025-01-20T00:00:00.000Z"
    }
    ```
  </Accordion>

  <Accordion title="Document AI — Declarations Page">
    Declarations pages typically provide the most complete policy data of all manual completion types. Most fields will be populated, though availability depends on the specific document.

    **Fields typically available:**

    * `carrier`
    * `policyNumber`
    * `isActive`
    * `effectiveDate`
    * `expirationDate`
    * `premium`
    * `address`
    * `properties`
    * `coverages`
    * `insureds`
    * `thirdParties`
    * `documents`

    **Fields typically missing (null or empty):**

    * Varies by document — some may omit `thirdParties` or specific insured details like `dateOfBirthYear` and `licenseNo`

    ```json Example Policy theme={null}
    {
      "id": "pol_FjT9oHXop5cHBGDD-abc2",
      "account": "acc_iO4yp_icsWx98BnlgXZQx",
      "type": "auto",
      "carrier": "GEICO Casualty Company",
      "policyNumber": "4461832059",
      "isActive": null,
      "effectiveDate": "2025-03-01T00:00:00.000Z",
      "expirationDate": "2025-09-01T00:00:00.000Z",
      "premium": 1250,
      "address": {
        "addressLine1": "456 Oak Ave.",
        "addressLine2": null,
        "city": "Dallas",
        "state": "Texas",
        "postalCode": "75201",
        "country": "USA"
      },
      "properties": [
        {
          "id": "prp_rStUvWxYzAbCdEfGh",
          "type": "vehicle",
          "data": {
            "bodyStyle": "SUV",
            "vin": "WDDWJ8EB4KF000000",
            "model": "Model S",
            "year": "2022",
            "make": "Tesla",
            "use": null
          }
        }
      ],
      "coverages": [
        {
          "code": "BI",
          "label": "Bodily Injury",
          "limitPerPerson": 100000,
          "limitPerAccident": 300000
        },
        {
          "code": "PD",
          "label": "Property Damage",
          "limitPerAccident": 50000
        },
        {
          "code": "COMP",
          "label": "Comprehensive",
          "deductible": 500,
          "property": "prp_rStUvWxYzAbCdEfGh"
        },
        {
          "code": "COLL",
          "label": "Collision",
          "deductible": 500,
          "property": "prp_rStUvWxYzAbCdEfGh"
        }
      ],
      "insureds": [
        {
          "type": null,
          "firstName": "Jane",
          "lastName": "Doe"
        }
      ],
      "thirdParties": [
        {
          "property": "prp_rStUvWxYzAbCdEfGh",
          "type": "lienholder",
          "name": "Super Lending Trust",
          "address": {
            "addressLine1": "PO Box 71083",
            "addressLine2": null,
            "city": "Charlotte",
            "state": "NC",
            "postalCode": "28272",
            "country": null
          }
        }
      ],
      "documents": [
        {
          "id": "doc_ghi789jkl012.pdf",
          "source": "user",
          "name": "Declaration Page",
          "type": ["declaration-page"],
          "url": "<signed-url>",
          "issuedDate": null,
          "effectiveDate": null,
          "createdAt": "2025-03-05T00:00:00.000Z"
        }
      ],
      "createdAt": "2025-03-05T00:00:00.000Z",
      "modifiedAt": "2025-03-05T00:00:00.000Z",
      "refreshedAt": "2025-03-05T00:00:00.000Z"
    }
    ```
  </Accordion>

  <Accordion title="Document AI — Push-through">
    When Document AI is unable to extract data after multiple attempts, Axle falls back to the Document AI push-through flow. The original source file is accepted, and the Policy is created with minimal data.

    <Warning>
      All structured policy fields will be missing. The Policy will only contain the
      uploaded document and a carrier value of `"Other"`.
    </Warning>

    **Fields typically available:**

    * `carrier` (set to `"Other"`)
    * `documents`

    **Fields typically missing (null or empty):**

    * `policyNumber`
    * `isActive` (undefined)
    * `effectiveDate`
    * `expirationDate`
    * `premium`
    * `address`
    * `properties`
    * `coverages`
    * `insureds`
    * `thirdParties`

    ```json Example Policy theme={null}
    {
      "id": "pol_ImW2rKArS8fKEJGG-jkl5",
      "account": "acc_lR7bs_lfvZA21EqniACTa",
      "type": "auto",
      "carrier": "Other",
      "policyNumber": null,
      "effectiveDate": null,
      "expirationDate": null,
      "premium": null,
      "address": null,
      "properties": [],
      "coverages": [],
      "insureds": [],
      "thirdParties": [],
      "documents": [
        {
          "id": "doc_xyz567abc890.png",
          "source": "user",
          "name": "User Uploaded Document",
          "type": ["declaration-page"],
          "url": "<signed-url>",
          "issuedDate": null,
          "effectiveDate": null,
          "createdAt": "2025-05-01T00:00:00.000Z"
        }
      ],
      "createdAt": "2025-05-01T00:00:00.000Z",
      "modifiedAt": "2025-05-01T00:00:00.000Z",
      "refreshedAt": "2025-05-01T00:00:00.000Z"
    }
    ```
  </Accordion>

  <Accordion title="Policy Form">
    When a user fills out the policy form manually, only the fields entered by the user will be present. Most detailed policy fields will be missing.

    **Fields typically available:**

    * `carrier`
    * `policyNumber`
    * `effectiveDate`
    * `expirationDate`
    * `documents`

    **Fields typically missing (null or empty):**

    * `isActive` (undefined)
    * `premium`
    * `address`
    * `properties`
    * `coverages`
    * `insureds`
    * `thirdParties`

    ```json Example Policy theme={null}
    {
      "id": "pol_GkU0pIYpq6dICHEE-def3",
      "account": "acc_jP5zq_jdtXy09ColgYARy",
      "type": "auto",
      "carrier": "Other",
      "policyNumber": "POL-2025-1234",
      "effectiveDate": "2025-02-01T00:00:00.000Z",
      "expirationDate": "2025-08-01T00:00:00.000Z",
      "premium": null,
      "address": null,
      "properties": [],
      "coverages": [],
      "insureds": [],
      "thirdParties": [],
      "documents": [
        {
          "id": "doc_mno345pqr678.pdf",
          "source": "user",
          "name": "User Uploaded Document",
          "type": ["declaration-page"],
          "url": "<signed-url>",
          "issuedDate": null,
          "effectiveDate": null,
          "createdAt": "2025-02-10T00:00:00.000Z"
        }
      ],
      "createdAt": "2025-02-10T00:00:00.000Z",
      "modifiedAt": "2025-02-10T00:00:00.000Z",
      "refreshedAt": "2025-02-10T00:00:00.000Z"
    }
    ```
  </Accordion>

  <Accordion title="Credit Card Policy Form">
    Credit card policies contain very limited data since the user is providing credit card-based rental car coverage information. Nearly every standard policy field will be missing.

    **Fields typically available:**

    * `carrier`
    * `documents`

    **Fields typically missing (null or empty):**

    * `policyNumber`
    * `isActive` (undefined)
    * `effectiveDate`
    * `expirationDate`
    * `premium`
    * `address`
    * `properties`
    * `coverages`
    * `insureds`
    * `thirdParties`

    ```json Example Policy theme={null}
    {
      "id": "pol_HlV1qJZqr7eJDIFF-ghi4",
      "account": "acc_kQ6ar_keuYz10DpmhZBSz",
      "type": "auto",
      "carrier": "Other",
      "policyNumber": null,
      "effectiveDate": null,
      "expirationDate": null,
      "premium": null,
      "address": null,
      "properties": [],
      "coverages": [],
      "insureds": [],
      "thirdParties": [],
      "documents": [
        {
          "id": "doc_stu901uvw234.pdf",
          "source": "user",
          "name": "Credit Card Policy Document",
          "type": ["declaration-page"],
          "url": "<signed-url>",
          "issuedDate": null,
          "effectiveDate": null,
          "createdAt": "2025-04-01T00:00:00.000Z"
        }
      ],
      "createdAt": "2025-04-01T00:00:00.000Z",
      "modifiedAt": "2025-04-01T00:00:00.000Z",
      "refreshedAt": "2025-04-01T00:00:00.000Z"
    }
    ```
  </Accordion>
</AccordionGroup>

## `result` and `resultDetail` on Policy and Account objects

Every [Policy](/api-reference/policies/policy) and [Account](/api-reference/accounts/account) objects contain fields that indicate how insurance information was obtained for each Axle entity. **`result`** appears on Policy only and is an Ignition completion type that describes the high-level Policy outcome. **`resultDetail`** appears on both Policy and Account and identifies the process that describes how each Ignition was completed in detail.

### `result`

Ignition completion type that describes the high-level Policy outcome.

| Value    | Description                                                                                 |
| -------- | ------------------------------------------------------------------------------------------- |
| `basic`  | Policy data was retrieved from a basic carrier integration.                                 |
| `link`   | Policy data was retrieved directly from the carrier portal.                                 |
| `manual` | Policy data was obtained from user-submitted files and information.                         |
| `proxy`  | Policy data was obtained from a completed [Proxy Ignition](/guides/proxy-ignition) session. |

### `resultDetail`

Identifies the process that describes how each Ignition was completed in detail.

| Value                           | Description                                                                                                                                                                             |
| ------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `basic`                         | A simplified carrier flow was used to access policy data.                                                                                                                               |
| `credit-card-form`              | The end user entered information to help locate their credit card-based rental car coverage.                                                                                            |
| `document-ai-declarations-page` | Document AI extracted policy data from an uploaded declarations page, which typically contains the full policy details.                                                                 |
| `document-ai-id-card`           | Document AI extracted policy data from an uploaded ID card, which typically contains the core policy details but omits detailed policy information such as coverages and third parties. |
| `document-ai-push-through`      | Document AI was unable to extract insurance data after multiple attempts, so the original source file was accepted as is, and the Policy object was created with minimal data.          |
| `manual-form`                   | The end user manually filled out a short form with key policy details and uploaded additional necessary documents.                                                                      |
| `policy-lookup`                 | A search using policy number and other policy details (VIN, postal code, etc.) was used to retrieve policy data.                                                                        |
| `policy-lookup-no-comp-coll`    | Same as `policy-lookup`, except no comprehensive or collision coverages exist for this policy, so limited data was retrieved.                                                           |
| `policy-lookup-no-lienholder`   | `policy-lookup` completed with no lienholder on the policy or the requesting client was not the lienholder on file, so limited data was retrieved.                                      |
| `policy-lookup-summary`         | Same as `policy-lookup`, except the carrier only returns a policy summary, so `coverages`, `properties`, `documents`, `thirdParties`, and `exclusions` were not retrieved.              |
| `user-portal-login`             | A user signed in through the carrier user portal to retrieve carrier-sourced policy data.                                                                                               |


# Events
Source: https://docs.axle.insure/guides/ignition-events

This guide will walk you through the various events that occur during an Ignition session.

Axle’s Ignition session is the main interface that allows your users to connect to their insurance accounts and authorize access to scoped data from their insurance policies.

Please first review the [Quickstart](/guides/quickstart) guide and API docs on how to start an Ignition session, if you have not already.

## Configure an Ignition session for event handling

Your `POST` request to `/ignition` can include the following request
body:

* `redirectUri` (optional) - the URL Axle Ignition will redirect the user to upon completion, exit, or error outcomes of the Ignition session, defaults to no redirect
* `webhookUri` (optional) - the URL Axle will send events to as the user proceeds through the Ignition session, defaults to no webhook events
* `user` (required) - user to attach. Please refer to [startIgnition](/api-reference/ignition/start-ignition) for more details.
* `metadata` (optional) - optional Ignition session metadata, please refer to [startIgnition](/api-reference/ignition/start-ignition) for more details

```bash Request Sample theme={null}
curl --request POST \
  --url https://api.axle.insure/ignition \
  --header 'Content-Type: application/json' \
  --header 'x-client-id: cli_mZj6YGXhQyQnccN97aXbq' \
  --header 'x-client-secret: RZM-5BErZuChKqycbCS1O' \
  --data '{
  "redirectUri": "https://example.com/insurance/redirect",
  "webhookUri": "https://example.com/insurance/webhook",
  "user": {"id": "usr_123456789"}
  }'
```

<Note>
  You can also receive Ignition status updates through the browser Window
  interface. This is most useful when initializing an Ignition session in an
  `iframe` element in your application.

  If you would like to receive
  `MessageEvent` messages to your main application Window from Ignition, you must specify an `origin`
  as a URL parameter when initalizing Ignition. The origin should not include any path, just the base domain as a URI.

  Example: `https://ignition.axle.insure/?origin=http://example.com`
</Note>

## Redirect and Window MessageEvent parameters

On Ignition status change, the following parameters will be shared via URL to the `redirectUri` provided and in the Window `MessageEvent`.

`status`: String

* complete
* exit
* error

**Additional parameters** *(dependent on status, see below)*

* `authCode`: String - authorization code that can be exchange for accessToken for scoped access to connected account and/or policy
* `client`: String - the client ID associated with the session. This is primarily useful for platforms who have multiple clients. See the [Axle for Platforms](/guides/platform-integration) guide for more information about platforms.
* `result`: String - "link" (direct carrier connection was made and policy is available) OR "manual" (policy details were collected via document or form) OR "proxy" (operation was completed on behalf of user)
* `step`: String - the step where the Ignition session was exited
* `message`: String - additional information about the Ignition session error

```text Redirect sample URL theme={null}
  https://example.com/insurance/redirect?status=complete&authCode=cod_LwPJhgxnjinMEPfGYc-XV&client=cli_mZj6YGXhQyQnccN97aXbq&result=link
```

### onComplete

When the user successfully connects to their carrier account and shares authorized access to a selected policy, OR when the user submits their policy information and/or documentation through Axle's manual collection form.

```json theme={null}
{
  "status": "complete",
  "authCode": "<authCode>",
  "client": "<client-id>",
  "result": "link" || "manual" || "proxy"
}
```

### onExit

When the user opts out of connecting to their carrier account and/or selecting a policy, OR when the user opts out of sharing the requested policy information and/or documentation.

```json theme={null}
{
  "status": "exit",
  "step": "<step-name>",
  "client": "<client-id>"
}
```

### onError

When Axle is unable to retrieve account or policy information from a selected carrier, OR when Axle is unable to collect policy information and/or documentation from the user.

```json theme={null}
{
  "status": "error",
  "message": "<message-body>",
  "client": "<client-id>"
}
```

<Warning>
  Never send requests from your client to the Axle API. The client should only
  be used to handle Ignition status through redirect or Window MessageEvent.
</Warning>

## Webhooks

If an optional `webhookUri` is provided, a `POST` request will be sent to the `webhookUri` with the following payload. The individual parameters included within `data` are the same as those listed above for the corresponding status, with the addition of `user` and `metadata` shared via the Ignition request body:

```json Example webhook payload theme={null}
{
  "id": "<event_id>",
  "type": "ignition.completed",
  "data": {
    "client": "<client-id>",
    "token": "ign_Z4ni-JHBvkn9PlKJHPEwk",
    ...{ parameters }
  },
  "createdAt": "2022-10-05T14:48:00.000Z"
}
```

| Type               | Data                                                                                                |
| ------------------ | --------------------------------------------------------------------------------------------------- |
| ignition.created   | client : String, token : String, user: Object, metadata: Object                                     |
| ignition.completed | client : String, token : String, user: Object, metadata: Object, authCode : String, result : String |
| ignition.opened    | client : String, token : String, user: Object, metadata: Object                                     |
| ignition.exited    | client : String, token : String, user: Object, metadata: Object, step : String                      |
| ignition.errored   | client : String, token : String, user: Object, metadata: Object, message : String                   |

<Note>
  Custom webhook headers can be configured to support uses cases like
  authentication. Please contact the Axle team if you would like to configure
  custom webhook headers!
</Note>


# Initialize
Source: https://docs.axle.insure/guides/initialize-ignition

This guide will help you understand how to display Axle's Ignition session to your users.

Once you have generated an Ignition token, you can guide the user to complete Axle's Ignition session for the user to share their insurance information.

<Tip>
  Using a clear call to action alongside a description of why you are requesting
  a user's insurance information will increase the open rate of Ignition. It is
  also recommended to include a link to Axle's
  [consumers](https://www.axle.insure/consumers) page in case your users have
  additional questions. Reach out to the Axle team for any guidance on how to
  design the best experience. We would love to help!
</Tip>

### Open Ignition in new window

<Steps>
  <Step title="Open Ignition in new window">
    Add link to the the constructed `ignitionUri` using an anchor tag or
    other mechanism.

    ```HTML theme={null}
    <a
      href="https://ignition.axle.insure/?token={ignitionToken}"
      target="_blank"
    >
      Share your insurance via Axle
    </a>
    ```
  </Step>

  <Step title="Process Ignition completion">Once a user completes the Ignition session, capture the `authCode` by either handling the parameters after Ignition redirects back to your application using the specified `redirectUri` or processing the `ignition.completed` webhook event.</Step>
</Steps>

<Tip>
  This method is best used for **asynchronous** user interactions such as via
  email, SMS, push notification, etc. that do not require immediate user action
  after insurance verification.
</Tip>

### Web: Display Ignition in iframe

<Steps>
  <Step title="Open iframe">
    Initialize the constructed `ignitionUri` within an iframe modal.

    <Note>
      If you would like to receive `MessageEvent` messages to your main application Window from Ignition, you must specify an `origin` as a URL parameter when initalizing Ignition. The origin should not include any path, just the base domain as a URI.

      Example: `https://ignition.axle.insure/?origin=http://example.com`
    </Note>

    <Tip>
      Axle recommends setting up an iframe in your application's client that is full viewport width and height, as Ignition is optimized for responsiveness across all viewports.

      For the best experience, you can set the background color and opacity (allowing a peek at your application's views or components) of Ignition. Contact the Axle team to enable this configuration!
    </Tip>
  </Step>

  <Step title="Listen for MessageEvent">Implement `window.addEventListener` to listen for Window `MessageEvent`. For added security, verify the origin of the message is the Axle Ignition base domain (e.g., `https://ignition.axle.insure`)</Step>

  <Step title="Process Ignition event">
    Process each Ignition event in your application's client. For example, when a user completes Ignition, process the event with `status=complete` by sending the `authCode` to your application's protected
    services to be exchanged for an `accessToken`.
  </Step>
</Steps>

```HTML Page with iframe and eventListener (example) theme={null}
<html>
  <head>
    <script>
      window.addEventListener("message", (message) => {
        if (event.origin === "https://ignition.axle.insure") {
          switch (message.data.status) {
            case "complete":
              console.log("Received completed message from Axle Ignition...", message.data);
              onCompleted(message.data.authCode);
              break;
            case "exit":
              console.log("Received exited message from Axle Ignition...", message.data);
              onExited(message.data.step);
              break;
            case "error":
              console.log("Received errored message from Axle Ignition...", message.data);
              onErrored(message.data.message);
              break;
            default:
              console.log("Received unknown message from Axle Ignition...");
              break;
          }
        } else {
          // Ignore or handle messages from other origins
        }
      });
    </script>
    <style>
      .ignition {
        z-index: 999; /* Bring modal to front of page */
        position: fixed;
        left: 0;
        top: 0;
        height: 100%;
        width: 100%;
        border: none;
      }
    </style>
  </head>
  <body>
    <iframe
      src="https://ignition.axle.insure/?token=ign_GZQkqPDF7JSY8vJnSU9LP&origin=http://example.com"
      class="ignition"
    ></iframe>
  </body>
</html>
```

### Mobile: Display Ignition in native view

<Steps>
  <Step title="Open webview">
    * On iOS, open the constructed `ignitionUri` within the natively supported
      `ASWebAuthentication` session ([full
      documentation](https://developer.apple.com/documentation/authenticationservices/authenticating_a_user_through_a_web_service)).
    * On Android, open the constructed `ignitionUri` within `Chrome Custom Tabs`
      ([full
      documentation](https://developer.chrome.com/docs/android/custom-tabs/integration-guide/))
      to create an in-app session and Android App Links ([full
      documentation](https://developer.android.com/training/app-links)) to
      deep-link back into your application.
  </Step>

  <Step title="Process Ignition event">
    Process each Ignition event that is returned to your application's client.
    For example, when a user completes Ignition, process the event with
    `status=complete` by sending the `authCode` to your application's protected
    services to be exchanged for an `accessToken`.
  </Step>
</Steps>

<Check>
  **Congrats!**

  At this stage the user will now be able to securely connect their insurance account
  via Axle 🎉.
</Check>


# Overview
Source: https://docs.axle.insure/guides/monitoring

Receive proactive notifications for updates to an insurance policy, such as policy cancellation or change in coverages.

<Warning>
  Monitoring is not enabled by default. It requires user consent and must be
  enabled for your client to receive account and policy events. Please contact
  the Axle team if you would like to enable this feature!
</Warning>

<Steps>
  <Step title="Configure Ignition to receive webhooks">
    Ensure that the request made to generate an Ignition token includes the webhook URL where you would like to receive notifications.

    <Note>
      <Snippet />
    </Note>

    ```bash Request Sample: cURL theme={null}
    curl --request POST \
      --url https://api.axle.insure/ignition \
      --header 'Content-Type: application/json' \
      --header 'x-client-id: cli_mZj6YGXhQyQnccN97aXbq' \
      --header 'x-client-secret: RZM-5BErZuChKqycbCS1O' \
      --data '{
        "webhookUri": "https://example.com/webhook",
        "user": {
          "id": "usr_xyz"
        }
      }'
    ```

    <Tip>
      Notifications can also be sent to your organization via other communication
      channels such as email or Slack. Please contact the Axle team to configure
      which events should be sent to each channel. All events will be sent via
      webhook if a `webhookUri` is provided.
    </Tip>

    <Tip>
      If you use the same webhook for every Ignition session, you can configure a
      global webhook URI with the Axle team instead and omit `webhookUri` from
      each request.

      All notifications will go to the updated global webhook. Note that existing Ignition sessions are not updated with the global webhook.
      Please contact the Axle team to set up the global webhook.
    </Tip>
  </Step>

  <Step title="Store `accessToken` for future access">
    The `accessToken` and `account` or `policy` you received via [Exchange Token](/api-reference/tokens/exchange-token) must be stored by your application to access updated Account or Policy objects.

    If a returning user links a new insurance account, a new access token will be returned. You should compare the new token against the one you have stored for this user and determine if the old access token
    needs to be de-scoped. See [Descope Token](/api-reference/tokens/exchange-token) for more details.

    Alternatively, if a returning user links the same insurance account, the same access token will be returned. This would re-connect a previously disconnected monitored account.

    <Tip>
      It is recommended to store the `accessToken` alongside your application's user identifier. All Account and Policy events return the `user.id` specified when generating an Ignition token, so this will improve retrievability.

      If a user ID was passed into the `user.id` field during Start Ignition, and you want a historical timeline of all accounts a user has linked across entities, you should store a mapping of user, entity, and access token in your system.
    </Tip>
  </Step>

  <Step title="Process Account and Policy events">
    Notifications will be triggered by the following events and will need to be processed by your application.

    * [Account events](/guides/account-events)
      * `account.modified`: Updates made to identifying details for the insurance account (e.g., name, email, phone)
      * `account.disconnected`: The account and any connected policies are no longer being monitored by Axle
    * [Policy events](/guides/policy-events)
      * `policy.modified`: Updates made to insurance policy, such as policy cancellation or change in coverages
  </Step>

  <Step title="Retrieve Account or Policy object">
    For security, Account and Policy events do not include the entire Account and Policy objects, but include a `ref` to identify which Account or Policy is impacted by this event. You can retrieve the object via this identifier and the `accessToken` stored in your application.

    <Info>
      Axle will continue refreshing the Account and Policy objects even if these
      events are not triggered. Refer to the `refreshedAt` date on the Account and
      Policy to determine when the data was last successfully retrieved from the
      insurance carrier.
    </Info>
  </Step>

  <Step title="Validate against requirements and contact user if action is required">
    `policy.modified`: Validate updated Policy against your application's requirements. If policy does not meet requirements, ask user to complete new Axle Ignition session.

    `account.disconnected`: Ask user to complete new Axle Ignition session. See [Account events](/guides/account-events) for additional guidance on messaging.

    Key considerations:

    * If the user reconnects the same insurance account and policy, Axle will merge the updated information with any existing Account or Policy objects.
  </Step>

  <Step title="If needed, stop monitoring for user's `accessToken`">
    When monitoring is no longer required for a specific user or entity, such as when a loan is no longer being tracked or a driver is offboarded from a platform, you can de-scope monitoring from the `accessToken` stored for that user or entity. See [Descope Token](/api-reference/tokens/descope-token) for more details.
  </Step>
</Steps>


# Optimizing conversion with Axle Ignition
Source: https://docs.axle.insure/guides/optimizing-ignition-conversion

Learn how to optimize your implementation of Axle Ignition, Axle’s embedded insurance verification flow. This guide outlines best practices to maximize user conversion by presenting Axle as the default, setting expectations, and minimizing friction.

<img alt="Optimizing Ignition Conversion Pn" />

## What is Axle Ignition?

**Axle Ignition** is a secure, embedded insurance verification flow that allows users to connect their insurance policy by logging in to their insurance provider or uploading proof of insurance. It eliminates the need for manual document collection and verification, and enables faster, more reliable workflows.

<Tip>
  Axle Ignition supports both login and upload options within a single, unified experience - helping your users verify coverage in seconds.
</Tip>

***

## Best practices for maximizing conversion

<Steps>
  <Step title="Craft clear, compelling, and actionable pre-Ignition messaging">
    Help users understand why they're being asked to share their insurance, what they should expect, and how to take the next step - all in a single, clear message.

    * **Explain the benefit to the user** – Show users how verifying insurance helps them, such as reducing wait times, streamlining onboarding, or fulfilling compliance. Tailor the benefit to your use case (e.g., rentals, test drives, lending).
    * **Set expectations** – Let users know they’ll be asked to log in to their insurance provider or upload proof of insurance through Axle.
    * **Use a clear CTA (call-to-action)** – Follow up with a short, directive CTA. Choose language like “Verify insurance,” “Link account,” or “Share proof of insurance.” Keep it consistent and action-oriented.

    **Examples putting it all together:**

    * “Quickly verify your insurance to speed up your time at the counter.”\
      CTA: **"Verify insurance"** or **"Share my insurance"**
    * “Securely link your insurance account in seconds through our partner, Axle. No uploads needed - we’ll automatically retrieve the documents we need, saving you time and hassle.”\
      CTA: **"Link insurance account"**

    <Tip>
      Use consistent, user-friendly CTAs that align with your brand tone and the user’s task - and pair them with clear expectations to reduce drop-off.
    </Tip>
  </Step>

  <Step title="Present Axle as the default path">
    Rather than presenting Axle as one of several equal options, make it the **primary** or **preferred** method for collecting insurance. Since Axle supports both account linking and document uploads through DocumentAI, pushing users to the Axle flow leads to the highest completion rates.

    **Examples:**

    * **If your implementation supports document uploads through DocumentAI** – Do not offer multiple separate options. Use a single CTA that covers both login and upload. Axle will optimize completion behind the scenes.

      > CTA: **"Share my insurance"**
    * **If you collect documents outside of Axle** –\
      Guide users to connect via Axle first. Only offer manual upload as a fallback later, or visually de-emphasize it using labels, color, or badges.

    Link Insurance Account \[Preferred]
    Upload Document \[Slower]
  </Step>

  <Step title="Keep messaging simple and focused">
    Avoid overwhelming the user with too many requests at once. Keep your messaging concise and break information into clear, discrete actions. This helps maintain engagement and improves conversion.

    **Tips:**

    * Use short paragraphs and scannable headers
    * Avoid jargon or technical detail early in the flow
    * Break steps into small, focused actions (e.g., ID, insurance, payment)
    * Allow users to complete steps in the order they choose when possible

    <Tip>
      Simplified flows lead to higher conversion and fewer support escalations.
    </Tip>
  </Step>

  <Step title="Re-engage users who drop off">
    If a user doesn’t complete the Axle flow, follow up with light-touch reminders:

    * In-app banners or nudges
    * Follow-up emails with deep links
    * Prompts at next log-in or session
  </Step>

  <Step title="Test, measure, and optimize">
    Use data to understand where users succeed - and where they drop off. Iterate on UX and messaging to improve over time.

    **What to track:**

    * Start and completion rates for Axle Ignition
    * A/B test results for CTA wording and placement
    * Drop-off points in the flow
    * User support tickets or confusion signals

    <Tip>
      Ask your Axle contact about best practices for logging and analyzing Ignition performance.
    </Tip>
  </Step>
</Steps>

***

## Frequently asked questions (FAQ)

**Q: What is Axle Ignition?**\
**A:** Axle Ignition is Axle’s embedded flow that allows users to log in to their insurance provider or upload proof of coverage. It’s used for real-time insurance verification across industries like car rentals, auto lending, employee compliance, and fleet services.

**Q: How do I maximize conversion with Axle?**\
**A:** Present Axle as the default option, explain the user benefit clearly, set expectations before the flow, and keep your messaging simple and focused.

**Q: What should my CTA say?**\
**A:** Use short, specific CTAs like “Share my insurance,” “Verify insurance,” or “Import insurance info” - paired with a clear explanation of the benefit.

**Q: When should I offer document upload?**\
**A:** We always recommend allowing Document uploads in Ignition via DocumentAI if you support documents generally. Having a single choice for the user allows us to optimize total completion and link rates by waterfalling the user to the best option for them.

***

## Partner with us

Every integration is different - and Axle’s **Solutions Engineering team** is here to help.

We’ll work with you to design the best user experience for your specific use case, including messaging, flow timing, and fallback handling.

> Reach out to your Axle contact or [email support@axle.insure](mailto:support@axle.insure) to get started.


# Axle for Platforms
Source: https://docs.axle.insure/guides/platform-integration

Integrate Axle's API into your platform, to provide instant insurance verification solutions for your customers.

## What is a platform?

* Our platform partners are typically software providers that provide many services to their customers, and want to offer Axle as a feature or add-on of their platform.
* For example, a dealership management system might be a platform with many dealerships as customers.
  * These dealerships want to use Axle to verify insurance information for their own users, but may not want to setup Axle themselves.
  * As they are already accustomed to using certain systems, it will be easier for them to use Axle if it is embedded into those systems.

## How does a platform use Axle?

In the Axle system, a platform's customers are referred to as `destination clients`.
The platform is responsible for onboarding destination clients to Axle, and then can make requests to Axle's APIs on behalf of the destination client.

Platforms can configure a new destination client using the [`POST /platform/clients`](/api-reference/platform/create-client) endpoint.
This will return a unique `id` for your new destination client, which the platform should store in their database alongside their internal unique identifier for the destination client,
because it will be used to authorize requests to Axle's APIs on behalf of the destination client.

Platforms should integrate Axle into their product or service using the process outlined in Axle's [Quickstart](/guides/quickstart) guide.
The only major difference is that in addition to providing the `x-client-id` and `x-client-secret` headers to authorize each request,
the platform should also provide the destination client `id` in the additional `x-destination-client-id` header.

<Tip>
  If you have not been sent your `x-client-id` and `x-client-secret`, please
  reach out to the Axle team!
</Tip>

## Onboarding a destination client

### Capture interest in Axle

Setup a landing page or self-service mechanism to capture interest in instant insurance verification through Axle by your customers, partners, or any other dependent services.

### Register a destination client with Axle

Once a service has expressed interest in leveraging Axle, use the [`POST /platform/clients`](/api-reference/platform/create-client) endpoint to register it as a new destination client.

When registering a new client, you'll be asked for the following information:

* `displayName`: A human-friendly name for the destination client. This will be used in Ignition and in the Axle dashboard.
* `entity`: A url-friendly name for the destination client. These must be unique in the Axle system, so it is recommended to use a combination of your platform's name and the destination client's name.

<Info>
  Your new destination client will inherit the Ignition and notification
  configurations present on your platform client. Please reach out to the Axle
  team if you would like to modify this base configuration or change a
  configuration for a specific destination client.
</Info>

Store the destination client's `id` in your database alongside your internal unique identifier for the destination client. This will be used to authorize requests to Axle's APIs on behalf of the destination client.

If you do happen to lose the destination client `id`, you can retrieve it using the [`GET /platform/clients`](/api-reference/platform/get-clients) endpoint to get a list of all destination clients registered with your platform.

### Make requests on behalf of destination client

You can now authorize requests to Axle's APIs on behalf of this destination client by providing the `x-destination-client-id` header. The following endpoints can be authorized on behalf of the destination client:

<CardGroup>
  <Card title="Ignition" icon="circle-play" href="/api-reference/ignition/start-ignition">
    Manage Ignition sessions.
  </Card>

  <Card title="Tokens" icon="key" href="/api-reference/tokens/exchange-token">
    Manage and exchange Access Tokens.
  </Card>

  <Card title="Accounts" icon="id-card" href="/api-reference/accounts/get-account">
    Retrieve information about an Account.
  </Card>

  <Card title="Policies" icon="file-contract" href="/api-reference/policies/get-policy">
    Retrieve information about a Policy.
  </Card>

  <Card title="Policy Reports" icon="file-pdf" href="/api-reference/policies/get-policy-report">
    Retrieve Policy Report.
  </Card>

  <Card title="Descope Token" icon="key" href="/api-reference/tokens/descope-token">
    Change the scope of an Access Token.
  </Card>
</CardGroup>

For more details and advice about how to integrate these API calls with your service, please see the [Quickstart](/guides/quickstart) guide.

### Handle redirect, Window MessageEvent, or webhook Ignition events

All events include a `client` parameter with the destination client `id`, so you can easily associate an event with the correct destination client. Please refer to the guides on [Ignition events](/guides/ignition-events) and [Account](/guides/account-events) or [Policy](/guides/policy-events) events for more details.

<Check>
  **Well Done!**

  Now that you have setup Axle in your platform, be sure to visit the full [📖 API Reference](/api-reference/overview) to see all the data fields that are available.
</Check>


# Policy Actions
Source: https://docs.axle.insure/guides/policy-actions

Execute an action on a policy on behalf of your user.

## Overview

Policy actions allow you to request carrier-side changes to a policy on behalf of your user. Once submitted, Axle will process the request and the policy will be updated once the action is complete.

The following operations are currently supported:

| Operation                    | Description                                                                      |
| ---------------------------- | -------------------------------------------------------------------------------- |
| `request-primary-lienholder` | Request that your organization be added as the primary lienholder on the policy. |

## Executing a Policy Action

Submit a `POST /policies/{policyId}/actions` request with the desired `operation`.

```bash Request Sample: cURL theme={null}
curl --request POST \
  --url https://api.axle.insure/policies/pol_mZj6YGXhQyQnccN97aXbq/actions \
  --header 'Content-Type: application/json' \
  --header 'x-client-id: cli_mZj6YGXhQyQnccN97aXbq' \
  --header 'x-client-secret: RZM-5BErZuChKqycbCS1O' \
  --data '{
  "operation": "request-primary-lienholder"
}'
```

A successful response returns the ID of the created policy action and an `processesInstantly` flag.

```json Response Sample theme={null}
{
  "success": true,
  "data": {
    "id": "pla_mZj6YGXhQyQnccN97aXbq",
    "processesInstantly": false
  }
}
```

## Webhooks

A `POST` request will be sent to the `webhookUri` you provided when generating the Ignition token at each stage of the action lifecycle.

<Tip>
  You must specify a `webhookUri` when generating an Ignition token to receive
  webhook events. See [Start Ignition](/api-reference/ignition/start-ignition)
  for more details.
</Tip>

All policy action webhook events include top-level `id`, `type`, and `createdAt`. The `data` object includes `client`, `policy`, `operation`, `input`, and optionally `user` and `metadata`.

```json Example webhook payload theme={null}
{
  "id": "<event_id>",
  "type": "policy-action.request-initiated",
  "data": {
    "client": "<client-id>",
    "policy": "<policy-id>",
    "operation": "request-primary-lienholder",
    "user": {
      "firstName": "John",
      "lastName": "Doe",
      "id": "usr_123456789",
      "email": "john.doe@gmail.com"
    },
    "metadata": {
      "claimNumber": "123456"
    },
    "input": {
      "lenderCode": "ABC123"
    },
    "createdAt": "2026-01-01T00:00:00.000Z",
  }
}
```

### Event types

Events follow this lifecycle: `policy-action.request-initiated` -> `policy-action.request-succeeded` or `policy-action.request-failed` -> (on success) `policy-action.policy-refresh-succeeded` or `policy-action.policy-refresh-failed`.

Which events you receive depends on the `processesInstantly` flag returned by [Execute Policy Action](/api-reference/policies/execute-policy-action):

* **`processesInstantly: true`** - If the policy action succeeds, the change is reflected on the policy right away. You'll receive a `policy-action.policy-refresh-succeeded` or `policy-action.policy-refresh-failed` event right after `policy-action.request-succeeded`, confirming whether Axle was able to retrieve the updated policy.
* **`processesInstantly: false`** - The effects of the policy action are not available immediately, even if the action itself was successful, so you'll only receive events up through `policy-action.request-succeeded` or `policy-action.request-failed`. To find out when the policy has been updated as a result of the action, opt in to [Monitoring](/guides/monitoring) to receive the [`policy.modified`](/guides/policy-events#policy-modified) event.

### policy-action.request-initiated

The action has been received and Axle has begun processing the insurance carrier request.

### policy-action.request-succeeded

The insurance carrier successfully processed the request.

### policy-action.request-failed

The insurance carrier request failed, or the action expired before completing.

### policy-action.policy-refresh-succeeded

Sent only for policy actions where `processesInstantly: true`. After a successful insurance carrier request, Axle was able to retrieve the latest policy data.

### policy-action.policy-refresh-failed

Sent only for policy actions where `processesInstantly: true`. After a successful insurance carrier request, Axle was unable to refresh the policy data. The carrier request itself succeeded, but the policy data may not yet reflect the change.

## Error Codes

If the request does not succeed, you may receive a `400 Bad Request` or `500 Internal Server Error` response.

### 400 Bad Request

| errorCode                     | message                                                       | When it occurs                                            |
| ----------------------------- | ------------------------------------------------------------- | --------------------------------------------------------- |
| `policy-action-not-supported` | Policy action `<operation>` is not supported for this policy. | The requested operation is not available for this policy. |

### 500 Internal Server Error

| errorCode | message                                            | When it occurs                                                        |
| --------- | -------------------------------------------------- | --------------------------------------------------------------------- |
| `default` | Oops something went wrong. Please try again later. | Default when an unexpected server error occurs. Retrying may succeed. |


# Policy events
Source: https://docs.axle.insure/guides/policy-events

This guide will walk you through the various Policy events that may occur when monitoring an insurance policy.

Once an insurance policy is connected through an Ignition session, Axle can monitor that policy for updates. These updates will trigger events that are sent from Axle to your systems via webhook or to your organization via communication channels such as email.

<Info>
  Policy events are only sent for insurance policies connected through Axle
  Ignition sessions that are configured with `monitoring` enabled. Please
  contact the Axle team if you would like to enable this feature!
</Info>

## Webhooks

<Tip>
  You must specify a `webhookUri` when generating an Ignition token to receive
  webhook events. See [Start Ignition](/api-reference/ignition/start-ignition)
  for more details.

  Custom webhook headers can be configured to support uses cases like
  authentication. Please contact the Axle team if you would like to configure
  custom webhook headers!
</Tip>

A `POST` request will be sent to the `webhookUri` with the following payload. All events will include `client`, `account`, `ref` (Policy object identifier), `user` (optionally specified when generating Ignition token), and `metadata` (optionally specified when generating Ignition token).

```json Example webhook payload theme={null}
{
  "id": "<event_id>",
  "type": "policy.modified",
  "data": {
    "client": "<client-id>",
    "account": "<account-id>",
    "ref": "pol_Z4ni-JHBvkn9PlKJHPEwk",
    "user": {},
    "metadata": {},
    ...{ parameters }
  },
  "createdAt": "2022-10-05T14:48:00.000Z"
}
```

### policy.modified

This event type indicates details on the Policy changed. Refer to [Policy](/api-reference/policies/policy) for more details on the fields that can be modified.

<Note>
  Axle performs safety checks on policy modifications before sending a
  `policy.modified` event. This may cause a short delay between when policy
  information was refreshed from the carrier and when you receive notification
  of the event.
</Note>

### policy.renewal-available

This event type indicates renewal policy is available for retrieval. Refer to [Policy](/api-reference/policies/get-policy#parameter-term) for more details on available options and how to retrieve it.

<Note>
  If the Get Policy API endpoint returns a 404, it means no renewal policy is
  available. We recommend calling the API again without the `term` query
  parameter OR passing in `term=current` as a query parameter.
</Note>

#### Special Policy Changes

<AccordionGroup>
  <Accordion title="Policy isActive changes to null">
    If a `policy.modified` [event](/guides/policy-events) indicates that a policy’s `isActive` field has changed to `null`, then
    the policy may have been removed from the account. It is recommended to reach out to the user to re-connect the policy for the existing
    account or link a new account.
  </Accordion>
</AccordionGroup>


# Proxy
Source: https://docs.axle.insure/guides/proxy-ignition

As an alternative to initializing Ignition, proxy insurance information on behalf of your user to Axle for processing and/or verification.

### Overview

Axle’s Ignition session is the main interface that allows your users to connect to their insurance accounts and authorize access to scoped data from their insurance policies.

However, sometimes insurance information is shared to you on behalf of your user, such as when an insurance carrier or agent sends documents via mail directly to the policy lienholder.

In these cases, you can "proxy" an Ignition session, effectively sharing information on behalf of your user instead of initializing Ignition for the user to complete it themself. Axle will then process and/or verify this information, depending on the use case.

<Warning>
  When proxying an Ignition session, you are agreeing that you have received
  consent from user to share their insurance information with Axle, a data processor, as persuant
  to Axle's [Privacy Policy](https://www.axle.insure/legal/privacy-policy) and
  [End User Terms](https://www.axle.insure/legal/end-user-terms).
</Warning>

<Steps>
  <Step title="Configure Ignition to receive webhooks">
    Ensure that the request made to generate an Ignition token includes the `webhookUri` where you would like to receive Ignition events.

    ```bash Request Sample: cURL theme={null}
    curl --request POST \
      --url https://api.axle.insure/ignition \
      --header 'Content-Type: application/json' \
      --header 'x-client-id: cli_mZj6YGXhQyQnccN97aXbq' \
      --header 'x-client-secret: RZM-5BErZuChKqycbCS1O' \
      --data '{
      "webhookUri": "https://example.com/webhook",
      "user": {"id": "usr_123456789"},
      "template": "template_abc123"
    }'
    ```

    <Info>
      The Axle Team can set up Ignition templates to overwrite the default configuration that is set per client.

      To apply one, pass the template in the [Start Ignition](/api-reference/ignition/start-ignition) request body. The template scopes to that single Ignition session. Contact the Axle team to set up a template.
    </Info>
  </Step>

  <Step title="Send proxy request">
    Select a supported [`operation`](/guides/proxy-ignition#supported-operations) and provide the required insurance information for the operation in the `POST /ignition/{ignitionToken}/proxy` request body. See [Proxy Ignition](/api-reference/ignition/proxy-ignition) API reference for more details on how to invoke the Proxy Ignition endpoint.

    <Info>
      When Proxy Ignition request is made, Axle will queue the proxy operation immediately. Completion times may vary by operation and current Axle volume, but will be under 24 hours.
    </Info>
  </Step>

  <Step title="Process Ignition events">
    Once the submitted insurance information has been processed and/or verified, an `POST` request will be sent to
    the `webhookUri` specified when generating the Ignition session. See [Ignition events](/guides/ignition-events) for more details on the payloads of each event.

    <Tabs>
      <Tab title="ignition.completed">
        Continue from Step 3 in the [Quickstart](/guides/quickstart) guide. In
        summary, you will need to exchange the short-lived `authCode` specified for
        an `accessToken`, which can then be used to retrieve Axle Account and Policy
        objects.

        <Tip>
          The `result` of the `ignition.completed` event will be the selected proxy `operation`. If you are using the same `webhookUri` across proxied and non-proxied Ignition sessions, you can use this result to filter the events.
        </Tip>
      </Tab>

      <Tab title="ignition.attempted">
        Fired when the operation was attempted but could not be completed due to
        invalid or incompatible inputs, or a policy-related block such as an
        inactive policy or missing lienholder. Unlike `ignition.errored`, which
        indicates a system error, this event reflects an issue with the provided
        data or policy state. The `errorCode` identifies the specific issue —
        correcting the inputs or resolving the policy condition before retrying
        may result in a different outcome.
      </Tab>

      <Tab title="ignition.errored">
        Fired when the operation failed due to a system error. Unlike
        `ignition.attempted`, this event is not caused by the provided inputs or
        policy state. The `errorCode` and `message` can be used to determine next
        steps — retrying the Proxy Ignition request may result in a different
        outcome.
      </Tab>
    </Tabs>
  </Step>
</Steps>

### Supported operations

<Info>
  Currently, only certain Ignition proxy operations are supported. Please reach
  out to the Axle team if you would like to request new operations.
</Info>

<Accordion title="Process insurance carrier policy document into Axle Policy" icon="file">
  Leverage Axle's Document AI to extract information from a policy document, such as a declarations page, policy renewal, ID card, or new business binder, and transform it into an [Axle Policy](/api-reference/policies/policy) object.

  In the request body, you must provide the following:

  * operation: `process-document`
  * input:

    * `name` for the document (such as the unique identifier of the document in your system)
    * `source` of the document (either `user` or `carrier`)
    * `policyType` of the document (`auto` or `home`)
    * `url` that can used to access the document.

    <Tip>
      This operation supports documents in the following formats: `pdf`, `jpg`,
      `jpeg`, and `png`. The url must directly serve the document via a HTTP GET
      request. For security, it is recommended to use a url with an 24-hour
      expiry, such as an AWS S3 signed url.
    </Tip>

  ```json Example request body theme={null}
  {
    "operation": "process-document",
    "input": {
      "name": "DOC_ABC",
      "source": "carrier",
      "policyType": "auto",
      "url": "https://your-document-bucket.s3.amazonaws.com/declarations-page.pdf"
    }
  }
  ```

  If the operation does not succeed, you may receive an `ignition.attempted` event or an `ignition.errored` event.

  #### `ignition.attempted` webhook event

  | errorCode                     | message                                                                                           | When it occurs                                                                                                                                   |
  | ----------------------------- | ------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ |
  | `document-data-empty`         | The uploaded document appears to be empty. Please try uploading it again.                         | The document url was empty, the downloaded document had no data, or Axle's Document AI determined the uploaded file was empty or an invalid PDF. |
  | `document-download-failed`    | We were unable to retrieve the document you provided. Please check the file and try again.        | The file could not be downloaded from the specified url.                                                                                         |
  | `unsupported-document`        | Please make sure to upload an image or pdf document with your policy information clearly legible. | The document was not supported by Axle's Document AI as it is either the wrong format, not legible, or not an insurance document.                |
  | `unsupported-document`        | The extracted text does not appear to be a valid insurance document                               | Document AI extracted text from the document, but it didn't validate as an insurance document.                                                   |
  | `document-type-not-supported` | This document type is not supported by the current client                                         | The document type is not enabled for this client.                                                                                                |
  | `document-type-not-supported` | This document type is not currently supported by Document AI                                      | The document type is not supported by Document AI.                                                                                               |
  | `document-missing-fields`     | The document is missing required data fields                                                      | Document AI parsed the document but required fields (e.g. carrier) could not be extracted from it.                                               |
  | `ignition-completed`          | Ignition session is already completed. Please create a new Ignition session.                      | The Ignition session has already completed. Create a new Ignition session before retrying.                                                       |

  #### `ignition.errored` webhook event

  | errorCode | message                                            | When it occurs                                                            |
  | --------- | -------------------------------------------------- | ------------------------------------------------------------------------- |
  | `default` | Oops something went wrong. Please try again later. | An unknown error occurred. Retrying may result in a successful operation. |
</Accordion>

<Accordion title="Lookup insurance policy using policy details" icon="magnifying-glass">
  Leverage Axle's carrier integrations to lookup insurance policy information.

  In the request body, you must provide the following:

  * operation: `policy-lookup`
  * input:

    * Exactly one of `carrier` or `naicCode`. `carrier` can be either a free-text string (such as `"State Farm Insurance Company"`) or an Axle carrier ID (such as `"state-farm"`). Use the [Get Carriers endpoint](/api-reference/carriers/get-carriers) for a list of supported carriers and their IDs.
    * `policyType` of the policy (`auto`, `home`, or `condo`)
    * `policyNumber` of the policy

    For `auto` policies:

    * `vin` of the vehicle
    * `insuredName` of the primary policyholder (either a full name string such as `"John Smith"` or an object with `firstName` and `lastName`)
    * `address` mailing address of the primary policyholder (either a string such as `"123 Main Street, New York, NY 10001"` or an address object with `addressLine1`, `addressLine2`, `city`, `state`, `postalCode`, and `country`)

    For `home` and `condo` policies:

    * `address` property address (either a string such as `"123 Main Street, New York, NY 10001"` or an address object with `addressLine1`, `addressLine2`, `city`, `state`, `postalCode`, and `country`)
    * `insuredName` of the primary policyholder (either a full name string such as `"John Smith"` or an object with `firstName` and `lastName`)

  <Tip>
    Instead of `carrier`, you may provide `naicCode` to identify the carrier by NAIC code (e.g., `"11851"` for Progressive).
  </Tip>

  <Tabs>
    <Tab title="Auto">
      ```json Example request body theme={null}
      {
        "operation": "policy-lookup",
        "input": {
          "carrier": "progressive",
          "policyType": "auto",
          "policyNumber": "123456789",
          "vin": "1HGCM82633A004352",
          "insuredName": "John Smith",
          "address": "123 Main Street, New York, NY 10001"
        }
      }
      ```

      ```json Use naicCode instead of carrier theme={null}
      {
        "operation": "policy-lookup",
        "input": {
          "naicCode": "11851",
          "policyType": "auto",
          "policyNumber": "123456789",
          "vin": "1HGCM82633A004352",
          "insuredName": {
            "firstName": "John",
            "lastName": "Smith"
          },
          "address": {
            "addressLine1": "123 Main St",
            "addressLine2": null,
            "city": "New York",
            "state": "NY",
            "postalCode": "10001",
            "country": "US"
          }
        }
      }
      ```
    </Tab>

    <Tab title="Home / Condo">
      ```json Example request body theme={null}
      {
        "operation": "policy-lookup",
        "input": {
          "carrier": "progressive",
          "policyType": "home",
          "policyNumber": "123456789",
          "address": {
            "addressLine1": "123 Main St",
            "addressLine2": null,
            "city": "New York",
            "state": "NY",
            "postalCode": "10001",
            "country": "US"
          },
          "insuredName": "John Smith"
        }
      }
      ```

      ```json Use naicCode instead of carrier theme={null}
      {
        "operation": "policy-lookup",
        "input": {
          "naicCode": "11851",
          "policyType": "home",
          "policyNumber": "123456789",
          "address": "123 Main Street, New York, NY 10001",
          "insuredName": "John Smith"
        }
      }
      ```
    </Tab>
  </Tabs>

  If the operation does not succeed, you may receive a `400 Bad Request` response, an `ignition.attempted` event, or an `ignition.errored` event.

  #### 400 Bad Request

  | errorCode                     | message                                                                                                                 | When it occurs                                                                                                                                                                     |
  | ----------------------------- | ----------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
  | `user-input-invalid`          | Invalid input for operation "policy-lookup".                                                                            | Required fields are missing or invalid.                                                                                                                                            |
  | `user-input-invalid`          | Sorry, the provided address is invalid or we are unable to process this address. Please update and try again.           | The provided address could not be parsed or validated.                                                                                                                             |
  | `carrier-not-found`           | Carrier not found. Please verify the carrier and try again.                                                             | The provided carrier identifier (`carrier` free-text string, Axle carrier ID, or `naicCode`) is invalid or not supported.                                                          |
  | `policy-lookup-not-supported` | This carrier does not support policy lookup.                                                                            | The carrier does not support this operation.                                                                                                                                       |
  | `policy-lookup-not-supported` | This carrier does not support policy lookup for type .                                                                  | The carrier does not support this operation for the specified policy type.                                                                                                         |
  | `ignition-processing`         | A request for this Ignition session is already in progress. Please retry once the current operation has completed.      | The request was submitted while another request for the same Ignition session is still in process. This error is primarily used for when an ignition session is invoked via proxy. |
  | `no-credentials`              | No active lienholder portal credentials were found for the provided carrier. Please contact Axle to set up credentials. | The client does not have lienholder portal credentials configured for this carrier.                                                                                                |

  #### 500 Internal Server Error

  | errorCode | message                                            | When it occurs                                                        |
  | --------- | -------------------------------------------------- | --------------------------------------------------------------------- |
  | `default` | Oops something went wrong. Please try again later. | Default when an unexpected server error occurs. Retrying may succeed. |

  #### `ignition.attempted` webhook event

  | errorCode               | message                                                                                                                                                                                       | When it occurs                                                                                                                           |
  | ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
  | `user-input-invalid`    | Your lookup is invalid or the policy cannot be found. Verify you have the correct details and try again.                                                                                      | The policy could not be found with the provided details. Update the input fields (e.g. policy number, VIN, address) before trying again. |
  | `lienholder-required`   | Sorry, we are unable to access this policy because there is no lienholder present or the lienholder provided is not listed on this policy. Please try again with another verification method. | No lienholder is present, or the requesting client is not the lienholder on file.                                                        |
  | `policy-not-active`     | Policy is not active.                                                                                                                                                                         | The policy exists but is not currently active.                                                                                           |
  | `policy-active-unknown` | Sorry, we didn't find any compatible policies. Please try again using another verification method.                                                                                            | The policy status could not be confirmed as active.                                                                                      |
  | `ignition-completed`    | Ignition session is already completed. Please create a new Ignition session.                                                                                                                  | The Ignition session has already completed. Create a new Ignition session before retrying.                                               |
  | `policy-type-mismatch`  | We were able to locate the policy but do not yet support this policy type. Please check back soon as we work on adding support.                                                               | The policy was found, but its type does not match the requested `policyType` or is not yet supported by Axle.                            |

  #### `ignition.errored` webhook event

  | errorCode | message                                            | When it occurs                                                        |
  | --------- | -------------------------------------------------- | --------------------------------------------------------------------- |
  | `default` | Oops something went wrong. Please try again later. | Default when an unexpected server error occurs. Retrying may succeed. |
</Accordion>


# Quickstart
Source: https://docs.axle.insure/guides/quickstart

Axle's powerful API makes it easy for you to quickly retrieve detailed information from your users' insurance policies. Here at Axle, we're champions for consumer data control and privacy, so you'll need to gain consent from the user to access their information.

This is where Ignition - Axle's consumer facing consent widget - comes into
play. This guide will walk you through setting up Ignition, obtaining access
tokens, and making requests against the Axle API.

#### How it works

Axle provides a consistent, single point integration to connect
your users' insurance accounts to your application. To do so, Axle closely
follows the OAuth 2.0 Authorization Code flow which begins when your user wants
to connect their insurance account to your application.

<Warning>
  **Never send requests from your application's client to the Axle API.**
  Instead, make requests from your application's protected services to avoid
  exposing your sensitive Axle API credentials.
</Warning>

### Step 1: Generate an Ignition token

Make a `POST` request to `/ignition`. In return, you'll retrieve an ignitionToken which
you'll need to pass to your application's client. This token will be used to initialize
Ignition and allows us to create secure, trackable session with your user. Ignition tokens do not expire.

```bash Request Sample: cURL theme={null}
curl --request POST \
  --url https://api.axle.insure/ignition \
  --header 'Content-Type: application/json' \
  --header 'x-client-id: cli_mZj6YGXhQyQnccN97aXbq' \
  --header 'x-client-secret: RZM-5BErZuChKqycbCS1O' \
  --data '{
  "redirectUri": "https://example.com/insurance/success",
  "webhookUri": "https://example.com/webhook",
  "user": {"id": "usr_123456789"},
  "template": "template_abc123"
  }'
```

<Info>
  You can specify fields when generating an Ignition token to handle Ignition
  events (see the guide on [Ignition events](/guides/ignition-events) for more
  details) as well as attach user information or other metadata (see [Start
  Ignition](/api-reference/ignition/start-ignition) for more details).
</Info>

<Tip>
  If you use the same webhook for every Ignition session, you can configure a
  global webhook URI and omit `webhookUri` from each request. Please contact the Axle team to set up a global webhook URI.
</Tip>

<Info>
  The Axle Team can set up Ignition templates to overwrite the default configuration that is set per client.

  To apply one, pass the template in the [Start Ignition](/api-reference/ignition/start-ignition) request body. The template scopes to that single Ignition session. Contact the Axle team to set up a template.
</Info>

```json Response Example theme={null}
{
  "success": true,
  "data": {
    "ignitionToken": "ign_ur7EPeAa0km4wRlDrPJ4Z",
    "ignitionUri": "https://ignition.axle.insure/?token=ign_ur7EPeAa0km4wRlDrPJ4Z"
  }
}
```

### Step 2: Initialize Ignition and process Ignition events

Here are some common ways you can present Ignition to your application's users:

* **Recommended:** display Ignition at the right step within your application's user experience (such as before booking a rental or closing a loan application) via an iframe or webview
* Send Ignition URL in an asychronous user communication (such as email or push notification)

<Tip>
  For guidance on specific implementations based on your application's
  requirements, refer to the [Initialize Ignition](/guides/initialize-ignition)
  and [Optimizing conversion](/guides/optimizing-ignition-conversion) guides.
</Tip>

Then, process events generated during the course of the Ignition session. See the [Ignition events](/guides/ignition-events) guide for each Ignition event.

### Step 3: Exchange tokens

Once the user successfully connects their account, you'll receive an authorization
code (`authCode`) as an Ignition event via redirect parameters, Window MessageEvent, or webhook.

However, for additional security (particularly if the Ignition event is delivered to your application's client), you'll need to exchange the short-lived `authCode` for a long-lived `accessToken` in your application's protected services.

<Note>
  Each `authCode` expires after 10 minutes so be sure you're exchanging codes in
  real time.
</Note>

To do so, make a `POST` request with your `authCode` to `token/exchange`. In
return you'll receive an `accessToken`, `account` identifier, and list of `policy` identifiers.

```bash Request Sample: cURL theme={null}
curl --request POST \
--url https://api.axle.insure/token/exchange \
--header 'Content-Type: application/json' \
--header 'x-client-id: cli_mZj6YGXhQyQnccN97aXbq' \
--header 'x-client-secret: RZM-5BErZuChKqycbCS1O' \
--data '{
"authCode": "cod_LGUgD5ZnqWy3pThdOLUsT"
}'
```

```json Response Example theme={null}
{
  "success": true,
  "data": {
    "account": "acc_gM2wn_gaqUv76ZljeVXOv",
    "policies": ["pol_CbxGmGWnp9bGAFCC-eod2"],
    "accessToken": "tok_IwShXCT_JPr6rmtiCVxcQ"
  }
}
```

### Step 4: Store access credentials

Store the `accessToken`, `account` identifier, and list of `policy` identifiers received in step 4 in your database - these values will be used to access account and policy information for the user going forward.

<Check>
  **Congrats!**

  You have now received an `accessToken` that represents consent from the user and
  can now leverage the Axle API to access their insurance data 🎉🎉!
</Check>

### Step 5: Retrieve the Policy

Now that you have an `accessToken`, you can retrieve the [Policy](/api-reference/policies/policy) object that was shared by the user by making a `GET` request to `policies/{id}` with
the `accessToken` passed in the `x-access-token` header.

```bash Request Sample: cURL theme={null}
curl --request GET \
  --url https://api.axle.insure/policies/pol_CbxGmGWnp9bGAFCC-eod2 \
  --header 'Content-Type: application/json' \
  --header 'x-access-token: tok_IwShXCT_JPr6rmtiCVxcQ' \
  --header 'x-client-id: cli_mZj6YGXhQyQnccN97aXbq' \
  --header 'x-client-secret: RZM-5BErZuChKqycbCS1O'
```

```json Response Example theme={null}
{
  "success": true,
  "data": {
    "id": "pol_CbxGmGWnp9bGAFCC-eod2",
    "accountId": "acc_gM2wn_gaqUv76ZljeVXOv",
    "type": "auto",
    "carrier": "state-farm",
    "policyNumber": "123456789",
    "isActive": true,
    "effectiveDate": "2023-10-22T04:00:00.000Z",
    "expirationDate": "2024-10-22T04:00:00.000Z",
    "premium": "543.23",
    "underwriter": {
      "name": "John Doe",
      "naicCode": "12345"
    },
    "address": {
      "addressLine1": "123 Fake St.",
      "addressLine2": "Unit 456",
      "city": "Atlanta",
      "state": "Georgia",
      "postalCode": "30315",
      "country": "USA"
    },
    "properties": [
      {
        "id": "prp_uSdzLVpi8c76H7kl6AQ-F",
        "type": "vehicle",
        "data": {
          "bodyStyle": "sedan",
          "vin": "WDDWJ8EB4KF776265",
          "model": "C 300",
          "year": "2019",
          "make": "Mercedes-Benz"
          "use": "commute"
        }
      }
    ],
    "coverages": [
      {
        "code": "BI",
        "label": "Bodily Injury",
        "limitPerPerson": 250000,
        "limitPerAccident": 500000
      },
      {
        "code": "PD",
        "label": "Property Damage",
        "limitPerAccident": 100000
      },
      {
        "code": "UMBI",
        "label": "Uninsured Bodily Injury",
        "limitPerPerson": 100000,
        "limitPerAccident": 300000
      },
      {
        "code": "COMP",
        "label": "Comprehensive",
        "deductible": 500,
        "property": "prp_uSdzLVpi8c76H7kl6AQ-F"
      },
      {
        "code": "COLL",
        "label": "Collision",
        "deductible": 500,
        "property": "prp_uSdzLVpi8c76H7kl6AQ-F"
      }
    ],
    "insureds": [
      {
        "firstName": "John",
        "lastName": "Smith",
        "dateOfBirthYear": "1990",
        "licenseNo": "•••••1234",
        "licenseState": "GA",
        "type": "primary"
      },
      {
        "firstName": "Jane",
        "lastName": "Doe",
        "dateOfBirthYear": "1992",
        "licenseNo": "•••••5678",
        "licenseState": "GA",
        "type": "secondary"
      }
    ],
    "thirdParties": [
      {
        "name": "Super Leasing Trust",
        "type": "lessor",
        "address": {
          "addressLine1": "Po Box 105205",
          "addressLine2": null,
          "city": "Atlanta",
          "state": "GA",
          "postalCode": "30348"
        },
        "property": "prp_uSdzLVpi8c76H7kl6AQ-F"
      }
    ],
    "documents": [
      {
        "source": "carrier",
        "name": "Declaration Page",
        "type": ["declaration-page"],
        "url": "<signed-url>",
        "id": "doc_jd73dw6fn02sj28.pdf",
        "issuedDate": "2023-12-31T00:00:00.000Z",
        "effectiveDate": "2024-01-02T00:00:00.000Z",
        "createdAt": "2024-01-01T00:00:00.000Z"
      }
    ],
    "exclusions": [],
    "createdAt": "2024-01-01T00:00:00.000Z",
    "modifiedAt": "2024-01-01T00:00:00.000Z",
    "refreshedAt": "2024-01-01T00:00:00.000Z"
  }
}
```

<Check>
  **Well Done!**

  Be sure to visit the full [📖 API Reference](/api-reference) to learn more about each endpoint and resource!
</Check>


# Testing Ignition
Source: https://docs.axle.insure/guides/sandbox/ignition-completion

The Axle sandbox can be used to test your integration of Axle's API in your application or platform. All Axle API endpoints can access the sandbox environment.

<Info>
  If you have not received access to the Axle sandbox, please reach out to the
  Axle team!
</Info>

## Accessing the sandbox

#### API Sandbox Url

```bash theme={null}
https://sandbox.axle.insure
```

#### Ignition Sandbox Url

```bash theme={null}
https://ignition.sandbox.axle.insure
```

#### Dashboard Sandbox Url

```bash theme={null}
https://dashboard.sandbox.axle.insure
```

## Testing Ignition completions in the sandbox

### Result: `link`

#### Using test credentials to complete Login

1. Generate an `Ignition` session. ([more details can be found here](/api-reference/ignition/start-ignition))
2. Once an `Ignition` session has been generated , select one of the test credentials based on which Axle scenario you would like to test. These credentials can be used for any carrier listed.
3. Input credentials into login page to simulate connecting to an insurance account for the selected carrier.
4. If applicable, complete the Ignition session by selecting a policy that you would like to test against.

Congrats! Now you can access sample [Account](/api-reference/accounts/account) or [Policy](/api-reference/policies/policy) objects after exchanging the generated `authCode` for an `accessToken`. See the [Quickstart](/guides/quickstart) guide for more details.

#### Test user credentials

<AccordionGroup>
  <Accordion title="Auto">
    The following credentials will connect to an account with a comprehensive set of `auto` policies.

    ```
    username: user-auto
    password: pass-auto
    ```

    Policies:

    * `2019 Mercedes-Benz C 300` — Active **current term** auto policy for a 2019 Mercedes-Benz C 300
      * Both renewal and current terms are available and will be immediately available via Axle API when this policy is selected. In Get Policy API call, provide optional `term=renewal` query parameter. More info can be found [here](/api-reference/policies/get-policy#parameter-renewal).
    * `2013 Hyundai Sonata` — Active **current term** auto policy for a 2013 Hyundai Sonata
      * Both renewal and current terms are available and will be immediately available via API when this policy is selected.
    * `Missing expiration date` — Policy with expiration date null
    * `Missing documents` — Policy with no documents
    * `Missing several policy details and no documents` — Policy missing coverages, expiration date, insureds, and premium and has no documents
    * `Renewal Policy` - Only renewal auto policy will be available. No current active auto policy available (i.e. `effectiveDate` on the policy is in the future)
    * `State Minimum` — Active auto policy which represents the minimum state-required coverage in most states (only BI and PD coverage)
  </Accordion>

  <Accordion title="Home">
    The following credentials will connect to an account with several active `home` policies.

    ```
    username: user-home
    password: pass-home
    ```

    Policies:

    * `123 Fake St., Atlanta, GA 30303` — Active **current term** home policy for this address
      * Renewal term is available and will be immediately available via Axle API when this policy is selected. In Get Policy API call, provide optional `term=renewal` query parameter. More info can be found [here](/api-reference/policies/get-policy#parameter-renewal).
    * `123 Sample Ln., Atlanta, GA 30303` — Active **current term** home policy for this address
      * Renewal term is available and will be immediately available via API when this policy is selected.
    * `Missing policy details` — Policy missing key details, including effective and expiration dates, premium, and third parties
    * `Missing policy details and documents` — Policy missing details, including effective and expiration dates, premium, and third parties, and has no documents
    * `Missing policy details and documents` — Policy missing details, including effective and expiration dates, premium, insureds, and third parties, and has no documents
    * `Missing policy details` — Policy missing key details, including effective and expiration dates, premium, insureds, and third parties.
    * `Missing declaration page` — Policy with documents but only includes a policy agreement, not a declarations page.
    * `Missing insured types` — Policy missing insured types.
    * `Pre-effective policy` — Pre-effective policy, an active policy with an effective date in the future
    * `Renewal Policy` - Only renewal auto policy will be available. No current active auto policy available (i.e. `effectiveDate` on the policy is in the future)
  </Accordion>

  <Accordion title="Renters">
    The following credentials will connect to an account with an active `renters` policy.

    ```
    username: user-renters
    password: pass-renters
    ```

    Policies:

    * `123 Main St, Unit 456, Atlanta, GA 30303` — Active renters policy for this address.
  </Accordion>

  <Accordion title="Flood">
    The following credentials will connect to an account with several active `flood` policies.

    ```
    username: user-flood
    password: pass-flood
    ```

    Policies:

    * `123 Fake St., Atlanta, GA 30303` — Active flood policy for this address.
    * `Missing documents` — Flood policy with no documents.
    * `Missing coverage details` — Flood policy missing coverage details
    * `Missing policy details and no documents` — Policy missing multiple details and has no documents.
  </Accordion>

  <Accordion title="Error">
    The following credentials will fail to connect to the Axle service, resulting in an `errored` status for the Ignition session.

    ```
    username: user-error
    password: pass-error
    ```

    Policies:

    * This credential simulates an error during the account step so no policies are available.
  </Accordion>
</AccordionGroup>

#### Using test inputs to complete Policy Lookup

1. After generating an `Ignition` session, select one of the below test inputs based on which Axle scenario you would like to test. These inputs can only be used for carriers that support Policy Lookup.
2. Navigate to a carrier which supports Policy Lookup.
3. Click on "Search your policy number" to arrive at the Policy Lookup page.
4. Type in the test inputs and click on "Search" to simulate searching for policy details from the selected carrier.

After seeing the Success page, you can now access sample [Account](/api-reference/accounts/account) or [Policy](/api-reference/policies/policy) objects after exchanging the generated `authCode` for an `accessToken`. See the [Quickstart](/guides/quickstart) guide for more details.

#### Test credentials for Policy Lookup

<AccordionGroup>
  <Accordion title="Auto">
    **Active Policy**

    The following test inputs will connect to a sample `auto` policy.

    ```
    Policy number: A123456789
    VIN: 12345
    ```

    **Inactive Policy**

    The following test inputs will connect to a sample inactive `auto` policy.

    ```
    Policy number: A12121212
    VIN: 12121
    ```
  </Accordion>

  <Accordion title="Home">
    **Active Policy**

    The following test inputs will connect to a sample `home` policy.

    ```
    Policy number: H123456789
    Postal code: 30303
    Address (for Ignition Proxy only): Enter either any valid US address string or an address object with `addressLine1`, `addressLine2`, `city`, `state`, `postalCode`, and `country`
    insuredName (for Ignition Proxy only): "John Smith"
    ```

    **Inactive Policy**

    The following test inputs will connect to a sample inactive `home` policy.

    ```
    Policy number: H121212121
    Postal code: 30303
    Address (for Ignition Proxy only): Enter either any valid US address string or an address object with `addressLine1`, `addressLine2`, `city`, `state`, `postalCode`, and `country`
    insuredName (for Ignition Proxy only): "John Smith"
    ```
  </Accordion>

  <Accordion title="Error">
    The following inputs will fail to connect to the Axle service, resulting in an `errored` status for the Ignition session.

    ```
    Policy number: error
    ```
  </Accordion>
</AccordionGroup>

### Result: `manual`

You can complete Ignition sessions manually by selecting "My carrier is not listed" on the carrier selection page and then uploading any document of the allowed types (defaults to `pdf`, `jpg`, `jpeg`, `png`).

<Tip>
  Your Axle `client` will be configured in the sandbox to mirror what will be
  used by your application's production environment. Contact the Axle team if
  you would like to make any changes, such as enabling "manual" Ignition
  completions.
</Tip>

#### Sending test documents through Axle's Document AI

If your Axle `client` is configured to used Document AI, you can use the following test documents to complete Ignition sessions and receive the expected Policy response.

<Tabs>
  <Tab title="Auto policy">
    <Card title="Identification (ID) card" icon="file" href="https://axle-labs-assets.s3.amazonaws.com/docs/id-card.png" />

    <Card title="Declarations page" icon="file" href="https://axle-labs-assets.s3.amazonaws.com/docs/declarations-page.pdf" />
  </Tab>

  <Tab title="Home policy">
    <Card title="Declarations page" icon="file" href="https://axle-labs-assets.s3.amazonaws.com/docs/home-declarations-page.pdf" />
  </Tab>
</Tabs>

#### Document AI failure and inaccuracy cases

If your Axle `client` is configured to use Document AI, you can use the following test documents to simulate failure and inaccuracy scenarios.

<Warning>
  Do not change the name of the documents and upload them through the Ignition
  flow to trigger the corresponding behavior.
</Warning>

<Tabs>
  <Tab title="Auto policy">
    Use the following test documents for auto policies.

    <Tabs>
      <Tab title="Missing data">
        These documents will return a successful response with missing or incomplete data fields in the resulting Policy.

        <Card title="ID card without expiration date" icon="file" href="https://axle-labs-assets.s3.amazonaws.com/docs/id-card-missing-expiration.png" />

        <Card title="Declarations page without coverages" icon="file" href="https://axle-labs-assets.s3.amazonaws.com/docs/declaration-page-missing-coverages.pdf" />

        <Card title="Declarations page without third parties" icon="file" href="https://axle-labs-assets.s3.amazonaws.com/docs/declaration-page-missing-third-parties.pdf" />
      </Tab>

      <Tab title="Error cases">
        These documents will trigger Document AI errors.

        <Card title="Blank document" icon="file" href="https://axle-labs-assets.s3.amazonaws.com/docs/declaration-page-blank.pdf" />
      </Tab>

      <Tab title="Enhanced manual push-through">
        Upload a file named `enhanced-manual-push-through` (any extension) to simulate Document AI failing to extract data and the case where we are unable to process the document. After multiple attempts, Axle will automatically fall back to the enhanced manual push-through flow, accepting the original source file as uploaded, and the policy will be created with carrier set to "Other" and minimal data fields.

        <Card title="Enhanced manual push-through document" icon="file" href="https://axle-labs-assets.s3.amazonaws.com/docs/enhanced-manual-push-through.png" />
      </Tab>
    </Tabs>
  </Tab>

  <Tab title="Home policy">
    Use the following test documents for home policies.

    <Tabs>
      <Tab title="Missing data">
        These documents will return a successful response with missing or incomplete data fields in the resulting Policy.

        <Card title="Declarations page without coverages" icon="file" href="https://axle-labs-assets.s3.amazonaws.com/docs/home-declaration-page-missing-coverages.pdf" />

        <Card title="Declarations page without third parties" icon="file" href="https://axle-labs-assets.s3.amazonaws.com/docs/home-declaration-page-missing-third-parties.pdf" />
      </Tab>

      <Tab title="Error cases">
        These documents will trigger Document AI errors.

        <Card title="Blank document" icon="file" href="https://axle-labs-assets.s3.amazonaws.com/docs/declaration-page-blank.pdf" />

        <Card title="Unsupported document type" icon="file" href="https://axle-labs-assets.s3.amazonaws.com/docs/document-type-not-supported.png" />
      </Tab>

      <Tab title="Enhanced manual push-through">
        Upload a file named `enhanced-manual-push-through` (any extension) to simulate Document AI failing to extract data and the case where we are unable to process the document. After multiple attempts, Axle will automatically fall back to the enhanced manual push-through flow, accepting the original source file as uploaded, and the policy will be created with carrier set to "Other" and minimal data fields.

        <Card title="Enhanced manual push-through document" icon="file" href="https://axle-labs-assets.s3.amazonaws.com/docs/enhanced-manual-push-through.pdf" />
      </Tab>
    </Tabs>
  </Tab>
</Tabs>


# Monitoring notifications
Source: https://docs.axle.insure/guides/sandbox/monitoring-notifications

Test in Sandbox environment notification for monitoring enabled accounts and policies

After completing an Ignition session and exchanging the `authCode` for an `accessToken`, you can trigger an Account event through [`POST /sandbox/account/{accountId}/event`](/api-reference/sandbox/trigger-account-event) or Policy event through [`POST /sandbox/policies/{policyId}/event`](/api-reference/sandbox/trigger-policy-event).

<Tip>
  You can also test notifications sent to other communication channels such as
  email or Slack by making a request to the same Axle API endpoints. Reach out
  to the Axle team to ensure your `client` is properly configured!
</Tip>

The following [Account events](/guides/account-events) and [Policy events](guides/policy-events) are supported:

**account.modified**

You can modify Account fields to simulate an `account.modified` event. The following example will change `email`, `firstName`, and `phone` fields on an existing Account.

```
{
  "email": "updatedEmail@axle.insure",
  "firstName": "Jane",
  "phone" "+14041230101"
}
```

**account.disconnected**

You can test `account.disconnected` event by setting the connection status to one of the "inactive" states. Refer to Account object for all the available [cases](/api-reference/accounts/account).

```
{
  "connection": {
      "status": "credentials-expired"
  }
}
```

<Info>
  When account has been set as `disconnected`, your user will need to complete
  an Axle Ignition session to reconnect it. If the user reconnects the same
  insurance account and policy, Axle will merge the updated information with any
  existing Account or Policy objects. More info on `account.disconnected` can be
  found [here](/guides/account-events#account-disconnected).
</Info>

**policy.modified**

You can modify Policy fields to simulate a `policy.modified` event. The following example will set Policy as inactive (e.g., the policy has been cancelled) as well as update the Policy address.

```
{
  "isActive": false,
  "address": {
      "addressLine1": "New Street",
      "addressLine2": "New Apt",
      "city": "Atlanta",
      "postalCode": "30315",
      "state": "GA",
      "country": "USA"
  }
}
```


# Validate Policy with Template
Source: https://docs.axle.insure/guides/sandbox/validate-policy-with-template

Evaluate a set of Rules against a policy to determine if your application’s requirements are met.

<Info>
  If you have not received access to the Axle sandbox, please reach out to the
  Axle team!
</Info>

## Step 1: Create and complete Ignition session

Follow the steps provided in [this guide](/guides/sandbox-ignition-completion) to create and complete ignition session. Once complete, note your [policy identifier](/api-reference/policies/policy#fields) which will be used to make API call to policy validation engine.

### Optional: Provide `metadata` object when generating ignition session

Include `metadata` in [Start Ignition](/api-reference/ignition/start-ignition) to supply dynamic rule input values at session creation time. At validation time, Axle resolves each rule input by looking up the `source` key defined in the template — first in the validate request body, then in the Ignition session metadata, and finally falling back to the template's `default`.

Keys must match your template `source` values; **metadata** shape and allowed types are defined in [Start Ignition](/api-reference/ignition/start-ignition).

## Step 2: Create Validation Templates

Start by identifying the [rules](/guides/validate/policy-validation#supported-rules) you want to use. Then, either [create](/api-reference/validation/templates/create-template) a new template or [modify](/api-reference/validation/templates/update-template) an existing one.

You can always look into the content and inputs for your template using [getTemplate API](/api-reference/validation/templates/get-template) endpoint

## Step 3: Validate `policy` using template

Use the template identifier to call [Validate Policy with Template](/api-reference/validation/validate-policy-template).

For validation rules that require input parameters (e.g. `comprehensive-coverage-meets-requirements`), supply values in the request body as documented on that endpoint (same rules as session `metadata` on Start Ignition). Keys must match each rule input’s `source`; request body values take priority over Ignition session metadata.

For example, if your template defines `"source": "maxDeductible"` on a rule input, pass `{ "maxDeductible": 500 }` in the request body.

More information about rules with `input` can be found [here](/api-reference/validation/templates/get-template#response-data-rules)


# Policy Validation
Source: https://docs.axle.insure/guides/validate/policy-validation

Evaluate a set of Rules against a policy to determine if your application's requirements are met.

## Overview

When embedding insurance verification into your application, you may want to evaluate whether a shared insurance policy meets your business' requirements. Each supported Rule is an individual check evaluated against the [Policy](/api-reference/policies/policy) object to determine if the Policy meets a certain requirement or set of requirements.

For example, the `policy-active` Rule checks if the policy is currently active, evaluating to `pass` if the `isActive` field of the policy is `true` and `fail` if it is `false`. If `isActive` is `null` (not provided by the insurance carrier), this Rule will resolve to `unknown`.

Some Rules are more complex, providing additional insight not found on the Policy object. For example, the `rental-covered-for-collision` Rule provides guidance on whether a policy affords coverage for collision damage when an insured is driving a rental vehicle.

Some Rules require additional input to be evaluated. For example, the `expiration-date-comparison` Rule requires an input date to compare against the policy's expiration date. For more details on the additional inputs that a Rule may require, refer to [Supported Rules](/guides/validate/policy-validation#supported-rules).

Each Rule evaluates to one of the following statuses:

| Status    | Description                                                                                               |
| --------- | --------------------------------------------------------------------------------------------------------- |
| `pass`    | The policy meets all requirements of the Rule                                                             |
| `fail`    | The policy does not meet all the requirements of the Rule                                                 |
| `caution` | The policy only partially meets the requirements of the Rule or the Rule returns an inconclusive outcome. |
| `unknown` | Not enough data was available to determine the outcome of the Rule                                        |

## Requesting Evaluation Rules

You can request that a Policy be evaluated against a specified set of Rules through the [Validate Policy](/api-reference/validation/templates/validate-policy) endpoint. Each Rule you requested will be run, and you'll receive a response with an overall status determination of either `pass`, `fail`, or `caution`.

* `pass` means that the policy succeeded in passing against all of the specified Rules.
* `fail` means that one or more specified Rules evaluated to a status of `fail`.
* `caution` means that one or more specified Rules evaluated to a status of `caution`. In most cases, it is recommended to complete a manual review of the policy.

The response also contains three other fields:

* `summary` - An object containing the names of all Rules on the policy and their resolved statuses.
* `rules` - An object containing the names of each Rules and their run details.
* `validationResult` - The unique identifier for the validation result of this request.

<CodeGroup>
  ```json Overall Status: Pass theme={null}
  {
    "status": "pass",
    "summary": {
      "policy-active": "pass",
      "rental-covered-for-collision": "pass",
    },
    "rules": {
      "policy-active":{
        "status": "pass",
        "metadata": {...},
      },
      "rental-covered-for-collision": {
        "status": "pass",
        "breakdown": {...},
        "metadata": {...}
      }
    },
    "validationResult": "val_abcdef123456"
  }
  ```

  ```json Overall Status: Fail theme={null}
  {
    "status": "fail",
    "summary": {
      "policy-active": "pass",
      "rental-covered-for-collision": "fail",
    },
    "rules": {
      "policy-active":{
        "status": "pass",
        "metadata": {...},
      },
      "rental-covered-for-collision": {
        "status": "fail",
        "breakdown": {...},
        "metadata": {...}
      }
    },
    "validationResult": "val_abcdef123456"
  }
  ```
</CodeGroup>

## Supported Rules

<Info>
  The Axle team is actively working on adding additional supported Rules. Please
  reach out with any suggestions!
</Info>

<AccordionGroup>
  <Accordion title="Policy is Active">
    ### `policy-active`

    Evaluates whether the policy is currently active.

    | Status    | Cause                                                                                                 |
    | --------- | ----------------------------------------------------------------------------------------------------- |
    | `pass`    | The policy is currently active                                                                        |
    | `fail`    | The policy is not currently active                                                                    |
    | `caution` | The `isActive` field is `null`, meaning Axle could not confirm the `isActive` status with the carrier |
    | `unknown` | The `isActive` field is `undefined`, meaning it's a manual policy                                     |

    ```typescript Example Rule theme={null}
    "policy-active": {
      "status": "pass",
      "metadata": {
        "isActive": true
      }
    }
    ```
  </Accordion>

  <Accordion title="Rental Vehicle is Covered For Collision Damage">
    ### `rental-covered-for-collision`

    Evaluates the likelihood that the policy provides coverage for collision damage when an insured is driving a rental vehicle, based on the collision coverage available on the policy and the policy terms of insurance agreements similar to the one used by this policy.

    There are three ways that a user’s auto insurance policy may cover collision damage to a rental vehicle.

    1. Their policy includes collision coverage and personal collision coverage extends to a rental vehicle.
    2. Their policy is registered in a state in which policies are required to cover collision damage to a rental vehicle under property damage liability terms.
    3. Their policy is registered in a state in which policies are required to cover collision damage to a rental vehicle under an endorsement.

    If any of these are true, then the `rental-covered-for-collision` Rule resolves to `pass`.

    #### Rental Coverage Validation AI

    In order to determine if a policy meets these criteria, Axle's Validation AI matches the auto policy to a repository of up-to-date policy agreements (also known as forms) as well as any relevant state regulations, and then synthesizes these resources into a recommendation.

    <Warning>
      The `rental-covered-for-collision` recommendation may not apply the following scenarios:

      * long term rentals (greater than 30 days)
      * rental of medium or heavy duty vehicles (above 10,000 lbs)
      * use of temporary substitute vehicles (such as replacement or loaner vehicle)
      * use of rental vehicle for TNC, DNC, or other auto business
      * rentals outside of the continental United States

      The recommendation made by the Rental Coverage Validation AI should not be treated as legal advice. It is made on a "best-effort" basis.
    </Warning>

    | Status    | Cause                                                                                                                                                                  |
    | --------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
    | `pass`    | The policy is likely to cover an insured for collision damage to their rental vehicle either because of their personal collision coverage or due to state regulations. |
    | `fail`    | The policy is unlikely to provide coverage for collision damage to a rental vehicle.                                                                                   |
    | `caution` | The Rental Coverage Validation AI is not confident in its recommendation.                                                                                              |
    | `unknown` | The policy cannot be matched to the required resources to make a recommendation.                                                                                       |

    This Validation also returns a message and message code, which can be used to explain to the user why the policy is or is not likely to cover collision damage to a rental vehicle.

    | Message Code                        | Evaluation Status | Message                                                                                                                                                     |
    | ----------------------------------- | ----------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- |
    | coll-extends-to-rental              | `pass`            | The policy has collision coverage and the matching policy agreements indicate that collision coverage extends to rental vehicles.                           |
    | pd-covers-rental-collision          | `pass`            | The policy is underwritten in a state in which policies are required to cover collision damage under property damage liability terms.                       |
    | endorsement-covers-rental-collision | `pass`            | The policy is underwritten in a state in which policies are required to cover collision damage under an endorsement.                                        |
    | coll-extends-to-rental-with-caution | `caution`         | The policy has collision coverage, but the matching policy agreements have conflicting answers about whether collision coverage extends to rental vehicles. |
    | coll-extends-to-rental-with-unknown | `unknown`         | The policy has collision coverage, but there is not enough information to determine if the policy extends collision coverage to rental vehicles.            |
    | coll-does-not-extend-to-rental      | `fail`            | The policy has collision coverage, but the matching policy agreements indicate that collision coverage does not extend to rental vehicles.                  |
    | coll-not-present                    | `fail`            | The policy does not have collision coverage, and therefore cannot extend collision coverage to rental vehicles.                                             |
    | coll-presence-unknown               | `unknown`         | It is unknown if the policy has collision coverage, and therefore it is unknown if the policy extends collision coverage to rental vehicles.                |

    ```typescript Example Rule theme={null}
    "rental-covered-for-collision": {
      "status": "pass",
      "message": {
        "code": "coll-extends-to-rental"
        "displayText": "The policy has collision coverage and the matching policy agreements indicate that collision coverage extends to rental vehicles."
      }
      "breakdown": {
        "collision-exists": {
          "value": "pass",
          "metadata": {
            "coverages": [
              {
                "code": "COLL",
                "label": "Collision",
                "deductible": 375,
                "property": "prp_uSdzLVpi8c76H7kl6AQ-F"
              }
            ],
            "input": {
              "coverageCode": "COLL"
            }
          }
          "collision-coverage-extends-to-rental": {
            "status": "pass",
            "metadata": {
              "carrier": "state-farm",
              "state": "NY"
            }
          },
          "property-damage-covers-rental-collision": {
            "status": "pass",
            "metadata": {
              "coverages": [
                {
                  "code": "PD",
                  "label": "Property Damage",
                  "limitPerAccident": 50000,
                  "property": "prp_uSdzLVpi8c76H7kl6AQ-F"
                }
              ],
              "state": "NY"
            }
          },
          "endorsement-covers-rental-collision": {
            "status": "pass",
            "metadata": {
              "state": "NY"
            }
          }
        }
      },
      "metadata": {
      }
    }
    ```

    #### Testing in Sandbox

    All sandbox `Auto` policies currently support policy validation testing, but we've also curated a special set of test policies specifically to provide options for testing the various outcomes of the `rental-covered-for-collision` Rule.

    Enter the following credentials into an ignition session, and then select the policy labeled with the message code you would like to test. The message codes and their explanations are listed in the table above.

    ```
    username: user-rental-cover
    password: pass-rental-cover
    ```
  </Accordion>

  <Accordion title="Policy Expiration Date is After Provided Date">
    ### `expiration-date-comparison`

    Given an input date, evaluates whether the policy's expiration date is greater than or equal to (on or after) the input date.

    If no input date is provided, the rule will default to comparing the policy's expiration date against today's date (UTC).

    | Status    | Cause                                                                |
    | --------- | -------------------------------------------------------------------- |
    | `pass`    | The policy's expiration date is on or after the provided input date. |
    | `fail`    | The policy's expiration date is before the provided input date.      |
    | `unknown` | The policy's expiration date is `null`.                              |

    This Rule optionally accepts additional input to be evaluated. If provided, the `date` must be an ISO 8601 string representing the date to compare against the policy's expiration date. If omitted, the rule defaults to using today's date.

    For example, valid input dates could be `2025-01-01` or `2025-01-01T00:00:00.000Z`. If an invalid `date` is provided, this Rule will return a `400` response code.

    ```typescript theme={null}
    {
      "rule": "expiration-date-comparison",
      "input": {
        "date": "2025-01-01"
      }
    }
    ```

    The returned evaluation will include

    * The policy's expiration date.
    * The input date that was provided.

    ```typescript theme={null}
    "expiration-date-comparison": {
      "status": "pass",
      "metadata": {
        "policyExpirationDate": "2025-02-01",
        "input": {
          "date": "2025-01-01"
        }
      }
    }
    ```
  </Accordion>

  <Accordion title="Collision Coverage Meets Requirements">
    ### `collision-coverage-meets-requirements`

    Evaluates whether the policy has collision coverage and if the coverage meets specific deductible requirements. This rule can evaluate coverage requirements for a specific vehicle (using VIN) or for the entire policy.

    **Input Parameters**

    * `vin` (optional): The Vehicle Identification Number to check for collision coverage specific to a vehicle.
    * `deductible` (optional): A specific collision deductible amount you want to verify against the policy.

    **Evaluation Criteria**

    The Rule is evaluated based on the following two criteria. Both of these criteria must be true for the `collision-coverage-meets-requirements` Rule to resolve to `pass`.

    1. `collision-exists`: Determines if collision coverage is present on the policy for any vehicle or, if a `vin` is provided, for a specified vehicle.

    2. `collision-deductible-comparison` (optional): Verifies if the provided `deductible` is less than or equal to the deductible specified in the collision coverage of the policy. This criteria will only run if `collision-exists` results in a `pass` and the optional `deductible` is provided.
       * If no `vin` is provided, the provided `deductible` will be verified against all collision coverages listed on the policy.
       * If a `vin` is provided, the provided `deductible` will be verified against only the collision coverage listed for the specified vehicle.

    | Status    | Cause                                                                                                          |
    | --------- | -------------------------------------------------------------------------------------------------------------- |
    | `pass`    | The policy has collision coverage and meets all specified requirements (`deductible` and/or `vin` if provided) |
    | `fail`    | The policy either lacks collision coverage or doesn't meet the specified deductible requirements               |
    | `unknown` | Not enough information was available to evaluate the coverage requirements                                     |

    This Rule also returns a message and message code, which can be used to explain to the user why the Rule failed to result in a `pass`.

    | Message Code                    | Evaluation Status | Message                                                                                                                     |
    | ------------------------------- | ----------------- | --------------------------------------------------------------------------------------------------------------------------- |
    | coll-exists                     | `pass`            | The COLL coverage exists on this policy.                                                                                    |
    | coll-exists-for-vin             | `pass`            | The COLL coverage exists on this policy for the specified vehicle.                                                          |
    | coll-valid-deductible           | `pass`            | The COLL coverage(s) on this policy have deductible(s) less than or equal to \[inputDeductible].                            |
    | coll-valid-deductible-for-vin   | `pass`            | The COLL coverage(s) on this policy for this specified vehicle have deductible(s) less than or equal to \[inputDeductible]. |
    | coll-does-not-exist             | `fail`            | The COLL coverage does not exist on this policy.                                                                            |
    | coll-does-not-exist-for-vin     | `fail`            | The COLL coverage does not exist on this policy for the specified vehicle.                                                  |
    | coll-invalid-deductible         | `fail`            | The COLL coverage(s) on this policy all have deductibles greater than \[inputDeductible].                                   |
    | coll-invalid-deductible-for-vin | `fail`            | The COLL coverage(s) on this policy for this specified vehicle all have deductibles greater than \[inputDeductible].        |
    | coll-unknown-deductible         | `unknown`         | The COLL coverage(s) on this policy have unknown deductibles.                                                               |
    | coll-unknown-vin                | `unknown`         | The Axle Policy has incomplete property VIN data. Validation cannot be performed.                                           |

    **Example Usage**

    This example Rule will verify if the policy contains collision coverage for the vehicle with the given `vin` and that the `deductible` for that coverage is less than or equal to \$1,000.

    ```typescript Example Rule Request theme={null}
    {
      rule: "collision-coverage-meets-requirements",
      input: {
        vin: "5FNRL38209B014050",
        deductible: 1000
      }
    }
    ```

    ```typescript Example Rule Response theme={null}
    "collision-coverage-meets-requirements": {
          status: "pass",
          metadata: {
            input: {
              vin: "5FNRL38209B014050",
              deductible: 1000
            }
          },
          breakdown: {
            "collision-exists": {
              status: "pass",
              metadata: {
                coverages: [
                  {
                    code: "COLL",
                    label: "Collision",
                    deductible: 500,
                    property: "prp_tmGUxLpgHjmW9r6M6WjhS",
                  },
                ],
                input: {
                  coverageCode: "COLL",
                  vin: "5FNRL38209B014050",
                }
              },
            },
            "collision-deductible-comparison": {
              status: "pass",
              metadata: {
                coverages: [
                  {
                    code: "COLL",
                    label: "Collision",
                    deductible: 500,
                    property: "prp_tmGUxLpgHjmW9r6M6WjhS",
                  },
                ],
                input: { deductible: 1000, vin: "5FNRL38209B014050" },
              },
            },
          },
          message: {
            code: "coll-valid-deductible-for-vin",
            displayText:
              "The COLL coverage(s) on this policy for this specified vehicle have deductible(s) less than or equal to $1000.",
          },
        }
    ```
  </Accordion>

  <Accordion title="Comprehensive Coverage Meets Requirements">
    ### `comprehensive-coverage-meets-requirements`

    Evaluates whether the policy has comprehensive coverage and if the coverage meets specific deductible requirements. This rule can evaluate coverage requirements for a specific vehicle (using VIN) or for the entire policy.

    **Input Parameters**

    * `vin` (optional): The Vehicle Identification Number to check for comprehensive coverage specific to a vehicle.
    * `deductible` (optional): A specific comprehensive deductible amount you want to verify against the policy.

    **Evaluation Criteria**

    The Rule is evaluated based on the following two criteria. Both of these criteria must be true for the `comprehensive-coverage-meets-requirements` Rule to resolve to `pass`.

    1. `comprehensive-exists`: Determines if comprehensive coverage is present on the policy for any vehicle or, if a `vin` is provided, for a specified vehicle.

    2. `comprehensive-deductible-comparison` (optional): Verifies if the provided `deductible` is less than or equal to the deductible specified in the comprehensive coverage of the policy. This criteria will only run if `comprehensive-exists` results in a `pass` and the optional `deductible` is provided.

    * If no `vin` is provided, the provided `deductible` will be verified against all comprehensive coverages listed on the policy.
    * If a `vin` is provided, the provided `deductible` will be verified against only the comprehensive coverage listed for the specified vehicle.

    | Status    | Cause                                                                                                              |
    | --------- | ------------------------------------------------------------------------------------------------------------------ |
    | `pass`    | The policy has comprehensive coverage and meets all specified requirements (`deductible` and/or `vin` if provided) |
    | `fail`    | The policy either lacks comprehensive coverage or doesn't meet the specified deductible requirements               |
    | `unknown` | Not enough information was available to evaluate the coverage requirements                                         |

    This Rule also returns a message and message code, which can be used to explain to the user why the Rule failed to result in a `pass`.

    | Message Code                    | Evaluation Status | Message                                                                                                                     |
    | ------------------------------- | ----------------- | --------------------------------------------------------------------------------------------------------------------------- |
    | comp-exists                     | `pass`            | The COMP coverage exists on this policy.                                                                                    |
    | comp-exists-for-vin             | `pass`            | The COMP coverage exists on this policy for the specified vehicle.                                                          |
    | comp-valid-deductible           | `pass`            | The COMP coverage(s) on this policy have deductible(s) less than or equal to \[inputDeductible].                            |
    | comp-valid-deductible-for-vin   | `pass`            | The COMP coverage(s) on this policy for this specified vehicle have deductible(s) less than or equal to \[inputDeductible]. |
    | comp-does-not-exist             | `fail`            | The COMP coverage does not exist on this policy.                                                                            |
    | comp-does-not-exist-for-vin     | `fail`            | The COMP coverage does not exist on this policy for the specified vehicle.                                                  |
    | comp-invalid-deductible         | `fail`            | The COMP coverage(s) on this policy all have deductibles greater than \[inputDeductible].                                   |
    | comp-invalid-deductible-for-vin | `fail`            | The COMP coverage(s) on this policy for this specified vehicle all have deductibles greater than \[inputDeductible].        |
    | comp-unknown-deductible         | `unknown`         | The COMP coverage(s) on this policy have unknown deductibles.                                                               |
    | comp-unknown-vin                | `unknown`         | The Axle Policy has incomplete property VIN data. Validation cannot be performed.                                           |

    **Example Usage**

    This example Rule will verify if the policy contains comprehensive coverage for the vehicle with the given `vin` and that the `deductible` for that coverage is less than or equal to \$1,000.

    ```typescript Example Rule Request theme={null}
    {
      rule: "comprehensive-coverage-meets-requirements",
      input: {
        vin: "5FNRL38209B014050",
        deductible: 1000
      }
    }
    ```

    ```typescript Example Rule Response theme={null}
    "comprehensive-coverage-meets-requirements": {
      status: "pass",
      metadata: {
        input: {
            vin: "5FNRL38209B014050",
            deductible: 1000
          }
      },
      breakdown: {
        "comprehensive-exists": {
          status: "pass",
          metadata: {
            coverages: [
              {
                code: "COMP",
                label: "Comprehensive",
                deductible: 500,
                property: "prp_tmGUxLpgHjmW9r6M6WjhS",
              },
            ],
            input: {
              coverageCode: "COMP",
              vin: "5FNRL38209B014050",
            }
          },
        },
        "comprehensive-deductible-comparison": {
          status: "pass",
          metadata: {
            coverages: [
              {
                code: "COMP",
                label: "Comprehensive",
                deductible: 500,
                property: "prp_tmGUxLpgHjmW9r6M6WjhS",
              },
            ],
            input: { deductible: 1000, vin: "5FNRL38209B014050" },
          },
        },
      },
      message: {
        code: "comp-valid-deductible-for-vin",
        displayText:
          "The COMP coverage(s) on this policy for this specified vehicle have deductible(s) less than or equal to $1000.",
      },
    }
    ```
  </Accordion>

  <Accordion title="Bodily Injury Coverage Meets Requirements">
    ### `bodily-injury-coverage-meets-requirements`

    Evaluates whether the policy has bodily injury coverage and if the coverage meets specific limit requirements.

    **Input Parameters**

    * `limitPerAccident` (optional): The limitPerAccident amount you want to verify against the policy.
    * `limitPerPerson` (optional): The limitPerPerson amount you want to verify against the policy.

    **Evaluation Criteria**

    The Rule is evaluated based on the following criteria, depending on if any limit was passed in. If no limits are passed in, then the Rule is evaluated based off if bodily injury coverage exists on the policy.

    1. `bodily-injury-exists`: Determines if bodily injury coverage is present on the policy.

    2. `bodily-injury-limit-per-person-comparison` (if applicable): Determines if the `limitPerPerson` specified on the policy's bodily injury coverage is greater than or equal to the provided `limitPerPerson`.

    3. `bodily-injury-limit-per-accident-comparison` (if applicable): Determines if the `limitPerAccident` specified on the policy's bodily injury coverage is greater than or equal to the provided `limitPerAccident`.

    | Status    | Cause                                                                                           |
    | --------- | ----------------------------------------------------------------------------------------------- |
    | `pass`    | The policy has bodily injury coverage and meets all specified limit requirements                |
    | `fail`    | The policy either lacks bodily injury coverage or doesn't meet the specified limit requirements |
    | `unknown` | Not enough information was available to evaluate the coverage requirements                      |

    This Rule also returns a message and message code which can be used to explain to the user why the Rule failed to result in a `pass`.

    | Message Code                             | Evaluation Status | Message                                                                                                                                         |
    | ---------------------------------------- | ----------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |
    | bodily-injury-exists                     | `pass`            | The BI coverage exists on this policy.                                                                                                          |
    | bodily-injury-valid-limit-per-person     | `pass`            | The BI coverage on this policy has a `limitPerPerson` greater than or equal to \[inputLimitPerPerson].                                          |
    | bodily-injury-valid-limit-per-accident   | `pass`            | The BI coverage on this policy has a `limitPerAccident` greater than or equal to \[inputLimitPerAccident].                                      |
    | bodily-injury-valid-limits               | `pass`            | The BI coverage on this policy has limits greater than or equal to \[inputLimitPerPerson] per person and \[inputLimitPerAccident] per accident. |
    | bodily-injury-invalid-limit-per-person   | `fail`            | The BI coverage on this policy has a `limitPerPerson` less than to \[inputLimitPerPerson].                                                      |
    | bodily-injury-invalid-limit-per-accident | `fail`            | The BI coverage on this policy has a `limitPerAccident` less than to \[inputLimitPerAccident].                                                  |
    | bodily-injury-invalid-limits             | `fail`            | The BI coverage on this policy has limits less than to \[inputLimitPerPerson] per person and \[inputLimitPerAccident] per accident.             |
    | bodily-injury-unknown-limit-per-person   | `unknown`         | The BI coverage on this policy has a `limitPerPerson` that is unknown.                                                                          |
    | bodily-injury-unknown-limit-per-accident | `unknown`         | The BI coverage on this policy has a `limitPerAccident` that is unknown.                                                                        |
    | bodily-injury-unknown-limits             | `unknown`         | The BI coverage on this policy has unknown limits.                                                                                              |

    **Example Usage**

    This example Rule will verify if the policy has bodily injury coverage and if the limitPerPerson on the coverage is greater than or equal to \$200,000.

    ```typescript Example Rule Request theme={null}
    {
      rule: "bodily-injury-coverage-meets-requirements",
      input: {
        limitPerPerson: 200000
      }
    }
    ```

    ```typescript Example Rule Response theme={null}
    "bodily-injury-coverage-meets-requirements": {
      status: "pass",
      metadata: {
        input: {
          limitPerPerson: 200000,
          limitPerAccident: undefined
        }
      },
      breakdown: {
        "bodily-injury-exists": {
          status: "pass",
          metadata: {
            coverages: [
              {
                code: "BI",
                label: "Bodily Injury",
                limitPerPerson: 250000,
                limitPerAccident: 500000
              },
            ],
            input: {
              coverageCode: "BI"
            }
          }
        },
        "bodily-injury-limit-per-person-comparison": {
          status: "pass",
          metadata: {
            coverages: [
              {
                code: "BI",
                label: "Bodily Injury",
                limitPerPerson: 250000,
                limitPerAccident: 500000,
              },
            ],
            input: {
              limitPerPerson: 200000,
            },
          },
        },
      },
      message: {
        code: "bodily-injury-valid-limit-per-person",
        displayText: "The BI coverage on this policy has a limitPerPerson greater than or equal to $200000.",
      }
    }
    ```
  </Accordion>

  <Accordion title="Uninsured/Underinsured Motorists Bodily Injury Coverage Meets Requirements">
    ### `uninsured-underinsured-bi-coverage-meets-requirements`

    Evaluates whether a policy includes uninsured motorists (UM), underinsured motorists (UIM), or uninsured/underinsured motorists (UUIM) bodily injury coverage and verifies if the coverage(s) meet the specified limit requirements.

    **Input Parameters**

    * `limitPerAccident` (optional): The limitPerAccident amount you want to verify against the policy.
    * `limitPerPerson` (optional): The limitPerPerson amount you want to verify against the policy.

    **Evaluation Criteria**

    The Rule is evaluated based on the following criteria. If no limits are specified in the input, then the Rule evaluates solely on the presence of any
    uninsured motorists, underinsured motorists, or uninsured/underinsured motorists bodily injury coverage on the policy.

    1. `uninsured-underinsured-bi-exists`: Determines if UM, UIM, or UUIM motorists bodily injury coverage is present on the policy.

    2. `uninsured-underinsured-bi-limit-per-person-comparison` (if applicable): Determines if the `limitPerPerson` on the policy's UM, UIM, or UUIM bodily injury coverage  is greater than or equal to the provided `limitPerPerson`.

    3. `uninsured-underinsured-bi-limit-per-accident-comparison` (if applicable): Determines if the `limitPerAccident` on the policy's UM, UIM, or UUIM bodily injury coverage  is greater than or equal to the provided `limitPerAccident`.

    | Status    | Cause                                                                                                                                              |
    | --------- | -------------------------------------------------------------------------------------------------------------------------------------------------- |
    | `pass`    | The policy has at least one of UM, UIM, or UUIM bodily injury and meets all specified limit requirements                                           |
    | `fail`    | The policy either doesn't have any UM, UIM, or UUIM bodily injury coverage, or has at least one but doesn't meet the specified limit requirements. |
    | `unknown` | Not enough information was available to evaluate the coverage requirements.                                                                        |

    This Rule also returns a message and message code which can be used to explain to the user why the Rule failed to result in a `pass`.

    | Message Code                                         | Evaluation Status | Message                                                                                                                                                                                 |
    | ---------------------------------------------------- | ----------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
    | uninsured-underinsured-bi-exists                     | `pass`            | At least one of UM, UIM, or UUIM bodily injury coverage exists on this policy.                                                                                                          |
    | uninsured-underinsured-bi-valid-limit-per-person     | `pass`            | At least one of UM, UIM, or UUIM bodily injury coverage on this policy has a `limitPerPerson` greater than or equal to \[inputLimitPerPerson].                                          |
    | uninsured-underinsured-bi-valid-limit-per-accident   | `pass`            | At least one of UM, UIM, or UUIM bodily injury coverage on this policy has a `limitPerAccident` greater than or equal to \[inputLimitPerAccident].                                      |
    | uninsured-underinsured-bi-valid-limits               | `pass`            | At least one of UM, UIM, or UUIM bodily injury coverage on this policy has limits greater than or equal to \[inputLimitPerPerson] per person and \[inputLimitPerAccident] per accident. |
    | uninsured-underinsured-bi-invalid-limit-per-person   | `fail`            | None of UM, UIM, or UUIM bodily injury coverage on this policy has a `limitPerPerson` greater than or equal to \[inputLimitPerPerson].                                                  |
    | uninsured-underinsured-bi-invalid-limit-per-accident | `fail`            | None of UM, UIM, or UUIM bodily injury coverage on this policy has a `limitPerAccident` greater than or equal to \[inputLimitPerAccident].                                              |
    | uninsured-underinsured-bi-invalid-limits             | `fail`            | None of UM, UIM, or UUIM bodily injury coverage on this policy has limits greater than or equal to \[inputLimitPerPerson] per person and \[inputLimitPerAccident] per accident.         |
    | uninsured-underinsured-bi-unknown-limit-per-person   | `unknown`         | At least one of UM, UIM, or UUIM bodily injury coverage on this policy has a `limitPerPerson` that is unknown.                                                                          |
    | uninsured-underinsured-bi-unknown-limit-per-accident | `unknown`         | At least one of UM, UIM, or UUIM bodily injury coverage on this policy has a `limitPerAccident` that is unknown.                                                                        |
    | uninsured-underinsured-bi-unknown-limits             | `unknown`         | At least one of UM, UIM, or UUIM bodily injury coverage on this policy has unknown limits.                                                                                              |

    **Example Usage**

    This example Rule will verify if the policy has at least one of UM, UIM, or UUIM bodily injury coverage and if the limitPerPerson on the coverage is greater than or equal to \$200,000.

    ```typescript Example Rule Request theme={null}
    {
      rule: "uninsured-underinsured-bi-coverage-meets-requirements",
      input: {
        limitPerPerson: 200000
      }
    }
    ```

    ```typescript Example Rule Response theme={null}
    "uninsured-underinsured-bi-coverage-meets-requirements": {
      status: "pass",
      metadata: {
        input: {
          limitPerPerson: 200000,
          limitPerAccident: undefined
        }
      },
      breakdown: {
        "uninsured-underinsured-bi-exists": {
          status: "pass",
          metadata: {
            coverages: [
              {
                code: "UMBI",
                label: "Uninsured Motorists Bodily Injury",
                limitPerPerson: 250000,
                limitPerAccident: 500000
              },
            ],
            input: {
              coverageCodes: ["UMBI", "UIMBI", "UUIMBI"]
            }
          }
        },
        "uninsured-underinsured-bi-limit-per-person-comparison": {
          status: "pass",
          metadata: {
            coverages: [
              {
                code: "UMBI",
                label: "Uninsured Motorists Bodily Injury",
                limitPerPerson: 250000,
                limitPerAccident: 500000,
              },
            ],
            input: {
              limitPerPerson: 200000,
            },
          },
        },
      },
      message: {
        code: "uninsured-underinsured-bi-valid-limit-per-person",
        displayText: "At least one of UM, UIM, or UUIM bodily injury coverage on this policy has a `limitPerPerson` greater than or equal to $200000.",
      }
    }
    ```
  </Accordion>

  <Accordion title="Property Damage Coverage Meets Requirements">
    ### `property-damage-coverage-meets-requirements`

    Evaluates whether the policy has property damage coverage and if the coverage meets specific limit requirements.

    **Input Parameters**

    * `limitPerAccident` (optional): The limitPerAccident amount you want to verify against the policy.

    **Evaluation Criteria**

    The Rule is evaluated based on the following criteria. If no limits are specified in the input, the Rule evaluates solely on the presence of property damage coverage on the policy.

    1. `property-damage-exists`: Determines if property damage coverage is present on the policy.

    2. `property-damage-limit-per-accident-comparison` (if applicable): Determines if the `limitPerAccident` specified on the policy's property damage coverage is greater than or equal to the provided `limitPerAccident`.

    | Status    | Cause                                                                                              |
    | --------- | -------------------------------------------------------------------------------------------------- |
    | `pass`    | The policy has property damage coverage and meets all specified limit requirements.                |
    | `fail`    | The policy either lacks property damage coverage or doesn't meet the specified limit requirements. |
    | `unknown` | Not enough information was available to evaluate the coverage requirements.                        |

    This Rule also returns a message and message code which can be used to explain to the user why the Rule failed to result in a `pass`.

    | Message Code                               | Evaluation Status | Message                                                                                                    |
    | ------------------------------------------ | ----------------- | ---------------------------------------------------------------------------------------------------------- |
    | property-damage-exists                     | `pass`            | The PD coverage exists on this policy.                                                                     |
    | property-damage-valid-limit-per-accident   | `pass`            | The PD coverage on this policy has a `limitPerAccident` greater than or equal to \[inputLimitPerAccident]. |
    | property-damage-invalid-limit-per-accident | `fail`            | The PD coverage on this policy has a `limitPerAccident` less than to \[inputLimitPerAccident].             |
    | property-damage-unknown-limit-per-accident | `unknown`         | The PD coverage on this policy has a `limitPerAccident` that is unknown.                                   |

    **Example Usage**

    This example Rule validates that the policy has property damage coverage and that the coverage's `limitPerAccident` is greater than or equal to \$50,000.

    ```typescript Example Rule Request theme={null}
    {
      rule: "property-damage-coverage-meets-requirements",
      input: {
        limitPerAccident: 50000
      }
    }
    ```

    ```typescript Example Rule Response theme={null}
    "property-damage-coverage-meets-requirements": {
      status: "pass",
      metadata: {
        input: {
          limitPerAccident: 50000
        }
      },
      breakdown: {
        "property-damage-exists": {
          status: "pass",
          metadata: {
            coverages: [
              {
                code: "PD",
                label: "Property Damage",
                limitPerAccident: 100000,
              },
            ],
            input: {
              coverageCode: "PD"
            }
          }
        },
        "property-damage-limit-per-accident-comparison": {
          status: "pass",
          metadata: {
            coverages: [
              {
                code: "PD",
                label: "Property Damage",
                limitPerAccident: 100000,
              },
            ],
            input: {
              limitPerAccident: 50000
            }
          }
        }
      },
      message: {
        code: "property-damage-valid-limit-per-accident",
        displayText: `The PD coverage on this policy has a limitPerAccident greater than or equal to $50000.`,
      }
    }
    ```
  </Accordion>

  <Accordion title="Uninsured/Underinsured Motorists Property Damage Coverage Meets Requirements">
    ### `uninsured-underinsured-pd-coverage-meets-requirements`

    Evaluates whether a policy includes uninsured motorist (UM), underinsured motorist (UIM), or uninsured/underinsured motorist (UUIM) property damage coverage and verifies if the coverage(s) meet the specified limit requirements.

    **Input Parameters**

    * `limitPerAccident` (optional): The limitPerAccident amount you want to verify against the policy.

    **Evaluation Criteria**

    The Rule is evaluated based on the following criteria. If no limit is specified in the input, the Rule evaluates solely on the presence of any uninsured motorist (UM), underinsured motorist (UIM), or uninsured/underinsured motorist (UUIM) property damage coverage on the policy.

    1. `uninsured-underinsured-pd-exists`: Determines if UM, UIM, or UUIM motorist property damage coverage is present on the policy.

    2. `uninsured-underinsured-pd-limit-per-accident-comparison` (if applicable): Determines if the `limitPerAccident` on the policy's UM, UIM, or UUIM property damage coverage  is greater than or equal to the provided `limitPerAccident`.

    | Status    | Cause                                                                                                                                                |
    | --------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- |
    | `pass`    | The policy has at least one of UM, UIM, or UUIM property damage coverage and meets all specified limit requirements.                                 |
    | `fail`    | The policy either doesn't have any UM, UIM, or UUIM property damage coverage, or has at least one but doesn't meet the specified limit requirements. |
    | `unknown` | Not enough information was available to evaluate the coverage requirements.                                                                          |

    This Rule also returns a message and message code which can be used to explain to the user why the Rule failed to result in a `pass`.

    | Message Code                                         | Evaluation Status | Message                                                                                                                                              |
    | ---------------------------------------------------- | ----------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- |
    | uninsured-underinsured-pd-exists                     | `pass`            | At least one of UM, UIM, or UUIM property damage coverage exists on this policy.                                                                     |
    | uninsured-underinsured-pd-valid-limit-per-accident   | `pass`            | At least one of UM, UIM, or UUIM property damage coverage on this policy has a `limitPerAccident` greater than or equal to \[inputLimitPerAccident]. |
    | uninsured-underinsured-pd-invalid-limit-per-accident | `fail`            | None of UM, UIM, or UUIM property damage coverage on this policy has a `limitPerAccident` less than to \[inputLimitPerAccident].                     |
    | uninsured-underinsured-pd-unknown-limit-per-accident | `unknown`         | At least one of UM, UIM, or UUIM property damage coverage on this policy has a `limitPerAccident` that is unknown.                                   |

    **Example Usage**

    This example Rule will verify if the policy has at laest one of UM, UIM, or UUIM property damage coverage and if the `limitPerAccident` on the coverage is greater than or equal to \$50,000.

    ```typescript Example Rule Request theme={null}
    {
      rule: "uninsured-underinsured-pd-coverage-meets-requirements",
      input: {
        limitPerAccident: 50000
      }
    }
    ```

    ```typescript Example Rule Response theme={null}
    "uninsured-underinsured-pd-coverage-meets-requirements": {
      status: "pass",
      metadata: {
        input: {
          limitPerAccident: 50000
        }
      },
      breakdown: {
        "uninsured-underinsured-pd-exists": {
          status: "pass",
          metadata: {
            coverages: [
              {
                code: "UIMPD",
                label: "Underinsured Motorists Property Damage",
                limitPerAccident: 100000,
              },
            ],
            input: {
              coverageCodes: ["UMPD", "UIMPD", "UUIMPD"]
            }
          }
        },
        "uninsured-underinsured-pd-limit-per-accident-comparison": {
          status: "pass",
          metadata: {
            coverages: [
              {
                code: "UIMPD",
                label: "Underinsured Motorists Property Damage",
                limitPerAccident: 100000,
              },
            ],
            input: {
              limitPerAccident: 50000
            }
          }
        }
      },
      message: {
        code: "uninsured-underinsured-pd-valid-limit-per-accident",
        displayText: `At least one of UM, UIM, or UUIM property damage coverage on this policy has a `limitPerAccident` greater than or equal to $50000.`,
      }
    }
    ```
  </Accordion>

  <Accordion title="Insureds Match">
    ### `insureds-match`

    Evaluates whether all of the input insured names are listed on the Axle policy.

    | Status    | Cause                                                                                                                                                                                                                  |
    | --------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
    | `pass`    | All of the input insured names are listed on the Axle policy.                                                                                                                                                          |
    | `caution` | One or more of the input insured names passed a fuzzy match. This occurs when either the input name or Axle policy name is missing an additional first name or middle name (e.g. "John Tracy Smith" vs. "John Smith"). |
    | `fail`    | One or more of the input insured names were not listed on the Axle policy.                                                                                                                                             |
    | `unknown` | An error occurred during validation.                                                                                                                                                                                   |

    **Input Parameters**

    * `insuredNames`: An array of full names provided as strings. Each name should be provided in the format `"firstName middleName lastName suffix"`
    * `fuzzyMatch` (optional): A boolean that enables similarity-based matching for insured names.

    If `fuzzyMatch` is `true`, this Rule calculates a similarity score between each input name and the policy insured name. A score of `0.7` or higher is treated as a match (`pass`), and a score below `0.7` is treated as not matching (`fail`).

    **Resolving `insuredNames` when using a Template**

    When `insuredNames` is configured with a `source` in a Validation Template (see [Dynamic Inputs via `source` and `default`](/guides/validate/policy-validation-with-template#dynamic-inputs-via-source-and-default)), Axle resolves the value using the following priority order:

    1. **Request body metadata** - the `metadata` object passed in the [Validate Policy with Template](/api-reference/validation/validate-policy-template) request body, keyed by `source` (e.g. `"insuredNames": ["Audrey Cheng", "Cam Duncan", "Matt Gross"]`).
    2. **Ignition session metadata** - the `metadata` object passed in [Start Ignition](/api-reference/ignition/start-ignition), keyed by `source`.
    3. **`user.firstName` and `user.lastName`** - if neither of the above provides a value, Axle falls back to the `user.firstName` and `user.lastName` fields from the [Start Ignition](/api-reference/ignition/start-ignition) request body, concatenated as a single name (e.g. `["${user.firstName} ${user.lastName}"]`).

    If none of these sources provide a value, the request fails with a `4xx` error.

    <Info>
      This Rule currently does not support nickname matching. Please contact the Axle team if this is a feature of interest.

      Additionally, it is unlikely that insureds across households will be present on a single insurance policy. Please ensure that the input only contains insured names you expect to be on the policy.
    </Info>

    **Example Usage**

    ```typescript Example Rule Request theme={null}
    {
      "rule": "insureds-match",
      "input": {
        "insuredNames": ["John Tracy Smith", "Alex Jacob Smith", "Jane Doe"],
        "fuzzyMatch": true
      }
    }
    ```

    ```typescript Example Rule Response theme={null}
    "insureds-match": {
      "status": "fail",
      "metadata": {
        "pass": ["John Tracy Smith", "Alex Jacob Smith"],
        "fail": ["Jane Doe"],
        "caution": [],
        "unknown": [],
      }
    }
    ```
  </Accordion>

  <Accordion title="Address Match">
    ### `address-match`

    Evaluates whether input address matches the address that is listed on the Axle policy.

    | Status    | Cause                                                                               |
    | --------- | ----------------------------------------------------------------------------------- |
    | `pass`    | Input address matches Axle Policy address                                           |
    | `caution` | Input and Axle policy `addressLine2` do not match                                   |
    | `fail`    | Input address does not match Axle Policy address                                    |
    | `unknown` | There is insufficient information to compare input address and Axle Policy address. |

    **Input Parameters**

    * `address`: Full address provided as a `string` that includes both Address Line 1 and 2 along with city, postal code, and state.

    **Example Usage**

    ```typescript Example Rule Request theme={null}
    {
      "rule": "address-match",
      "input": {
        "address": "123 Axle St. NE, Apartment 111, Atlanta, GA 30303"
      }
    }
    ```

    ```typescript Example Rule Response theme={null}
    "address-match": {
      "status": "pass",
      "metadata": {
        "pass": [
          {
            "addressLine1": "123 Axle Street NE",
            "addressLine2": "APT 111",
            "city": "Atlanta",
            "state": "GA",
            "postalCode": "30303",
            "country": "US"
          }
        ],
        "fail": [],
        "caution": [],
        "unknown": []
      }
    }
    ```
  </Accordion>

  <Accordion title="Properties Match">
    ### `properties-match`

    Evaluates whether input property matches the property that is listed on Axle Policy. Properties can be matched via yearMakeModel, VIN, or address (corresponding to type of property).

    ### yearMakeModel (property type `vehicle`)

    Evaluates if provided yearMakeModel matches yearMakeModel listed as one of the properties when `policy.properties.type=vehicle`

    | Status    | Cause                                                                                                                                |
    | --------- | ------------------------------------------------------------------------------------------------------------------------------------ |
    | `pass`    | Exact match on the year and high similarity threshold score on `make` and `model` to one of the properties listed on the Axle Policy |
    | `caution` | Exact match on the year and medium similarity threshold score on `make` and `model`                                                  |
    | `fail`    | No match on year or low similarity threshold score on `make` and `model`                                                             |
    | `unknown` | There is insufficient information to compare input yearMakeModel and Axle Policy                                                     |

    **Input Parameters**

    * `yearMakeModel`: Provide a string in the following format "\<year> \<make model of the vehicle>". For example, you can provide "2009 Honda Odyssey"

    **Example Usage**

    ```typescript Example Rule Request theme={null}
    {
      "rule": "properties-match",
      "input": {
          "yearMakeModel": "2009 Honda Odyssey"
      }
    }
    ```

    ```typescript Example Rule Response theme={null}
    "properties-match": {
        "status": "pass",
        "metadata": {
          "pass": [
            {
              "type": "vehicle",
              "data": {
                "bodyStyle": "minivan",
                "vin": "5FNRL38209B014050",
                "model": "Odyssey",
                "year": "2009",
                "make": "Honda"
              },
              "id": "prp_tmGUxLpgHjmW9r6M6WjhS"
            }
          ],
          "fail": [],
          "caution": [],
          "unknown": []
        }
    }
    ```

    ### vin (property type `vehicle`)

    Evaluates if provided VIN matches the VIN listed as one of the properties when `policy.properties.type=vehicle`

    | Status    | Cause                                                                  |
    | --------- | ---------------------------------------------------------------------- |
    | `pass`    | VIN matches a property listed on the Axle Policy                       |
    | `fail`    | VIN doesn't match any of the properties                                |
    | `unknown` | There is insufficient information to compare input VIN and Axle Policy |

    **Input Parameters**

    * `vin`: Provide VIN number of the vehicle as a `string`

    **Example Usage**

    ```typescript Example Rule Request theme={null}
    {
      "rule": "properties-match",
      "input": {
          "vin": "AAABC38A450011111"
      }
    }
    ```

    ```typescript Example Rule Response theme={null}
    "properties-match": {
      "status": "pass",
      "metadata": {
        "pass": [
          {
            "type": "vehicle",
            "data": {
              "vin": "AAABC38A450011111",
              "model": "Q4",
              "year": "2025",
              "make": "Audi"
            },
            "id": "prp_8BKSFvreM7FOwI_3X2sxB"
          }
        ],
        "fail": [],
        "caution": [],
        "unknown": []
      }
    }
    ```

    ### Address (property type `dwelling`)

    Evaluates if provided address matches the address listed as one of the properties when `policy.properties.type=dwelling`

    | Status    | Cause                                                                                       |
    | --------- | ------------------------------------------------------------------------------------------- |
    | `pass`    | Input address matches one of the properties on the Axle Policy                              |
    | `caution` | Input address may not match any of the properties because of a difference in `addressLine2` |
    | `fail`    | Input address does not match any of the properties                                          |
    | `unknown` | There is insufficient information to compare input address and Axle Policy                  |

    **Input Parameters**

    * `address`: Full address provided as a `string` that includes both Address Line 1 and 2 along with city, postal code, and state.

    **Example Usage**

    ```typescript Example Rule Request theme={null}
    {
      "rule": "properties-match",
      "input": {
        "address": "123 Axle St. NE, Apartment 111, Atlanta, GA 30303"
      }
    }
    ```

    ```typescript Example Rule Response theme={null}
    "address-match": {
      "status": "pass",
      "metadata": {
        "pass": [
          {
            "addressLine1": "123 Axle Street NE",
            "addressLine2": "APT 111",
            "city": "Atlanta",
            "state": "GA",
            "postalCode": "30303",
            "country": "US"
          }
        ],
        "fail": [],
        "caution": [],
        "unknown": []
      }
    }
    ```
  </Accordion>

  <Accordion title="Third Parties Match">
    ### `third-party-match`

    Evaluates whether a third party listed on the policy matches the provided name and, if provided, the third party's address.

    #### Input Parameters

    * `name` (required): String representing the name of the third party (e.g., "Major Bank").
    * `address` (optional): String representing the address of the third party.

    #### Responses

    | Status    | Cause                                                                                               |
    | --------- | --------------------------------------------------------------------------------------------------- |
    | `pass`    | Input name is a high-confidence match. If provided, address is also a high-confidence match.        |
    | `caution` | Input name is a medium-confidence match OR, if provided, address is a medium confidence match.      |
    | `fail`    | Input name does not match or address does not match.                                                |
    | `unknown` | There is insufficient information to compare the input third party details with those on the policy |

    #### Example Usage

    ```typescript Example Rule Request theme={null}
    {
      "rule": "third-party-match",
      "input": {
        "name": "Major Bank",
        "address": "123 Main St, Springfield, IL 62701",
      }
    }
    ```

    ```typescript Example Rule Response theme={null}
    {
      "third-party-match": {
        "status": "pass",
        "metadata": {
          "pass": [
            {
              "id": "prp_abc123",
              "type": "interest",
              "data": {
                "name": "Major Bank",
                "address": {
                  addressLine1: "123 Main St",
                  addressLine2: null,
                  state: "IL",
                  city: "Springfield",
                  country: "USA",
                  postalCode: "62701",
                }
              }
            }
          ],
          "fail": [],
          "caution": [],
          "unknown": []
        }
      }
    }
    ```
  </Accordion>

  <Accordion title="Required Policy Information is Present">
    ### `required-policy-information-is-present`

    Evaluates if the policy either has (1) certain required fields present OR (2) at least one declarations page. If either sub-rule passes, the overall Rule resolves to `pass`. Otherwise, it resolves to `fail`.

    This Rule combines two separate sub-rules:

    1. `fields-exist` – Verifies that all fields specified by your `requiredFields` input are present on the policy. If every requested field is found, this Rule resolves to `pass`; otherwise, it resolves to `fail` and includes a `missingFields` list in the metadata.
    2. `declarations-page-exists` – Checks whether the policy has at least one document classified by Axle as a declaration page.

    | Status | Cause                                                                                 |
    | ------ | ------------------------------------------------------------------------------------- |
    | `pass` | The policy has all required fields, or there is a declarations page (or both).        |
    | `fail` | Neither the required fields nor a declarations page could be confirmed on the policy. |

    **Input Parameters**

    * `requiredFields`: An object used to specify which fields must exist on the policy. Each key maps to a boolean (or nested object / array structure) indicating whether that particular field is required. The shape of the object mirrors the Axle Policy Schema.

    Below is an example request specifying all the possible required fields that can be checked for existence. If you receive a 400 Input Validation error, please check that you provided only fields listed in the example below.

    If either the required fields or the declarations page check is satisfied, the Rule evaluates to `pass`.

    ```typescript Example Rule Request theme={null}
    // The below example shows all the possible fields that can be checked for existence
    {
    "rule": "required-policy-information-is-present",
    "input": {
       "requiredFields": {
          "carrier": true,
          "type": true,
          "policyNumber": true,
          "premium": true,
          "isActive": true,
          "effectiveDate": true,
          "expirationDate": true,
          "address": {
            "addressLine1": true,
            "state": true,
            "city": true,
            "postalCode": true
          }
          "properties": [
            {
              "data": {
                "vin": true,
                "year": true,
                "make": true,
                "model": true,
                "use": true
              }
            }
          ],
          "coverages":[
            {
              "deductible": true,
              "limitPerPerson": true,
              "limitPerAccident": true
            }
          ],
          "insureds":[
            {
              "firstName": true,
              "lastName": true
            }
          ],
          "thirdParties":[
            {
              "name": true,
              "address": {
                "addressLine1": true,
                "state": true,
                "city": true,
                "postalCode": true
              }
            }
          ]
      }
    }
    }
    ```

    ```typescript Example Rule Response theme={null}
    "required-policy-information-is-present": {
      "status": "pass",
      "summary": {
          "required-policy-information-is-present": "pass"
      },
      "rules": {
          "required-policy-information-is-present": {
              "status": "pass",
              "breakdown": {
                  "fields-exist": {
                      "status": "fail",
                      "metadata": {
                          "missingFields": ["premium"]
                      }
                  },
                  "declarations-page-exists": {
                      "status": "pass",
                      "metadata": {
                          "documents": [
                              {
                                  "createdAt": "2025-01-10T16:28:07.089Z",
                                  "issuedDate": "2024-12-24T00:00:00.000Z",
                                  "name": "Auto Policy Document Amended",
                                  "source": "carrier",
                                  "type": [
                                      "policy-agreement",
                                      "declaration-page"
                                  ],
                                  "key": "doc_FqDyv9F2b6x5eZ_jokGWU.pdf",
                                  "effectiveDate": null
                              }
                          ]
                      }
                  }
              },
              "metadata": {}
          }
      }
    }
    ```
  </Accordion>

  <Accordion title="Vehicle Use Meets Requirements">
    ### `vehicle-use-meets-requirements`

    Evaluates whether any vehicle on the policy has a specified use (e.g., business, commute, or pleasure). If a `vin` or `yearMakeModel` is provided, the rule ensures that the matched vehicle has the expected use.

    #### Input Parameters

    * `use` (required): One of `business`, `commute`, or `pleasure`.
    * `vin` (optional): The Vehicle Identification Number of the vehicle you want to check. If provided, the rule will only evaluate the vehicle with this VIN.
    * `yearMakeModel` (optional): Formatted string, e.g., `"2020 Toyota Camry"` specifying which vehicle to check. If provided, the rule will only evaluate the vehicle that matches this yearMakeModel.

    #### Responses

    | Status    | Cause                                                                                  |
    | --------- | -------------------------------------------------------------------------------------- |
    | `pass`    | At least one vehicle (or the specified vehicle) has the expected use.                  |
    | `fail`    | All vehicles (or just the specified vehicle) fail to meet the usage requirement.       |
    | `unknown` | Vehicle use data is not available or the specified vehicle is not found on the policy. |

    #### Example Usage

    ```typescript Example Rule Request theme={null}
    {
    "rule": "vehicle-use-meets-requirements",
    "input": {
      "use": "business",
      "vin": "5FNRL38209B014050",
    }
    }
    ```

    ```typescript Example Rule Response theme={null}
    "vehicle-use-meets-requirements": {
    "status": "pass",
    "metadata": {
      "pass": [
        {
          "id": "prp_tmGUxLpgHjmW9r6M6WjhS",
          "type": "vehicle",
          "data": {
            "vin": "5FNRL38209B014050",
            "make": "Honda",
            "year": "2019",
            "model": "Odyssey",
            "use": "business"
          }
        }
      ],
      "fail": [],
      "caution": [],
      "unknown": []
    }
    }

    ```
  </Accordion>

  <Accordion title="Policy Created Via Credit Card Form">
    ### `policy-created-via-credit-card`

    Evaluates whether the policy was created via Axle's credit card submission flow.

    This Rule does not require any input.

    | Status | Cause                                  |
    | ------ | -------------------------------------- |
    | `pass` | The policy is a credit card policy     |
    | `fail` | The policy is not a credit card policy |

    **Example Usage**

    ```typescript Example Rule Request theme={null}
    {
      "rule": "policy-created-via-credit-card"
    }
    ```

    ```typescript Example Rule Response theme={null}
    "policy-created-via-credit-card": {
      "status": "pass",
    }
    ```
  </Accordion>

  <Accordion title="Policy Refreshed Within Days">
    ### `refreshed-within-days`

    Evaluates whether the policy has been refreshed within the last N days (relative to the current time the validation is executed).

    #### Input Parameters

    * `days` (required): A non‑negative number representing how many days back from "now" to consider acceptable. If the policy's `refreshedAt` timestamp is on or after the computed threshold (more recent than `days` days ago), the Rule resolves to `pass`; otherwise it resolves to `fail`.

    #### Responses

    | Status | Cause                                                     |
    | ------ | --------------------------------------------------------- |
    | `pass` | `policy.refreshedAt` is within (>=) the last `days` days. |
    | `fail` | `policy.refreshedAt` is older than the last `days` days.  |

    This Rule does not currently return `caution` or `unknown` outcomes.

    #### Metadata Returned

    * `refreshedAt`: The policy's `refreshedAt` timestamp.
    * `input.days`: The input number of days used for comparison.
    * `thresholdDate`: The ISO timestamp representing the earliest acceptable refresh time (`now - days`).

    #### Example Usage

    ```typescript Example Rule Request theme={null}
    {
      "rule": "refreshed-within-days",
      "input": { "days": 30 }
    }
    ```

    ```typescript Example Rule Response theme={null}
    "refreshed-within-days": {
      "status": "pass",
      "metadata": {
        "refreshedAt": "2025-08-15T14:22:10.123Z",
        "input": { "days": 30 },
        "thresholdDate": "2025-08-10T14:22:10.456Z"
      }
    }
    ```
  </Accordion>
</AccordionGroup>

## Applicability of Evaluation Rules

Depending on the [completion result](/guides/completion-types) of Axle ignition, not all Rules are applicable. For example, when `manual` is enabled and end-users decide to use Policy Form as their verification method, they enter only basic policy details through a short form. Since no coverage information is collected, attempting to validate missing data does not apply.

<Info>
  Configuration of completion results (i.e. manual vs. link) are set up during
  onboarding. You can modify the accepted completion results and manual
  configuration options by contacting the Axle team.
</Info>

Due to insufficient information to validate the policy or compare provided values, the `status` of those rules will be marked as `unknown`. For the most comprehensive validation results, it is recommended to encourage your application's users to complete via link or by uploading a full policy document such as declaration page.

For more information on result outcomes, please consult [Result Outcomes](/guides/completion-types#result-outcomes) to see the difference between link vs. manual (in addition to different types of manual configurations)


# Policy Validation with Templates
Source: https://docs.axle.insure/guides/validate/policy-validation-with-template

Templates let you evaluate a set of Rules against a policy by storing rules and inputs, and pulling dynamic values from custom metadata.

## Overview

As an extension of [Policy Validation](/guides/validate/policy-validation), you can also use Templates to simplify Rule configuration in your application. Instead of manually storing the list of rules, you can define them once and let Axle handle rule maintenance and policy validation.

### Dynamic Inputs via `source` and `default`

Rules that can have inputs (e.g. `collision-coverage-meets-requirements` which can have a `deductible` input) are configured in a template using a `source` key instead of a hardcoded value. At evaluation time, Axle looks up the rule input value dynamically using the following priority order:

1. **Request body metadata** — the flat `metadata` object passed in the [Validate Policy with Template](/api-reference/validation/validate-policy-template) request body, keyed by `source`.
2. **Ignition session metadata** — the `metadata` object via [Start Ignition](/api-reference/ignition/start-ignition), keyed by `source`.
3. **Template default** — the `default` value defined on the rule input in the template (if set).

This means you can store rule configuration once in a template and provide the actual input values at runtime — either when launching an Ignition session or when calling the validate endpoint.

<Info>
  **Metadata rules** are defined in [Start Ignition](/api-reference/ignition/start-ignition) (`metadata` on the session) and [Validate Policy with Template](/api-reference/validation/validate-policy-template) (request body).
</Info>

### Example Template

```json theme={null}
{
  "id": "tmp_jsK9vrCIfABlCW7PqIknc",
  "rules": [
    {
      "rule": "collision-coverage-meets-requirements",
      "input": {
        "deductible": {
          "source": "maxDeductible",
          "default": 500
        }
      }
    }
  ],
  "createdAt": "2025-06-10T13:57:22.300Z",
  "modifiedAt": "2025-06-10T13:57:22.300Z"
}
```

In this example, `source: "maxDeductible"` tells Axle to look for a key named `maxDeductible` in the request body metadata or Ignition session metadata. If neither provides that key, the `default` value of `500` is used.

### Usage

<Steps>
  <Step title="Create or modify Validation Template">
    Start by identifying the [rules](/guides/validate/policy-validation#supported-rules) you want to use. Then, either [create](/api-reference/validation/templates/create-template) a new template or [modify](/api-reference/validation/templates/update-template) an existing one.

    If your application is a [platform](/guides/platform-integration), you can [create](/api-reference/platform/create-templates) shareable template across all of your destination clients. If you are existing Axle for Platforms customer, please reach out to Axle team for more information.
  </Step>

  <Step title="Provide dynamic inputs to Ignition metadata (optional)">
    Include `metadata` in [Start Ignition](/api-reference/ignition/start-ignition) to serve as dynamic Rule inputs. The keys in this object must match the `source` values defined in your Template's rule inputs, and the values must conform to the associated Rule input type.

    For example, if a template rule input has `"source": "maxDeductible"`, include `"maxDeductible": 500` in the `metadata` object when starting Ignition.
  </Step>

  <Step title="Retrieve Validation Templates">
    After creating a template, you can store its Template identifier in your application. Using this identifier, you can [retrieve](/api-reference/validation/templates/get-template) specific template and all of its details or [get all the available](/api-reference/validation/templates/get-templates) Templates for your Axle client or destination client.
  </Step>

  <Step title="Request Policy Validation with Template">
    Use the Template identifier to make a request to [Validate Policy with Template](/api-reference/validation/validate-policy-template). The request body accepts a flat `metadata` object whose keys correspond to the `source` values in your Template's rule inputs — these values override any matching keys from the Ignition session metadata.

    <Warning>
      Request body metadata keys take priority over Ignition session metadata keys
      when resolving rule inputs. See [Dynamic Inputs via `source` and
      `default`](#dynamic-inputs-via-source-and-default) for the full resolution
      order.
    </Warning>
  </Step>
</Steps>


# Widgets
Source: https://docs.axle.insure/guides/widgets

This guide will help you understand how to display Axle's embeddable widgets to your users.

Axle widgets are full-viewport overlays that surface additional user experiences within your application, similar to [Axle Ignition](/guides/initialize-ignition). Currently, `validation` is the only supported widget type - it displays a policy's [validation](/guides/validate/policy-validation) result to the user.

## Start a widget session

Once you have a `validationResult` from [Validate Policy](/api-reference/validation/validate-policy), start a widget session using the [Start Widget](/api-reference/widgets/start-widget) endpoint. This returns a `widgetToken` and a `widgetUri` to display to the user.

```bash Request Sample theme={null}
curl --request POST \
  --url https://sandbox.axle.insure/widgets \
  --header 'Content-Type: application/json' \
  --header 'x-client-id: cli_mZj6YGXhQyQnccN97aXbq' \
  --header 'x-client-secret: RZM-5BErZuChKqycbCS1O' \
  --data '{
  "validation": {
    "enabled": true,
    "data": {
      "validationResult": "val_abcdef123456"
    }
  }
  }'
```

```json Response theme={null}
{
  "success": true,
  "data": {
    "widgetToken": "ey...",
    "widgetUri": "https://widget.sandbox.axle.insure/?token=ey..."
  }
}
```

## Appending origin or redirect URI

Before rendering the widget, your application should append either `origin` (for web) or `redirectUri` (for mobile) as a query parameter to the `widgetUri`. This tells the widget how to communicate back to your application on exit.

**Web:**

```
https://widget.sandbox.axle.insure/?token=ey...&origin=https://example.com
```

**Mobile:**

```
https://widget.sandbox.axle.insure/?token=ey...&redirectUri=https://example.com/validation/redirect
```

## Web: Display in iframe

<Steps>
  <Step title="Open iframe">
    Render the `widgetUri` (with `origin` appended) in an iframe set to 100% width and 100% height of the viewport. Axle handles all internal layout and scrolling, so your application doesn't need to manage the widget's sizing.
  </Step>

  <Step title="Listen for MessageEvent">
    Add an event listener on the parent window. For security, verify that the message origin is the Axle widget domain (e.g., `https://widget.sandbox.axle.insure`) before processing.
  </Step>

  <Step title="Process the exit event">
    When the user closes or exits the widget, remove the iframe (or close the modal) and return the user to the previous view.
  </Step>
</Steps>

```HTML Page with iframe and eventListener (example) theme={null}
<style>
  .validation-widget {
    z-index: 999;
    position: fixed;
    left: 0;
    top: 0;
    height: 100%;
    width: 100%;
    border: none;
  }
</style>

<iframe
  src="https://widget.sandbox.axle.insure/?token=ey...&origin=https://example.com"
  class="validation-widget"
></iframe>

<script>
  window.addEventListener("message", (event) => {
    if (event.origin === "https://widget.sandbox.axle.insure") {
      switch (event.data.status) {
        case "exit":
          // Remove the iframe / close the modal
          break;
      }
    }
  });
</script>
```

## Mobile: Display in native webview

Open the `widgetUri` (with `redirectUri` appended) in a native webview. When the user exits the widget, Axle redirects to the `redirectUri` you provided with a `status` query parameter appended:

```
https://example.com/validation/redirect?status=exit
```

Your native app should catch this redirect and close the webview.

## Widget events

| Platform         | Delivery                              | Requires                              |
| ---------------- | ------------------------------------- | ------------------------------------- |
| Web (iframe)     | `window.postMessage` to parent window | `origin` appended to `widgetUri`      |
| Mobile (webview) | URL redirect                          | `redirectUri` appended to `widgetUri` |

### onExit

Emitted when the user closes or exits the widget (e.g., clicks a close button or back action).

**Via `postMessage` (web):**

```json theme={null}
{
  "status": "exit"
}
```

**Via redirect (mobile):**

```
{redirectUri}?status=exit
```

When your application receives this event, it should tear down the iframe or close the webview and return the user to the previous view.

<Check>
  That's it - your users can now view their validation result through Axle's widget without leaving your application 🎉.
</Check>


# Security
Source: https://docs.axle.insure/security

At Axle, security and privacy are at the forefront of everything we do. We leverage the latest in cloud infrastructure and weave secure-by-design and privacy-by-design principles into our engineering DNA.

## Security practices

Security affects everything we do at Axle. We are SOC 2 Type 2 certified and we:

* Force HTTPS on all connections, so data in-transit is encrypted with TLS 1.2.
* Encrypt all database data at-rest with AES-256.
* Host all servers in the US, in data centers that are SOC 1, SOC 2 and ISO 27001 certified. Our data centers have round-the-clock security, fully redundant power systems, two-factor authentication and physical audit logs.
* Regularly conduct external penetration tests from third-party vendors.
* Regularly conduct security awareness training sessions with all employees.
* Maintain detailed audit logs of all internal systems.

## Reporting security bugs or concerns

Please contact Axle's security team, via email at security\[at]axle.insure. We welcome reports from end users, security researchers, and anyone else!


# Welcome
Source: https://docs.axle.insure/welcome

Axle is a universal API for insurance data. With Axle, companies can instantly verify insurance and monitor ongoing coverage, helping them create a frictionless experience for their users and reduce operational risk through better-informed decisions. Axle is backed by leading investors including Google and Y Combinator.

<Card title="Quickstart" icon="rocket-launch" href="/guides/quickstart">
  Initialize Ignition and retrieve insurance information.
</Card>

<Card title="API Reference" icon="code" href="/api-reference/overview">
  View and experiment with the Axle API.
</Card>