Use cases · comparison
Which Unified HRIS API Generates EDI 834 Files? (None of Them, and What to Do Instead)
None of the seven unified HRIS/payroll APIs compared here (Bindbee, Merge, Finch, Kombo, Apideck, Knit and Unified.to) documents EDI 834 generation as a product as of 1 Oct 2026; they supply the inputs to an 834, such as census, dependents, enrollments and terminations, while carrier-specific files are built by your own EDI engine, a carrier-connectivity or EDI vendor, or a ben-admin system's feed marketplace.
By Eli Wilson · Published
Short answer: none of the seven unified HRIS/payroll APIs compared here (Bindbee, Merge, Finch, Kombo, Apideck, Knit and Unified.to) documents EDI 834 generation as a product, as of 1 Oct 2026. A unified API’s job is to supply the inputs to an 834: census, dependents, enrollments, terminations. Carrier-specific 834 files are built by your own EDI engine, a carrier-connectivity or EDI vendor, or the feed marketplace of a ben-admin system.
The vendors differ a lot in which of those inputs they can supply, especially dependents and enrollments, and that is the part worth comparing. One vendor also works with 834s in the other direction: Bindbee can ingest legacy EDI 834 files delivered over SFTP and serve them as normalized API data. That is read-side only; it does not produce files for carriers.
If a vendor tells you their unified API “does 834”, ask for the docs page. None was found for any of these seven.
Comparison: 834 generation and the inputs each vendor supplies
As of 1 Oct 2026, from public docs and pricing pages. “Not documented” means searched for and not found; “no evidence found” means the same for the vendors checked in an earlier pass.
| Vendor | Generates carrier-ready 834 files | Dependents | Enrollment / benefits read |
|---|---|---|---|
| Bindbee | No. Ingests legacy 834 files over SFTP and serves them as API data (read side only) | Dependent model (relationship, DOB, SSN, student status) on connectors that support it | 4 read-only models (Employer Benefit, Benefit, Dependent Benefit, Benefit Coverage), not on every connector |
| Merge | No evidence found in Merge’s docs | Not verified | EmployerBenefit and enrollment-level Benefit read objects |
| Finch | No evidence found in Finch’s docs | Part of the Benefits API (Early Access) | Benefits API (plans, enrollments, dependents) in Early Access since 14 Sep 2026 for ADP Workforce Now and Workday; GA targeted Summer 2027 |
| Kombo | No evidence found in Kombo’s docs | Not documented (no dependents path in Kombo’s OpenAPI) | Not documented (no benefits or enrollment path in Kombo’s OpenAPI) |
| Apideck | Not documented | No dependents model (Employee has a partner field) | No benefits or enrollment model; benefit amounts appear in payroll read (benefits[] with employee deduction and employer contribution) |
| Knit | Not documented | employee_dependent model | No plan or enrollment model; employee_deduction carries benefit type, contributions, frequency and start/end dates |
| Unified.to | Not documented | No separate model; Employee relationships[] with is_dependent flag | Benefit object is plan-level; employee-level Deduction object with benefit_id, coverage_level, start/end. Support varies by connector |
All seven document employee data read (identity, status, employment dates), with per-connector field coverage to check. Bindbee’s termination statuses and Apideck’s EmployeeTerminated webhook event are examples of how termination reaches you.
Finch’s Benefits launch (Early Access, 14 Sep 2026) positions its API as a replacement for “CSV uploads, EDI feeds, and SFTP drops” between employers and carriers. That is a pitch to send enrollment data by API rather than by file. It is not 834 generation. Carriers that only accept 834s still need a file built to their companion guide.
Why unified APIs stop short of 834
An 834 is a carrier-facing file. Every carrier publishes a companion guide that narrows the standard: which segments they require, how they want coverage levels coded, how they treat terminations and changes, file cadence, and testing steps before go-live. The work is per carrier, per employer group, and ongoing.
A unified HRIS API works on the other side of your platform. It normalizes what the employer’s systems hold. That’s a different integration surface with different counterparties. You can see the split in what these vendors ship: employee, payroll and (sometimes) benefits read; some write back into payroll; nothing addressed to carriers.
The architecture that works
Employer HRIS / payroll
│ (unified API: census, dependents, enrollments, terminations)
▼
Your benefits platform ──► eligibility + enrollment state (your source of truth)
│
▼
834 build layer (your EDI engine, or an EDI / carrier-connectivity vendor)
│ per-carrier companion-guide rules
▼
Carriers1. Inputs from the unified API
The fields an 834 build typically needs, and where they come from:
- Employee and employment: identity, hire date, status, termination date. Know which statuses your vendor treats as terminal. In Bindbee they are
INACTIVE,RETIRED,DECEASED,INACTIVE_EXTERNAL, andLEAVEis not a termination. See identify a termination and detecting terminations and coverage end dates. - Dependents: relationship, DOB, SSN, student status. This is the input that varies most. Bindbee’s Dependent model is not available on the Paycor, Paylocity, Paycom, Rippling and SAP SuccessFactors API connectors and is Beta on Paychex (API). Knit has a dependents model; Unified.to flags dependents on the employee’s relationships; Apideck and Kombo document none. Where dependents are available, DOB and SSN are often permission-gated in the source.
- Enrollments and coverage: Bindbee’s Benefit, Benefit Coverage and Dependent Benefit models give
coverage_tier,effective_dateand who is covered, where the connector supports them (Benefit Coverage is Beta on UKG Pro and UKG Ready). Merge has a Benefit read object. Knit and Unified.to give employee-level deductions with benefit type and dates, which tell you someone pays for a plan but not which dependents are covered. See benefits data models.
In many platforms the enrollment itself lives in your system, because the employee enrolled with you. In that case you only need census and terminations from the HRIS, which is the more widely available set at every vendor. See sync census data.
2. Your eligibility state
Keep one canonical record per member and coverage line, with effective dates. Generate 834 content from this record, not straight from the HRIS payload. That gives you one place to apply plan rules, and one place to audit what you sent.
HRIS signals map to 834 maintenance types roughly as: a termination becomes a cancel or term, a new hire becomes an add, and a tier change becomes a change. The reason codes come from your own enrollment flow.
3. The 834 build layer
Three common options:
- Build in-house with an EDI library or integration engine. Most control, most carrier-onboarding work.
- Use an EDI or carrier-connectivity vendor. Examples of the category: Noyo (API-first carrier connectivity), Tabulera (an EDI 834 service provider), PilotFish (an integration engine).
- Use a ben-admin system’s carrier feeds if your customers already run one. Employee Navigator, for example, offers a marketplace of pre-configured carrier 834 feeds, with what it describes as a “small 1-time fee” for new carriers. Its partner page lists $750 one-time per new carrier plus $0.45 PEPM recurring, and it sends full files only (no change-only files).
These are named as examples of the category. This is not an endorsement or a feature comparison.
4. Timing
Your 834 can only be as fresh as its inputs. Sync-based vendors refresh on a schedule: Bindbee every 24 hours by default (Pro lists 12–24 hours; Enterprise configurable), Merge Launch daily, Knit Start Up every 24 hours, Finch automated connections roughly daily and assisted ones every 7 days. Pass-through vendors (Apideck, Unified.to) read the source when you call, so freshness is your polling schedule. Add a reconciliation pass whichever you use; in Bindbee’s case, exhausted webhook deliveries are not redelivered. Statutory and carrier clocks run from the event date, so carry effective dates through to the file. See sync cadence and statutory deadlines.
Limits by vendor
Across all seven
- None documents 834 generation, so the carrier-facing build falls to your platform, an EDI vendor or a ben-admin system’s feed marketplace.
- Bindbee, Apideck, Knit and Unified.to document no COBRA feature; for Merge, Finch and Kombo it was not verified. Divorce and legal separation are usually not recorded in HRIS data; at best you see a dependent’s coverage disappear or a tier change, with no reason field. Your 834 maintenance codes for those events have to come from your own enrollment flow.
- Not real-time in the sense of events pushed as they happen. Expect a daily cadence on synced inputs.
Bindbee
- Does not generate 834 files or send anything to carriers. Its 834 ingestion over SFTP is read-side only.
- Benefits read is connector-dependent: the ADP Workforce Now API connector doesn’t support the benefits models (ADP’s SFTP connector supports all four); Paycor, Paychex and Rippling API connectors don’t; Workday, UKG Pro, UKG Ready and BambooHR do. Check model availability.
- Dependent read is missing on the Paycor, Paylocity, Paycom, Rippling and SAP SuccessFactors API connectors.
- Benefits models are read-only. Gusto is not in Bindbee’s integration list.
Merge
- No 834 generation found in Merge’s docs. Enrollment inputs come from its EmployerBenefit and Benefit read objects.
Finch
- No 834 generation found in Finch’s docs. Its Benefits API is Early Access for ADP Workforce Now and Workday only, with GA targeted for Summer 2027.
Kombo
- No 834 generation found in Kombo’s docs, and no benefits, enrollment or dependents path in its OpenAPI.
Apideck
- 834 and COBRA not documented. No dependents or benefits model, so dependent and coverage data for an 834 must come from elsewhere.
Knit
- 834 and COBRA not documented. Dependents are available, but there is no enrollment model linking dependents to coverage; you infer enrollment from deductions.
Unified.to
- 834 and COBRA not documented. The Benefit object is plan-level, not an enrollment, and Workday’s integration lists no Benefit or Deduction object.
Frequently asked
- Do any unified HRIS APIs generate EDI 834 files?
- No documentation of 834 generation as a product was found for Bindbee, Merge, Finch, Kombo, Apideck, Knit or Unified.to as of 1 Oct 2026. They supply inputs such as census, dependent, enrollment and termination data. Your platform or an EDI vendor builds the 834.
- Can a unified API read 834 files?
- Bindbee can: it ingests legacy EDI 834 files delivered over SFTP and serves them as normalized API data, read side only. Apideck, Knit and Unified.to don't document 834 handling of any kind; for Merge, Finch and Kombo it was not verified.
Source limits
Documentation and pricing-page comparison as of 1 Oct 2026; nothing verified hands-on. 'Not documented' means searched for and not found; 'no evidence found' means the same for the vendors checked in an earlier pass. Merge dependents, and COBRA and 834-read handling at Merge, Finch and Kombo, were not verified. Noyo, Tabulera, PilotFish and Employee Navigator are named as examples of the category, not compared or endorsed.
Sources checked
Wrong or out of date? payrolldataspecs@gmail.com — corrections are free. How claims are scored: methodology.