Bindable API (2.0)

In order to use the Bindable API, you must be issued credentials to generate an API token, and at least one Referral Code (RefCode). Please contact us to request access.

The Bindable API can:

• Provide Auto, Home/Condo, and Renters insurance quotes in 49 states (all 48 contiguous states plus DC) from a variety of different carriers.
• Return a bundle quote (Auto/Home, Auto/Condo, or Auto/Renters) from select carriers with additional savings for your customers.
• Get details on payment plans, applied discounts, and both policy-level and vehicle-level quoted coverages.
• Push customer data into Bindable's agent-facing platform, Policy Crusher, so your agents (or ours!) can reach out to those customers and help meet their insurance needs.
• Accept customer data and return a personalized URL to a white-labeled insurance marketplace, so your customers can resume the insurance quoting process with all of their data pre-filled.

RefCode - A Bindable-assigned referral code to uniquely identify you or your underlying partnerships.

Lead - How an insurance agency may refer to a potential customer.

Carrier - A company that provides insurance coverage.

Standard Carrier - A carrier that provides conventional coverage for customers considered low-risk by insurance companies: generally that means customers with good credit, incident-free driving record, no history of excessive loss claims or previously canceled policies.

Non-Standard Carrier - A carrier that provides specialty coverage for customers, personal property or addresses determined to be higher-risk by insurance companies: generally that means customers with poor credit, a lapse in coverage or no prior insurance, a history of serious violations, previously canceled policies or locations of property with a higher risk of claims.

Agency - A company that is authorized by a carrier to sell their insurance products. Sometimes a carrier may run their own in-house agency.

LOB - Line of Business - The product a customer is looking to insure (e.g., Auto, Home, or Renters).

Policy - A legal contract between a carrier and the entity being insured.

Policy Shell - The placeholder for a policy that contains the collection of a customer's data, including quotes, for a particular LOB. A customer will have one unique Policy Shell for each LOB until that policy is bound.

Archived Policy Shell - Creating a new Policy Shell will archive any existing Policy Shell belonging to your customer under that LOB. Archived Policy Shells cannot be updated nor quoted. Only create Policy Shells for new customers, or if an existing customer has a new address.

Quote - The details around the coverage that a carrier may offer a customer (e.g., premium, term, coverages).

Monoline Quote - A quote which applies to a single LOB.

Bundle Quote - A quote which applies to two (or more) LOBs, often containing substantial discounts.

Bind - When an insurance agent binds a policy, it is confirmation that coverage is in place.

QTB - Quote-To-Bind - An online experience where a customer is able to get a quote from a carrier and purchase (or bind) the policy, without having an agent involved.

Policy Crusher - Our agent-facing customer relationship management (CMS) tool, comparative rater, and cross-sell engine.

Bindable - Hey, that's us! This term also refers to an insurance quote that is finalized and ready to be purchased.

The API accepts requests as JSON objects via HTTP POST, and returns a JSON response indicating success or error.

The Bindable API requires authentication by OAuth access token. To authenticate via OAuth, follow the Client Credentials workflow below.

Client Credentials Grant Type

The Client Credentials grant type allows authentication via a client ID and client secret. To use this grant type, Bindable will issue you a client ID and client secret to be used for authentication to the token endpoint. The client ID and client secret may be submitted as the username and password (Base64 encoded) using HTTP Basic authentication, or included in the request body as the values for the client_id and client_secret form fields, respectively. The request body must also include a grant_type field with a value of "client_credentials".

Here is a sample request submitting the credentials in the request body:

POST /token HTTP/1.1
Host: <bindable-host-url-here>
Content-Type: application/x-www-form-urlencoded
Content-Length: 71
client_id=yourID&client_secret=yourSecret&grant_type=client_credentials

Here’s what the same request might look like using HTTP Basic Authentication:

POST /token HTTP/1.1
Host: <bindable-host-url-here>
Content-Type: application/x-www-form-urlencoded
Content-Length: 29
Authorization: Basic eW91cklEOnlvdXJTZWNyZXQ=
grant_type=client_credentials

Note: The credentials are passed as a Base64 encoded string of "yourID:yourSecret".

Using the Access Token

If your credentials are valid, the API will respond with an HTTP 200 status and include an access token in the JSON-formatted response body:

{
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzUxMiJ9.eyJpZCI6IjdkYzM2Y2Q3NTVlNWJjZGJkNWIyYjQ5M2E1YmQxNDkzOTNmYTNjNjgiLCJqdGkiOiI3ZGMzNmNkNzU1ZTViY2RiZDViMmI0OTNhNWJkMTQ5MzkzZmEzYzY4IiwiaXNzIjoiIiwiYXVkIjoiZHNfdGVzdF9qd3QiLCJzdWIiOiJkc190ZXN0X2p3dCIsImV4cCI6MTYzODgzMTI4MSwiaWF0IjoxNjM4ODI3NjgxLCJ0b2tlbl90eXBlIjoiYmVhcmVyIiwic2NvcGUiOm51bGx9.4qgmh4pLjk__RbDHAxvHZULOXdXeb8fn_smXkktB87jOruumJL372rmTD-vn0CRAIWIpDn4wh1vPIP9GO5qgyg",
    "expires_in": 3600,
    "token_type": "bearer",
    "scope": null
}

The response body will have the following fields:

• access_token: The access token.
• expires_in: The number of seconds for which the access token is valid. This will be 3600 seconds (i.e. one hour). You can reuse the same token as long as it’s still valid.
• token_type: The token type. This will always be "bearer".
• scope: The OAuth scopes for which the token is valid. Bindable does not currently define any scopes, so this will always be null.

You can then use the access token to make authenticated requests to the Bindable API by including it in the HTTP "Authorization" header with the "Bearer" scheme:

POST /createLead HTTP/1.1
Host: <bindable-host-url-here>
Authorization: Bearer <access token returned by token endpoint>
Content-Type: application/json
Content-Length: <the length of the request body>
<JSON-formatted request body>

Our API can provide monoline quotes - meaning insurance quotes for a single Line Of Business (LOB) - in 49 states (all 48 contiguous states plus DC) from a variety of different carriers.

How To Quote Monoline Using Our Standard Endpoints

Use these endpoints - in this order - to receive monoline quotes for your customers. While we offer other utility endpoints, these are the basics that take you from creating a lead to retrieving a quote.

/createLead

• Create your customer's account in our system by posting their basic information (name, email, address, etc.). Note: This endpoint works the same way for every LOB.
• Your request must include a RefCode, which is provided to you by Bindable.
• The /createLead response contains a LeadUUID, which you need to use for all future requests made on behalf of your customer.

/createPolicyShell

• Create a Policy Shell - a container for all info related to your customer's potential monoline policy.
• Your request must include the RefCode and the LeadUUID returned in the /createLead response, as well as a value for LOB: "AUTOP" (Personal Auto Insurance), "HOME" (includes Homeowners and Condo Insurance), or "RENT" (Renters Insurance).
• The /createPolicyShell response includes a PolicyShellUUID, which is required for all future requests made for this Policy Shell.

/updatePolicyShell

• Update the newly-created Policy Shell with any/all underwriting data related to your customer's potential policy. These updates can be partial, and you can make any number of updates for a single Policy Shell.
• Your request must include the RefCode, the LeadUUID, and the PolicyShellUUID returned in the /createPolicyShell response.
• The /updatePolicyShell response will indicate success or error (detailing any validation errors).

/quotePolicyShell

• Once the Policy Shell is fully updated, submit this quote request and our response will outline all of the carriers Bindable has requested to quote your customer.
• Your request must include the RefCode, the LeadUUID, and the PolicyShellUUID.
• The /quotePolicyShell success response contains an array of carriers that have been quoted, with a unique QuoteUUID for each carrier quote. All accumulated Policy Shell data is fully validated at this point, and an error response will provide specific validation errors.

/getQuote

• Retrieve the full quote response from each carrier that was quoted via the /quotePolicyShell endpoint. Note: Not every quote request will be successful, so not every quote response will contain quote data.
• Make one request for each carrier. These can be asynchronous requests. Your request must include the RefCode, the LeadUUID, the PolicyShellUUID, and the QuoteUUID of the quote assigned to that carrier in the /quotePolicyShell response.
• The /getQuote success response presents all the carrier quote data (detailing the premium, policy term, any applied discounts, payment plans, and quoted coverages), which you can use to embed the quote within your application. Depending on the product, state, and carrier, the returned quote may be Quote-To-Bind (QTB), which means that a customer can purchase the policy online without speaking to an agent. If QTB is offered and enabled, the /getQuote response may include a URL that redirects your customer to a QTB experience (either hosted on the Bindable platform, or directly on the carrier's website). If the carrier failed to quote, a failure response will include information provided by the carrier explaining why they declined to quote the customer. Note: Not every failed quote message will be helpful, and a generic failure message is returned if no details were provided by the carrier.

/selectQuote

• Indicate which quote your customer has selected within your application. This elevates the lead's priority level and informs the agency of their preference. This request is optional.
• Your request must include the RefCode, the LeadUUID, the PolicyShellUUID, and the QuoteUUID of the quote your customer has selected.
• The /selectQuote response indicates success or failure.

Our API can provide Auto/Home and Auto/Renters bundle quotes - including bundle discounts - in 49 states (all 48 contiguous states plus DC) from a variety of different carriers.

How To Quote Bundles Using Our Standard Endpoints

Use these endpoints - in this general order - to receive bundle quotes for your customers. While we offer other utility endpoints, these are the basics that will take you from creating a lead to bundling two LOBs together and retrieving bundle-discounted quotes.

Note: The exact order and timing of your requests can vary, depending on the flow of your application. In order to quote a bundle, you'll need to have at least created both an auto Policy Shell and a property Policy Shell for your customer. But once both Policy Shells are created, you can update and quote them in any order. Bindable recommends you post updates and quote requests for the customer's auto Policy Shell before you even start collecting and updating their property Policy Shell, but that's just a general guideline.

You will be quoting each LOB separately, but the quotes will each be processed as half of a bundle, reflecting whatever bundle discounts each carrier may apply. Each carrier will recognize the two quote requests as being associated with the same customer in their system.

/createLead

• Create your customer's account in our system by posting their basic information (name, email, address, etc.). Note: You only need to use this endpoint once per customer.
• Your request must include a RefCode, which is provided to you by Bindable.
• The /createLead response contains a LeadUUID, which you need to use for all future requests made on behalf of your customer.

/createPolicyShell

• Create Policy Shells - containers for all info related to your customer's two potential policies, one for each LOB. You will make two separate requests to this endpoint: one for the auto Policy Shell and one for the property Policy Shell.
• Your requests must include the RefCode and the LeadUUID returned in the /createLead response, as well as a value for the LOB indicating each Line of Business: "AUTOP" (Personal Auto Insurance), "HOME" (includes Homeowners and Condo Insurance), or "RENT" (Renters Insurance).
• Each /createPolicyShell response must include a PolicyShellUUID, which is required for all future requests made for this Policy Shell. After making both requests, you will have two PolicyShellUUIDs, one for the auto policy and one for the property policy.

/updatePolicyShell

• Update each newly-created Policy Shell with individual requests containing any/all underwriting data related to your customer's potential policy for each LOB. These updates can be partial, and you can make any number of updates for each Policy Shell. You must update the auto Policy Shell separately from the property Policy Shell.
• Your requests must include the RefCode, the LeadUUID, and the relevant PolicyShellUUID returned in the /createPolicyShell response for each LOB.
• The /updatePolicyShell response will indicate success or error (detailing any validation errors).

/quotePolicyShell

• Once each Policy Shell is fully updated, submit this quote request individually for each LOB and our response will outline all the carriers Bindable has requested to quote your customer for that LOB. You need to quote the auto Policy Shell separately from the property Policy Shell, but in each case the quotes will be processed as half of a bundle.
• Your request must include the RefCode, the LeadUUID, the PolicyShellUUID for the primary LOB you are quoting, and the PolicyShellUUID for the secondary LOB which you are bundling with the primary LOB.
• The /quotePolicyShell success responses each contain an array of carriers that have been quoted for that LOB, with a unique QuoteUUID for each carrier quote. All accumulated Policy Shell data is fully validated at this point, and an error response will provide specific validation errors.

/getQuote

• Retrieve full quote response from each carrier that was quoted via the /quotePolicyShell endpoint. Note: Not every quote request will be successful, so not every quote response will contain quote data.
• For each LOB, make one request for each carrier. These can be asynchronous requests. Your request must include the RefCode, the LeadUUID, the PolicyShellUUID, and the QuoteUUID of the quote assigned to that carrier in the /quotePolicyShell response.
• The /getQuote success response presents all the carrier quote data (detailing the premium, policy term, any applied discounts, payment plans, and quoted coverages), which you can use to embed the quote within your application. Each response will explicitly indicate whether the carrier has applied a bundle discount, and if so, will include the name of that particular carrier discount as well as (if provided) an itemized discount amount. If the carrier failed to quote, a failure response will include information provided by the carrier explaining why they declined to quote the customer. Note: Not every failed quote message will be helpful, and a generic failure message is returned if no details were provided by the carrier.

/selectQuote

• Indicate which quote your customer has selected within your application. This elevates the lead's priority level and informs the agency of their preference. This request is optional, and it can be made for the auto and/or property quotes.
• Your request must include the RefCode, the LeadUUID, the PolicyShellUUID, and the QuoteUUID of the quote your customer has selected.
• The /selectQuote response indicates success or error.

Both basic info and policy-specific data can be prefilled on our consumer funnel. This is beneficial to the user experience as it reduces friction by creating less form inputs for customers to fill out. Here are the basics of creating a custom URL that contains a customer's prefilled data.

Note: Prefilling data requires a Bindable-hosted quoting application. Prefilling policy-specific data is only available for Auto, Home, and Renters LOBs.

/createLead

• Create your customer's account in our system by posting their basic information (name, email, address, etc.). Note: This endpoint works the same way for every LOB.
• Your request must include a RefCode, which is provided to you by Bindable.
• The /createLead response contains a LeadUUID, which you need to use for all future requests made on behalf of your customer.

/createPolicyShell

• Create a Policy Shell - a container for all info related to your customer's potential monoline policy.
• Your request must include the RefCode and the LeadUUID returned in the /createLead response, as well as a value for LOB.
• The /createPolicyShell response includes a PolicyShellUUID, which is required for all future requests made for this Policy Shell.

At this point, you can either continue prefilling data by making POST requests to /updatePolicyShell or you can create the customer's ReturnURL - that is, a custom URL that has your customer's data prefilled in our enrollment funnel. Once you have all of your data prefilled, use the endpoints listed below.

/createReturnURL

• Create a tokenized URL that redirects your customer to our enrollment funnel with prefilled data.
• Your request must include the RefCode, LeadUUID, and PolicyShellUUID. There is one optional property you may include:
  • ExpirationTime: Control when your URL expires (in minutes). The default is 30 days (43200 minutes).

/validateReturnURL

• An optional endpoint that allows you to check if the created ReturnURL is valid, invalid, or expired.
• If invalid or expired, you can make another POST request to /createReturnURL in order to create a new ReturnURL.

/expireReturnURL

• Manually expire the ReturnURL. Useful for security purposes, e.g. setting the URL to expire once a customer binds a policy.

For partners integrated with the Bindable agency, you can request that the agency contact your customer via phone and SMS at any point within your customer flow once you've created a Policy Shell.

The only requirement is that you obtain consent to be contacted via phone and SMS from your customer, and you submit that consent information in an /updatePolicyShell request. The customer needs to have granted consent for both phone and SMS contact, and you will need to provide the exact consent language and the timestamp when consent was given. If you want the agency to contact your customer about a bundle, you will need to update both Policy Shells with consent information.

Our implementation team will work with you during your integration buildout to ensure you have the correct consent language for our agency.

Use these endpoints - in this order - to request our agency contact your customers.

/createLead

• Create your customer's account in our system by posting their basic information (name, email, address, etc.). Note: This endpoint works the same way for every LOB.
• Your request must include a RefCode, which is provided to you by Bindable.
• The /createLead response contains a LeadUUID, which you need to use for all future requests made on behalf of your customer.

/createPolicyShell

• Create a Policy Shell - a container for all info related to your customer's potential monoline policy.
• Your request must include the RefCode and the LeadUUID returned in the /createLead response, as well as a value for LOB: "AUTOP" (Personal Auto Insurance), "HOME" (includes Homeowners and Condo Insurance), or "RENT" (Renters Insurance).
• The /createPolicyShell response includes a PolicyShellUUID, which is required for all future requests made for this Policy Shell.

/updatePolicyShell

• You will need to include data confirming your customer consented to be contacted by phone and SMS in this update request in order for the subsequent /contactLead request to succeed. (It's up to you whether you also include any or all underwriting data related to your customer's potential policy - that's not necessary.)
• Your request must include the RefCode, the LeadUUID, and the PolicyShellUUID returned in the /createPolicyShell response.
• The /updatePolicyShell response will indicate success or error (detailing any validation errors).

At this point in the flow you have the ability to make a /contactLead request, and any data you've provided in your earlier requests will be instantly accessible by our agent when they contact your customer:

/contactLead

• Initiate the request for our agency to contact your customer via phone and SMS.
• Your requests must include the RefCode, the LeadUUID, and the relevant PolicyShellUUID for the LOB of the policy the agent will be selling the customer (if the customer is bundling auto with home or renters, submit PolicyShellUUIDs for each LOB.)
• A success response will confirm that the LeadUUID and PolicyShellUUID(s) are valid, the appropriate consent to be contacted has been granted, and the contact process has been initiated.
• The endpoint will return an error response under these scenarios:
  • if phone and SMS consent to contact the customer have not both been granted
  • if the Policy Shell has already been bound, or has been archived
  • if an agent has already engaged the customer and recently marked the Policy Shell "Sale In Process"
  • if an agent has already engaged the customer and recently marked the Policy Shell "No Sale"

Or, you can continue on to quoting:

/quotePolicyShell

• Once the Policy Shell is fully updated, submit this quote request and our response will outline all of the carriers Bindable has requested to quote your customer.
• Your request must include the RefCode, the LeadUUID, and the PolicyShellUUID.
• The /quotePolicyShell success response contains an array of carriers that have been quoted, with a unique QuoteUUID for each carrier quote. All accumulated Policy Shell data is fully validated at this point, and an error response will provide specific validation errors.

/getQuote

• Retrieve the full quote response from each carrier that was quoted via the /quotePolicyShell endpoint. Note: Not every quote request will be successful, so not every quote response will contain quote data.
• Make one request for each carrier. These can be asynchronous requests. Your request must include the RefCode, the LeadUUID, the PolicyShellUUID, and the QuoteUUID of the quote assigned to that carrier in the /quotePolicyShell response.
• The /getQuote success response presents all the carrier quote data (detailing the premium, policy term, any applied discounts, payment plans, and quoted coverages), which you can use to embed the quote within your application. Depending on the product, state, and carrier, the returned quote may be Quote-To-Bind (QTB), which means that a customer can purchase the policy online without speaking to an agent. If QTB is offered and enabled, the /getQuote response may include a URL that redirects your customer to a QTB experience (either hosted on the Bindable platform, or directly on the carrier's website). If the carrier failed to quote, a failure response will include information provided by the carrier explaining why they declined to quote the customer. Note: Not every failed quote message will be helpful, and a generic failure message is returned if no details were provided by the carrier.

At this point in the flow you have the ability to make a /contactLeadrequest, and our agents will have full access to all of the carrier quotes received by your customer. This includes additional quote data and carrier messaging directed to agents. In addition, agents will have access to informative messaging returned by any carriers who declined to quote.

Or, if your customer flow requires it, you can wait until the customer proactively selects one of their quotes:

/selectQuote

• Indicate which quote your customer has selected within your application. This elevates the lead's priority level and informs the agency of their preference. This request is optional.
• Your request must include the RefCode, the LeadUUID, the PolicyShellUUID, and the QuoteUUID of the quote your customer has selected.
• The /selectQuote response indicates success or failure.

At this point in the flow you have the ability to make a /contactLead request, and our agents will be shown which carrier quote your customer selected and when they selected it.

A recommended workflow is to make a /contactLead request if your customer selects a non-QTB quote, or does not select any quote after a timeout you define. But if the customer does select a QTB quote, and enters the Quote-To-Bind process not requiring the assistance of an agent, you only make a /contactLead request in the event the customer did not complete purchase themselves (depending on the carrier, purchase confirmation may be available in real time via the Bindable webhook.)

Note: if your customer is bundling auto with home or renters, refer to Embedded Bundle Quoting - Auto/Home or Auto/Renters. You'll need to provide consent information for each LOB in its /updatePolicyShell request, to indicate that the customer has consented to be contacted about both policies.

Each customer will have a single Policy Shell for each LOB, and that Policy Shell's unique identifier is its PolicyShellUUID. The Policy Shell is a container for all data related to the customer's potential policy before it is bound: all underwriting data, all carrier quotes, all partnership and lead source information, all contact and consent data, and the entire history of agency engagement with the customer regarding this potential policy.

Once the policy is bound, that Policy Shell is converted to an active bound policy. It can no longer be updated nor quoted nor used to request agency contact. If that same customer has a potential Policy Shell for a different LOB, and that policy has not yet been bound, you can still make update, quote and contact requests on behalf of that customer for that potential Policy Shell.

When you issue a /createPolicyShell request, any existing Policy Shell you previously created for your customer under that LOB will be archived, along with the underwriting data and quotes associated with that existing Policy Shell. The new Policy Shell will essentially be a clean slate. Archived Policy Shells cannot be updated nor quoted nor used to request agency contact.

The only use cases for creating a second Policy Shell for an existing customer would be substantial changes to the underwriting data: if that customer has a new address, or got married, or needs to add/remove drivers or vehicles, etc.

The general recommended practice is to create one Policy Shell per LOB for your customer, and issue update, quote and/or contact requests up until that policy is bound.

Our API accepts vehicles from 1966 up through next year's models. The vehicle Year, Make, Model, Trim, and VIN fields are all required, and the VIN can be a full VIN specific to your vehicle or a partial VIN which applies generally to your vehicle's Trim.

Full VIN vs. Partial VIN

If you have values for all five vehicle fields (whether your customer has provided the full VIN or you've obtained a partial VIN via another source), submit those values. Partial VIN formats we accept include:

• 17-digit VINs backfilled with "1111111" containing the calculated check digit: 5GZCZ43D631111111
• 17-digit VINs backfilled with "1111111" containing a wildcard as the check digit: 5GZCZ43D&31111111
• 10-digit stub VINs with a wildcard as the check digit: 5GZCZ43D*3

/ymmt Endpoint

If you don't have access to all five vehicle fields, use our /ymmt utility endpoint (year-make-model-trim) to obtain these values. This endpoint uses the waterfall model where you make successive requests to eventually obtain all five fields including a partial VIN for your vehicle.

This endpoint works well with an interface in your app or website that iteratively prompts your customer for their vehicle data. Your app first makes a /ymmt request to obtain valid year values so that you can prompt the customer for the year of their vehicle. A follow-up /ymmt request containing that year returns all the valid models for that year. When you customer chooses a model, make a request containing both the year and model to obtain all the valid makes, and so on.

Once you've obtained all five vehicle fields from the /ymmt endpoint, use the exact values returned in those responses to make up the Year, Make, Model, Trim and VIN fields for your vehicle.

In each state we have three coverage packages tailored specifically for that state to provide you with fully-defined package options for quoting. You can easily quote by selecting one of these pre-defined coverage packages, or you can customize your coverage selections however you or your customer choose.

Auto Coverage Packages

Our coverage packages are defined on a low/medium/high scale. Depending on your integration, you may be able to pre-define these packages and their constituent coverages.

• Package1: a budget package, with the least amount of coverage, using state minimums and/or limits just above state minimums
• Package2: our standard package, with mid-range coverages designed to broadly apply to most customers
• Package3: an enhanced package, with higher limits and more coverages provided

Use the /coveragePackages endpoint to obtain all the details of these three packages in any state.

The /coveragePackages response fully defines each coverage package, listing all the constituent coverages and their defined limits and deductibles, and providing a customer-friendly name of the package.

For embedded quoting, you can use this response to pre-populate an interface in your app or website to present these three package options and their defined coverages to your customers.

Post the selected package under the CoveragePackage property. That package's vehicle deductibles and limits will apply to each vehicle on the policy, unless the vehicle has been submitted as liability-only.

You can customize the auto coverages for any customer by posting the CoveragePackage in the /updatePolicyShell request as "Custom" and then defining the customizable coverages under the CustomCoverages property. Note: If CoveragePackage is "Custom", then CustomCoverages are required; and if you post CustomCoverages in your request, then CoveragePackage must also be posted as "Custom".

Auto Custom Coverages

Custom Coverages offer your customers a more flexible way to quote using their own coverage combinations. You are able to customize the main policy-level liability coverages, and choose different deductibles and limits for each vehicle, using any combination of values which are valid in that state.

Use the /stateCoverages endpoint to obtain the customizable coverages and all of their valid values in any state.

For embedded quoting, you can use the /stateCoverages response to pre-populate an interface in your app or website to present these coverages and their value options to your customers.

Post the selected coverage values under the CustomCoverages object.

The GarageAddress fields are important for customers who park or garage any of their vehicles at an address different from their provided residential address. Auto carriers determine their rates based on the addresses where vehicles are garaged.

If a customer parks at least one of their vehicles at an alternate address at least 50% of the time, make an /updatePolicyShell request and provide that address via the GarageAddress fields. Note: if you are submitting a GarageAddress, then GarageAddress1, GarageCity, GarageState, and GarageZipCode are required, and GarageAddress2 is optional.

If an update contains an alternate GarageAddress (or one has already been posted in an earlier update), then at least one vehicle must be designated as garaged at that alternate address by having the WhereGaraged property posted as "Alternate".

Note: if a customer has received quotes and then changes their GarageAddress (or any address) from what has been previously posted to us, you must create a new AUTOP Policy Shell containing the new address(es) for that lead, using the /createPolicyShell endpoint.

All household members of driving age should be insured on a single policy, whether or not they will be operating any of the insured vehicles. They should all be posted to the AUTOP Policy Shell with the appropriate DriverType when quoting.

Driver Type options:

Use these endpoints within your quoting application to help augment customer data, and to select which coverage packages to quote.

/getCarriers

• Retrieve our list of valid Prior Carriers for your customer to select from.

/ymmt

• Retrieve vehicle year, make, model, trim, and VIN data to help your customer identify their vehicles.
• Bindable recommends a waterfall approach with four select inputs for year, make, model, and trim. The first request populates the years in the first select input. Once the customer selects a year, a second request is made with that year to retrieve the makes, and so on.

/coveragePackages

• Once you know what state your customer resides in, use this endpoint to retrieve the three coverage packages, along with underlying limits and deductibles of each package for that state.

/stateCoverages

• Use the /stateCoverages endpoint to obtain the customizable coverages and all of their valid values in any state. These coverage values can then be used in the CustomCoverages object in the /updatePolicyShell request.

The AUTOP and HOME LOBs allow you to submit information on your customer's prior insurance policies, if any. The AUTOP LOB requires details about the prior policy's expiration date and liability limits, whereas the Home LOB does not.

Auto: Currently Insured

When the customer currently has an auto insurance policy, with no lapse in coverage, post information about that policy via these required fields:

• PriorCarrier: use the /getCarriers endpoint for an up-to-date list of auto carriers. If a carrier is not on that list, post "Other Standard" for standard carriers, and "Other Non-standard" for non-standard carriers. (See Glossary for definitions.)
• PriorExpirationDate: to indicate there's no lapse in coverage, this date must be equal or later than the posted EffectiveDate, and so cannot be in the past.
• PriorLiability: the Bodily Injury limits of the prior policy.
• LengthWithPriorCarrier: how long the customer has been insured by the prior carrier.
• LengthWithContinuousCoverage: how long the customer has been continuously insured (by any carriers).

Auto: No Prior Insurance

When the customer has had no auto insurance within the last 90 days, post information about that lack of coverage via these required fields:

• PriorCarrier: post "No Prior Insurance".
• ReasonNoPriorAuto: the reason why the customer currently has no auto insurance.

Auto: Lapse In Coverage

When the customer currently has no auto insurance but has been insured within the last 90 days, post information about that policy and the lapse in coverage via these required fields:

• PriorCarrier: use the /getCarriers endpoint for an up-to-date list of auto carriers. If a carrier is not on that list, post "Other Standard" for standard carriers, and "Other Non-standard" for non-standard carriers.
• PriorExpirationDate: to indicate there is a lapse in coverage, this date must be earlier than the EffectiveDate, and must be within the last 90 days. The number of days between the PriorExpirationDate and the EffectiveDate determines the length of the lapse in coverage, so it is important that these dates be accurate.
• ReasonNoPriorAuto: the reason why the customer currently has no auto insurance.
• PriorLiability: the Bodily Injury limits of the prior policy.
• LengthWithPriorCarrier: how long the customer had been insured by the prior carrier before the lapse.
• LengthWithContinuousCoverage: how long the customer had been continuously insured (by any carriers) before the lapse.

Home: Currently Insured

When the customer currently has a home insurance policy, post information about that policy via these required fields:

• PriorCarrier: use the /getCarriers endpoint for an up-to-date list of home carriers. If a carrier is not on that list, post "Other Standard" for standard carriers, and "Other Non-standard" for non-standard carriers.
• LengthWithPriorCarrier: how long the customer has been insured by the prior carrier.
• LengthWithContinuousCoverage: how long the customer has been continuously insured (by any carriers).

Home: No Prior Insurance

When the customer currently has no home insurance, whether lapsed or not, post information about that lack of coverage via these required fields:

• PriorCarrier: post "No Prior Insurance".
• ReasonNoPriorHome: the reason why the customer currently has no home insurance.

To protect customer Personally Identifiable Information (PII), we require all partner-developed applications that use the /lookupDriverData endpoint to mask the display of the Date of Birth (DOB) and Driver’s License numbers (DL#) if they are displayed to the end user. Keep in mind, these fields are not returned 100% of the time.

In the PreProduction environment, DOB & DL# will be returned for development/testing purposes. In the Production environment, the DOB and DL# will be suppressed until we are able to verify that your application is adequately masking this data in a PreProduction environment.

Masking Rules:

• You can display “Age” in place of “DOB”.
• For DOB, mask the Month and Day components, and only display the Year.
• For DL#, show a maximum of the 4 right-most digits, but less than half the total.
  • e.g. if the DL# is 7 digits, you should only display the 3 right-most digits.
• For both fields, the data can not be unmasked to the customer. If the customer needs to edit either field, the data must be cleared and re-entered.
• For both fields, the data masking must occur server-side. In no way should the unmasked data be accessible client-side.

Example of driver display with Age instead of DOB:

Example of masking DOB and DL#:

Example of a user attempting to edit DOB (data is cleared, not unmasked):

Bindable grants permission to access these endpoints according to the specific type of integration you are building. If your integration has not been granted access to one of these endpoints, we will return a "403 Forbidden" error response. Please contact your Bindable implementation specialist or relationship manager with any questions about endpoint access.