Deel vs Humaans

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.

Humaans

API tokens are limited by eight scopes and the creator's role, can expire and can be rotated with a seven-day overlap, and rate limits are published with Retry-After on 429. No OpenAPI file, API changelog, official SDK or idempotency keys were found, and prices are by quote, so an agent needs a paying customer's token.

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

Humaans

1. Send Authorization: Bearer <token> to https://app.humaans.io/api. Call GET /api/token-info first to read the token's scopes and expiry
2. Expect a role limit as well as scopes. A token made by a user with the User role reads only public company data and that person's own profile
3. Page with $limit (maximum 250) and $skip, and pass -g to curl because parameters use $ and []
4. On 429 wait the seconds in Retry-After. The bucket holds 40 requests and refills at 7 a second per token
5. Check state before retrying a POST. No idempotency key exists, and DELETE /api/people/:id cannot be undone