| Category | The kind of system - hris, ats or lms. Decides which models exist and appears in every endpoint path |
| Integration | A vendor system, named by a slug such as bamboohr |
| Connector | Your customer’s connection to one integration. Holds their credentials and sync schedule |
| Model | A unified object type - employee, benefit, candidate. The same across every integration in its category |
| Record | One instance of a model, synced from one connector |
| Organization | Your Bindbee account |
| Environment | Development or Production. Separate connectors and keys; shared logs, scope and custom fields |
| API key | Authenticates your organization. Sent as Authorization: Bearer, on every request |
| Connector token | Tells Bindbee whose data you want. Sent as X-Connector-Token on any request that reads or writes a specific connector |
| Scope | The models and fields Bindbee is allowed to fetch. A field outside scope is absent from responses |
| Sync | The job that fetches the data from the source system and puts it in Bindbee’s shape. Automatic in Production, manual in Development |
| Custom field | A value the unified model doesn’t carry, pulled out of the raw payload with a JMESPath expression |
| Magic Link | A hosted page where your customer authorizes their own system, with no front-end code on your side |
| Passthrough | A request forwarded to the source system’s own API, using the credentials already on a connector |
| Issue | A failure raised automatically against a connector, carrying the request and response behind it |
| Meta API | Returns the request shape a write endpoint expects for a given connector, since required fields differ by system |
id vs remote_id | id is Bindbee’s identifier - stable, the one to store. remote_id is the source system’s own |
