Unified Insurance Quoting API
A single, unified API to connect to 60+ of the world’s top insurance carriers.
In January 2022, Herald had just launched the MVP of their product. Herald's vision is to develop a unified API to power the insurance ecosystem, integrating with all of the worlds biggest insurance carriers (we've been equated to the Plaid of insurance). It all started with Quoting, powering brokerages, SaaS platforms, and embedded insurance experiences to offer quotes across multiple carriers through a single integration.
In March of 2022, I joined Herald as Director of Product to lead the Product team. Through my leadership, Herald has developed the industry standard for submitting applications and quoting via API, powering some of the largest brokerages in America.
As an Aggregator of other API's, in an industry that tends to be behind the times, you have to design a solution that scales for any scenario. Naturally, brokerages want to access files associated with an insurance quote or policy, but only some carriers make them available via API. Some are returned via links, some are returned in an encrypted Base 64 format. Some are accessible immediately, and some take 24 hours.
In designing a unified API, you have to develop your own level abstraction of abstraction that will scale for any scenario you might run into. This involves countless hours of research into the API's you'll be integrating with, and the desired experiences of the platforms integrating with you.
These are some of the key features we developed from 2022 - 2023. All features were prioritized accordingly in Quarterly Planning based on customer demand, impact in total quotes, and potential contracts.
Files: The /files endpoint allows customers to get metadata for an individual file, as well as getting a temporary link to stream the contents of a file. Carriers can offer multiple files to accompany a quote, from a sample insurance policy to a PDF report of a company's potential cyber risk. We integrated with multiple carrier APIs to download and host these files ourselves for each quote, making them accessible through a single API.
Industry Classifications (Search): Our /classifications endpoint allows customers to get over 20,000 professions to classify an applicant, each of which is mapped to each individual carrier's classification system. In order to support front-end classification experiences, we offer a query for search, limiting the amount of results, and pagination.
Producers + Connections: A producer is typically an agent or broker authorized to sell an insurance product on behalf of one or more insurance carriers. Each licensed agent that will be getting quotes and binding (purchasing) policies is a producer in Herald's system.
In Herald’s ecosystem, producers are a part of a larger hierarchy that represents the real world. In the real-world, a producer belongs to a distributor (essentially, the brokerage or agency that they work for) and can be grouped with other producers based on attributes such as their office or the division they are a part of. These real-world relationships are reflected in our API, where each producer is required to belong to a distributor and can be associated with multiple groups.
When submitting an application to get a quote, we use producer_id to communicate these relationships with the carrier so they identify who is requesting insurance. In order to successfully get a quote, the producer must have a connection to carrier.
A connection is the relationship between an individual producer and an individual carriers' product. The /connections endpoint requires the API-level representation of the producer in order to authentication that they are licensed and approved to sell the carriers products. For example, the carrier may understand the producer via a 32-digit UUID, the producers office via a 6-digit office code, and the producers distributor via domain. I created the connections endpoint to dynamically communicate exactly what representations are needed for the producer to authenticate with the carrier, largely inspired by the Plaid authentication flow in which the user selects their bank, and is prompted to authenticate with that banks flow.
