The Message beside it carries the source system’s response verbatim.
Bindbee errors
Report the failure with the connector ID, the failing model, and the timestamp of the run. An error message on its own rarely locates it.Origin-system errors
The credentials the connector authenticated with are almost always the problem. An integration user provisioned below the permissions the sync needs is the case Bindbee sees most - a Workday ISU without its minimum grants, or API credentials scoped more narrowly than the models you enabled. Bindbee reads what those credentials expose. Many HR systems answer a permission gap with an empty result rather than an error, so a gap can surface as missing data instead of a failure.Before you start
- You have the connector ID and the name of the affected model or field.
- You can reach the customer’s HRIS administrator.
Steps
1
Read the source system's own response
Open Logs for the connector and find the failing request. Bindbee keeps the source system’s answer as it arrived: the upstream status, the endpoint called, and the response body. See Logs.That body stays unnormalized on purpose. “The Workday integration system user lacks Get_Workers permission on this security group” is the sentence an administrator can act on, and
PERMISSION_DENIED would lose it.Result: You know which upstream resource was refused.2
Name the access the failing model needs
Translate the model that failed into the access it needs.
Result: The specific access to request.
A missing sensitive-data grant raises no error. The connector authenticates cleanly,
the model loads, and those fields come back null.
3
Send the customer their setup guide
The setup guide carries per-system click paths and is white-labeled, so the one for their platform can go straight to the administrator.Result: They know where to click in their own system.
4
Resync once the permission is granted
Permission changes apply from the next run onwards. Trigger a fresh one to pull the newly readable models or fields.Result: The next sync includes what was refused.
When the error doesn’t make sense
Origin systems return their own error text, and some of it is opaque even to the people who administer those systems daily. Ask Bindbee what it means.Alerting
Theconnector_sync_error webhook event fires when a model fails, so you hear about it without polling - see Monitoring this programmatically.
Frequently Asked Questions
The administrator says the permission is already granted
The administrator says the permission is already granted
Check the permission sits on the account the connector authenticated as, rather than the administrator’s own. Integration users get provisioned with a narrower role than the person configuring them.Some platforms require the integration user to be reactivated, or a token reissued, before a change takes effect.
The failure appears on some runs but not others
The failure appears on some runs but not others
Intermittent permission errors indicate token scope changing between refreshes, or a source system applying limits under load. Capture the timestamps of both a succeeding and a failing run before escalating.
Records return but a specific field is still null
Records return but a specific field is still null
Fetch the raw payload to see whether the value arrived at all - see Inspect raw data. A value present in
raw_data and absent from the unified response is a mapping question, and you can surface it as a custom field.The integration connects over SFTP rather than an API
The integration connects over SFTP rather than an API
File-based connectors fail differently: SFTP credentials and the files the source system drops govern access, in place of API scopes. A missing field points at the file layout.
Every model failed, not just one
Every model failed, not just one
That’s the credential itself rather than a permission on it - see Connector relink.
Related
- Sync status - the step before this one
- Logs - the last resort, when no error explains what you’re seeing
- Connector relink - when every model fails at once