> ## Documentation Index
> Fetch the complete documentation index at: https://docs.bindbee.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Resolve Duplicate Records

> Work out whether two records are a duplicate, then report it.

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.

<Info>
  **Before you start**

  * You have the Bindbee `id` of each record involved.
</Info>

## Steps

<Steps>
  <Step title="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](/guides/data-models/employee-data).

    **Result:** You know whether you have one person or two records.
  </Step>

  <Step title="Check whether the source system holds two">
    Compare `remote_id` across both records, then fetch `raw_data` - see [Inspect raw data](/guides/reading-writing/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.
  </Step>

  <Step title="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](/guides/reading-writing/writing-data/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.
  </Step>

  <Step title="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.
  </Step>
</Steps>

## Frequently Asked Questions

<AccordionGroup>
  <Accordion title="Duplicates appeared after a resync">
    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.
  </Accordion>

  <Accordion title="Every record appears to have duplicated at once">
    The connector was deleted and recreated, which discards record identities and returns the whole dataset under new IDs - see [Relinking versus deleting](/guides/troubleshooting/connector-relink#relinking-versus-deleting).
  </Accordion>
</AccordionGroup>

## Related

* [Missing records](/guides/troubleshooting/missing-records) - when a record is absent instead of doubled
* [Record counts](/guides/troubleshooting/record-counts) - when the totals disagree
* [Record identity](/guides/reading-writing/record-identity) - the conditions Bindbee identifies a record against