BambooHR vs HiBob

BambooHR

The REST API publishes an OpenAPI 3.1 spec with 389 operations, llms.txt and OAuth scopes with separate write variants, and every call runs with the authorising user's permissions. No rate limit numbers are published, the MCP server is in beta, and its results can omit records without saying so.

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.

BambooHR

1. Treat a short or empty result as what this caller may see. list_employees drops employees when a filter or sort field is restricted
2. Honour Retry-After on 429. Rate-limited calls returned 503 before 16 September 2026, so handle both
3. Ask for read scopes only unless the task writes. Write access needs the matching .write scope
4. Request offline_access to receive a refresh token. Access tokens last one hour
5. Use list-employees with fields, filter and cursor paging in place of the unpaginated directory endpoint

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