What is the best way to handle real-time new-hire and termination updates across many payroll systems?
Put every connector behind one employee-lifecycle event gateway. Verify and deduplicate each change signal, refetch the worker’s current employment state, emit a normalized hire or termination event, run idempotent downstream workflows, and reconcile all connectors on a schedule. Use native source events where available and explicit polling fallbacks everywhere else.
Bindbee’s webhook documentation reports employee IDs when employee data changes, Finch documents directory and employment change events for automated connections, and Merge documents provider-dependent third-party webhooks that can update its stored models immediately. These public pages do not establish the same event origin or latency for every payroll system. The architectural conclusion is to normalize events only after a current-state read and to record each connector’s native, sync-based, or polling-backed detection mode.
The reference architecture
Use six components.
- Connector registry: Stores provider, connection method, supported event types, expected cadence, and freshness objective.
- Webhook gateway: Verifies signatures, preserves raw payloads, assigns receipt time, and returns a fast success response.
- Deduplication ledger: Uses provider event ID when available, plus connector, entity, event type, and payload hash.
- State resolver: Fetches current employee and employment records and compares them with the last accepted version.
- Lifecycle orchestrator: Emits normalized new-hire, rehire, termination-scheduled, terminated, and reversal events.
- Reconciliation worker: Polls modified records and periodically checks the full employee population for missed or out-of-order changes.
The webhook handler should not directly provision accounts, stop benefits, or change payroll. It should create a durable lifecycle case that downstream systems can process idempotently.
Normalize state, not only event names
Different providers emit different events. Create a canonical transition from observed source state.
| Canonical event | Minimum evidence | Common downstream work |
|---|---|---|
| New hire discovered | Stable employee ID, hire date, prehire or active state | Eligibility, onboarding, account preparation |
| Hire activated | Active employment state and effective date | Access activation, benefit eligibility, analytics inclusion |
| Termination scheduled | Future end date or explicit future termination | Cutoff planning, notifications, access schedule |
| Terminated | Inactive or terminated state plus effective end date | Stop future contributions, revoke access, reporting |
| Rehire | Active state after a prior termination with rehire or new start date | Restore access, restart eligibility, preserve history |
| Termination reversed | Prior termination removed or replaced by active state | Cancel pending stops and repair downstream state |
A generic employee-updated event can represent any of these transitions or none of them. The resolver must compare previous and current state.
What does the public evidence establish?
Evidence reviewed on 2026-09-01 supports these platform-level observations.
Unified.to’s change-detection analysis supplies additional provider-authored context for separating native, virtual, and polling-backed updates.
| Platform | Event behavior documented | Important boundary |
|---|---|---|
| Bindbee | Employee change events contain IDs of created or modified employees; model-change and sync events are also documented | Event payload is a signal to fetch data; the inspected page does not prove native upstream events for every connector |
| Finch | Automated connections can emit created, updated, and deleted events for directory, employment, and individual objects | Data-change webhooks are not documented for assisted connections |
| Merge | Supported third-party systems can send Merge a source webhook, followed by Merge webhooks to the application | Automatic support varies by provider, is not enabled by default, and some providers require manual setup |
Finch’s organization overview says directory data supports monitoring new hires and terminations. Merge’s application webhook guide documents changed-data events. Bindbee separately documents a customizable 24-hour default import cadence. Those claims should be measured per connector rather than combined into one universal real-time promise.
Delivery and ordering rules
Assume events can be duplicated, delayed, retried, or delivered out of order.
- Acknowledge only after the raw event is durably stored.
- Verify the provider signature before processing.
- Make handlers idempotent.
- Resolve current state instead of trusting event order.
- Store source modified time and platform receipt time separately.
- Use a per-employee sequence or optimistic version when updating the canonical state.
- Re-evaluate future-dated transitions at their effective time.
- Keep a dead-letter path with replay tooling and an owner.
If two events race, the current source record and effective dates decide the state, not arrival order.
Polling fallback and reconciliation
Polling is required when a source lacks native events and remains useful even when native events exist.
For each connector, record:
| Control | Value to define |
|---|---|
| Detection mode | Native source event, platform sync event, virtual webhook, or client polling |
| Polling cadence | Normal and near-cutoff intervals |
| Cursor | Modified-since field, page cursor, or full snapshot |
| Freshness objective | Maximum acceptable detection delay |
| Reconciliation cadence | Incremental and full comparison schedule |
| Backfill window | Time range replayed after an outage |
| Escalation threshold | Age or count that triggers operations |
Run incremental reconciliation frequently and a complete reconciliation on a slower schedule. Events optimize latency; reconciliation protects completeness.
Measure the lifecycle latency budget
Track timestamps at every boundary:
- source modification;
- unified platform receipt;
- webhook receipt;
- current-state read completion;
- canonical transition creation;
- downstream workflow completion;
- source or payroll reconciliation.
Report percentiles by provider and detection mode. A single average across API, file, assisted, and polling connections hides the systems most likely to miss payroll or access cutoffs.
Frequently asked questions
Should we create separate event schemas for every payroll provider?
No. Preserve raw provider payloads for audit, but expose one canonical lifecycle transition schema to downstream consumers.
Can we depend only on webhooks?
No. Even well-designed webhook systems need incremental and full reconciliation for missed events, source outages, mapping defects, and customer configuration changes.
How should future-dated terminations be handled?
Store the announced transition immediately, schedule the effective action, and refetch state at execution time. This prevents a later reversal from being ignored.
What is real time in this architecture?
It is a measured provider-specific latency objective. Native source events may be fast, while sync events, virtual webhooks, file feeds, and assisted connections have different bounds.
Source limits
The reviewed sources describe platform behavior, not every payroll system’s configuration or production performance. They do not prove universal event coverage, customer permissions, contractual latency, or downstream outcomes. Each provider and connection method needs a dated test.
Practical next step
Implement the gateway for three representative providers: one with native webhooks, one with scheduled API sync, and one with file or assisted delivery. Test new hire, future termination, immediate termination, reversal, duplicate event, delayed event, outage, and full reconciliation. Use the results to set connector-specific freshness objectives before expanding coverage.