Herald Changelog

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.

‍

Brand New Docs

This week we released our brand new Herald Docs, accessible to the public from our website. Prior to this release our docs were private, only accessible to customers with a login.

Few things affect a developer’s experience more than API documentation, and the world’s leading infrastructure companies all publicly expose their docs. These observations inspired us to start down the journey of sharing more and more of our documentation with the broader insurtech community. We strive to make our product one of the easiest APIs for developers to integrate with, and this release is a monumental step in our journey. Our new docs emphasize the core concepts of our product, and walk developers through specific use cases.

This material marks a first step in our journey towards open documentation, and we will add new docs and guides over time.

More clarity for inactive quotes

Last month, we announced our detailed status messages for quotes that are referred, declined, or unsupported. These status messages provide context as to why the quote is inactive, which could be anything from an out-of-appetite class code or too many employees.

As of this release, we’ve expanded status messages to every carrier integration making it easier than ever to get active quotes during testing.

Fixes and Improvements

• We began collecting and storing the full response for each error to speed up the troubleshooting process.
• We fixed a bug in our webhooks, where unresponsive quotes were not receiving a webhook response.
• We expanded our supported class codes for Workers Comp, GL, and BOP, which introduced 6 new risk parameters.
• We fixed a bug that was not returning a portal link for one of our recent carrier integrations.

‍