Skip to main content
Bindbee identifies a record against a set of conditions, and creates a new one only when something in that set differs. Most reported duplicates turn out to be something else.
Before you start
  • You have the Bindbee id of each record involved.

Steps

1

Check whether it's two employments

An employee is a person. An employment is a job, and one person legitimately has several: a rehire, a transfer, a promotion, or two concurrent roles.Fetch employees alone and count. If the duplication disappears, the fix is selecting the right employment. See Reading employees.Result: You know whether you have one person or two records.
2

Check whether the source system holds two

Compare remote_id across both records, then fetch raw_data - see Inspect raw data.Different remote_id values mean two distinct records exist upstream, putting the fix in the customer’s HRIS. Mergers, payroll migrations, and rehires processed as a new person all produce this.Result: You know which side the duplication is on.
3

Check whether you created it

If you write to this connector, a duplicate may be yours: a retried write without a consistent idempotency key creates a second record. Check the creation timestamps against your own write logs, and send X-Idempotency-Key on future writes - see Idempotency.Key your own records on the Bindbee id. Source systems reissue remote_id and employee_number on rehire, transfer, or record merge, so keying on either duplicates the record in your system the moment the upstream ID changes.Result: You know whether the duplicate originated with you.
4

Report anything left to Bindbee

Check both records belong to the same connector first. IDs are per connector, so one person across two connectors legitimately has two.Within one connector, a shared remote_id means the unique-record conditions didn’t hold, which is ours to fix. Send Bindbee both id values and the connector ID. Deduplicating on your side would mask it.Result: Bindbee resolves the duplicate at source.

Frequently Asked Questions

A resync refreshes existing records. Where one appeared anyway, the upstream identifier changed during the window and the record arrived as new. Compare remote_id values before and after.
The connector was deleted and recreated, which discards record identities and returns the whole dataset under new IDs - see Relinking versus deleting.