HiBob vs Zoho People

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.

Zoho People

The REST API covers employee forms, leave, attendance, timesheets, files and learning, with per-endpoint rate limits and Markdown docs listed in an llms.txt. No OpenAPI spec, official SDK or dated API changelog was found, the Free plan has no API access, and several scopes come only as ALL.

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

Zoho People

1. Use the accounts host and API host of the organisation's data centre. Tokens issued in one region fail in another
2. Stay under each page's threshold, often 30 calls a minute. Exceeding it locks that endpoint for five minutes
3. Page form records with sIndex and limit, at most 200 a call, and use modifiedtime to fetch only changes
4. Look up form and field label names with /api/forms before writing. inputData takes label names, and lookup fields take record IDs
5. Send the refresh token and client secret in the POST body, not the query string, and store the refresh token, which never expires