Three big features

Thank you for your patience here. This entry is about a week late because your beloved author was traveling to sunny San Diego. But this one is worth the wait, because we launched three big features.

1. Another BOP carrier

Markel’s Business Owners’ Policy (BOP) product is now available through Herald. Not only does this addition expand our BOP appetite, but it also represents the first carrier with two separate products available through our API. This title won’t belong exclusively to Markel for long; we’ve got a long list of carriers with multiple automatically-underwritten products that we’re integrating as quickly as possible.

2. Webhooks

When you create a submission through Herald, we immediately return a quote id for every product you’ve requested. Today, our customers use that id to poll our API (using the GET /quotes endpoint) and check each quote’s status. When the quote status moves from “pending” to “active” our customers can show the price.

This approach required our customers to write polling logic that can be frustrating to build and maintain. With webhooks, we remove this frustration by returning push notifications for certain events. To start, Herald will send notifications when quotes change status. In the future, we will use this same infrastructure to send notifications for other events.

3. "Conversational" applications

Our customers build applications that collect information about a business and submit it to carriers through Herald. But building an application that collects all of the required information for a submission is a complex task. Today, our customers must account for the following four elements in their applications:

1. Questions: The user must answer all the risk and coverage questions that carriers require to get a quote for their product. This list grows when getting quotes for multiple products.
2. Conditionality: You have to show users additional questions according to conditional logic. For example, some questions are only relevant for businesses within a certain state or industry.
3. Validation: Risk and coverage values must be sent to Herald in a valid format so that we can send that information to all relevant carriers at the correct level of specificity.
4. Maintenance: These elements shift as carriers change questions, validation rules, and conditional logic over time.

Last week, we launched a new “conversational” application endpoint (/applications) that removes the burden of these four elements from our customers. This endpoint receives any known information about the applicant, and returns the full list of required questions to render on screen for the user. Our customers can iterate on this process until the application status becomes “complete.” At this point, the application can be submitted and the user can receive quotes.

This feature is currently available in beta. If you are interested in trying it out, or learning more, please reach out to us at hello@heraldapi.com.

Fixes and improvements

In addition to Markel’s BOP product, webhooks, and the /applications endpoint, we also made various other fixes and improvements:

• We added support for multi-location, multi-building BOP submissions.
• We updated the quote status for certain classes of business to “unsupported” when applying for BOP products. We will support more and more of these classes over time.
• We updated the flowchart in our API documentation to reflect the “unsupported” status.
• We updated our documentation to reflect the /applications endpoint (in beta).
• We edited the documentation around the /submissions endpoint for brevity and clarity.

‍