Critical behaviors
Read the full People read API contract before integrating. See also People API (rate limits, permissions table, troubleshooting).
How this endpoint works
- Bulk read — Returns employee field data for many employees in one call. Uses
POST(notGET); the request body selectsfields, optionalfilters, andshowInactive. - No pagination — Each successful call returns all matching employees in one
employeesarray. Withoutfilters, that is every employee the service user can access (respectingshowInactive). Max 400 field IDs infields[]. See Pagination and result scope.
Field IDs and responses
- Request field IDs — Use dot notation from Fields metadata (e.g.
root.id,work.department). This is the canonical field ID — stable when a field moves categories; not a live category path. Use metadatacategoryIdfor permissions, not the prefix in the field ID string. - Response field keys — Slash notation (e.g.
/root/id). The same employee may also include nested category objects (e.g.work.siteIdalongside/work/siteId). - Silent omission — Fields in
fields[]without permission or with invalid IDs are omitted (200 OK, no warning). Always validate the response against your request. - Default fields — If
fields[]is omitted, returns fields fromroot,about,employment, andwork(subject to permissions). - Custom fields — Not in default responses; request each metadata
idinfields[]and grant category permission. See Custom employee fields (category fields).
Filters
- Supported filters — Only
root.idandroot.emailwith operatorequals. Other field paths return400. - Omit when not filtering — Do not send
filters: []or an empty object; that can return400. Omit thefiltersproperty entirely to return all employees the service user can access (respectingshowInactive).
showInactive (terminated and former employees)
showInactive (terminated and former employees)- Default
false— Active employees only (internal.status= Active). Terminated/hired (internal.status= Inactive) are excluded unlessshowInactiveistrue. - Set
showInactive: truewhen the caller needs terminated, hired, or any kind of leave employees. - Permissions —
showInactive: truealone is not enough. The service user must be allowed to access this audience (permission group Access data for must not be limited to Employed-only). See How to read the employee status and showInactive (contract).
Large companies recommendations
For all employees in a large company: do not call once with many fields and no filter.
- Search with
fields: ["root.id"]only (setshowInactive: trueif leavers are required). - Batch follow-up searches with a
root.idfilter and the fields you need (e.g. 50–200 IDs per call).
See Recommended pattern for large companies.
Permissions
Grant the service user View on each field's category (categoryId from metadata), not per field ID, and audience that includes all the people you want to access. Note that the default is to include only employed employees.
Scope
This endpoint covers employee fields only, including current values of historical tables (e.g., work table columns). It does not include historical Employee Tables rows or Workforce Planning positions.
Request examples (Try It)
Use Examples → Request Example on this page:
| Example | Purpose |
|---|---|
| Default search | showInactive: false, common fields — active employees only |
| Discover employee IDs | Lightweight root.id only |
| Include terminated / inactive employees | showInactive: true |
| Batch read by employee IDs | root.id filter with multiple IDs |
Default Try It body omits filters when not filtering.
Setup walkthrough: Read employee data · Field types & humanReadable: Fields metadata
400Bad request. The request contains incorrect parameters or syntax errors. Please review the request body
403Forbidden. The service user does not have permissions to access this table or employees. Check the permissions as explained in the endpoint description.
429"Too Many Requests" error. This indicates that you've exceeded the rate limit for requests. Please verify that you are using the correct endpoint with the POST method. Additionally, check the HTTP headers for rate limit information, such as the number of requests allowed and the time until the limit resets. For more details, see Rate Limiting.
