The 2 Types of Benefits APIs: Employer Connections vs Carrier Connections

Benefits APIs are quickly transforming how data moves between employers’ Human Capital Management (HCM) systems and insurance carriers. For an industry that has spent most of the last 20 years exchanging data in batch files, this is a major technological shift — one that’s driving greater accuracy and efficiency for carriers, navigators, TPAs, leave platforms, and more.

There are two types of benefits APIs: one that operates on the employer side of the benefits ecosystem, and one that functions on the carrier side. Both exchange data with the benefits administration (ben admin) platform used by employers and employees to run benefits programs. 

As with most new technologies, there’s some lingering ambiguity about the players involved. In this post, we’ll break down the data challenges that led the industry here, the two distinct sides of the benefits ecosystem, and the two types of benefits APIs: employer connections and carrier connections.

What are the two types of benefits APIs?

There are two kinds of benefits APIs: those that handle employer connections and those that handle carrier connections. On the employer side, benefits APIs exchange employer data from the HCM system (or systems) to a ben admin platform. On the carrier side, benefits APIs move data between the insurance carriers’ internal systems and the ben admin platform. Sometimes these are referred to as ben admin APIs.

The two types are complementary, but don't converge. An employer-side integration can tell you what an employee is enrolled in today but can't move a new election into a carrier. A carrier-side integration can enroll an employee going forward but has no view into what's currently in place across an employer's book of business.

Both the employer connection and the carrier connection are necessary to facilitate the full benefits workflow, from plan design through open enrollment and claims processing. 

The benefits data problem

Before we jump into comparing employer-side and carrier-side benefits APIs, it’s worth understanding the data problem they solve. 

For the most part, the benefits ecosystem still relies on antiquated, manual data plumbing, and that comes at a cost: higher operations headcount, data errors, and slow client onboarding.

Almost every workflow in benefits depends on data from the employer, data from the insurance carrier, or both. But getting current, structured, employer-specific benefits data is a challenge when most of the industry runs on file-based data exchange. Overnight batch cadences, per-partner file specs, and integration projects that take weeks to stand up for each new employer and carrier are still the norm. Even where APIs exist, they’re often gated behind partnership programs that take months to secure and sometimes carry per-employer access fees. Smaller providers frequently offer nothing at all. 

The result is a benefits ecosystem where data is hard-earned, but outdated and inconsistent from one employer to the next. That manifests as a poor experience for the employers and employees. New plan-year elections don't show up in downstream systems until they reach the first paychecks of the new year, a lag of two or three months. Enrollment status at claim time is a phone call away. And every downstream product spends the first weeks of each employer relationship setting up a file feed before any real work can start.

The industry is converging on unified APIs as the fix on both sides of the data exchange. 

The two sides of the benefits data ecosystem

There are two sides to this data ecosystem: the employer side and the carrier side. Both are essential to administering a benefits program, and neither holds the full picture alone. The employer knows who works there, what they earn, and what they’ve elected. The carrier knows what coverage is actually in force, what’s been billed, and what’s been paid. The central source of truth for data on both sides of this exchange is the ben admin system.

What lives in a ben admin system

A benefits administration (ben admin) system is the software an employer uses to configure and administer its benefits program. HR teams use it to set up plan offerings each year, employees use it to make elections during open enrollment and after qualifying life events, and it’s the record of what the employer’s benefits program actually is. 

The ben admin system is the place where employer-side benefits data and carrier-side benefits data meet. On the employer side, it holds employee, earnings, and election data. On the carrier side, it holds confirmations, coverage status, and billing details. 

Ben admin systems come in a few shapes. Many large employers will select a single HCM system to bundle payroll, HRIS, ben admin, and other employee-centric workflows into an all-in-one solution. Other employers may cherry pick a dedicated ben admin platform that integrates with their other systems of record. 

Whichever shape the setup takes, keeping all the data in sync is crucial. Payroll calculations rely on up-to-date employee information, benefit payouts rely on how much an employee is paid and their eligibility window, and benefit funding often comes directly from payroll contributions. 

Who relies on benefits data

A long tail of software sits downstream of the ben admin system and depends on data from both the employer side and the carrier side. 

• HR analytics and reporting tools segment benefits utilization and cost by cohort, tenure, or geography.
• Employee-communications platforms run eligibility-based outreach during open enrollment or after qualifying life events.
• Benefits navigators use HR and plan data to help employees understand what benefits their company offers, which they are eligible for, and what they’re enrolled in.
• Leave & absence platforms confirm medical, STD, and LTD coverage before an employee goes on leave, and help arrange payouts.
• Financial wellness and decision support tools modeling total compensation and coverage costs against take-home pay.
• Insurance TPAs prepare ACA 1094-C / 1095-C filings, manage COBRA notices, and calculate claims run-out for FSAs.
• Insurance carriers verify coverage at claim time, calculate definition-of-earnings for life and disability payouts, and reconcile premium billing on self-billed groups.

These are just a few possible use cases for downstream services. Most software touching the employee-benefits relationship reads from this same well of data, and what they share is the difficulty of reaching it reliably.

Comparing employer connections and carrier connections

We’ve established what data lives in a ben admin system, which side of the ecosystem the data comes from, and the types of benefit workflows that depend on that data. Now we’ll compare how that data is accessed by the companies that need it, both with and without APIs.

The key differences lie in what data each side holds and how that data has traditionally been shared with downstream applications. Because each side of the exchange uses different data formats and file types, the benefits APIs that have emerged to facilitate programmatic data flow on each side are fundamentally different.

Employer connections: reading from the HCM and writing to payroll

On the employer side of the benefits data ecosystem, HR, payroll, and benefits data flows out of the employer's tech stack and reaches the software that reads it downstream. That includes who works at the employer, what they earn, what benefits they've elected, and who their dependents are. 

But the flow isn't purely one-way. For benefits funded by payroll deductions, deduction data has to be written back into the payroll system so paychecks come out right and stay accurate as enrollments change. This applies to medical premium contributions, 401(k) contributions, HSA and FSA elections, voluntary life and disability insurance, and so on.

Traditionally, getting this data out has meant custom file feeds, configured for every individual employer. The industry standard is SFTP transfer. Every new employer has to go through a weeks-long setup project that involves agreeing on the file spec, mapping individual data fields, and running tests before the transfer can go live. In lieu of SFTP, some benefits companies may ask employers to export and upload CSV reports from their HCM systems on a weekly, monthly, or quarterly basis. And that’s just to read the employer’s data — adjusting payroll contributions is even more manual because that data needs to be configured for individual employees and even individual pay periods.

Where APIs exist with the HCM providers, they typically require a formal partnership program — involving legal review, security audits, and in some cases revenue-share agreements — before a technical integration can begin. Each implementation then must be independently maintained.

Unified APIs are the alternative. Instead of setting up a file feed for every employer, the benefits company builds one integration. Then each employer authorizes their own data to flow through that integration, no matter which HR/payroll or ben admin system they use. Data comes back through a single standardized interface, and where the integration supports it, deductions are written back to payroll through the same connection.

‍

Carrier connections: reading from and writing to the carrier

On the carrier side, data is piped between the insurance carrier and the ben admin system. The data flows in both directions: carriers send information about plan designs and rates to the ben admin system, where employees can make elections during open enrollment or after a qualifying life event. Then, those elections have to reach the carrier's core system so coverage can activate, premiums can be billed, and claims can be paid.

The dominant format for moving this data is the EDI 834, the ANSI X12 standard for benefit enrollment and maintenance transactions, mandated by HIPAA for the electronic exchange of health plan enrollment data. According to Guardian's 2023 Quantum Leap report, roughly two-thirds of employers still transmit enrollment to carriers this way. The 834 is a distinctive shape of technology: fields are position-based, cadence is batch (usually nightly), and reconciliation happens through reverse-direction 834s the carrier sends back to confirm what was received. It works — the format has been in production for more than twenty years. But it's slow, opaque, and hard to diagnose when something breaks.

A newer generation of carrier-side APIs, led by companies like Ideon and Noyo, is replacing the 834's batch cadence with real-time transmission, continuous reconciliation, and better visibility for both sides of the write hand-off. This is a distinct build from the employer-side unified APIs’ work: it requires a different set of carrier partnerships and a different data model.

Benefits APIs: employer connections vs. carrier connections, side by side

Where Finch fits in

Finch is the benefits data connectivity leader on the employer side. We're laser-focused on the employment ecosystem (payroll, HR, and benefits), with more integrations than any other unified API in the space. We've built an opinionated data model informed by years of mapping the messy details, and are the only unified API that can both read benefits data and write deductions back to payroll, which matters for the payroll-funded portion of most benefits.

Our Benefits API is now available for ADP Workforce Now and Workday, with more integrations on the way. Talk to us about early access or read the developer docs to get started.

FAQ

Is Finch a competitor to Ideon or Noyo?

No. Finch builds employer connections; Ideon and Noyo build carrier connections. Finch reads benefits data out of an employer's HCM — the plan catalog, who's enrolled, covered dependents, coverage dates — and writes deductions back to payroll. Ideon and Noyo move elections in the other direction, from a ben admin platform into an insurance carrier's core systems, replacing the EDI 834. The two sit on opposite sides of the ben admin system and solve different problems. Companies that need both typically use one of each.

What's the difference between employer-side and carrier-side benefits APIs? 

Employer-side APIs read benefits enrollment data from an employer's HCM: the plan catalog, per-employee elections, dependents, and coverage windows. Carrier-side APIs write new enrollments into insurance carriers' core systems, replacing the traditional EDI 834 file feed. The two solve different problems on different sides of the employer-carrier boundary.

Can one benefits API handle both employer data and carrier data?

Generally no. The technical work of reading current enrollment out of an HCM is different from the work of writing new elections into a carrier: different partnerships, different data models, different reliability guarantees. Companies that need both typically pair an employer-side unified API like Finch with a carrier-side unified API. Ideon and Noyo are the two main players there.

How does benefits data get from an HCM to an insurance carrier?

It changes hands twice, and the ben admin system sits in the middle. On the employer side, HR, payroll, and benefits data flows out of the HCM — who works there, what they earn, what they've elected, and who their dependents are. On the carrier side, those elections have to move from the ben admin system to the carrier's core system so coverage can activate, premiums can be billed, and claims can be paid. That second hand-off still runs mostly on the EDI 834, a nightly batch file, for roughly two-thirds of employers. No single API spans both hand-offs today: reading current enrollment out of an HCM and writing new elections into a carrier require different partnerships, different data models, and different reliability guarantees.

What data does Finch return for benefits? 

Plans (catalog, carrier, coverage tiers, deduction codes), enrollments (per-employee elections, contributions, dependents), and dependents (demographic data). Coverage varies by provider; see the field support matrix for exact fields.

‍Do employer-side APIs deal with the EDI 834? 

No. The 834 is a carrier-side file format; it exists to move new enrollment elections from ben admin platforms into insurance carriers. Employer-side APIs read directly from the HCM and don't touch that hand-off.