Herald Changelog

Our API Reference is Open to the Public

This week we officially made our API Reference public, which contains details about Herald's full API schema. Previously, we limited access to our API Reference to customers only, using a login. Our API reference contains sample requests, sample responses, and the ability to make mock calls.

We previously released our public-facing Herald Docs, which document the core concepts and principals of Herald. With the addition of our now-public-facing API Reference, you have full transparency into our product. Our API Reference provides visibility to both our [.h-code]master[.h-code] and [.h-code]beta[.h-code] branches, documenting both released and unreleased features.

Fixes and Improvements

• We improved our data cleaning to strip everything after a trailing [.h-code]/[.h-code] from domain names. Previously submitting a domain name such as [.h-code]heraldapi.com/docs[.h-code] would cause an error, but our data cleaning now transforms it to [.h-code]heraldapi.com[.h-code].
• We fixed a bug that allowed users to submit a string of characters, such as [.h-code]yes[.h-code], as a valid domain name.
• We updated domain name to be an optional parameter for certain products.
• We fixed a bug that required a risk parameter for 5-year claim history when using certain cyber products, even when it was irrelevant.

Tailoring question text to your audience

An applicant, or an agent representative, must answer questions about their level of risk and the coverage items they seek in order to get an insurance quote. This week we launched support for alternative versions of the same question text: one oriented towards the applicant and one oriented towards their agent. We now provide applicant- and agent-facing text for every risk and coverage parameter in Herald.

With this feature, our customers can customize which type of question text their user sees based on the experience they're trying to build. Prior to this release Herald only offered one version of the text for each question that was provided by the relevant carriers. This text was inconsistent across the multiple carriers integrated with Herald. Sometimes this text was written for the applicant, other times for the agent.

These text options appear in the [.h-endpoint-link]/applications[.h-endpoint-link] responses, located within the [.h-code]parameter_text[.h-code] object for each risk and coverage parameter. We have also documented the details around applicant- and agent-facing text in the Appendix for every parameter in Herald.

Fixes and Improvements

• We fixed a bug that was returning quotes without a [.h-code]portal_link[.h-code] for certain Cyber products.
• We enhanced Cyber products to accept more values for Aggregate Limits.
• We improved the error messaging around certain malformed requests to our /quotes endpoint.
• We fixed a bug that was throwing an erroneous [.h-code]400[.h-code] error when Content-Type was not set to “application/json.”

‍

The Classifications API

We’ve already simplified the process to classify an applicant with Herald Codes. This week we took it a step further by releasing our [.h-endpoint-link]/classifications[.h-endpoint-link] endpoint.

The classifications API allows customers to get classifications to classify an applicant. Each classification includes the Herald Code needed to classify the applicant with Herald, along with the description and 6-Digit code defined by NAICS.

Copied

{
    "id": "j8de53",
    "description": "Law firms",
    "naics_2017_6_digit": "541110",
    "naics_2017_6_digit_description": "Offices of Lawyers"
},
 

This endpoint supports a [.h-code]search[.h-code] query, enabling our customers to build front-end industry search to classify applicants easily. Search results are powered by Elasticsearch, enabling fuzzy search and prioritizing results based on a number of factors. Learn more about the classifications API here.

Data Cleaning

We’ve introduced Data Cleaning for values that are commonly formatted incorrectly. Herald has pre-defined formatting requirements for values like Email, Phone Number, and Domain. Previously, submitting a value with the incorrect format would throw a [.h-code]400[.h-code] error.

With our Data Cleaning feature, Herald correctly maps these values to the correct format instead of throwing an error. For example, Herald requires [.h-code]phone_number[.h-code] to be 10-digits with no special characters. Submitting a phone number in the format “(123) 456-7890” will now be reformatted to “1234567890” automatically to prevent throwing errors and building validation on your own.

What’s not new: Herald still reformats these values when submitting to an individual carrier, to each carriers expected format.

Features and Improvements

• Added a [.h-code]conditional_on[.h-code] property to the Dynamic Application to show which parameter triggered the conditional parameter.
• We now default the cyber retroactive date for certain carriers to the year 1970 to always request Full Prior Acts coverage.
• We launched a prefill feature for the Herald Request Builder to streamline testing. This feature prefills the application with default values to quickly complete applications.
• Updated cyber status messages to offer enhanced messages for quotes that are active, declined, and expired.
• Enhanced Cyber products to accommodate a broader range of coverage limit requests.

‍