We recently released our newest partnership with ProWriters, a wholesale brokerage and MGA specializing in cyber insurance. The ProWriters’ online platform allows brokers to receive quotes from multiple carriers in less than a minute. As an MGA for some carriers, ProWriters has the authority to rate and quote directly. For At-Bay’s quotes ProWriters works as a wholesaler. The ProWriters platform sends each submission to our platform through an Application Programming Interface (API). At-Bay, in return, sends back a bindable quote.
What is an API and how does ours work?
The API is the language and the system through which our two platforms communicate. For people we have UI (User Interface): a website or other software that expects a human to interact with it. When we expect a system to interact with our system we provide an interface that suits systems talking to each other. An API call is a request that the client system (ProWriters’ portal) sends the server (At-Bay’s platform) over the internet. To get a quote the client request needs information like:
- General information on the applicant: name, address, industry (NAICS code), internet domains, annual revenue
- Application answers. ProWriters’ flow initially assumes a set of answers to get an initial quote, but then allows the user to change the answers and re-submit for a quote.
- Policy terms: limit, retention, effective date
Unlike the other carriers on the platform, we collect information about the applicant’s internet domains using our Quick Scan. This gives us a better picture of the applicant’s cyber risk. Our platform then takes our scan’s result along with the application’s answers and determines if the applicant is eligible for an automatic quote and the premium (if it is eligible). It then sends a response back to ProWriters’ request with fields like is_eligible, premium, and a list of identifiers for the submission and quote for future reference.
What’s the big deal and what do we get from this API integration?
Traditional systems were not designed for other external systems to interact with them. Insurance is an industry that adopted IT early on and many traditional carriers are still using traditional systems that were built as a monolith, not separating between front end user interface and back end business logic. This makes them very slow in the API game. It’s probably the reason why some of them chose to simply implement all the rating and document generation on ProWriters’ side.
Going the API route allows to separate different concerns and move faster when things change. If we have a new risk model, we implement it on our side without bothering ProWriters. They still send us the same information for the submission and get a premium. They don’t need to care about how we calculated the premium and the fact that we changed it. If ProWriters change the user flow they can do it without bothering us. It means everyone can move faster.
For the same reason we insisted on generating the quote documents on our end and having ProWriters download them through the API. This setup makes updating the documents completely care free for the API client.
Next, for our systems and underwriters there’s no real difference between submissions coming from the API or from our own portal. It’s marked as having a different source, but everything else remains the same. The broker can log into At-Bay’s Broker Platform and review, customize, or bind the quote on our platform, or she can get an underwriter to review a submission that was marked as ineligible for automatic quote.
Lastly, we also offer some security recommendations based on our Quick Scan. After a quote is provided, the client system can request a PDF that has security recommendations for the company submitted with specific finding we collected in our scan. Unlike other carriers in the market, our Quick Scan is proprietary and evolves along with our risk model. This allows us to support the broker better in case there are follow ups and adjust our rating where we found improvements.
Things we learned when working on the API integration
We learned a few good lessons working on the API and the integration with ProWriters that are worth sharing.
Make sure you have an engaged partner
We verified that it does take two to tango. Our engineering team and ProWriters’ have separate backlogs and cycles. Roadmaps, sprints, priorities are different and pretty opaque to the other partner. If the timing is misaligned and only one side to the integration is available at a time it takes a really long time to iterate on the solution. This does not mean you need to guarantee and be guaranteed a full dedication of the whole team, but it does require some level of commitment or efforts will go down the drain.
Over-communicate with your partner
Engagement goes beyond availability of developers. It was really fun solving a PDF merge problem that our client had with the PDF that we provided programmatically by talking about the issue and working together to resolve it. Even when you have a partner that’s available to you on the other side you really want to keep sending updates on where you are and what you’re working on. It lets them know you’re still available. It can also save you a lot of time if your partner understands which parts of the integrations are harder and which ones are easier, because as a partner you may be able to accommodate and add support for a format or a flow that fits your partner’s setup.
Standardize the non-standard
My short commercial insurance experience has taught me how non-standard products are. Coverages differ, definitions and parameters vary and change, the rating can be done in a million different ways. It’s very easy to get lost in the details and keep increasing scope and complexity.
My first recommendation would be smart about what parts you generalize and what do you “hack” or hard-code. Hard-coding solutions are quick in the short term, but then stop you from expanding and moving forward. So when a problem is more dynamic and changing in nature it makes sense to generalize, but where things are relatively constant you can make shortcuts. For example, if you keep adding brokers to the system maybe an endpoint to define new brokers is in place. But if you keep working with the same brokers you can just get a list of them from your partner and add them to your system manually. However, parameters of coverage change frequently between submissions so allowing for flexibility in the structure and making room to add more in the future is worth spending the effort on.
A second recommendation would be to break the processes you already have and separate concerns. If in our system a quote includes an email notification to the user requesting the quote, the quote API endpoint does not need to send an email necessarily. Notifications can be handled by the API client or by At-Bay’s API but in a separate endpoint. This way the API can cater both to clients who want to handle notifications themselves and those who want to rely on our API for emails.
Want to learn more about our API? Let’s talk!
