Retrieval · comparison

How to read benefit enrollments from an HRIS: the four unified benefits models

Reading enrollments through a unified API means reading up to four things — the plan catalog, each employee's enrollment, dependent coverage and coverage amounts — and the seven vendors compared here model these very differently, with availability varying by connector on every vendor that models them at all.

By Eli Wilson · Published 2026-10-01

Reading enrollments through a unified API means reading up to four things: the plan catalog, each employee’s enrollment, dependent coverage, and coverage amounts. The seven vendors compared here model these very differently, and on every vendor that models them at all, availability varies by connector. As of 1 Oct 2026: Bindbee has four read-only benefits models plus a Dependent model. Merge has a plan object (EmployerBenefit) and an enrollment object (Benefit). Finch’s Benefits API (plans, enrollments, dependents) is in Early Access on ADP Workforce Now and Workday. Unified.to has a plan-level Benefit object and an employee-level Deduction object. Knit has no plan or enrollment model, but exposes benefits through an employee deduction model and has a dependents model. Apideck and Kombo document no benefits model.

The per-connector detail below uses Bindbee’s docs, because its four models map one-to-one onto the four things above and its availability matrix is public. The same questions apply to every vendor: which object holds the enrollment, and on which of your customers’ systems is it actually populated?

How the unified APIs model benefits (as of 1 Oct 2026)

Sources for every cell are at the end. “Not verified” means it was not researched for this piece; “not documented” means the vendor’s docs were searched and it was not found.

What each model holds, using Bindbee’s four as the example

Full field reference: benefits data models.

Employer Benefit: the plan catalog. One row per plan the employer offers, whether or not anyone enrolls. Key fields are plan_name, provider_name, benefit_plan_category, payroll_codes and deduction_code. These are how a deduction line on a payroll run matches back to the plan. Unified.to’s Benefit object plays the same role.

Benefit: one employee’s enrollment in one plan. Fields include coverage_tier, employee_contribution, company_contribution and effective_date. This is the record you reconcile against your own enrollment data. Merge’s Benefit and Finch’s enrollments are the closest equivalents; Unified.to’s Deduction and Knit’s employee_deduction carry similar contribution and date fields but are framed as deductions, not enrollments.

Dependent Benefit: a dependent’s coverage under a plan. It points to the dependent and to the employer_benefit (the plan), not to the employee’s enrollment. To find which dependents ride on an employee’s medical enrollment, join both records on employer_benefit. Dependent Benefit carries no money; contributions sit on the employee’s Benefit.

Benefit Coverage: what is covered. Fields include amount, currency, is_employee_covered and covered_dependents. It attaches to the enrollment, with one record per covered person.

Dependent: the person. Fields include relationship, date of birth and is_student, among others. Dependent DOB is often permission-gated in the source system, so expect gaps until the customer grants access.

The enums are normalized: 11 plan categories, 11 coverage tiers and a plan frequency with 11 values. That lets you map “EE+Spouse” from one system and its equivalent from another to the same value.

Connector availability

Benefits read depends on the connector, on every vendor that models it. Bindbee states 102+ HRIS integrations; its public integrations page at docs.bindbee.dev lists 90 HRIS/payroll connector entries today. Only some of those connectors expose benefits models. From the docs (model availability, 1 Oct 2026):

When a system’s API connector doesn’t expose benefits, check whether the customer can send an SFTP export instead. Rippling is the clearest case: the Rippling API connector has no benefits read, and the Rippling SFTP connector supports all four models. Reading from ben-admin systems as sources is covered in reading data from bswift, Ease, Employee Navigator and PlanSource.

The same unevenness shows up elsewhere. Unified.to’s per-integration pages list no Benefit or Deduction object for Workday, and no Deduction object for Rippling, BambooHR, Dayforce or Paycom; ADP Workforce Now, Paycor and UKG Ready list Deduction read (list/get). Finch’s Benefits API covers ADP Workforce Now and Workday during Early Access. Merge’s and Knit’s per-integration coverage of their benefits objects was not verified for this piece; check their integration lists by name.

Census is a separate question. In Bindbee, Dependent read is not supported on the Paycor, Paylocity, Paycom, Rippling and SAP SuccessFactors API connectors, and is Beta on Paychex (API). See building a quote-ready census from HRIS data.

Reading enrollments correctly

These notes come from Bindbee’s docs, but most apply to any vendor that models enrollments.

Enrollments accumulate. Bindbee keeps one enrollment per plan year, so an unfiltered read of Benefit returns history. Filter with effective_date_from / effective_date_to for the plan year you care about, or you’ll count last year’s medical election as a second active plan.

curl --request GET \
  --url 'https://api.bindbee.dev/api/hris/v1/benefits?employee_id=<EMPLOYEE_ID>&effective_date_from=2026-01-01&expand=employer_benefit' \
  --header 'Authorization: Bearer <BINDBEE_API_KEY>' \
  --header 'X-Connector-Token: <CONNECTOR_TOKEN>'

Two dates on one enrollment are not the same day. A plan elected during open enrollment carries a start_date at election and an effective_date at the plan-year boundary.

Renewal creates new plan records. An Employer Benefit ID you stored last year won’t resolve this year, so re-read the catalog each plan year.

Amounts are not on the enrollment. If you read only Benefit, you get the contribution and the tier but no insured sums, and nothing tells you they are missing. Read Benefit Coverage for amounts.

Enums are open. An unmapped coverage_tier comes back as the source’s raw string, so handle values outside the 11.

Join through the catalog. Resolve each Benefit to its Employer Benefit to get the plan name, carrier (provider_name) and category. To match payroll, use the catalog’s deduction_code / payroll_codes by ID, not by comparing code strings, and check first, because both fields can be empty.

Check against payroll. Enrollment records say what the employee elected. Payroll deduction lines say what payroll actually took. If you read both, you can catch a missing or wrong deduction before the employee does. On Apideck, payroll read is the only benefits signal, so you see the second half of this check but not the first.

Use raw data for the long tail. In Bindbee, pass include_raw_data to get the source payload next to the normalized record; custom fields can be mapped with JMESPath, and anything outside the unified model is reachable through passthrough. Merge (Professional and Enterprise), Apideck, Knit and Unified.to also list passthrough.

Freshness. Bindbee production connectors sync every 24 hours by default (sync frequency), and webhooks fire after a sync, with a modified_after reconciliation needed because exhausted deliveries are not redelivered. Apideck and Unified.to describe their reads as pass-through to the source at request time (their claim); Knit pushes polled syncs to your webhook, every 24 hours on its Start Up plan. Coverage end dates after a termination are covered in detecting terminations and coverage end dates.

Limits by vendor

• Bindbee: the benefits models are read-only, so you can’t create or change an enrollment in the HRIS; you write the resulting deduction to payroll via POST /employee-payroll-runs on connectors that support it (see the deduction write matrix). Benefits read is missing on the ADP WFN, Paycor, Paychex and Rippling API connectors, and Paylocity API has only Benefit, in Beta. SFTP connectors return what the customer’s export template includes, and a missing file raises no error. Gusto is not listed. Benefits models need the Pro tier; Basic/Lite covers the Employee model only.
• Merge: an enrollment-level Benefit object exists, but which integrations populate it was not verified here. No write to benefits objects is documented. The Launch plan excludes passthrough, which is how you would reach fields outside the common model.
• Finch: the Benefits API is Early Access on two systems, with GA targeted for Summer 2027. Deduction write on Pro is marked “Employer Fee Required” on the pricing page.
• Kombo: no benefits, enrollment, dependents or deduction paths in its OpenAPI as of 1 Oct 2026. A “benefits on the Q4 2026 roadmap” statement appears only on Bindbee’s comparison page; nothing on kombo.dev or docs.kombo.dev confirms or dates it.
• Apideck: no benefits, enrollment or dependents model, and no deduction write. Benefit amounts are visible only after payroll has run.
• Knit: no plan or enrollment model, so there is no plan catalog to join to; plan name, carrier and coverage tier fields on employee_deduction were not verified for this piece. Deduction write is documented on a subset of payroll systems only.
• Unified.to: Benefit is a plan-level object (Unified’s model page), although Unified’s HRIS skill doc calls it an enrollment; read the field list before relying on it. Deduction coverage is narrow on large US systems. Dependents are flags on the employee’s relationships, not a separate model with its own coverage records.

Next step

List your customers’ HRIS and payroll systems and check each vendor’s published benefits coverage against that list, system by system. Bindbee publishes a model availability matrix; Unified.to publishes per-integration object lists; Knit publishes supported-app lists per endpoint; Finch lists the Benefits API’s supported systems. For Merge, check its per-integration coverage pages.

Frequently asked

Which unified APIs have an employee-level benefits record?

Bindbee (Benefit), Merge (Benefit) and Finch (Benefits API enrollments, Early Access). Unified.to (Deduction, linked to a plan) and Knit (`employee_deduction`) model it as a deduction rather than an enrollment. Apideck and Kombo have none, as of 1 Oct 2026.

Can a unified API read benefits from ADP Workforce Now?

Bindbee: through ADP's SFTP connector, yes, all four models; through the ADP WFN API connector, no. Finch: the Benefits API (Early Access) starts with ADP WFN. Unified.to: Deduction list/get on ADP WFN. Merge, Knit: not verified for this piece. Apideck: payroll read only, with benefit amounts. Kombo: no benefits model.

Source limits

Sources checked

Wrong or out of date? payrolldataspecs@gmail.com — corrections are free. How claims are scored: methodology.