Guide to Successfully Bind Quotes

Manual Binds

📘

Binding via email or after underwriter review

You can bind manually via your broker's account in the At-Bay Broker Platform by appending the company_id in our API response to our Broker Platform link:

• Production https://keeprisk.at-bay.com/company/{company_id}
• Demo https://keeprisk-demo.at-bay.com/company/{company_id}

Automated Binds via API

Step 1. Contingencies

When you make a GET request to /quotes/{quote_id}, the response will contain a property called contingencies which is an array of contingency objects.

❗️

Multiple Contingencies

Referred quotes will sometimes have multiple contingencies in the contingencies array after underwriter review. Please reflect this back to your user so this can be handled manually via a link to our Broker Platform

"contingencies": [
  {
    "contingency_id": int,
    "status": "closed" || "open",
    "text": str,
    "type": "post_bind" || "pre_bind"
  }
],

This list will usually include only one contingency that's the post-bind contingency of a signed /application.

🚧

Contingency Status

Contingencies will only be closed after underwriter review.
However, this does not matter for our usual post-bind signature contingency.

Step 2. Fulfilling Contingencies and Uploading Documents

You can fulfill contingencies by uploading documents tied to them.

For the post-bind signature contingency you must:

• Download our application by making a GET request to /quotes/application/{quote_id}
• Upload the signed application using POST /documents

Upload Documents

In our /documents endpoint, we expect 4 fields in the request body's payload.
These 4 form-data fields are:

{
  "contingency": {contingency_id}, //as part of the response in the contingency object of GET /quotes
  "file": File, //One file per request. Though multiple requests(supporting documents) can be made per contingency
  "quote_identifier": {quote_id},
  "name": str 
}

Step 3. Make a Bind Request

Once the support documents are uploaded, you can make POST request to /bind!

Request body payload:

{
    "quote_identifier": {quote_id},
    "dates": {
        "effective": str, //"YYYY-MM-DD"
        "expiration": str //"YYYY-MM-DD"
    },
    "app_attestation": boolean // Optional field. Omittance will result in a bind request or conditional binder issued.
}

For more detail regarding the results of a bind request, please check out the table on app attestation.

❗️

Quote validity period for binds

The effective date cannot be more than 7 days in the past from the current date and more than 30 days in the future.

Step 4. Retrieve Policy Documents or Poll for closed Contingencies

If you have sent a bind request with app_attestation:true with uploaded documents, you can now make GET requests to quotes/policy/{quote_id} and other document endpoints.

With conditional binders, these endpoints can also be utilized:
quotes/binder, quotes/billing_statement, quotes/security_letter.

The quote_status of successfully bound quotes or quotes with conditional binders will be policy_active and a policy_number will be available in the response of GET /quotes.

❗️

Resubmitting a bind request

If you initially received a conditional binder, you must wait for underwriter review. You cannot submit another bind request with app_attestation:true. Ensure that app_attestation can be used before submitting a bind request.

Quotes will expire after 30 days if the conditional binder has not been fulfilled.

Polling Strategy for Unfulfilled Contingencies

We recommend making a GET request to /quotes/{quote_id} once a day to see if the contingency status has moved from open to closed. Our underwriters will review your bind request within a few business days.

🚧

Quote Status bind_requested

If a quote has entered the bind_requested status, it usually means there are pre-bind contingencies or more post-bind contingencies than our usual signature contingency that needs manual underwriter review.