Deel vs HiBob

Deel

The API has 506 operations in public OpenAPI 3.1 specs, about 90 read and write OAuth scopes, a sandbox and a dated versioning policy with one year of deprecation notice. The limit is 5 requests a second for a whole organisation, and the legal documents load only with JavaScript, so data handling terms weren't read.

HiBob

Service users start with no permissions and gain view or edit rights per field, and the docs are served as Markdown with an OpenAPI definition on each endpoint page. There is no public price, trial or free sandbox, so an agent needs a paying customer's admin to issue credentials. No idempotency keys or official SDKs were found.

Deel

1. Queue calls to stay under 5 requests a second for the whole organisation. Other integrations on the same account share the limit
2. Send X-Version: 2026-01-01 on REST calls, and watch X-State, Deprecation and Sunset response headers
3. Send a UUID Idempotency-Key on POST and PATCH. Only retry a 5xx on a write when the request carried one
4. Test against https://api-staging.letsdeel.com/rest with a sandbox token. Production and sandbox tokens aren't interchangeable
5. Request read scopes only (people:read, time-off:read) for a read-only agent. Rejecting a time-off request is irreversible

HiBob

1. Send Authorization: Basic base64(SERVICE-USER-ID:TOKEN) to https://api.hibob.com/v1. Ask the Bob admin to put the service user in a permission group first, because it starts with none
2. Request only the fields needed in fields on POST /people/search (maximum 400). The call returns all matching employees at once, so batch by root.id in large companies
3. Compare returned fields with requested ones. Missing permission or a wrong field ID yields 200 with the field omitted
4. Stop on 401 or 403. More than 50 in 10 seconds blocks the IP for 5 minutes
5. Back off on 429 using Retry-After. Writes such as update, create and terminate employee allow 10 calls a minute, and no idempotency key exists, so check state before retrying a write