HRIS: Why GET /employees and GET /employees/{id} return different fields
1. Overview
When listing employees with GET /hris/employees, you may notice that some fields are empty or missing - but those same fields are populated when you fetch a single employee with GET /hris/employees/{id}. This is expected behaviour and is explained by how the two endpoints work under the hood.
2. How the two endpoints work
List employees (GET /hris/employees) makes a single request to the provider and returns a defined set of fields for each employee. This is optimised for performance across large employee lists.
Get one employee (GET /hris/employees/{id}) makes a main request to the provider plus potentially several additional child requests - for example, separate calls to fetch jobs, compensations, and custom fields. The results are merged into a single unified response, which is why more fields are populated.
3. Which fields are fetched
Apideck only requests the provider fields that map to the unified fields supported for that operation. It does not request everything the provider has and then drop part of it - what is requested is what is returned.
Without field filtering - the connector fetches a defined default set of provider fields covering the unified fields supported for that endpoint (list or detail).
With field selection / data scopes - only the provider fields that map to your consented or requested unified fields are fetched, which may be a subset of the default.
4. How to check which fields are supported per endpoint
For each HRIS connector, the supported fields per endpoint are documented on the connector's page in the developer docs. For example, on the BambooHR Employees page you can see the supported list fields and supported detail fields separately.
If you need this information programmatically across all providers, you can call the Connector API and read the supported_list_fields and supported_fields arrays for each connector.
