Contact Us

What Makes a Good API?

author avatar
By The Boost Team on Jan 13, 2023
8 min read
A closeup of a person using a mobile phone and a laptop, with a stylized overlay of networked dots.

APIs have become ubiquitous in modern technology - and in modern tech marketing. If you’ve ever looked into buying a software service or platform in the last ten years, the odds are that a good API was listed as one of the selling points. But what exactly makes an API “good?”

Before we dive into that question, let’s take a minute to recap what APIs are, and why they’ve become so central to business and technology.

API 101: What is an API?

Application Programming Interfaces (APIs) are the mechanisms that allow computer software to communicate with each other. APIs ensure that when one software system makes a request, another system can understand the request and respond correctly. When discussing the relationship between two software systems, the application sending the request for action is called the client, and the application sending the response is called the server

For example, your bank’s software system houses all of your banking data–that software system is the server. The banking app on your phone is the client. When you initiate actions in your banking app, like making transactions, checking your account balance, or even chatting with a representative, the app communicates with the bank’s software via its API and tells it which action to perform. The server provides an API for the client to use to perform actions.

How does an API work?

Let’s say that you want to make a transfer of funds from your checking account to your savings account. You open your banking app and navigate to the transfer tab where you are asked which account you are transferring from, which account you are transferring to, the amount you want to transfer, and any additional notes before you can submit the request. Within seconds of submitting your request, the number on your checking account decreases and the number on your savings account increases, and the physical amount of money you can withdraw from the bank for both accounts has changed. 

For this to happen and money to actually be moved, the app needs a way to tell the bank’s system what to do. That is where the API comes in. The APIs are the rules and protocols that are coded into both systems as a set of predetermined requests and responses. 

When you enter how much money you want to move and where you want to move it to, the client communicates with the API on the server. When the server receives that request, it reads the information and executes a predetermined set of actions to move exactly the amount of money that you requested into the correct account.  

From a technical standpoint, APIs consist of two main components: an address and a body. The address, also known as an endpoint, tells the data where it's supposed to go (in our example, the bank’s system). The body is the data that will be delivered to that address. 

Why are APIs important?

APIs allow developers to automate functions and create a very clear, easy-to-understand relationship between what the user needs to do and what the computer systems will do in response to their requests. 

Without APIs, the modern conveniences of apps, digital transactions, and the like couldn't exist. Everything would require human, manual interference. Instead of quickly logging into an app on your phone to make a transfer of funds, you would have to physically go into your bank or talk to a teller over the phone, and your request would take much longer to process. 

But because of the code and predetermined actions built into digital systems through APIs, users can interact with services much faster. You can transfer your money in seconds, and the bank can gather your information, automate manual processes, and make their work more efficient.

What Makes a Good API?

Now that we’ve established what an API is and why they are important, let’s talk about what makes a good API. While all APIs follow the same principle of allowing systems to communicate, not all APIs function equally well. The quality at which an API is developed impacts how effective any system will be at actually doing what the user is asking for.  

So what makes a good, well-constructed API? Here are 5 aspects of a good API.

1. Simplicity

First and foremost, APIs should be simple. This means having clear addresses, endpoints, and easy-to-understand request body structures. In our banking example, the bank’s software and the app’s software are presumably owned and operated by the same company–the bank. Oftentimes, however, the client and the server belong to different companies. Developers at both companies will need to build their systems to be able to understand the API and react accordingly. A simple, straightforward API structure makes it easier to correctly implement.  

Let's take a look at an insurance API example. Say that you own a pet store and you have partnered with an insurance carrier to offer embedded pet insurance to your customers. In order for your customers to purchase insurance from you, they have to enter their information in a form on your website. Then the insurance company receives that information, makes an underwriting decision, and issues the policy. 

In order for the insurance company to receive your customers’ information and take action on it, your front-end systems need to communicate with your insurance partner’s system. The set of requests and responses between these separate systems should be simple and clear. The simpler the API, the faster and more seamless the integration between these two systems will be, and the fewer opportunities for mistakes. 

2. Complete, inclusive functionality

A good API should be able to execute all (or at least most) of the functions a user would need. Going back to our bank example, an app that allowed the user to check their balance but not to transfer funds wouldn’t be very useful to the customer. To be effective, the bank’s API needs to be able to handle most of the things a customer might want to use their bank app for. 

For more complex functions, it’s important that an API be able to collect and process all of the information needed to return a response. For our pet insurance example, let’s say that in order to decide to issue a policy, the insurance company needs ten pieces of information from the customer. 

If the API could only handle five of those pieces of information, the rest would need to be submitted separately (likely over email or a phone call with an insurance agent). It would be an inconvenient experience for both the customer and the insurance company, and increase the likelihood of manual errors. A good insurance API would be able to collect and process all information needed to issue a policy, right from the app or website.

3. Useful error handling

Errors are inevitable with any piece of software. What sets a good API apart from a bad one is how it handles errors when they arise. Good error handling can make the difference between getting back on track quickly, or getting bogged down in bug reports.

Broadly speaking, there are two kinds of software errors: 400 errors and 500 errors. The difference between the two is how much information they can give about what’s gone wrong.

400-type errors are specific errors with an identified problem. One of the most familiar is a “404 not found” error, which occurs on the web when a user tries to navigate to a web page that doesn’t exist. If you’ve ever mistyped a URL or clicked on an old link to an inactive page, you’ve seen a 404 error. Because 400-type errors give a specific reason for why the request failed, they also give direction on how to go about fixing the problem.

500-type errors, on the other hand, are much less clear. 500 errors indicate general server failures, crashes, or bugs. These tend to be more frustrating for users and developers alike, since they don’t contain much to go on for how to fix it.

A good API should be able to produce mostly 400-type errors that identify the problem so that it can be easily tracked and fixed. When an API produces a lot of unidentifiable 500 errors, it indicates a poor-quality API.

4. Thorough documentation

While not technically part of the API itself, good documentation is essential to a successful API. As developers integrate systems or build the API rules into an app, documentation has a direct impact on how quickly they can work, and how well they can avoid errors.  Good documentation should specifically describe each of the endpoints, what the requests should contain, and what the responses will contain.

In many applications, an API will touch various parts of an overall system. This is especially true for more complex operations like our pet insurance example. On the user’s side, applying for insurance might seem like a straightforward software operation - they fill out the form, and the software sends it. On the insurance company’s side, however, it’s much more complex. 

When the user submits their application, numerous parts of the insurance company’s system will be involved with the process. One part of the system will document the personal information they provided in the application. Another part will use that information to make calculations around premium costs, and still another part will generate the policy itself. In order to make sure this all happens seamlessly, developers need access to comprehensive, up-to-date documentation for how all these components interact and are executed via the API. 

5. Fast performance

Finally, a key benefit of APIs in general is speed. Rather than trudging through manual processes, APIs are meant to automate functions that would take much longer if human interactions were required. A good API should allow information to be passed between servers quickly and efficiently.

Going back to our earlier examples, no one wants to sit and wait to see if their bank transfer request or their insurance application was successfully received. For the best user experience, APIs should process requests in less than a second. If an API is slow to respond, it may indicate inefficient architecture, or that the servers are housed on insufficiently powerful hardware.

Get to know the Boost API for insurance

APIs allow businesses to function in a modern, technologically savvy way. By continuously improving the communication between client and server systems, consumers have access to a wider variety of digital transactions and services than ever before.

If you want to learn more about Boost’s API and how we can help your business stand out through insurance-as-a-service, contact us, or dive into building your insurance program with Boost Launchpad.

Previous articles
preview image
Selling Non-Admitted Insurance Products vs Admitted: What's the Difference?
May 12, 2023
When it comes to insurance, there are two major regulatory types: admitted and non-admitted Admitted insurance refers to insurance products that have been licensed by the Division of Insurance (DOI) in the state where they are being sold and are subject to state regulations. In addition to meeting state standards on things like price, coverage, and packaging, admitted insurance products offer additional protection to their end buyers - if the carrier fails, the state will pay a certain amount of its outstanding claims. Non-admitted insurance, on the other hand, refers to products that are not licensed or approved by the state DOI, and do not have the same financial protections from the state. There can be many benefits to offering non-admitted insurance products, but because they aren’t regulated by the state, there are unique responsibilities that agents, brokers, and insurance have to keep in mind. In this blog, we will break down 3 important areas where non-admitted insurance products differ from admitted insurance products, and explain the implications for agents and brokers.  By nature, non-admitted insurance products exist to cover hard-to-place risks that most admitted products won’t cover — whether that be insuring a barrier island home that is frequently at risk of flooding or covering Beyoncé’s voice in the event of injury.  To sell non-admitted policies that cover these unpredictable, difficult-to-price, high-risk situations, regulations require an agent or broker to first get several declinations from separate admitted insurance carriers. The exact number can vary by state, but the standard is typically three declinations.   A declination is a written refusal of an admitted insurance carrier to issue an insurance policy. To get one, the agent or broker will have to fill out an application or written request for coverage to each insurer, and then wait for the insurers to return documents that decline each request. This process ensures that the agent or broker has done their due diligence in attempting to place the risk in the admitted market, and that they understand and accept responsibility for offering a non-admitted policy. This process of getting three declinations often has to be done for every policy sold. Going back to our examples: say an agent goes through the usual process to find an insurance policy for their client’s island home: they make inquiries to three carriers for admitted products, are declined three times, and eventually place the risk with a non-admitted product. If their client’s next-door neighbor then calls and asks the agent to find them a policy as well, the agent would generally have to once again try for three different admitted products before moving on to the non-admitted market.  There can be state-specific nuances to the compliance requirements regarding declinations. In some states, there may be exceptions to the declination rule if no equivalent product exists in the admitted market. For example, crypto wallet insurance is a first-of-its-kind insurance offering, and only currently exists as a non-admitted product. In some states, this means the agent or broker selling it can be absolved of having to do the due diligence of getting three declinations from admitted carriers.  Some states also allow for getting the declinations once, and then using it for all similar risks going forward. In that case, the agent in our above example wouldn’t need to get three new declinations for the neighbor’s house - the risk would be similar enough that they could use the declinations they had already received as justification for placing their client with a non-admitted product. Every agent and broker needs an insurance license to sell insurance products, and most will need more than one. Insurance is licensed at the state level, so a license is required for each state you intend to sell in. There are also different types of licenses required for selling admitted and non-admitted products.  Here are the four types of licenses an agency will need to sell non-admitted insurance products. Current agents and brokers will already have the first two license types but may need two additional license types to start selling non-admitted products. The basic license required for selling insurance is known as a “producer” or “agent” license. This is obtained by completing a pre-licensing course and passing the required tests in a particular state which allows an individual to sell insurance in that state.  An agency or brokerage will also have to attain an “entity” or “agency” license. This license allows a company (rather than an individual) to sell insurance within the resident state.  Selling non-admitted insurance products requires an additional non-admitted license. In most states, the non-admitted license will have an entirely separate license number from the individual license.  Finally, selling non-admitted insurance products requires a surplus lines license. While non-admitted products don’t have to go through the intense approval processes with the DOI, the companies that create these products do need to submit articles of incorporation, a list of officers, and various financial and company information to the surplus lines office, which is run and regulated by the state. Any agents or brokers who wish to sell non-admitted insurance policies also need to be licensed by this office.   Both admitted and non-admitted insurance products are subject to taxes in the states where they are being sold. While every state has its own taxes and fees, there are some standard differences between how admitted and non-admitted insurance products are handled across the board. The major differences boil down to how and by whom taxes and premiums are calculated and collected.  For admitted insurance products, taxes and fees are generally included in the premium, and are calculated and remitted by the insurance carrier. The broker or agent selling the product doesn’t usually need to concern themselves with taxes for these products, since those are the carrier’s responsibility.  Non-admitted insurance, on the other hand, is not so simple. For these types of insurance products, the premium calculations are handled by the insurance carrier, and the taxes and fees are calculated separately by the broker or agent. The broker or agent is then responsible for collecting those taxes and passing the money on to the appropriate state government(s). The process goes something like this: The insurance carrier determines the premium amount and sends that information to the agency or brokerage, along with the policy documentation and a state disclosure form declaring that the non-admitted product complies with state regulations. From there, a broker or agent has to calculate Excess and Surplus lines (E&S) tax on top of the premium and any surplus lines fees. Many agents and brokers also add an administrative fee for non-admitted products to help offset the greater administration costs. Once the total amount is calculated, it can be shared with the policyholder.  Once a policyholder makes their payment, the broker or agent will have to send the premium payment to the carrier, remit the taxes to the state, send fees to the surplus lines office, and take the administrative fees for themselves. For this process, agents and brokers typically use a state-specific surplus lines agent management system (AMS) to file the product, policy, policy number, effective date, expiration date, line of business, E&S carrier, and the premium amount. The AMS will also calculate and reconcile the taxes, and then that state will send them a bill at the end of the month, quarter, or year (depending on which state they are selling in) to settle the remaining taxes. In short, non-admitted billing is much more operationally burdensome for brokers and agents to support versus admitted, which is why adding on an additional administrative fee is very common.  Non-admitted insurance products are an important part of the insurance market and can help provide vital protection for hard-to-place risks. Being equipped, informed, and licensed to sell these products can open up lucrative new lines of business for agents, brokers, and insurtechs. If you want to learn more about selling non-admitted insurance or getting your insurance licenses through Boost’s licensing-as-a-service, contact us.
Continue Reading
Offering insurance: build, partner, or white-label?
Offering Insurance: Build, Partner, or White-Label?
Nov 1, 2021
So you’ve heard that the insurance market is set to pass $700B gross written premiums this year and that changing consumer expectations are creating big opportunities for companies that haven’t traditionally offered insurance. Now what? If you’re ready to get started with offering insurance, your options fall into three general buckets: build and sell the insurance product yourself from scratch, partner with an insurance company to offer their product, or work with an insurance-as-a-service provider to offer white-label insurance products. So, which is right for your business? We’ll go through what’s involved with the top 3 options, as well as some pros and cons to be aware of. Your first option for offering insurance to your customers is also the most intensive: you can create the insurance products you want to offer, in-house. With this option, you would essentially create a business within a business: an insurance agency that operates as part of your company. As with most business-DIY options, the big advantage of building your own is that you can create exactly what you want. You’ll be responsible for the concept, design, operations, compliance, and tech, so you can approach each area in a way that centers your business needs. Building a new business from scratch is never easy, but insurance is a particularly difficult vertical to get into. It’s complex and heavily regulated, and getting started requires a significant investment of time and money. How significant? Here’s a quick overview of the steps you’d need to follow to create your own insurance products and offer them on your website. All in all, you’re looking at a multi-year timeline to build your insurance products in-house from scratch, with a considerable financial investment as well. And that’s not even considering the ongoing financial investment to maintain them - long-term program management requires significant resources. Besides just the effort involved, the long lead time for getting an insurance product to market means that by the time you get there, the market may well have changed. On top of time concerns, there’s another disadvantage you should weigh before going the build route. Everything we just covered about starting your own insurance program probably falls outside your company’s core business and specialization. What’s more, recruiting and hiring the right people to manage it may be significantly more challenging than hiring the right people for your core business. It’s often difficult to know what to look for when hiring for a completely different skill set, outside your core industry. Once you’ve brought all these new people on board, you’ll also have to manage them in an area where your core leadership has little experience. Consider whether the benefits of building it yourself outweigh the inevitable distraction of running an entirely separate secondary business within your company. Instead of creating an insurance product yourself, you might choose to partner with an established insurance company to offer your customers their product. In this scenario, you would have a link on your site for the customer to buy insurance. When the customer clicks it, they would be taken to the insurance partner’s website to buy the product from them. This is sometimes called affinity marketing, or click-through affinity. In this situation, you would be essentially acting as lead gen for your insurance partner. Your partner may pay you a certain amount per click, but after that you would not participate in the transaction. Your insurance partner would complete the transaction, collect the premiums, and own the insurance relationship with the customer. A click-through insurance partnership like this is both fast and simple to set up. After you’ve worked out the details of the partnership agreement, all you’ll need to do is add the link on your website to direct customers to the insurer. A partnership like this is also relatively low-commitment. Because you’re simply passing web traffic on to the insurer, you can later switch insurance partners or even remove the insurance option from your site altogether with a minimum of disruption to your business. The easy setup of a click-through affinity partnership also comes with considerable drawbacks. Because you’re just providing a link to your partner’s signup form, you lose control of the customer immediately after they click the link. Whatever comes after that is up to your insurance partner. If the customer has a negative experience during the process, it might reflect badly on your brand for offering the referral. Even if the experience is a good one, losing control of the customer comes with another big downside: you also lose control of the revenue. The insurance customer relationship will be with your partner, and they’ll collect the premiums. While a click-through partnership is a fast and straightforward way to connect your customers with insurance, it also removes one of the major benefits of offering insurance on your site in the first place. With this option, you won’t see the kind of regular recurring revenue that you would if your company were able to collect the premiums. Further underlining that it’s not your product (or your customer), with this kind of partnership you’ll have little to no input into the insurance product you’re offering. Your insurance partner will build, develop, and sell the products that best fit their business interests, which may or may not be a good fit for your particular customers. As just another marketing partner, you won’t have much influence to try and get a product created that closely matches what your customers need from insurance.  A relatively new third option is to work with a company that offers insurance-as-a-service, and white-label the insurance product they provide you with. If you aren’t familiar with insurance-as-a-service, it generally works like this: insurance-as-a-service providers are companies who have already done the work we outlined in Option 1 (Boost is one example). They’ll have all the necessary state licenses to create their own insurance products, and they will have already negotiated with licensed carriers to back those products. A good insurance-as-a-service provider will also already have built the necessary technology to offer an embedded insurance product experience. Your company can then sign on with the provider to offer one or more of the insurance products they’ve created, under your own brand name, on your company’s website or app. Unlike affinity partnerships, partnering with a white-label insurance-as-a-service provider doesn’t simply generate customers for someone else. Your company will be the one selling the insurance product, on your own website. The customer will buy the policy from you, and you’ll be the one to collect the premiums and own the ongoing customer relationship. White-labeling an insurance-as-a-service product offers many of the advantages of building it yourself, but at a fraction of the time and cost. Because your partner will have already done the heavy lifting on things like operations, technology, compliance, and capital, you can easily offer the right insurance products for your customers - and get to market in a dramatically shorter timeline versus trying to create an insurance company from scratch. A white-label insurance product also allows you to reap the full business benefits of offering your customers insurance: While white-labeling an insurance-as-a-service product is much faster and easier than building one yourself, it’s still more involved than simply adding a link to your website. Working with an insurance-as-a-service provider may take longer to implement than partnering with an insurer for click-through affinity since you will be building the full experience into your website rather than just linking out to an insurance partner's website. Selling white-label insurance policies also requires an important additional step: someone at your company will need to be licensed as an individual broker, and then sponsor a license for your company. You may recall this as Step 1 in the build process - the broker license is required to legally sell insurance, which your company will do with its insurance-as-a-service products. This sounds much more intimidating than it actually is. The insurance licensing process itself is relatively simple and straightforward. However, it does require additional effort from one of your employees (usually a senior executive who is unlikely to leave the company). The other good news is that not only is the licensing process easier than it sounds, but once it’s done, it’s done. You’ll need to maintain it with fees, renewals, etc, but you won’t need to go through the process again as long as that employee is still at the company. A good insurance-as-a-service partner will also help you with this step, so you can check the box and start offering insurance to your customers as soon as possible.  The insurance market is changing quickly, and there’s never been a better time for new entrants to take advantage of the embedded insurance opportunity. Depending on the route you take to get there, however, the cost, time to market, and experience for your customers can vary a great deal. When starting on the road to offering insurance, it pays to carefully consider your budget, your timeframe, and your business goals, so that you can choose the option that’s right for your company. Is insurance-as-a-service the right option for you? Boost can help get you started. Contact us today to learn more about your options for offering the different ways to offer insurance with one of our Boost product experts.
Continue Reading
The top 3 takeaways from our embedded insurance consumer survey
Embedded Insurance Survey Results: What We Learned From Consumers
Feb 3, 2023
You may have heard that embedded insurance is a big opportunity to grow your business, but are your customers actually interested?  We wanted to get the story straight from the source, and so in Q4 2022 Boost surveyed 650+ US consumers. We asked about their experiences with insurance, how they felt about their current insurance options, and what mattered most in their insurance purchases.  Here are the top 3 things that we learned from our consumer insurance survey results. [See Full Size] In our insurance survey, a whopping 73% of consumers had either already bought insurance from a non-insurance brand, or would be interested in doing so. While price was mentioned most often, other reasons included brand loyalty and convenience. Trust was another important factor. 62% of respondents were interested in buying financial products from a trusted brand, rather than a bank. For millennials, the number went up to 95%. First movers might have an advantage here as well. 20% of our respondents had never been offered financial products from a retail brand - but they liked the idea. All this is promising news for companies outside the traditional insurance sphere who are looking to build revenue and customer loyalty with embedded insurance. If you can deliver the product and experience consumers are looking for, the appetite is there. It’s hardly a secret that convenience is crucial to customer experience in the digital age, so it comes as no surprise that it was important to our respondents. 59% told us that they’d be more likely to buy insurance if it were offered digitally, as part of a related transaction. Younger consumers were more likely to be enthusiastic about digital insurance: nearly 70% of respondents aged 18-29 were interested in buying insurance directly through a transaction on a retail website. For half of our respondents, embedded insurance wasn’t a novel idea. 50% had already bought embedded insurance at least once, at the point of sale in a related transaction. For many consumers, insurance is a long-term purchase. 68% of our survey respondents told us they’d had the same insurance provider for at least two years, and 10% had had the same provider for more than five years. For retailers, insurance could also be an overall boost to retention. 62% of respondents said that when a retailer offered protect-your-purchase options, they were more likely to be repeat customers. Learn more about offering embedded insurance in our free guide, or contact us to get started.
Continue Reading