Getting Started

Introduction

Production Environment URL

https://api.allstateleadmarketplace.com/v2/

Testing Environment URL

https://int.allstateleadmarketplace.com/v2/

This document covers Version 2 of the Allstate Lead Marketplace Lead API. We use built-in HTTP features, like HTTP authentication, HTTP verbs (ie, POST) and standard response codes to simplify integrations into the API.

JSON will be returned in all responses from the API, including errors.

Authentication

Test Your Authentication

curl uses the -u flag to pass basic auth credentials:

curl "https://{domain}/v2/marco"
   -u "api_key:"

Response

{
    "response": "polo!",
    "_meta": {
        "vendor_name": "some-vendor",
        "api_version": "v2.0.0",
        "status_code": 200,
        "response_ms": 100
    }
}

You authenticate to the Allstate Lead Marketplace API by providing your API key in the request. Authentication to the API occurs via HTTP Basic Auth. Provide your API key as the basic auth username (adding a colon after the API key). You do not need to provide a password.

For example, if your API Key was api-key, your header would look like the following:

Generate an encoded value for the Authorization Header

<?php

echo base64_encode("api-key:");  // YXBpLWtleTo=

Authorization: Basic YXBpLWtleTo=

All API requests must be made over HTTPS in the Production environment - calls made over plain HTTP will fail.

Testing The API

We provide a development environment for you to test your integration with the Allstate Lead Marketplace API. Please use the https://int.allstateleadmarketplace.com URL when testing.

To test successful responses, the integration server is configured to accept all transactions in the state of California (CA). So any zipcode in that state for all valid leads should match and sell there.

Errors returned from leads sent to CA should highlight potential issues with your integration and should be verified. Please reach out to your representative if you need help.

Integrations Support

If you have any questions or need help in integration with the Allstate Lead Marketplace, please email integrations@allstateleadmarketplace.com.

When possible, please include full Request and Response examples in your support requests.

Selling Leads

There is a single method to sell leads into the Allstate Lead Marketplace.

• Ping Post Method allows for a bidding model on leads. This method requires two requests to complete the sales transaction, a Ping Request and a subsequent PingPost Request.

  This method allows the client to receive a bid amount for leads that can be matched to a buyer before sending the lead's Personally Identifiable Information.

Ping Requests

Ping Request Endpoint

POST /ping

A Ping request allows a client to determine if their lead can be sold and receive a bid amount without requiring that they send the lead's Personally Identifiable Information.

Internally on a Ping Request, the API will search for a buyer before returning a response. However, at this point the lead is not sold - to finalize the sales transaction, the client may accept the bid by making a subsequent PingPost Request containing the lead's Personally Identifiable Information.

Making Requests

Example Request Body

{
    "vertical": "auto-insurance",
    "external_id": 12345,
    "city": "San Diego",
    "state": "CA",
    "zipcode": "92101",
    "country": "USA",
    "years_at_address": "2",
    "residence_status": "home",
    "self_credit_rating": "good",
    "best_contact_time": "17:00",
    "ip_address": "8.8.8.8",
    "user_agent": "Chromium/25.0.1364.160",
    "dob": "1983-03-06",
    "tcpa": true,
    "current_insurance_company": "allstate",
    "desired_coverage_type": "BASIC",
    "desired_collision_deductible": 500,
    "desired_comprehensive_deductible": 500,
    "currently_insured": true,
    "insured_since": "2000-01-01",
    "policy_start": "2013-02-01",
    "policy_expiration": "2014-02-01",
    "bundle_insurance": true,
    "exclusive": true,
    "drivers": [
        {...}
    ],
    "vehicles": [
        {...}
    ]
}

This endpoint expects a HTTP POST containing a JSON body with all required fields for one of the following lead types:

• Auto Insurance Lead Object
• Home Insurance Lead Object

Receiving A Response

On a successful Request, the API will respond with a JSON object containing a matched status, a bid amount and a Ping Id (ping_id).

For your enjoyment, all API responses are accompanied by a _meta object containing some useful metadata.

Example Successful Response

{
    "ping_id": "83f95515cdad5eb91",
    "matched": true,
    "bid": 10.52, 
    "dba_name": "Allstate",
    "_meta": {
        "vendor_name": "some-vendor",
        "api_version": "v2.0.0",
        "status_code": 200,
        "response_ms": 512
    }
}

Response Properties

Errors

Example Error Response

{
    "error": "Invalid vertical specified.",
    "_meta": {
        "vendor_name": "some-vendor",
        "api_version": "v2.0.0",
        "status_code": 400,
        "response_ms": 128
    }
}

We hate responding with errors, but sometimes it happens. The most common errors are caused by failing validation on the lead's properties - in which case, it'd behoove you to reference Lead Objects to ensure your integration is correct.

Here is a list of errors you may encounter when sending Ping Requests.

Error Messages

PingPost Requests

PingPost Request Endpoint

POST /pingpost/{ping_id}

A PingPost request should follow a Ping request. The URI should contain the Ping Id (ping_id) that was returned from the Ping request. It should also include the lead's Personally Identifiable Information that was omitted from the Ping Request.

Internally, the API will attempt to sell the lead to the previously matched buyer before returning a response.

Making Requests

Example Request Body

{
    "first_name": "Leeroy",
    "last_name": "Jenkins",
    "email": "leeeeroy@jenkins.com",
    "home_phone": "555-555-5555",
    "address1": "black wing lair road",
    "tcpa_one_to_one_consent": true
}

This endpoint expects a HTTP POST containing a JSON body with all required Personally Identifiable Information fields for the lead.

Receiving A Response

On a successful Request, the API will respond with a JSON object containing a lead_sold status, a payout amount and the original Ping Id (ping_id).

For your enjoyment, all API responses are accompanied by a _meta object containing some useful metadata.

Example Successful Response

{
    "ping_id": "83f95515cdad5eb91",
    "lead_sold": true,
    "payout": 10.52,
    "dba_name": "Allstate",
    "_meta": {
        "vendor_name": "some-vendor",
        "api_version": "v2.0.0",
        "status_code": 200,
        "response_ms": 356
    }
}

Response Properties

Errors

Example Error Response

{
    "error": "Invalid or expired Ping Id given.",
    "_meta": {
        "vendor_name": "some-vendor",
        "api_version": "v2.0.0",
        "status_code": 400,
        "response_ms": 128
    }
}

Things didn't go according to plan? Did we mention validation is the number one cause of errors? Let's double check those Lead Objects one more time to ensure your integration is correct.

Otherwise, here is a list of errors you may encounter when sending PingPost Requests.

Error Messages

Call Transfers

Allstate Lead Marketplace supports the PingPost model for bidding on Calls Transfers. This method requires two requests to complete the sales transaction, a Call Match Request and a subsequent Call Post Request.

This method allows the client to receive a bid amount and transfer number for calls that can be matched to a buyer before sending the lead's Personally Identifiable Information.

Call Match Requests

Call Match Request Endpoint

POST /calls/match

A Call Match request allows a client to determine if their call can be sold and receive a bid amount for that call without requiring that they send the lead's Personally Identifiable Information.

Internally on a Call Match Request, the API will search for a buyer before returning a response. However, at this point the call is not sold - to receive the transfer number, the client may accept the bid by making a subsequent Call Post Request containing the lead's Personally Identifiable Information.

When a match is found, the response will include the telephone number that the call should be transferred to, as well as providing the expiration date or TTL when the phone number will no longer be locked for the request.

Making Requests

Example Request Body

{
    "vertical": "auto-insurance",
    "external_id": 12345,
    "city": "San Diego",
    "state": "CA",
    "zipcode": "92101",
    "country": "USA",
    "years_at_address": "2",
    "residence_status": "home",
    "self_credit_rating": "good",
    "best_contact_time": "17:00",
    "ip_address": "8.8.8.8",
    "user_agent": "Chromium/25.0.1364.160",
    "dob": "1983-03-06",
    "tcpa": true,
    "current_insurance_company": "allstate",
    "desired_coverage_type": "BASIC",
    "desired_collision_deductible": 500,
    "desired_comprehensive_deductible": 500,
    "currently_insured": true,
    "insured_since": "2000-01-01",
    "policy_start": "2013-02-01",
    "policy_expiration": "2014-02-01",
    "bundle_insurance": true,
    "exclusive": true,
    "drivers": [
        {...}
    ],
    "vehicles": [
        {...}
    ]
}

This endpoint expects a HTTP POST containing a JSON body with all required fields for one of the following call types:

• Auto Insurance Lead Object
  • Drivers Object
  • Vehicles Object
• Home Insurance Lead Object

Receiving A Response

On a successful Match Request, the API will respond with a JSON object containing a matched status, a bid amount, a unique call_id for the request, the carrier_name and the phone_number and expiration (TTL) for the number to transfer to.

For your enjoyment, all API responses are accompanied by a _meta object containing some useful metadata.

Example Successful Response

{
    "call_id": "132dd5570d6dbbc6951552660070",
    "matched": true,
    "bid": 22.5,
    "phone_number": "+15555555",
    "expiration": "2015-06-01 15:00:00",
    "carrier_name": "Allstate Insurance",
    "dba_name": "Allstate",
    "_meta": {
        "vendor_name": "some-vendor",
        "api_version": "v2.1.0",
        "status_code": 200,
        "response_ms": 826
    }
}

Response Properties

Errors

Example Error Response

{
    "error": "Invalid vertical specified.",
    "_meta": {
        "vendor_name": "some-vendor",
        "api_version": "v2.0.0",
        "status_code": 400,
        "response_ms": 128
    }
}

We hate responding with errors, but sometimes it happens. The most common errors are caused by failing validation on the lead's properties - in which case, it'd behoove you to reference Lead Objects to ensure your integration is correct.

Here is a list of errors you may encounter when sending Ping Requests.

Error Messages

Call Post Requests

Call PingPost Request Endpoint

POST /calls/post/{call_id}

A Call Post request should follow a Call Match request. The URI should contain the Call Id (call_id) that was returned from the Call Match request.

Making Requests

Example Request Body

{
    "first_name": "Leeroy",
    "last_name": "Jenkins",
    "email": "leeeeroy@jenkins.com",
    "home_phone": "555-555-5555",
    "address1": "black wing lair road",
    "tcpa_one_to_one_consent": true
}

This endpoint expects a HTTP POST containing a JSON body with all required Personally Identifiable Information fields for the call. These fields will still need to pass basic validation (non-empty fields, etc) in order to trigger a successful sale at the end of the call.

Receiving A Response

On a successful Request, the API will respond with a JSON object containing the call_id, a boolean success property that the lead passed validation and posted successfully, the carrier_name that the call will be transferred to, as well as the original transfer phone_number and expiration (TTL) of the original Match Request.

For your enjoyment, all API responses are accompanied by a _meta object containing some useful metadata.

Example Successful Response

{
    "call_id": "132dd5570d6dbbc6951552660070",
    "success": true,
    "phone_number": "+15555555555",
    "expiration": "2015-06-01 15:00:00",
    "carrier_name": "Allstate Insurance",
    "dba_name": "Allstate",
    "_meta": {
        "vendor_name": "some-vendor",
        "api_version": "v2.0.0",
        "status_code": 200,
        "response_ms": 356
    }
}

Response Properties

Errors

Example Error Response

{
    "error": "Invalid or expired Call Id given.",
    "_meta": {
        "vendor_name": "some-vendor",
        "api_version": "v2.0.0",
        "status_code": 400,
        "response_ms": 128
    }
}

From time to time, errors may result. Please look at the following list of potential errors to help tune your integration. If you need help, feel free to reach out.

Error Messages

Click to Call Match Requests

Click to Call Match Request Endpoint

POST /calls/match

A Click to Call Match request allows a client to determine if their call can be sold and receive a bid amount for that call without requiring that they send the lead's Personally Identifiable Information.

Internally on a Click to Call Match Request, the API will search for a buyer before returning a response. However, at this point the call is not sold - to receive the transfer number, the client may accept the bid by making a subsequent Click to Call Post Request containing the lead's phone number.

When a match is found, the response will include the telephone number that the call should be transferred to, as well as providing the expiration date or TTL when the phone number will no longer be locked for the request.

Making Requests

Example Request Body

{
    "vertical": "auto-insurance",
    "zipcode": "92101",
    "currently_insured": true,
    "product_variant": "click-to-call",
    "insured_since": "2000-01-01",
    "residence_status": "home",
    "self_credit_rating": "good",
    "drivers": [
        {
            "id": 1,
            "marital_status": "married",
            "requires_sr22": false,
            "dui": false,
            "tickets_and_accidents": false,
            "valid_license": true
        }
    ],
    "vehicles": [
        {
            "id": 1,
            "drivers": [
                1
            ],
            "year": "2005",
            "make": "Ford",
            "model": "F-150",
            "trim": "Lariat",
            "vin": "ABC123",
            "leased": false,
            "primary_use": "commutework",
            "commute_days": 5,
            "commute_mileage": 10,
            "annual_mileage": 12000,
            "alarm": false,
            "garage_type": "garage"
        }
    ]
}

This endpoint expects a HTTP POST containing a JSON body with all required fields: vertical, zipcode, currently_insured, and product_variant: click-to-call. Other fields shown in the example to the right are optional.

Receiving A Response

On a successful Match Request, the API will respond with a JSON object containing a matched status, a bid amount, a unique call_id for the request, the carrier_name and the phone_number and expiration (TTL) for the number to transfer to.

For your enjoyment, all API responses are accompanied by a _meta object containing some useful metadata.

Example Successful Response

{
    "call_id": "132dd5570d6dbbc6951552660070",
    "matched": true,
    "bid": 22.5,
    "phone_number": "+15555555",
    "expiration": "2015-06-01 15:00:00",
    "carrier_name": "Allstate Insurance",
    "dba_name": "Allstate",
    "_meta": {
        "vendor_name": "some-vendor",
        "api_version": "v2.1.0",
        "status_code": 200,
        "response_ms": 826
    }
}

Response Properties

Errors

Example Error Response

{
    "error": "Invalid vertical specified.",
    "_meta": {
        "vendor_name": "some-vendor",
        "api_version": "v2.0.0",
        "status_code": 400,
        "response_ms": 128
    }
}

We hate responding with errors, but sometimes it happens. The most common errors are caused by failing validation on the lead's properties - in which case, it'd behoove you to reference Lead Objects to ensure your integration is correct.

Here is a list of errors you may encounter when sending Ping Requests.

Error Messages

Click to Call Post Requests

Click to Call PingPost Request Endpoint

POST /calls/post/{call_id}

A Click to Call Post request should follow a Click to Call Match request. The URI should contain the Call Id (call_id) that was returned from the Call Match request.

Making Requests

Example Request Body

{
    "home_phone": "555-555-5555"
}

This endpoint expects a HTTP POST containing a JSON body with lead's phone number for the call. This field will still need to pass basic validation (non-empty fields, etc) in order to trigger a successful sale at the end of the call.

Receiving A Response

On a successful Request, the API will respond with a JSON object containing the call_id, a boolean success property that the lead passed validation and posted successfully, the carrier_name that the call will be transferred to, as well as the original transfer phone_number and expiration (TTL) of the original Match Request.

For your enjoyment, all API responses are accompanied by a _meta object containing some useful metadata.

Example Successful Response

{
    "call_id": "132dd5570d6dbbc6951552660070",
    "success": true,
    "phone_number": "+15555555555",
    "expiration": "2015-06-01 15:00:00",
    "carrier_name": "Allstate Insurance",
    "dba_name": "Allstate",
    "_meta": {
        "vendor_name": "some-vendor",
        "api_version": "v2.0.0",
        "status_code": 200,
        "response_ms": 356
    }
}

Response Properties

Errors

Example Error Response

{
    "error": "Invalid or expired Call Id given.",
    "_meta": {
        "vendor_name": "some-vendor",
        "api_version": "v2.0.0",
        "status_code": 400,
        "response_ms": 128
    }
}

From time to time, errors may result. Please look at the following list of potential errors to help tune your integration. If you need help, feel free to reach out.

Error Messages

Short Form Match Requests

Short Form Transfer Match Request Endpoint

POST /calls/match

A Short Form Transfer Match request allows client to send a warm transfer without requiring the leads full data post.

Internally on a Short Form Transfer Match Request, the API will search for a buyer before returning a response. However, at this point the call is not sold - to receive the transfer number, the client may accept the bid by making a subsequent Call Post Request containing the lead’s Personally Identifiable Information.

When a match is found, the response will include the telephone number that the call should be transferred to, as well as providing the expiration date or TTL when the phone number will no longer be locked for the request.

Making Requests

Example Request Body

{
  "vertical": "auto-insurance",
  "zipcode": "92101",
  "product_variant": "short-form-call",
  "external_id": "12345",
  "residence_status": "home",
  "currently_insured": true,
  "current_insurance_company": "allstate",
  "insured_since": "2021-01-01",
  "number_of_vehicles": 2
}

This endpoint expects a HTTP POST containing a JSON body with all required fields: vertical, zipcode, currently_insured, external_id, residence_status, current_insurance_company (if insured), insured_since (if insured), vehicles, drivers, and product_variant: short-form-call.

Receiving A Response

On a successful Match Request, the API will respond with a JSON object containing a matched status, a bid amount, a unique call_id for the request, the carrier_name and the phone_number and expiration (TTL) for the number to transfer to.

For your enjoyment, all API responses are accompanied by a _meta object containing some useful metadata.

Example Successful Response

{
    "call_id": "132dd5570d6dbbc6951552660070",
    "matched": true,
    "bid": 22.5,
    "phone_number": "+15555555",
    "expiration": "2015-06-01 15:00:00",
    "carrier_name": "Allstate Insurance",
    "dba_name": "Allstate",
    "_meta": {
        "vendor_name": "some-vendor",
        "api_version": "v2.1.0",
        "status_code": 200,
        "response_ms": 826
    }
}

Response Properties

Errors

Example Error Response

{
    "error": "Invalid vertical specified.",
    "_meta": {
        "vendor_name": "some-vendor",
        "api_version": "v2.0.0",
        "status_code": 400,
        "response_ms": 128
    }
}

We hate responding with errors, but sometimes it happens. The most common errors are caused by failing validation on the lead's properties - in which case, it'd behoove you to reference Lead Objects to ensure your integration is correct.

Here is a list of errors you may encounter when sending Ping Requests.

Error Messages

Short Form Post Requests

Short Form Transfer PingPost Request Endpoint

POST /calls/post/{call_id}

A Short Form Transfer Post request should follow a Short Form Transfer Match request. The URI should contain the Call Id (call_id) that was returned from the Call Match request.

Making Requests

Example Request Body

{
    "first_name": "Leeroy",
    "last_name": "Jenkins",
    "email": "leeeeroy@jenkins.com",
    "home_phone": "555-555-5555",
    "address1": "black wing lair road",
}

This endpoint expects a HTTP POST containing a JSON body with the lead's first_name, last_name, email and home_number for the call. This field will still need to pass basic validation (non-empty fields, etc) in order to trigger a successful sale at the end of the call.

Receiving A Response

On a successful Request, the API will respond with a JSON object containing the call_id, a boolean success property that the lead passed validation and posted successfully, the carrier_name that the call will be transferred to, as well as the original transfer phone_number and expiration (TTL) of the original Match Request.

For your enjoyment, all API responses are accompanied by a _meta object containing some useful metadata.

Example Successful Response

{
    "call_id": "132dd5570d6dbbc6951552660070",
    "success": true,
    "phone_number": "+15555555555",
    "expiration": "2015-06-01 15:00:00",
    "carrier_name": "Allstate Insurance",
    "dba_name": "Allstate",
    "_meta": {
        "vendor_name": "some-vendor",
        "api_version": "v2.0.0",
        "status_code": 200,
        "response_ms": 356
    }
}

Response Properties

Errors

Example Error Response

{
    "error": "Invalid or expired Call Id given.",
    "_meta": {
        "vendor_name": "some-vendor",
        "api_version": "v2.0.0",
        "status_code": 400,
        "response_ms": 128
    }
}

From time to time, errors may result. Please look at the following list of potential errors to help tune your integration. If you need help, feel free to reach out.

Error Messages

Call Status Webhook

Example POST Request

{
    "id": 123,
    "call_id": "83f95515cdad5eb91",
    "call_duration": 55,
    "lead_sold": true,
    "payout": "25"
}

Example GET Request

?id=123&call_id=83f&call_duration=55&lead_sold=1&payout=25

Call status notifications are delivered through a customizable webhook. This is to provide the vendor with immediate feedback on the status of the call in real time, when the call terminates.

The Allstate Lead Marketplace will automatically send a notification to your URL via GET or POST containing the client's original id (taken from the external_id which was passed to ALM during sales transactions), the call_id identifier, the total call_duration in seconds, a lead_sold status on whether or not the call was successful and the payout confirmation for the vendor.

In order to properly configure the webhook, Allstate Lead Marketplace will need to be supplied with the following:

• An endpoint to notify - ideally using HTTPS
• The HTTP Method to use (we support GET or POST - though suggest using POST)
• Optional credentials to secure your endpoint (which would be passed in the Authorization header)

Request Properties

Returning Leads

All returns can be managed directly by logging into the Allstate Lead Marketplace and visiting the Returns section. However, as a convenience a client may subscribe to return notifications through a configurable webhook. Clients who opt in to use this system will receive a notification when a User on the Allstate Lead Marketplace has requested a return for a lead sold by that client.

Returns Webhook

Example POST Request (via JSON Request Body)

{
    "lead": "83f95515cdad5eb91",
    "reason": "Disconnected",
    "id": 123,
    "first_name": "kevin",
    "last_name": "bacon",
    "email": "kbacon@aol.com",
    "phone": "5555555555"
}

Example GET Request

?lead=83f95515cdad5eb91&reason=Disconnected&id=123

Return notifications are delivered through a customizable webhook. If configured, the Allstate Lead Marketplace will send a notification to your URL via either GET or POST containing ALM's lead identifier, the return reason, and the client's original id (taken from the external_id which was passed to ALM during sales transactions).

When the notification is delivered via POST, the data will be delivered via a JSON Request body as per the example to the right.

It's up to the client to approve or deny the return by sending a Return Decision Request back to the API.

Request Properties

Return Decision Requests

Return Decision Request Endpoint

POST /return

A Return Decision Request is used for approving or denying returns that have been delivered through the Returns Webhook.

When a return is requested, a reason for the return is set by the User. When denying a return, the denial reason should typically be an inverse of the return reason - after the lead has been verified.

For example, if a User returns a lead because of a wrong_number, the Client should verify the number and deny the return with correct_number. If the phone number proves to be a bad number, the return should be approved.

Making Requests

Example Request Body

{
    "lead": "83f95515cdad5eb91",
    "return_approved": false,
    "return_deny_reason": "correct_number"
}

This endpoint expects a HTTP POST containing a JSON body with all required fields for the Return Decision Object.

You have the ability to accept or deny the return by setting the boolean return_approved value in the request. If you choose to deny a return, your request must be accompanied with one of the allowed reasons. See the Return Decision Object for a list of approved reasons.

Receiving A Response

On a successful Request, the API will respond with a JSON object containing a success message.

For your enjoyment, all API responses are accompanied by a _meta object containing some useful metadata.

Example Successful Response

{
    "success": true,
    "_meta": {
        "vendor_name": "some-vendor",
        "api_version": "v2.0.0",
        "status_code": 200,
        "response_ms": 322
    }
}

Response Properties

Errors

Example Error Response

{
    "error": "Duplicate lead found.",
    "_meta": {
        "vendor_name": "some-vendor",
        "api_version": "v2.0.0",
        "status_code": 400,
        "response_ms": 128
    }
}

It's possible that you may get an error response when attempting to approve or deny a return that has already had a decision. This can happen when the lead was either approved or denied through the Allstate Lead Management platform in the Returns section or if the lead was automatically accepted after 3 days of being in a Pending state.

Here are some errors you may encounter while trying to approve or deny a return:

Error Messages

Reference Objects

Personally Identifiable Information

Example

{
    "first_name": "Leeroy",
    "last_name": "Jenkins",
    "email": "leeeeroy@jenkins.com",
    "home_phone": "555-555-5555",
    "work_phone": "555-555-5555",
    "address1": "black wing lair road"
}

Personally Identifiable Information is required to complete all lead sales. In a Ping Request, these fields can be omitted, however, to finalize the sales transactions a follow up PingPost Request should be made which contain these properties.

In a Post Request, which is a single request transaction, all of these fields must be included - as well as the vertical specific lead properties outlined below.

Attributes

Auto Insurance Lead Object

Example Auto Insurance Lead Object

{
    "vertical": "auto-insurance",
    "external_id": 12345,
    "city": "San Diego",
    "state": "CA",
    "zipcode": "92101",
    "country": "USA",
    "years_at_address": 2,
    "residence_status": "home",
    "self_credit_rating": "good",
    "best_contact_time": "17:00",
    "ip_address": "8.8.8.8",
    "user_agent": "Chromium/25.0.1364.160",
    "dob": "1983-03-06",
    "tcpa": true,
    "tcpa_one_to_one_consent": true,
    "current_insurance_company": "allstate",
    "desired_coverage_type": "BASIC",
    "desired_collision_deductible": 500,
    "desired_comprehensive_deductible": 500,
    "currently_insured": true,
    "insured_since": "2000-01-01",
    "policy_start": "2013-02-01",
    "policy_expiration": "2014-02-01",
    "bundle_insurance": true,
    "exclusive": true,
    "number_of_vehicles": 2,
    "drivers": [
        {...}
    ],
    "vehicles": [
        {...}
    ]
}

An Auto Insurance Lead Object is used to sell to the vertical auto-insurance. Below are the properties that should be included when making a Ping Request - it should be noted that when making a Post Request that the Personally Identifiable Information should be included with these objects.

Attributes

Auto Insurance Driver Object

Example Auto Insurance Driver Object

{
    "id": 1,
    "relation": "self",
    "gender": "male",
    "marital_status": "married",
    "edu_level": "ADG",
    "occupation": "ACCOUNTSREC",
    "dob": "1983-03-06",
    "license_age": 16,
    "years_employed": 15,
    "years_at_residence": 2,
    "requires_sr22": false,
    "dui": false,
    "tickets_and_accidents": false,
    "valid_license": true
}

An Auto Insurance Driver Object is used to describe the drivers on a requested auto insurance quote.

Attributes

Auto Insurance Vehicle Object

Example Auto Insurance Vehicle Object

{
    "id": 1,
    "drivers": [
        1
    ],
    "year": "1983",
    "make": "Fiat",
    "model": "Uno",
    "trim": "3-Door Hatchback",
    "vin": "ABC123",
    "leased": false,
    "primary_use": "commutework",
    "commute_days": 5,
    "commute_mileage": 10,
    "annual_mileage": 12000,
    "alarm": false,
    "garage_type": "garage"
}

An Auto Insurance Vehicle Object is used to describe the vehicles on a requested auto insurance quote.

Attributes

Home Insurance Lead Object

Example Home Insurance Lead Object

{
    "vertical": "home-insurance",
    "external_id": 12345,
    "city": "San Diego",
    "state": "CA",
    "zipcode": "92101",
    "country": "USA",
    "years_at_address": "2",
    "residence_status": "home",
    "self_credit_rating": "good",
    "best_contact_time": "17:00",
    "ip_address": "8.8.8.8",
    "user_agent": "Chromium/25.0.1364.160",
    "dob": "1983-03-06",
    "tcpa": true,
    "tcpa_one_to_one_consent":  true,
    "gender": "male",
    "policy_start": "2014-03-01",
    "property_type": "condo",
    "year_built": "1999",
    "property_ownership": "condo",
    "owner_occupied": true,
    "property_zipcode": "90024",
    "property_address": "123 Test St",
    "property_city": "Los Angeles",
    "property_state": "CA",
    "property_country": "USA",
    "construction_type": "brick",
    "foundation": "crawlspace",
    "roof_type": "asphalt",
    "roof_age": "1-5",
    "primary_heating_system": "electric",
    "marital_status": "single",
    "bedrooms": "3",
    "bathrooms": "2.5",
    "stories": "bilevel",
    "garage_type": "attached-carport",
    "square_feet": "2200",
    "security_system": "monitored",
    "fire_alarm": "inside-city",
    "dog_breed": true,
    "located_in_flood_plain": false,
    "deadbolts": false,
    "fire_extinguishers": false,
    "trampoline": true,
    "covered_deck_patio": false,
    "swimming_pool": false,
    "replacement_cost": 200000,
    "personal_liability": "100k",
    "desired_deductible": "$1000",
    "five_year_claims": false,
    "currently_insured": true,
    "exclusive": true
}

A Home Insurance Lead Object is used to sell to the vertical home-insurance. Below are the properties that should be included when making a Ping Request - it should be noted that when making a Post Request that the Personally Identifiable Information should be included with these objects.

Attributes

Return Decision Object

Example Return Decision Object

{
    "lead": "83f95515cdad5eb91",
    "return_approved": false,
    "return_deny_reason": "correct_number"
}

The Return Decision Object is used to approve or deny returns that have been requested against leads sold by the client. When a return is denied (approved: false), then a reason must be supplied. When a return is requested, a reason for the return is set by the User. When denying a return, the denial reason should typically be an inverse of the return reason - after the lead has been verified.

Attributes

Response Metadata Object

Example Metadata Object

{
    "_meta": {
        "vendor_name": "some-vendor",
        "api_version": "v2.0.0",
        "status_code": 400,
        "response_ms": 128
    }
}

All responses from the Allstate Lead Marketplace API are accompanied with a Metadata object which provides some useful information under the _meta property. This can be helpful for debugging.

Attributes

Enumerated Values

This section is used to detail Enum type fields that either have an extensive list of options and to clearly define the allowed values.

Desired Coverage Types

The Desired Coverage Type values are set to encompass a few different levels and types of coverage. These are meant to be bucketed and estimated. If you do not see a value that matches the user's exact preference, please use the closest possible.

Values

Education Levels

The different values used for Education Level are detailed below. If you do not see an Education Level that matches perfectly to the user's declared education, please use your judgement in mapping that value as closely as possible to the allowed values.

Values

Occupations

There is a long list of possible values that can be used to describe a lead's occupation. Please reference this list to properly integrate the occupation properties.

Values