Factorial vs Zoho People

Factorial

A public OpenAPI 3.1 definition covers 615 operations, including leave approval and employee termination, and OAuth apps can be limited to 33 scopes. API keys always grant every scope and never expire. No idempotency keys exist, and a request to an expired API version is answered in an older schema with no error.

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.

Factorial

1. Send an API key in x-api-key and an OAuth token in Authorization: Bearer. The key is JWT-formatted but is rejected as a bearer token
2. Pin the version in the path, such as /api/2026-10-01/resources/..., and migrate within a year. Expired versions answer in an older schema without an error
3. Treat a 200 with an empty body as a credential from the other environment. Production is api.factorialhr.com and demo is api.eu2.demo.factorial.dev
4. Page with limit=100 and pass meta.end_cursor as after_id. A larger limit is capped at 100
5. Check whether a record exists before retrying a create. Retry only 429 and 5xx with backoff, and branch on code for 422 because messages are localised

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