Integration and APIs
Calling the applications from other systems, and letting them call you.
The request header every write needs
Read requests need only the session. Every state changing request must also carry a small presence header naming the application family, or it is refused with 403 bad request - a message that reads like a permissions problem and is not one.
| Family | Header |
|---|---|
| Suites and Central ERP | x-cx: 1 |
| HCM | x-hr: 1 |
| Inventory and WMS | x-inv: 1 |
| Investec | x-iv: 1 |
| Projects | x-pmo: 1 |
| Hospitality | x-hz: 1 |
| Accounts portal | x-acct: 1 |
Authentication
An API call uses the same session cookie as the browser and is therefore the same identity, with the same entity scope and the same module permissions. There is no separate API identity that bypasses those checks.
Webhooks and connectors
Outbound webhooks fire on record events. Connections support API key, bearer token, basic authentication, OAuth 2.0 client credentials and HMAC request signing. Secrets are write-only: once saved they are never returned by the API, so a leaked response cannot expose them.
Rate and payload limits
Bodies are capped, and sign-in attempts are throttled per address after repeated failures. A bulk load should page through records rather than sending one very large request.