Herald Changelog

The latest updates at Herald.

The changes below are Herald additions and updates that are backwards compatible. In the event of a change that may affect your integration with Herald, you'll be contacted in advance to ensure you have sufficient time to adjust. Read more in our guide to High Impact Changes at Herald.
Mar 17, 2025
Latest

We've been focused on developing, refining, and enhancing our commercial insurance APIs. While this update provides key highlights, more details will be shared soon. Stay informed about the latest features and improvements, with additional updates to come.

Effortless Insurance Applications with Herald's Autofill API

Say goodbye to tedious data entry! Herald's new Autofill API streamlines the insurance application process by instantly populating Herald applications with saved business data. Whether starting fresh or completing a partially filled application, Autofill ensures accuracy while saving valuable time. Elevate your workflow and boost efficiency with seamless integration—try it today!

Herald & Babbix Introduce Native Quoting in Outlook

Email remains a dominant tool for insurance brokers, but manual workflows slow down the quoting process. Now, Herald and Babbix are changing that. With native quoting inside Outlook, brokers can instantly extract key data from emails using Babbix’s AI-powered tools, while Herald submits that information to carriers—returning a panel of quotes as soon as they’re ready. No more back-and-forth emails or manual data entry. Easily integrate it into your existing platform or launch a new offering with zero new code required. Watch a demo here.

May 31, 2023

Bind 2.0 with CFC!

In our last changelog, we announced that we launched an updated version of our bind endpoints (Bind 2.0) in Beta. This week we’re excited to announce Bind 2.0 functionality is now live with CFC for their Cyber and Tech E&O products. We’ve also included a few new bind features:

  • Pre-fill from the application: When starting the Bind process with Herald, we now automatically pull in the relevant date if it was provided at the quote stage, for example a desired effective date. If the data is invalid — such as if the effective date becomes out of a carrier’s range — we allow the user to update that information.
  • Invalid status for expired quotes: A user attempting to bind an expired quote will receive an error message indicating that the quote is expired and cannot be bound.
  • Policy Files: Users can use Herald’s Policies endpoint to retrieve various files provided by carriers post-bind such as the Dec Page, Policy, and Endorsements.

Stay tuned as we continue to roll out documentation and add new carriers and products to bind 2.0!

Another BOP product

We’ve recently added 1 new Business Owners Policy (BOP) product, bringing our number of BOP products to 7.

Account linking

When generating quotes via API, some carriers will provide an account_ID which can be used to associate future submissions and quotes with the same applicant/insured. Herald now captures these account_ids (at times called company_ids, company_code, account_number, etc…) and automatically applies it to future submissions that users send. We will expand this functionality to additional carriers as they make it available.

Now, as a result, users who log into carrier portals where this functionality is in place will see multiple submissions and quotes grouped together.

Fixes and improvements

  • We updated a cyber product to reflect changes in carrier required questions.
  • Carriers often require producers to authenticate with their API via email. Under various scenarios, a single producer may use different emails with different carriers. Herald now allows a single producer to specify a specific email for any given carrier with which they are establishing a connection.

May 24, 2023

Bind 2.0 has launched (beta)!

For a little while now, we’ve been re-working our endpoint for binding policies across carriers. We wanted to launch a more robust bind endpoint that accounted for the wide array of scenarios we’ve encountered across the dozens of carriers we work with. For example, to bind, carriers may require:

  • Signed applications
  • Payments
  • Uploading files
  • Responding to contingencies
  • Responding to requests for more information
  • Completing tasks outside an API (e.g., in a carrier portal)

Using our new bind endpoints, our users follow a flow similar to our Quote flow. To bind, users:

  • Create a Bind Application to collect all the values a given carrier needs to bind (these vary widely based on each carrier and their product, because nothing is every straightforward in insurance!)
  • Send a Bind Order to request to bind a quote
  • Get a Policy if a Bind Order is accepted by a carrier.

Our new Bind flow is still in beta. You can check it out in detail on our “herald-cyber” test product in our Sandbox environment. We welcome your feedback! We’ll be rolling our our detailed documentation and bind integrations for all of our carriers (where available) on an ongoing basis, so keep an eye out!

Increased information passed to carriers for referrals

When an applicant gets a referred quote from Herald, we tell them it has been ‘referred’. This means the applicant (or broker) will need to follow up with an underwriter to receive quotes.

For some carriers, we added more information to what Herald passes to underwriters for these ‘referred’ quotes. This means the underwriter has a more holistic view of the account and increases the speed in which applicants obtain responses back about their requested coverage.

Fixes and improvements

  • We’ve added the capability to receive Cyber Risk Assessments PDFs via API available to customers for some Cyber products. This is the 3rd file type that Herald supports. All these files can be accessed using the [.h-endpoint-link] /files[.h-endpoint-link] endpoint.
  • We’ve fixed a bug in which for some products the producer referral flow was showing as active but should have been shown as referred.

Subscribe to our changelog to stay up to date!

May 10, 2023

Another MPL product

We’ve recently added 1 new Miscellaneous Professional Liability product (MPL), bringing our number of MPL products to 5.

Knockout Logic

Sometimes a user filling out an application answers a question that will immediately disqualify them from receiving a quote from a certain carrier. For example, if a carrier only offers policies to businesses with revenue under a certain threshold, any applicant with revenue over that threshold will be disqualified, regardless of how they answer any other application questions.

We refer to these questions as ‘knockout questions’. It is helpful to know which questions have this impact, as the user can then stop filling out the rest of the application (or at least the questions on the application relevant to product for which they’ve been knocked out).

We’ve now exposed this information, which we call ‘knockout logic’ in our /applications service, and now communicate if an applicant has been knocked out and for which products.

We show this as an error message that returns in the early exits object. Customers have the option of exposing the message to applicants as well.

  • Example message: “The quote is declined because the total gross sales exceed the permitted maximum.”

For certain products, we currently knockout based on:

  • Revenue
  • Industry

Fixes and Improvements

  • We’ve made applications PDFs via API available to customers, in addition to the other files already offered (e.g., Quote Letter). These can be accessed using the [.h-endpoint-link] /files[.h-endpoint-link] endpoint.
  • We’ve expanded the prices array in the quote object. We’ve added additional detail, breaking out the fees included in the premium.