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.
Introducing Data Extractions (Beta)
Streamline quote-and-bind workflow with PDF extraction
Herald recently announced the launch of its Data Extraction feature to streamline the insurance quote-and-bind workflow by enabling brokerages to extract unstructured data from PDF documents—such as application forms—and integrate them into their systems
You can leverage the /data_extraction endpoint to post and retrieve data from PDFs that you upload via the existing /files endpoint. See step-by-step guidance here.
Note that /data_extraction is a beta endpoint. If you would like to request access to this beta release, please contact support@heraldapi.com.
Shareable links in HeRB
We’ve enabled customers to share links at every stage of the quote and bind process in HeRB. For example, you could easily share a link to a quote with your colleagues via email, or share with Herald customer success representative a bind application you need help with.
Additional feature enhancements and bug fixes
- We’ve added customer and agent facing tooltips to the appendix, allowing customers to view tooltips in the /application endpoint response
- We’ve simplified our /insurance_parameters relevance and combined identical conditionals for different products
- We’ve removed a set of conditional parameters for a carrier’s EPLI product to stay in sync with carrier requirements
- We’ve fixed a bug related to authorized vendor parameters for a Management Liability product
- We’ve fixed a bug related to re-rate flow
- We’ve fixed a bug related to a carrier’s MPL file failure in the new quote processor flow
Bind 2.0 Has Launched (Beta)
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!
Another MPL Integration and Knockout Logic
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.
Dynamic Application Updates
Updates to the dynamic application API
We released a handful of new features to our dynamic application endpoint. All of these features support building a more structured, cohesive application-filling experience.
- Ordering: Across our insurance products we have mapped nearly 1,000 (deduplicated) questions, in the form of risk and coverage parameters, that may need to be submitted on an application. We recently made changes to improve the order in which we organize these parameters. We improved this order based on industry standards, the intent of the parameter, and a number of other factors. Learn more about our approach to ordering by reading the docs and our appendix.
- Sections: In addition to establishing the order in which we return parameters, we have also categorized each parameter into an individual [.h-code]section[.h-code]. Every parameter now belongs to a [.h-code]section[.h-code] such as Basic Information (for parameters such as Name and Email), or Risk Information (for parameters specific to the applicant’s risks). A [.h-code]section[.h-code] is provided for each risk and coverage parameter in both the application response and the appendix. Read more about sections here.
- Currency: We have added [.h-code]currency[.h-code] as a new input type. This input type allows you to add unique styling to parameters that expect a currency.
New Cyber Product
This week we integrated a new Admitted Cyber product. This integrations bring us to a total of 31 supported products, including 8 Cyber products.
Fixes and Improvements
- We added a special kind of validation to our risk parameter for industry classification to confirm that the value submitted is a valid Herald Index Entry code.
- We fixed a bug that prevented users from making GET /producers requests when using [.h-code]external_id[.h-code] as a query parameter.
- We deprecated the [.h-code]text[.h-code] property in our application response, which was previously replaced with the [.h-code]parameter_text[.h-code] object that includes agent-facing and applicant-facing text.
- We expanded our [.h-endpoint-link]/classifications[.h-endpoint-link] endpoint to support querying to multiple 2017 NAICS codes at once.