What is an API in Insurance?

An API (application programming interface) is a defined way for one software system to ask another for data or to perform an action, such as returning a premium or issuing a policy. In insurance, APIs connect policy, claims, pricing and distribution systems without rekeying.

This guide is for insurance operations, IT and product teams. It explains what an API does in insurance terms, where insurers, MGAs and brokers use them, what documentation and security to expect and what to ask a vendor. Connecting specific systems is covered in our page on insurance API integration.

What an API is, explained without jargon

An API is a contract between two systems. One system, the client, sends a request in an agreed format. The other, the server, carries out the request and sends back a response, also in an agreed format. Neither needs to know how the other works inside. They only need to agree on the request and the response.

A broker's quoting portal is a good example. When a broker enters a commercial property risk, the portal sends a request to the insurer's rating API containing the address, trade, sums insured and claims history. The insurer's system applies its rating rules and returns a premium, excess and any referral reasons. The broker sees a quote in seconds, and nobody at the insurer has touched it.

Requests come in two broad kinds. Some ask for data: "what is the status of claim 12345?" or "which policies renew next month?" Others ask the receiving system to do something: "bind this quote", "add this vehicle to the fleet" or "register this claim". In both cases the API defines exactly which fields must be sent, which are optional and what comes back, including the error returned when something is wrong.

Common insurance uses

Rating and pricing calls are the most common. A policy administration system may call an external rating engine, or expose its own rating to partners, so that a quote can be produced wherever the customer is.

Quote and bind from broker portals and price comparison sites works the same way. The aggregator collects the customer's answers, sends them to each insurer's API and displays the prices returned. When the customer chooses, a second call binds the cover and a third may return the policy documents.

Embedded insurance puts cover inside another company's buying journey, such as gadget cover at an electronics retailer's checkout or travel cover on an airline booking. The retailer's system calls the insurer's or MGA's API to price and issue the policy without the customer leaving the retailer's site.

First notification of loss can be submitted by API from a broker system, a partner app or a telematics provider, so that a claim is created with structured data from the outset. Payments use APIs to take card payments, set up direct debits and pay claims. Document generation APIs produce schedules, certificates and endorsements from policy data.

Data enrichment and fraud checks are a growing use. At the point of quote, the insurer's system can call third-party services to verify an address, retrieve property attributes, check a vehicle's history, confirm a company's details or screen the customer against sanctions lists. Each is a separate API call that returns data the underwriting rules then use.

REST APIs and what "documented" means: OpenAPI specifications and sandboxes

Most modern insurance APIs are REST APIs. REST is a style of API that runs over the same web protocol as a browser, organises data into resources such as a policy, a quote or a claim, and uses standard actions to read, create, update or delete them. Requests and responses are usually in JSON, a text format both people and systems can read.

An API is only as useful as its documentation, because the team connecting to it needs to know every field, rule and error message. The common standard for describing REST APIs is the OpenAPI Specification, an open standard run under the Linux Foundation. According to Swagger's documentation, it was formerly called the Swagger Specification, and the open-source Swagger UI tool turns an OpenAPI definition into interactive documentation where developers can try requests.

A sandbox, or test environment, is the other half of good documentation. A partner building a broker integration needs somewhere to send test quotes and binds without creating real policies. A vendor that provides separate development and test environments lets partners build and test integrations before anything reaches production.

API security: authentication, OAuth 2.0 and access control

An insurance API exposes personal data, premium and the power to put cover in force, so security is part of the design from the start. Three controls matter most.

Authentication proves who is calling. Most modern APIs use the OAuth 2.0 authorization framework, published by the Internet Engineering Task Force as RFC 6749 in October 2012. Under OAuth 2.0 the calling system obtains a time-limited access token from an authorisation server and presents it with each request, so passwords are never sent with every call and access can be withdrawn centrally.

Authorisation, or access control, decides what an authenticated caller may do. A broker partner might be allowed to quote and bind on certain products but not to cancel policies or see claims. An MGA's TPA might read policy data and write claims data but not change premium. Role-based access control applies these permissions consistently.

Encryption protects data in transit between systems and at rest in the database. Logging records every call, so that the insurer can show who accessed or changed a record and when, which supports both security monitoring and audit.

API-first versus APIs added later: why it matters for a policy administration system

An API-first system is designed so that every function is available through its APIs, and the vendor's own screens use the same APIs a partner would. Anything a user can do on screen, an external system can do by API.

In many older policy administration systems, APIs were added later on top of a system designed for screen-based use. Those APIs often cover only part of the system, such as quoting, while binding, mid-term adjustments or claims still need a user at a screen or a batch file overnight. Each gap becomes a manual step or a custom integration, and custom integrations add cost every time either side changes. Our article on the hidden cost of insurance system integration covers this in more detail.

The difference shows when an insurer launches a new distribution channel. With an API-first system, the partner connects to APIs that already exist. With APIs added later, the project often starts by building the API the partner needs.

APIs and ACORD data standards

An API defines how two systems talk. A data standard defines what the words mean. ACORD publishes data standards for the insurance industry, including XML standards for property and casualty and, for reinsurance and large commercial business, XML and JSON standards covering placing, claims and accounting and settlement. ACORD describes its Next-Generation Digital Standards as transaction-centric standards for APIs, microservices and other newer architectures.

Using a common standard reduces mapping work. If a broker system and an insurer system both describe a property risk using ACORD definitions, the integration needs less translation between them. In practice, many insurance APIs use their own data models, and integration projects include a mapping step between the two.

How this applies to policy administration

A policy administration system sits at the centre of an insurer's or MGA's systems, so the coverage and quality of its APIs decide how easily everything else connects to it: broker portals, rating engines, CRM, finance, data enrichment services, claims and reporting. As software as a service (SaaS) platforms replace on-premise systems, the API is also how the customer's own systems reach the platform.

Genasys publishes 450+ documented REST API endpoints, authenticated with OAuth 2.0, with OpenAPI documentation in an interactive Swagger UI, as described on its product page. For how microservices relate to APIs inside a platform, see our glossary entry on microservices in insurance.

Questions to ask a vendor about its API

Coverage comes first. Ask which functions are available by API and which are screen-only, with specific transactions in mind: quote, bind, mid-term adjustment, cancellation, renewal, claim registration, payment and document retrieval.

Ask how many endpoints are documented and whether the documentation is published in OpenAPI format, whether there is a test environment for partners and how long a typical partner integration has taken for an existing customer.

Ask how the API is secured, including the authentication method, how permissions are set for each partner, how data is encrypted and what is logged. Ask how changes are handled: how the vendor versions its API, how much notice it gives before changing or retiring an endpoint and whether old versions keep working during the transition.

Ask whether the system can notify other systems when something happens, such as a policy being bound or a claim being paid, so that partners do not have to keep asking. Ask about limits on the number of calls and the response times the vendor commits to. Finally, ask which integrations are already live with other customers, because an existing connection to your CRM, finance system or payment provider is quicker to switch on than a new one.