Retrieval · guide

Detecting employee terminations and benefits coverage end dates from HRIS data

Treat INACTIVE, RETIRED, DECEASED and INACTIVE_EXTERNAL as terminations (LEAVE is not), act on the termination_date, and take the coverage end date from the benefit record's end_date — how quickly you hear about a termination depends on the vendor's sync or pass-through architecture, so run a reconciliation pass.

By Eli Wilson · Published 2026-10-01

Treat four employment statuses as terminations: INACTIVE, RETIRED, DECEASED and INACTIVE_EXTERNAL. LEAVE is not a termination. Act on the termination_date, and take the coverage end date from the benefit record’s end_date, which is often the last day of the month. How quickly you hear about a termination depends on the vendor’s architecture. Stored-sync vendors deliver it on the next sync: every 24 hours by default on Bindbee, daily on Merge’s Launch plan, about daily on Finch’s automated connections (7 days on assisted ones), every 24 hours on Knit’s Start Up plan. Apideck and Unified.to describe themselves as pass-through, so a read reaches the source at request time (their claim), but change notification on both is polling unless the source sends native events. In every case the clock starts when HR enters the change, and statutory deadlines run from the event date. Run a reconciliation pass so you don’t miss any.

The status names and code below are from Bindbee’s docs; the rules apply to any vendor.

How unified APIs surface terminations (as of 1 Oct 2026)

“Not verified” means it was not researched for this article. Check the vendor’s docs.

Step 1: Decide what counts as a termination

A workable rule, as set out in Bindbee’s identify a termination guide:

• Terminal statuses: INACTIVE, RETIRED, DECEASED, INACTIVE_EXTERNAL. INACTIVE_EXTERNAL is a contractor ending an engagement. Matching only on INACTIVE misses them.
• LEAVE is not a termination. Don’t end coverage on a leave status. Whether coverage continues during leave is decided by the plan.

TERMINAL = {"INACTIVE", "RETIRED", "DECEASED", "INACTIVE_EXTERNAL"}
# LEAVE is NOT a termination

if emp["employment_status"] in TERMINAL:
    handle_departure(emp)

Normalize on the status enum and don’t parse the source system’s labels. Every payroll system names these differently, and the unified status is what makes one rule work across all of them.

employment_status, termination_date and termination_reason all sit on the employee, so one call carries everything the decision needs. Keep termination_reason: whether a termination is a COBRA qualifying event can depend on it (gross misconduct is the exception).

Step 2: Act on the termination date

The status change reaches you on a sync. Terminations are often entered weeks before they take effect, and HR teams sometimes enter them after the fact. Store and act on termination_date:

• If termination_date is in the future (a scheduled termination), queue the action for that date. Keep the scheduled action cancellable until the date passes. Rescinded resignations, entry errors and quick rehires are common. If a later sync shows the status back to ACTIVE or the date moved, cancel or reschedule.
• If termination_date is in the past, compute every downstream date (coverage end, notices, carrier updates) from it.
• If the status is terminal but termination_date is empty, flag it for review. Don’t assume today’s date.

termination_date = emp["termination_date"]
if termination_date > today:
    schedule_offboarding(emp, at=termination_date)   # reversible until then
else:
    offboard(emp)

Step 3: Take coverage end from the benefit record

Coverage end is a plan rule, not an HR fact. It does not have to match the termination date, and the employer’s plan documents decide. Bindbee’s docs say it plainly: the coverage end date comes from the benefit record, not from employment.

In practice:

1. Find the employee’s current enrollments. Enrollments accumulate one per plan year, so filter Benefit by effective_date for the current plan year (benefits models).
2. Read end_date on each current Benefit and Dependent Benefit. It is often the last day of the month, not the termination date. Expect a window where the employee is terminated and coverage is still active.
3. If the source system hasn’t updated the benefit record yet, apply the employer’s plan rule in your own system and reconcile when the record catches up.
4. Find every dependent whose coverage ends with the employee’s. Dependent Benefit points to the plan, so join it to the employee’s Benefit on employer_benefit; Benefit Coverage (covered_dependents) lists who is covered under the enrollment.

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

Benefits read isn’t available on every connector. ADP WFN API, Paycor API, Paychex API and Rippling API don’t expose benefits models, and Paylocity API has only the Benefit model in Beta. On those connectors you get the termination from employment data, but the coverage end has to come from your own records or from an SFTP export. The four models are explained in reading benefit enrollments from an HRIS.

Other vendors have the same gap in different places. Apideck and Kombo have no benefits model, so coverage end always comes from your own records. Knit’s employee_deduction and Unified.to’s Deduction carry start and end dates, but those are deduction dates, which need not equal the plan’s coverage end; Unified.to lists no Deduction object on Workday, Rippling, BambooHR, Dayforce or Paycom. Finch’s Benefits API is Early Access on ADP WFN and Workday. Merge’s per-integration Benefit coverage was not verified here.

Step 4: Get notified, then reconcile

The pattern is the same on every vendor: listen for changes, then reconcile on a schedule because notifications can be missed. Bindbee’s mechanics as the worked example: on the Pro or Enterprise tier, subscribe to employee_data_changed and connector_synced. When one fires, fetch the changed employees by ID:

curl --request GET \
  --url 'https://api.bindbee.dev/api/hris/v1/employees?ids=<ID_1>,<ID_2>' \
  --header 'Authorization: Bearer <BINDBEE_API_KEY>' \
  --header 'X-Connector-Token: <CONNECTOR_TOKEN>'

Return 200 as soon as you have the webhook payload and process asynchronously. Bindbee retries a failed delivery up to 4 times within 60 seconds, with a 10-second timeout per attempt, and deliveries that exhaust those retries are not redelivered. So on a schedule, query employees with modified_after set to your last successful pass and diff statuses against your own records. That is how you catch the termination whose webhook you missed.

Handle connector_sync_error too. If a customer’s connection has been failing for days, you’re missing terminations without knowing it. Once the error clears, you can trigger an on-demand resync (POST /api/embedded/v1/connectors/resync) instead of waiting for the next scheduled one.

Default sync is every 24 hours per connection. A different cadence goes through Bindbee support (or the Enterprise tier) (sync frequency). Worst-case detection latency is the sync interval plus your own processing time.

On the other vendors: Apideck has an EmployeeTerminated webhook event, but where the source has no native webhook it comes from a poller that runs “typically every 24 hours” by default and compares all items per resource. Unified.to’s virtual webhooks can poll as often as every minute on paid plans; virtual-webhook runs that find new data count as billable API calls. Knit pushes each polled sync to your webhook (24 hours on Start Up). On a pass-through vendor you can also query the source directly before acting, which helps confirm a termination but is subject to the source system’s own rate limits and availability at that moment. How that interacts with notice deadlines is covered in sync cadence and statutory deadlines for benefits platforms.

Stop the deduction too

A termination should also stop future benefit deductions. How depends on the vendor. Knit documents an unenroll-from-deduction endpoint (ADP Run, ADP WFN, Paycor, Paychex, Paylocity, QuickBooks Payroll). Unified.to lists Deduction remove on Paylocity, Paychex and UKG Pro. Finch documents deduction write on Pro. Merge, Kombo and Apideck document no deduction write. Bindbee has no PATCH for deductions. Each POST /employee-payroll-runs write targets one pay period or one payroll run (a start_date / end_date on Workday and SAP SuccessFactors, a payroll_run id on UKG Ready, a payroll_file batch on ADP), not a recurring deduction election (create endpoint docs). Nothing recurs unless you write it again, so to stop the deduction after a termination, don’t write it for the next period. If you already wrote a line for a period that hasn’t closed, handle the correction with the customer’s payroll team or through the vendor API via passthrough. Cut-off timing for corrections is covered in idempotency and payroll cut-offs for deduction writes.

Limits by vendor

• Bindbee: detection is bounded by sync cadence, 24 hours by default. No COBRA qualifying-event detection, endpoint or event; it gives you the termination status, date and reason. Coverage end needs a benefits-capable connector, and several large API connectors lack one. Webhooks are Pro / Enterprise; on Basic/Lite you poll, and only the Employee model is available.
• Merge: Launch syncs daily; faster sync is on paid contracts. Change notification and per-integration Benefit coverage were not verified here.
• Finch: assisted connections refresh every 7 days, which is a large share of a 30-day notice window. The Benefits API is Early Access on two systems.
• Kombo: no benefits model, so coverage end comes from your own records. Cadence and notification were not verified here.
• Apideck: no benefits model, so no coverage end date from the API. Virtual webhooks poll about every 24 hours by default, so a pass-through read does not mean you hear about a termination sooner. Platform rate limits are not published; per-connector limits apply.
• Knit: no benefits plan model; deduction end dates need not equal coverage end dates. 24-hour sync on Start Up.
• Unified.to: Deduction is missing on several large US systems. Frequent virtual-webhook polling is billed when it finds data.
• All vendors: source data quality varies. If the customer’s HR team enters terminations late or leaves termination_date blank, the API returns what the source has. No COBRA feature is documented on Bindbee, Kombo, Apideck, Knit or Unified.to; Merge and Finch were not verified for this piece.

Next step

Whichever vendor you use, wire its change notification and its error or sync-failure signal to a handler using the rules above, and run a scheduled reconciliation from day one. Bindbee’s identify a termination guide shows one full flow.

Frequently asked

How fast will I see a termination through a unified API?

On stored-sync vendors, after the next sync plus your processing time: every 24 hours by default on Bindbee and on Knit's Start Up plan, daily on Merge Launch, about daily on Finch automated connections and 7 days on assisted ones. On pass-through vendors (Apideck, Unified.to, by their own description), a read reaches the source when you make it, but you still need something to tell you to read: a native source webhook, a virtual webhook (Apideck about 24 hours by default; Unified.to as often as 1 minute on paid plans) or your own polling. No vendor makes HR enter the change sooner.

Can a unified API tell me if a termination triggers COBRA?

Bindbee, Kombo, Apideck, Knit and Unified.to document no COBRA feature; Merge and Finch were not verified for this piece. They provide the status, dates and (where modelled) benefits records. COBRA qualification and notices are your logic or your COBRA administrator's.

Source limits

Sources checked

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