Skip to main content
Source-system credentials expire, get rotated, or lose access. The connector moves to RELINK_NEEDED and stops syncing. Reads keep returning the last successful sync, so downstream systems treat stale data as current. The data endpoints answer 200 throughout.
Relink the existing connector. Deleting it and starting fresh breaks every Bindbee ID you have stored - see Relinking versus deleting.
Before you start
  • You’ve confirmed the failure is credential-related, rather than a permission gap - see Origin-system errors.
  • You can reach the customer’s HRIS administrator.

​
Steps

1

Open the connector

Locate it under Connectors. The Relink Needed counter above the list totals every connection in this state.Result: You can see its current status and sync history.
2

Generate a relink

A connector needing re-authorization carries a Relink Needed banner with the date it entered that state, and Force Sync is disabled. Click Relink Connector to produce an updated Magic Link for the same connector.Result: A link ready to send to the customer.
A connector page showing a Relink Needed banner with the date since it entered that state and a Relink Connector button, a grayed-out Force Sync control, and a sync history whose most recent run is marked Failed
3

Send it to the administrator

Forward the link to whoever administers their HRIS, with the relevant guide from help.bindbee.dev.Where a token, certificate, or integration user was rotated on their side, they need the new values ready before opening the link.Result: The customer has what they need to reconnect.
4

Resync and verify

Once they’ve reconnected, trigger a sync rather than waiting for the next scheduled run. Then check the run completed in the connector’s sync history.Result: The connector is syncing again and the data is current.
The connector_token survives a relink. Relinking updates the credentials behind the connector rather than the connector itself.

​
Relinking versus deleting

A connector in RELINK_NEEDED has two exits. Relinking keeps the connector’s identity, history, records and connector_token, and syncing resumes where it left off. This is the right response to a broken connector. Deleting removes the connector and its data - identifiers, records, sync history. Recovery means a new connector and a fresh initial sync. Every record comes back with a new Bindbee id, breaking any foreign key you stored. Deletion earns its place when a customer churns or a connection was created in error - see Data deletion.

​
Catch it earlier

The expensive part is the days before anyone notices. Subscribe to connector_sync_error and a stalled connector reaches you the day it breaks - see Monitoring this programmatically. Branch on connector.connector_status in the payload. RELINK_NEEDED is the one value that means your customer must act. The rest retry on the next scheduled sync.
A connector can sit at COMPLETE with its last sync Failed. Credentials are fine and data still isn’t arriving, which is a different problem - see Sync status.

​
Frequently Asked Questions

Mark the connection degraded in your own system so downstream jobs skip it rather than consuming stale data. The connector keeps its last synced state.
Recurring expiry points at a personal account subject to password rotation or offboarding, where a dedicated integration user belongs. A service account fixes it permanently.