Parameters

When requesting a quote or policy, institutions gather information on the business to determine eligibility and calculate pricing. With Herald, this information is collected in the form of parameters, which are relevant for applications and bind applications.

• Parameters in applications: Used to collect information related to the business’s operations, exposure to risks, and desired coverages. This information is sent to an institution to request a quote.
• Parameters in bind applications: Used to collect any remaining information required to get a policy. This can include contact information, payment terms for the policy, and more. Information that was optional to quote typically becomes required to get a policy.

Types of Parameters

Every parameter is documented in our Appendix, but relevant parameters are provided dynamically through [.h-endpoint-link]/applications[.h-endpoint-link] and [.h-endpoint-link]/bind_applications[.h-endpoint-link].  We categorize parameters into one of three categories: [.h-code]risk_values[.h-code], [.h-code]coverage_values[.h-code], and [.h-code]admin_values[.h-code].

[.icon-circle-blue][.icon-circle-blue] Admin values are currently only relevant in bind applications, unless you are leveraging our proxies feature in beta.

‍

All parameters, regardless of the type of parameter, behave the same. Make sure to read about the relationships and complexities of parameters before creating applications. The set of parameters needed to get a quote or a policy which will vary depending on the product(s) you are using. Here are some examples:

Risk Values

Coverage Values

Admin Values

(Only relevant for bind applications)

‍

Using Parameters

Getting quotes and policies from any institution involves submitting values for risk, coverage, and admin parameters. Every individual parameter has metadata associated with it such as the products it is relevant for, the text to render on screen, acceptable values and validation…the list goes on.

If you are building a static experience, you’ll have to get this information from the Appendix. The appendix serves as our question library, listing each question and all of its associated data. However, you can get relevant parameters for the products you are using by creating applications and bind applications.

Let’s take a look at an example of how risk and coverage parameters are shown when creating an application to get a quote. You can create an application by submitting a product, or multiple products, to [.h-endpoint-link]/applications[.h-endpoint-link] like this:

POST /application

Copied

{
  "products": [
    "prd_mq3r_herald_general_liability"
  ]
}
 

The response would include all relevant parameters to get a quote for this product.

Response

Copied

{
  "application": {
    "id": "6e7c1486-9720-4135-b2b3-44e46df0404c",
    "status": "incomplete",
    "products": [
      "prd_mc4r_herald_general_liability"
    ],
    "risk_values": [
      
      {
        "risk_parameter_id": "rsk_m4p9_insured_name",
        "value": null,
        "text": "Insured name",
        "input_type": "short_text",
        "relevant_products": [
          "prd_mc4r_herald_general_liability"
        ],
        "affects_conditions": false,
        "required_for": [
          "quote"
        ],
        "schema": {
          "type": "string"
        }
      },
      ...
    ],
    "coverage_values": [
      {
        "coverage_parameter_id": "cvg_14fb_gl_damages_premises_limit",
        "value": null,
        "text": "Damages to Premises Rented Limit",
        "input_type": "integer",
        "relevant_products": ["prd_mc4r_herald_general_liability"],
        "affects_conditions": false,
        "required_for": [],
        "schema": {
          "type": "number",
          "minimum": 0,
          "maximum": 5000000
        }
      },
      ...
    ]
  }
}
 

Read our full guides on creating applications and creating bind applications.

‍

Parameter Metadata

The following metadata is provided for every parameter when creating applications and bind applications (this information is also available in the Appendix):

[.icon-circle-blue][.icon-circle-blue] Learn how to use these properties to build your application in our guide to building a front-end application.

‍

Complexities

There are a few complexities when dealing with risk and coverage parameters.

It’s important to be aware of the following relationships and behaviors, which are documented in more detail in our parameter relationships doc.

1. Parameters can have conditional relationships. In many cases, a parameter is only relevant under certain conditions. For example, a carrier may need to ask if an applicant serves alcohol, but only if the applicant has provided a certain class code for an industry such as catering.
2. Parameters can have parent/child relationships. Some parameters are children of parent parameters, and some child parameters can be parents to other parameters. For example, if an applicant performs work in multiple industries, they may need to submit revenue for each industry. In this case, the risk parameter for industry (class code) would be a parent of the risk parameter for revenue.
3. The same parameter can have multiple values, appearing multiple times. Let’s imagine that an applicant has multiple locations- one in San Francisco and one in Los Angeles. In this case the “Location” risk parameter (a parent) should appear twice. We flag when this is a possible using [.h-code]creates_array: true[.h-code], and use [.h-code]instance[.h-code] to differentiate between each instance of the parameter.

‍