Use cases · guide

Building a quote-ready census from HRIS data

Most of a quote census comes from four HRIS models — Employee, Employment, Dependent and Compensation — but current coverage tier and enrollment data are the hard part: they need a benefits model, the seven vendors compared here differ widely, and where a vendor does model benefits, it is not available on every connector.

By Eli Wilson · Published 2026-10-01

Short answer: most of a quote census comes from four HRIS models: Employee, Employment, Dependent and Compensation. Employee and Employment are the most widely available models in a unified HRIS API; Dependent is not. Current coverage tier and enrollment data are the hard part: they need a benefits model, and the seven vendors compared below differ widely. Bindbee and Merge have enrollment-level models; Finch’s is in Early Access; Unified.to and Knit expose employee-level deductions rather than enrollments; Apideck and Kombo have none. Dependents vary too: Apideck and Kombo document no dependents model. Where a vendor does model benefits, benefits read is not available on every connector. Bindbee’s published matrix shows the pattern. On ADP Workforce Now (API) you get dependents but no benefits models. On Paychex (API), Paycor (API) and Rippling (API) you get neither benefits models nor dependents, so the census has employees and pay only. The SFTP variants of ADP, Paychex, Paycom, Paylocity and Rippling return both.

One public walkthrough is Bindbee’s sync census data use case. The core of it is two requests:

GET /employees?page_size=200&expand=home_location
GET /dependents?page_size=200

One row of the census you build from them might look like this (illustrative values; the column layout is the carrier’s):

This page covers the data mapping, where the gaps are, and how seven unified APIs compare.

Comparison: census inputs by vendor (as of 1 Oct 2026)

Demographics and dependents:

Current elections and plan data:

Sources are listed at the end. “Not verified” means it was not researched for this piece.

What a census row is made of

Carriers and brokers each have their own census template, so keep the target layout in configuration. The inputs nearly always come from the same places. Model names below are Bindbee’s, used as the worked example; the other vendors’ equivalents are in the tables above.

Bindbee normalizes coverage tiers into 11 values, plan categories into 11, and contribution frequencies into 11 (benefits data model). If a source uses a tier Bindbee doesn’t map, coverage_tier carries the source’s original string. Handle unknown values explicitly; include_raw_data shows you the full original record.

Building it step by step

1. Check model availability before you promise a census. Open the model availability matrix for the customer’s connector. “Beta” means the model is built but not yet battle-tested, and it is enabled on request. If Benefit isn’t available on their connector, your census will have no current elections; if Dependent isn’t available either, it will have employees and pay only.

Scope out ssn, bank info and ethnicity before the first sync. A quote prices on none of them, and widening scope later triggers a resync (Scoping).

2. Pull the population. Read Employee and Employment, then filter to the eligible roster the quote covers. Three statuses need an explicit decision: LEAVE is still enrolled and still rated, RETIRED is often quoted as its own population, and PENDING covers new hires inside the waiting period. Decide whether someone was active on the census as-of date from termination_date, the same rule as detecting terminations (identify a termination).

3. Attach dependents. Where the connector provides Dependent, join it to Employee. Check for missing DOBs before you send anything. An empty field means either your scope excluded it or the customer’s credentials cannot read it: check your scope first, then the customer’s HRIS permissions. Fix it with the customer’s admin before you send the census.

4. Attach current elections, if available. (More on the benefits models in reading benefit enrollments from an HRIS.) Benefit records accumulate, one per plan year, so an unfiltered read returns history. Filter to the enrollment whose effective_date covers your census as-of date, then take coverage_tier from that record.

5. Attach compensation for plans that are priced on salary.

**6. Fill tier gaps explicitly.**Bindbee’s census walkthrough builds the tier from relationship on the Dependent model. Where the Benefit model is available, coverage_tier on the current enrollment records the tier the employee elected. Where neither is available, mark the tier as unknown and collect it from the employer or its current ben-admin export.

7. Freeze and version. A census is a snapshot. Store the as-of date, the connector’s last sync time and the rows you sent, so you can explain any difference when the carrier comes back with a quote.

Freshness

Production Bindbee connectors sync every 24 hours by default (sync frequency). For a quote census that is normally fine: you need a consistent snapshot more than you need the latest minute. Two traps make a snapshot quietly incomplete. Until a sync finishes, reads return 200 with partial data and nothing on the response says so, so gate the extract on the connector_synced webhook. And a census that stops at page one looks like a success, so follow the pagination cursor to the end. If you are rebuilding many censuses at once, budget against the rate limit of 200 requests per minute per connector token (rate limits). The source system’s own limits govern how quickly a sync completes.

On other vendors the traps differ. Knit pushes polled syncs to your webhook, so the census is built from the data you have stored from those deliveries; how Knit signals that a sync has finished was not verified for this piece. On pass-through vendors (Apideck, Unified.to), every page of a census pull is a live request to the source, so the source’s rate limits and availability apply during the pull itself; on Unified.to each page is also a billable call. Following pagination to the end matters on every vendor.

Limits by vendor

• Bindbee: benefits read is the gap, not demographics. On ADP Workforce Now (API), Paychex (API), Paycor (API) and Rippling (API) there are no benefits models, and Paychex, Paycor and Rippling (API) also lack Dependent. ADP’s SFTP connector provides all four benefits models, so for ADP customers who can set up a file export, that route closes the gap (API vs SFTP connectors). Bindbee states 102+ HRIS integrations; its public integrations page at docs.bindbee.dev lists 90 HRIS/payroll connector entries today. Gusto is not listed, so it cannot build a census for Gusto employers today. The Basic/Lite tier is Employee-only. SFTP connectors return only what the export contains. The per-connection price is not published.
• Merge: per-integration coverage of Benefit and dependents was not verified here. Launch excludes passthrough and SFTP, which are the usual routes around a gap.
• Finch: enrollment data is Early Access on two systems. Its 250+ provider list on Pro is broader than most, but mostly assisted connections, which refresh every 7 days.
• Kombo: no benefits or dependents paths, so tier and dependents must come from somewhere else.
• Apideck: no dependents or enrollment model. Payroll read shows what was deducted per benefit, which hints at current elections but not the tier. Gusto is listed live.
• Knit: no enrollment model and coverage tier not verified; dependents are available. Gusto is not in the docs HRIS list.
• Unified.to: dependents are flags on relationships; Benefit and Deduction are absent on several large US systems. No Gusto integration page.

Frequently asked

Can I get a census from an employer's HRIS without the benefits models?

Yes, on connectors that expose Dependent. Check the matrix: several large API connectors return employees and pay without dependents. Without the benefits models you'll be missing current plan and coverage tier, which you would then collect separately.

Can a unified API send the census to a carrier?

None of the seven documents it. Bindbee, Kombo, Apideck, Knit and Unified.to document no EDI 834 generation, and no evidence was found for Merge or Finch. They supply the data. Formatting to a carrier template, or generating an EDI 834, is done by your system or by an EDI vendor.

Source limits

Sources checked

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