Returns a single employee record as a JSON object (or XML when Accept: application/xml). The id field is always present and is returned as a string; it is the internal employee ID — see the id and employeeNumber field documentation in the response schema for the distinction between the internal ID and the editable Employee # value. Pass the id 0 to read the authenticated caller's own record.
Requesting fields. Every other field is included only when explicitly named in the fields query parameter. With no fields parameter, the response contains only id — there is no implicit default field set. Field names come from List Fields (list-fields), which also exposes custom-field aliases usable here. The maximum number of fields per request is 400.
Field-name vocabulary. The names used here differ from the employee dataset (queried via Get Data from Dataset (v2) (get-data-from-dataset-v2)): this endpoint uses short names (workEmail, jobTitle, department, supervisor) where the dataset uses qualified names (email, jobInformationJobTitle, jobInformationDepartment, jobInformationReportsTo).
Effective-dated values. By default only currently effective values from historical tables (job title, compensation, employment status, etc.) are returned; pass onlyCurrent=false to include future-dated values.
Permissions. Field-level permissions are applied silently: any requested field the authenticated caller cannot view is omitted from the response with no marker — an absent field may indicate either that it was not requested or that the caller lacks permission to view it. This differs from get-data-from-dataset-v2 for the employee dataset, which always returns every requested field but represents inaccessible values as empty and lists the withheld field names in a per-record _restrictedFields array. Record-level permissions apply in addition to field-level ones. Which employees a caller can view depends on their access-level configuration, which may be limited to themselves, to their direct or indirect reports, or to another configured set. If the caller cannot view the requested employee, the endpoint returns 403 with Insufficient Permissions to view this employee rather than a partial record.
Related endpoints. Use this for fetching arbitrary fields on a single known employee. For multiple employees, use list-employees. For complex filtering or tabular reports, use get-data-from-dataset-v2. To look up information published in a coworker's company directory entry, such as job title, department, location, work contact details, or who they report to, use Get Employees Directory (get-employees-directory), which is governed by directory sharing settings rather than by per-employee record permissions and is available when directory or org-chart access is shared with the caller's access level.
OAuth Scopes: employee, employee:assets, employee:compensation, employee:contact, employee:custom_fields, employee:custom_fields_encrypted, employee:demographic, employee:dependent, employee:dependent:ssn, employee:education, employee:emergency_contacts, employee:identification, employee:job, employee:job.write, employee:management, employee:name, employee:photo, employee:vaccination, sensitive_employee:address, sensitive_employee:creditcards, sensitive_employee:protected_info
| Time | Status | User Agent | |
|---|---|---|---|
Retrieving recent requests… | |||
400The fields parameter contained more than 400 entries.
401Unauthorized.
403The authenticated user does not have permission to view this employee.
404No employee was found for the supplied ID.
