Compliance · guide

Sync cadence and statutory deadlines for benefits platforms

No unified HRIS API makes an HR change arrive the moment it happens: stored-sync vendors copy the source on a schedule (24 hours by default on Bindbee, Finch automated and Knit Start Up, daily on Merge Launch), pass-through vendors read the source on request but still poll for change notification unless the source sends native events, so design for worst-case latency against COBRA's 30-, 14- and 60-day clocks.

By Eli Wilson · Published 2026-10-01

Short answer: unified HRIS APIs get data to you in one of two ways, and neither makes an HR change arrive the moment it happens. Stored-sync vendors copy the source on a schedule: Bindbee every 24 hours by default, Merge daily on its Launch plan, Finch every 24 hours on automated connections and every 7 days on assisted ones, Knit every 24 hours on its Start Up plan (Knit pushes each sync to your webhook). Pass-through vendors, by their own description, send each read to the source system when you make it: Apideck calls itself a “real-time pass-through layer” and Unified.to says “every API request hits the source platform directly”. A pass-through read is as fresh as the source, but you still have to know when to read, and on both vendors change notification is polling unless the source sends native events: Apideck’s virtual webhooks run “typically every 24 hours” by default, Unified.to’s as often as every minute on paid plans. Statutory clocks don’t wait for any of this. Under COBRA, an employer has 30 days from the qualifying event (or from loss of coverage, if the plan says so) to notify the plan administrator, and the administrator then has 14 days from that notice to send the election notice. For divorce, legal separation or a child losing dependent status, the employee or beneficiary must notify the plan within 60 days. Design around the worst case, act on the dates in the record (such as termination_date), and pair notifications with a reconciliation pass.

Worst-case detection latency ≈ time for HR to enter the change + notification or sync interval + export schedule (for file sources) + your processing time + time for a human to act. A worked example: a termination dated Monday is entered in the HRIS on Wednesday, picked up by a 24-hour sync or poll at 02:00 Thursday and processed at 09:00 Thursday. By then the employer is on day 3 of its 30. A one-minute poll would have caught it on Wednesday, still day 2: the HR entry lag is the part no vendor controls.

Comparison: architecture and cadence (as of 1 Oct 2026)

Comparison: change notification and limits (as of 1 Oct 2026)

“Not verified” means no figure was confirmed on the vendor’s public pages for this piece. Ask the vendor for it in writing. Architecture descriptions in quotes are the vendors’ own claims.

What “real-time” usually means

When a unified API talks about fresh data, check four separate things:

1. Where a read is served from. A stored-sync vendor answers from its last copy, so a read is at most one sync interval old. A pass-through vendor forwards the read to the source, so it returns what the source holds at that moment.
2. How you learn something changed. A webhook tells you a change was found. On a stored-sync vendor it fires after a sync (Bindbee, Knit). On a pass-through vendor without a native source webhook, it comes from a poller (Apideck about every 24 hours by default; Unified.to as often as every minute on paid plans). A one-minute poller detects changes far sooner than a daily sync; a 24-hour poller does not.
3. Source-system speed and availability. Every vendor is bound by the source’s own API. On a stored sync, source rate limits govern how quickly a sync completes (Bindbee’s docs say this directly, rate limits). On pass-through, they govern your read itself: Apideck returns a ConnectorRateLimitError when a connector’s limit is hit and times a request out at about 29 seconds. If the source is slow or down when you read, a pass-through read has no stored copy to fall back on, whereas a stored-sync read returns the last synced data.
4. Cost of polling. Frequent polling is not free. Unified.to bills virtual-webhook runs that find new data as API calls, and each list page counts as a call; Knit sets monthly fair-use call caps.

So “real-time” on a pass-through vendor means fresh reads, not instant notification, and it trades a stored copy for a dependency on the source at request time. Stored sync means predictable reads that are up to one interval old. Bindbee is not real-time: it syncs on a schedule, every 24 hours by default (Pro listed as 12–24 hours, Enterprise configurable), and its webhooks fire after a sync, when that sync finds changes. Don’t build compliance logic that assumes any vendor sees a change before HR enters it.

Writes have their own lag. A Bindbee write goes straight to the source system and returns the source’s response, but it is not readable through GET until the next sync. On a pass-through vendor, a read after a write goes to the source; whether the source shows the change immediately depends on the source system, and was not verified for this piece.

Designing around the worst case

1. Know which clock is yours

Source: 29 U.S.C. 1166; 29 CFR 2590.606-2. Confirm deadlines with your compliance counsel; plan terms can change them.

2. Compute latency honestly

For a stored-sync connector at a 24-hour cadence (Bindbee default, Knit Start Up, Merge Launch), worst-case latency is up to 24 hours plus your own steps. On a pass-through vendor, it is your notification interval: about 24 hours on Apideck’s default virtual webhooks, as little as a minute on Unified.to’s paid plans, or however often you poll yourself. For an SFTP connector, add the customer’s export schedule: a weekly export means up to a week (see API vs SFTP connectors and reading bswift, Ease, Employee Navigator and PlanSource). On SFTP connections, a file that stops arriving raises no error, so alert on how long since the data last changed, against the agreed export schedule. For a Finch assisted connection, the documented refresh is 7 days.

When an employer tells you about a termination, read it now rather than waiting for the next cycle. On Bindbee, force a resync for that connection (POST /api/embedded/v1/connectors/resync, then wait for connector_synced); don’t put resync on a schedule, Bindbee asks you not to, and on SFTP connections a resync only re-reads the last file received. On a pass-through vendor, a direct read of that employee does the same job, subject to the source’s limits at that moment.

Compare that number with the deadline your compliance team works to for each event type. If the margin is thin, ask for a faster cadence or polling interval (Bindbee Pro is listed at 12–24 hours and Enterprise is configurable; Merge and Knit offer custom sync on paid contracts; Apideck’s polling frequency varies by plan) or change the process, for example by having the employer notify you directly for terminations.

3. Act on event dates, not arrival dates

Bindbee’s termination guide says it plainly: act on termination_date. Terminal statuses are INACTIVE, RETIRED, DECEASED and INACTIVE_EXTERNAL. LEAVE is not a termination. Coverage end date comes from the benefit record (detecting terminations and coverage end dates).

If a termination dated two weeks ago shows up today, because the employer entered it late or an export was delayed, your clock started two weeks ago. Flag such records (“arrived N days after event”) so operations can prioritise them.

4. Some events never fire

Not every qualifying change appears as a record change:

• Dependent aging out is a date calculation from DOB. No event fires; you need a scheduled job.
• Divorce or legal separation is usually not recorded in HRIS data. At most, a dependent’s coverage disappears or a tier changes, with no reason field.
• Reduction in hours is visible only where the source exposes employment and hours fields.

No COBRA qualifying-event feature is documented on Bindbee, Kombo, Apideck, Knit or Unified.to; Merge and Finch were not verified for this piece. These vendors provide the data you use to infer events (detecting terminations and coverage end dates).

5. Reconcile as well as listen

Any notification can be missed, so every design needs a scheduled reconciliation. Bindbee retries a webhook up to 4 times within 60 seconds, with a 10-second timeout per attempt, and exhausted deliveries are not redelivered. Run a scheduled reconciliation pass with modified_after set to the last successful checkpoint so that a missed webhook doesn’t become a missed deadline. Treat connector_sync_error as an operational alert: a connection that hasn’t synced is a connection whose data is ageing.

6. Budget the rate limit for catch-up

After an outage, or at open enrollment, reconciliation can be heavy. Bindbee’s limit is 200 requests per minute per connector token; because it applies per token, spreading work across connections helps. On pass-through vendors a full reconciliation reads the source directly, so the source’s own limits apply to every page, and on Unified.to each page is a billable call.

Limits by vendor

• Bindbee: 24 hours is the default; a faster schedule goes through support and your plan tier, and a one-off sync is an API call. Webhooks require Pro or Enterprise (Basic/Lite customers poll), fire only after a sync, and exhausted deliveries are not redelivered. SFTP sources are only as fresh as their export, and a missing file raises no error. Benefits models are missing on several API connectors (ADP WFN API, Paychex API, Paycor API, Rippling API), so coverage end dates have to come from somewhere else there. No COBRA feature and no 834 generation.
• Merge: daily on Launch; faster sync needs a paid contract. Change notification was not verified here.
• Finch: assisted connections refresh every 7 days, nearly a quarter of a 30-day employer notice window before you have done anything.
• Kombo: cadence was not verified here.
• Apideck: fresh reads, but default virtual webhooks poll about every 24 hours, so detection can be as slow as a daily sync. Reads depend on the source being available and within its limits; no platform rate limit is published.
• Knit: 24-hour sync on Start Up; configurable cadence is on contract plans. Native real-time events exist only where the source supports them.
• Unified.to: one-minute virtual webhooks are possible on paid plans, but polling that finds data is billed per call, and each read depends on the source at request time. Rate-limit units are not stated.

Frequently asked

Is a pass-through API better for statutory deadlines?

It can shorten detection if you poll often, for example with Unified.to's one-minute virtual webhooks. It does not help if notification is still daily, as with Apideck's default. It adds a dependency on the source system's availability and rate limits at the moment you read, and frequent polling has a cost. Compare the full latency chain, not the label.

Which date should start my compliance clock?

It depends whose clock it is. The employer's clock runs from the event date, such as `termination_date` (or loss of coverage under some plans); the administrator's runs from the date it's notified. Never from the date your system received the record.

Source limits

Sources checked

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