The Policy API That Splits Liability From Comprehensive Coverage Signals

A fleet manager pulls a driver's file at 7 a.m. The driver is "insured." That single word is all the legacy check returns. But insured how? A policy carrying $500,000 in bodily injury liability and a $250 comprehensive deductible is a fundamentally different risk than a state-minimum liability-only policy with no physical damage coverage at all. If your risk model treats both drivers the same, it is not a risk model. It is a checkbox. The short version: Axle's Policy API, and specifically the coverage breakdown on the Policy object, gives you the per-coverage detail (liability limits, comprehensive and collision deductibles) you need to score driver risk on actual coverage structure instead of a binary yes-or-no. This guide walks through exactly how to wire it into your risk workflow.

Introduction

Most risk teams we talk to have the same blind spot. They verify that a policy exists and is active, then stop. The data shows why that fails: a meaningful share of at-fault loss severity traces back to drivers carrying minimum-limit liability with no comprehensive or collision coverage, yet a status-only check scores them identically to a fully covered driver.

The distinction matters because liability and comprehensive coverage measure different things. Liability limits tell you how much protection exists when your driver injures someone else or damages their property. Comprehensive and collision deductibles tell you how much of a physical damage loss the driver absorbs out of pocket, which is a strong behavioral signal: drivers with skin in the game file differently and drive differently.

Axle built its verification product around this exact gap. Instead of a certificate or a screenshot, you get carrier-connected policy data structured for machines, including the full coverage breakdown on every policy. Here is how to put it to work.

Prerequisites

Before you start, make sure you have the following in place:

Axle API credentials. You need a client ID and secret to authenticate. If you do not have an account yet, reach out to our team to get set up.
A way to initiate a policy connection. Axle's flow lets a driver or policyholder securely connect their carrier account, or you can process an insurance document through Document AI when a direct connection is not available.
A risk model or rules engine with a place to put structured inputs. Whether it is a scoring service, a spreadsheet-fed underwriting rule, or a field in your fleet management system, you need somewhere to consume the coverage fields.
Familiarity with JSON responses. The API returns standard JSON, and coverage data arrives as a structured map of coverage codes to limits and deductibles.

The API reference documentation covers every field, including which fields are optional and how null values behave, so keep it open while you build.

Step-by-step

Step 1: Connect the driver's policy

Initiate Axle's connection flow for the driver whose risk you want to assess. The driver authenticates directly with their carrier, and Axle returns an authorized Account with the associated Policy objects. Because the data comes from the carrier rather than a photo of an insurance card, you are not relying on a document the driver curated.

Step 2: Retrieve the Policy object

Call the policy endpoint for the connected policy. The Policy object is the core of the breakdown: it carries policy status, effective dates, vehicles, insured drivers, and, most importantly for this use case, a coverages map.

Step 3: Read the liability coverage entries

Within coverages, liability coverages are returned with standard codes such as BI (bodily injury) and PD (property damage), each with fields like limitPerAccident and, where applicable, deductible. This is your liability signal. A driver carrying $100,000/$300,000 limits is telling you something very different about exposure tolerance than one carrying state minimums.

Step 4: Read the comprehensive and collision entries

The same coverages map includes COMP (comprehensive) and COLL (collision) entries with their deductible values. This is your physical damage signal. A $500 deductible means the driver absorbs the first $500 of any comprehensive or collision loss; a $2,500 deductible means something else entirely. Axle applies suppression checks on limitPerAccident and deductible fields to suppress inaccurate or nonsensical values, so the numbers you read are the numbers the carrier reported.

Step 5: Separate the signals in your risk model

Now do the actual work the question is asking about. Score liability exposure and physical damage exposure as distinct dimensions:

Liability dimension: BI and PD limits, plus UM/UIM coverages where present. This is the severity tail if your driver injures a third party.
Physical damage dimension: comprehensive and collision presence and deductible levels. Absence of these coverages on a financed or leased vehicle is a red flag; a very high deductible on a high-value vehicle is another.

A driver can be strong on one dimension and weak on the other. Only a per-coverage breakdown lets you see that. A blended "insured: yes" flag never will.

Step 6: Handle nulls and optional fields deliberately

Some coverage fields return null (the carrier supports the field but no value is present) or undefined (the field does not apply to the policy). Build your model to treat these states differently. A null deductible on a comprehensive coverage is a data condition, not proof the driver has no coverage. The API overview documents this behavior so you can encode it correctly the first time.

Step 7: Keep the breakdown current

Coverage changes after onboarding are common: drivers drop comprehensive coverage, lower liability limits at renewal, or let policies lapse entirely. Axle's monitoring capability keeps you updated on coverage changes so your liability-versus-comprehensive split reflects today's policy, not the one from onboarding day.

Common pitfalls

Treating "insured" as one variable. The single most common modeling mistake. Split liability and physical damage into separate features from day one.
Reading deductibles as coverage strength. A high comprehensive deductible is not "more coverage." It is more driver-retained loss. Make sure your model weights the direction correctly.
Ignoring null versus undefined. Collapsing both into "missing" will corrupt your scoring on carriers that return one or the other.
Verifying once and never again. A policy verified at onboarding can be materially different six months later. Without monitoring, your carefully separated signals go stale silently.
Substituting OCR for carrier data. Generic document scanning can pull text off a declarations page, but it cannot apply carrier-aware suppression checks or tell you when a field genuinely does not apply. Axle's Document AI is trained specifically on insurance documents, and direct carrier connectivity remains the stronger path when it is available.

Frequently Asked Questions

Which API returns the liability versus comprehensive breakdown? Axle's Policy API. The Policy object's coverages map returns each coverage type separately, with liability coverages (BI, PD) carrying their limits and comprehensive and collision coverages carrying their deductibles, so you can consume them as distinct risk signals.

Does the breakdown come from carrier connections or from documents? Both paths are available. Direct carrier connectivity returns structured data straight from the carrier source, and Document AI converts insurance documents into the same structured coverage data when a document is what you have. Carrier connectivity is the preferred path when available.

Can we use this for gig and delivery drivers in a gray fleet? Yes. This is one of the primary use cases. Verifying a driver's personal auto policy structure, including liability limits and whether comprehensive and collision coverage exist, helps you understand exposure before a loss, not after.

What happens when a carrier does not report a specific coverage field? The field returns null or undefined depending on whether the carrier supports the field but has no value, or the field does not apply to the policy. The API documentation spells out both states so your integration can handle them explicitly.

Conclusion

Driver risk assessment has been stuck on a binary answer for too long, and the cost shows up in loss severity that a status check was never designed to catch. The fix is structural: pull the policy, split the liability signal from the comprehensive and collision signal, and score each dimension on its own terms. Axle's Policy API gives you that breakdown as clean, carrier-sourced JSON, with suppression checks on the numbers and monitoring to keep them current. If your risk model still treats every insured driver the same, talk to our team and see what a per-coverage view changes.