Skip to main content
Open the connector and read what its last sync did, model by model. Most data questions are answered here.

​
Steps

1

Find the connector

Open Connectors. The list shows every connection with its integration, type, and when it last linked. Check the counters to identify Active, Incomplete and Relink Needed.
Result: You’ve identified the connector to investigate.
2

Review the sync history

Select the connector and go to Sync. Each run lists its trigger, status, record and employee counts, and when it ends.Result: You know which run to open.
The Sync tab of a connector, listing six runs: one in progress at 41 percent with counts reading Calculating and 2 hr 21 min left, three marked Synced with full record counts, one marked Partial with lower counts, and one marked Failed with no counts
These are the dashboard’s labels. The sync_status field carries a narrower set - Syncing, Done or Failed. Code branching on a Partial will never match.
3

Read the status on each model

Click into a run to reach Sync info. The header carries the run’s status and duration. Every model the connector covers is listed below with its record count, timings, and status.Result: A status for every model. Synced, Skipped and Not Supported all end the investigation here, without reaching Logs. Only Failed continues.
The Sync info screen for a run marked Partial, listing Employee and Company as Synced, Employment as Skipped with no records, Dependent as Failed with an expanded Issue and Message showing User not authorized and a Permission issue found banner, and three models still Pending
4

Expand a failed model

A Failed row expands in place to name the failure:Bindbee also flags a recognized cause above the detail - a permission refusal surfaces as Permission issue found!In the run above, Dependent failed with User not authorized. against Integration Partner - a permission gap on the customer’s side. See Origin-system errors.Result: You know whether to report it to Bindbee or take a permission back to the customer.
5

Confirm the timing

Compare the run’s start time against the connector’s configured cadence to work out when the next one is due.Result: You know whether the data you’re reading is current.
Development connectors have no recurring schedule. On one of those, the last sync is its initial sync or the last one someone triggered - see Syncing.

​
Diagnose a partial sync

The connector is authenticated and running, so the failure is scoped to specific models. Note every model reporting Failed, then match the set against these patterns. The cause is usually shared across them.

​
Retry the sync

For transient and size-related failures, trigger a fresh run. If the same models fail the same way afterwards, it isn’t transient.
Click Force Sync on the connector’s Overview tab. It grays out while a run is in progress, and on a connector needing re-authorization.
Resync. Do not delete and recreate. Deleting a connector discards its sync history and record identities, which changes the IDs your system has stored.

​
Monitoring this programmatically

Subscribe to webhook events instead of polling. connector_sync_started, connector_synced and connector_sync_error cover the states above. See Choose Webhook Events for the catalog.
The per-model breakdown is dashboard-only. The connector endpoint returns a single sync_status for the whole run, so these events are the only way to alert on one model.

​
Frequently Asked Questions

Zero records, or records with empty fields. Either the model is out of scope, or the credentials lack permission for that endpoint - see Origin-system errors and Missing records.
Development connectors don’t auto-sync. On a Production connector this is a stall - see Connector relink.
Wait for it to finish. Duration scales with population size and with how many API calls the source system makes per record.
  • Errors - the next step when a model reports Failed
  • Logs - the last resort, once this and Errors haven’t explained it
  • Syncing - the schedule a status is measured against