Herald Changelog

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.

‍

Sorry for a bit of a delay, our last changelog was held up by our preparation for for Insuretech Connect (ITC) in Las Vegas. We apologized for being late last year for the same reason, but as always ITC was worth it. Despite the event prep, we still launched two new carrier API integrations since our last update.

Two New Products

We launched two new insurance products this week: one BOP (Business Owners Policy) and one General Liability. These integrations bring us to a total of 22 supported products, including 7 supported General Liability products and 5 supported BOP products.

Dynamic Application Updates

We updated our dynamic application endpoint ([.h-code]/applications[.h-code]) after receiving some feedback from our customers:

1. Submitting multiple instances of risk parameters: Previously, we included two instances of any risk parameter with the quality of creates_array: true, to represent that one instance was required (such as an applicant’s first location), and the next marginal instance was optional (such as an applicant’s second location, if applicable). Our developers gave us the feedback that the optional instance was more confusing than helpful. We now include only 1 instance of each parameter that can have multiple values. You can create additional instances, such as a second location for an applicant, by following the steps in our guide to creating instances.
2. Ordering of Conditional Questions: Previously, we inserted conditional questions in the middle of the application as they became relevant, making them difficult for developers to find. We now group conditional questions at the bottom of the application.
3. Relationships of Buildings and Coverages: Building coverages are now conditional on individual building risk parameters. Submitting a building for an applicant of [.h-code]building_1[.h-code] returns a conditional group of coverages for [.h-code]building_1[.h-code]. Previously, these values had to be submitted at the same time, which made our dynamic application difficult to render in real time as users filled out the application form. Read more in our guide to using risk-specific coverages.

Features and Improvements

• Fixed a bug where submitting 2 claims for the same amount would throw a [.h-code]400[.h-code] error.
• Added early decline logic for Cyber quotes for specific states that are out of appetite for certain products.
• Added the ability to edit products on an application when using the Herald Request Builder (HeRB).
• Introduced persistent login and page navigation to the Herald Request Builder (HeRB).
• Updated the quote response for certain Cyber products to include a portal link.
• Fixed a bug that was causing irrelevant [.h-code]coverage_parameters[.h-code] to be included in the quote response.
• Implemented new status messages for Cyber quotes.
• Fixed a bug that allowed submissions with property deductibles greater than the property coverage limit.
• Allowed [.h-code]null[.h-code] values for optional parameters when making a submission.
• Created a check to make sure General Aggregate Limits are at least 2x the Occurrence Limit. If it is not, we default the General Aggregate Limit to 2x the desired Occurrence Limit for certain carriers.

‍

The Herald Request Builder

Today we’re launching the Herald Request Builder (HeRB), an interactive demonstration of our dynamic application with real-time API requests.

The Herald Request Builder is a fully interactive demo of our application, submission, and quote endpoints. Each step has a front-end editor and JSON payload, all pulling from our APIs sandbox environment in real time.

Herald customers can access HeRB with their sandbox token to:

• Create real sandbox applications for their products
• Demo real-time conditionality of risk and coverage parameters
• Retrieve test quotes
• And more, all while viewing the actual API requests and responses.

You can learn more about HeRB in our docs.

Features and Improvements

While building HeRB, we had the opportunity to build a front-end with our own API. During the process we found some room for improvement. Here’s some of the updates we made to our API while building HeRB:

• We’re now returning [.h-code]text[.h-code] for coverage parameters in the quote response, so customers can easily show all coverages and limits associated with a quote.
• We changed the risk parameter for domain to a [.h-code]string[.h-code] that can have multiple values. Previously domain was an array for multiple domains.
• We’re now including [.h-code]creates_array: false[.h-code], which was previously only a relevant property when [.h-code]true[.h-code].
• We added an error message when submitting a partially completed address without required fields, like city or state.

Additional Fixes

• Fixed a bug for dates set in the past, mapping them to a date in the future to prevent inactive quotes.
• Enhanced some of our Cyber integrations to support 5 optional coverages, including website media content liability and hardware replacement cost.
• Updated our Quote response to include the same coverages for every product. The quote response now contains coverages as null that were previously not present in the response at all.

‍