Retrieval · guide

How Benefits Platforms Keep Employee Census in Sync with Payroll

Benefits platforms don't own census data: they read it from each employer's HRIS or payroll system, usually once a day, through direct integrations, a unified HRIS/payroll API or SFTP file drops, and the setups that hold up add change notifications that trigger a re-read, a periodic reconciliation pass that catches anything the notifications missed, and logic that acts on the effective dates in the record rather than on the day the change arrived.

By Eli Wilson · Published 2026-10-01

Short answer: benefits platforms don’t own census data. They read it from each employer’s HRIS or payroll system, usually once a day, through direct integrations, a unified HRIS/payroll API, or SFTP file drops. The setups that hold up add three things to that read: change notifications that trigger a re-read, a periodic reconciliation pass that catches anything the notifications missed, and logic that acts on the effective dates in the record rather than on the day the change arrived.

Unified APIs get the data to you in two different ways. Bindbee, Merge, Finch and Knit run scheduled syncs (Bindbee 24 hours by default, Merge Launch daily, Finch automated connections roughly daily, Knit Start Up 24 hours). Apideck and Unified.to describe themselves as pass-through layers that read the source on each request and don’t store the data (their own claims), so freshness depends on how often you, or their virtual webhooks, poll. Either way, the design question is how you stay correct between reads.

Vendor comparison: census data and sync mechanics

Facts as of 1 Oct 2026, taken from each vendor’s public pricing pages and docs (see Sources). “Not verified” means the point was not researched for this article. “Not documented” means it was searched for in the vendor’s docs and not found. Neither means the vendor lacks it.

What each vendor can give you

How fresh it is

What “census” means in practice

For a benefits platform, census is the set of fields that decide eligibility and cost:

• Employee: name, date of birth, identifiers, status.
• Employment: hire date, termination date, employment type. Hours are often not a unified field; Bindbee’s model, for example, has no hours field, so hours come through raw_data or a custom field where the source exposes them.
• Dependent: relationship, date of birth, student status. Vendors model this differently (a Dependent model in Bindbee, employee_dependent in Knit, flags on Employee relationships in Unified.to, none in Apideck), and coverage varies by connector. Where dependents are available, DOB and SSN are often permission-gated in the source.
• Compensation: needed for salary-based benefits such as life and disability.

Employee and employment data is far more widely available across connectors than dependent or benefits enrollment data, at every vendor checked. If you plan to read current elections from the HRIS too, check each vendor’s per-connector matrix. Bindbee’s is at model availability; its sync census data use case covers a quote-ready pull. For the one-time quoting extract, see building a quote-ready census from HRIS data.

The sync loop that holds up

1. Initial full pull

When an employer connects, pull the full population once. Store the source’s identifiers alongside your own so later changes can be matched without fuzzy name matching.

2. Scheduled sync or scheduled polling

With a sync-based vendor, the integration layer re-reads the source on a schedule and you read its copy. Bindbee’s production connectors sync every 24 hours by default, set per connection, with a different cadence arranged through support (sync frequency). Merge’s Launch plan syncs daily. Finch’s automated connections refresh roughly daily and its assisted connections every 7 days, so find out which connection type each customer is on. Knit’s Start Up plan syncs every 24 hours and pushes changes to your webhook.

With a pass-through vendor (Apideck, Unified.to), each request goes to the source system, so “how often” is your own polling schedule or the vendor’s virtual-webhook interval. Source-system rate limits then hit your requests directly: Apideck returns a ConnectorRateLimitError and notes that limits vary by connector.

Source-system limits govern how fast any full read completes, so a large employer on a slow vendor API takes longer either way. With a sync-based vendor, gate full reads on a sync-complete signal (in Bindbee, connector_synced), since a read mid-sync is quietly short (syncing). For how cadence lines up with statutory clocks, see sync cadence and statutory deadlines.

3. Change notifications

Subscribe to change events and re-read only what moved. Examples: Bindbee’s employee_data_changed and connector_data_modified, plus sync-health events such as connector_sync_error; Apideck’s EmployeeTerminated and EmployeeUpdated events; Knit’s virtual webhooks and virtual deleted-data events; Unified.to’s native and virtual webhooks. Alert your ops team on sync errors. A silent sync failure looks exactly like “no changes”.

Virtual webhooks are polling done by the vendor. Apideck’s poll typically every 24 hours by default; Unified.to’s run on the interval you set, down to 1 minute on paid plans. Know which kind you are getting on each connector.

4. Reconciliation pass

Webhooks get lost. In Bindbee’s case, deliveries that exhaust their retries are not redelivered. The fix, with any vendor, is a scheduled reconciliation job that re-reads changes since your last good checkpoint (in Bindbee, a query with modified_after) and processes anything you haven’t seen. Treat webhooks as a latency optimization and reconciliation as the source of correctness.

5. Act on effective dates

The day a change reaches you is not the day it happened. A termination entered three days late still has the original termination_date. Your eligibility logic should key off the dates in the record:

• Know which statuses mean terminated. In Bindbee they are INACTIVE, RETIRED, DECEASED and INACTIVE_EXTERNAL; LEAVE is not a termination.
• Act on termination_date, not on arrival time.
• Coverage end dates come from the benefit record, not from the employment record. See identify a termination and detecting terminations and coverage end dates.

6. Close the loop with payroll

Census sync is the inbound half. After enrollment, the deductions have to land in payroll, which only some vendors and connectors support (see the first table). See writing benefits deductions back into payroll for the connector lists and mechanics.

When files are the answer

Some employers’ payroll systems either lack a usable API or the employer’s IT team prefers a scheduled export. Bindbee’s docs list 13 SFTP connector entries, including isolved and SFTP variants of ADP, Paychex, Paycom and Paylocity; Merge offers SFTP on Professional and Enterprise; Kombo from its Scale plan. SFTP connectors were not documented for Apideck, Knit or Unified.to. An SFTP connector returns whatever the customer’s export template includes, so census completeness depends on that template. Bindbee’s SFTP connectors are read-only, and a missing file raises no error and no failed sync; it looks like frozen data, so monitor file freshness yourself. See API vs SFTP connectors.

Limits you should know

• Across vendors: daily is the common default. Detection latency is your read cadence plus your own processing. Do not design for real-time; “real-time” on a pass-through API means each read hits the source, not that changes are pushed to you as they happen.
• Bindbee: the default is 24 hours, Pro lists 12–24 hours and Enterprise is configurable. Webhooks are Pro and Enterprise only; on Basic you poll, and Basic covers only the Employee model. Missed webhooks are not replayed, so a reconciliation job is required. Bindbee supports 102+ HRIS integrations; the public integrations page at docs.bindbee.dev lists 90 HRIS/payroll connector entries today; ask Bindbee for the full list. Gusto is not listed. Dependent read is not supported on the Paycor, Paylocity, Paycom, Rippling and SAP SuccessFactors API connectors, and is Beta on Paychex (API).
• Merge: the Launch plan syncs daily; custom sync and SFTP are on paid contracts (Professional and Enterprise). Deduction write is not documented in Merge’s HRIS common models as of 1 Oct 2026.
• Finch: assisted connections refresh every 7 days, so census freshness depends on which connection type each customer is on. Deduction write is a Pro plan feature.
• Kombo: SFTP integrations start at the Scale plan. Its OpenAPI has no dependents, benefits or deduction paths.
• Apideck: no dependents model and no deduction write. Virtual webhooks poll about every 24 hours by default, and every read is subject to the source’s rate limits. SFTP connectors are not documented. Data is EU-hosted by default; a US region is not documented.
• Knit: Start Up syncs every 24 hours; faster cadence is on contract plans (Scale Up, Enterprise) with unpublished prices. Gusto is not in Knit’s docs HRIS list. SFTP connectors are not documented. The no-storage claim is Knit’s own.
• Unified.to: coverage depth varies by connector (Paycom, for example, lists only Group, Location, Employee and Bankaccount reads). Gusto has no integration page. SFTP connectors are not documented. The no-storage claim is Unified.to’s own, and every list page you read is a billable call.

Frequently asked

How often do benefits platforms sync census data?

Daily is the common default. Bindbee syncs production connectors every 24 hours by default; Merge's Launch plan syncs daily; Finch's automated connections refresh roughly daily and assisted ones every 7 days; Knit's Start Up plan syncs every 24 hours. Apideck and Unified.to don't sync on a schedule: you read through them on demand, and their virtual webhooks poll for you (Apideck about every 24 hours by default, Unified.to on your interval down to 1 minute on paid plans).

Can webhooks replace scheduled reads?

No. A webhook can only tell you about a change the integration layer has already seen, and native events exist only where the source system emits them. Deliveries can also fail; Bindbee, for one, does not redeliver exhausted deliveries. Use webhooks to trigger work early and a reconciliation pass for correctness.

Source limits

Sources checked

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