Queries the named dataset and returns the matching rows. The response is a JSON object with data (an array of row objects, each wrapping its values under a fields object whose keys match the requested field names), links (pagination navigation URLs; prev and/or next, omitted at boundaries), and meta (with page, pageSize, totalPages, totalItems).

Use this for tabular reporting, custom field selection across many employees, and OData-style filtering against the full dataset field catalog. For lightweight directory-style employee listings or batch lookups by ID, use List Employees (list-employees) instead. For the full set of fields on a single employee, use Get Employee (get-employee) instead.

Discover valid datasetName values via List Datasets (v1.2) (list-datasets-v1-2). Discover valid field names for a dataset via Get Fields from Dataset (v1.2) (get-fields-from-dataset-v1-2); the field set is dataset-specific.

Field-name vocabulary differs from the dedicated employee endpoints. The employee dataset uses fully qualified names such as jobInformationJobTitle, jobInformationDepartment, jobInformationReportsTo, and employmentStatus, where List Employees / Get Employee use shorter names like jobTitleName, department, reportsTo, and status. Always source field names from Get Fields from Dataset (v1.2) — names from the employee endpoints will not necessarily resolve here.

Filter expressions use OData-style syntax with comparison operators eq, ne, lt, le, gt, ge, the list operator in, and logical operators and / or. A single filter expression may use and or or, but not both; mixed logical expressions return 422 with code INVALID_FILTER. Operator support varies by field type: eq and ne work on text fields; ordering operators lt, le, gt, ge are supported on numeric and date fields but not on text fields; in is supported on enumerated/list fields but not on free-text fields; on options-type fields (single-select enums) the operators are restricted to those defined for that field type. Unsupported operator/field-type combinations return a 422 with a VALIDATION_ERROR problem detail. Filter fields do not need to appear in the fields array; rows are filtered server-side. String literals in filter expressions are wrapped in single quotes, e.g. firstName eq 'Ashley' or firstName in ('Ashley','Charlotte').

orderBy is a comma-separated list of <field> <asc|desc> rules. Every field used in orderBy must also appear in the fields array; omitting it returns a 400 with code UE-1001. orderBy is optional; with no orderBy the row order is unspecified.

Field-level access is enforced server-side based on the authenticated caller's permissions and OAuth scopes. Callers without permission to a requested field receive an error from the semantic layer rather than silent omission of the field from rows; callers without dataset-level access receive 403. There is no per-row redaction within the response — a row that includes the caller in its access scope returns all requested fields, and a dataset the caller cannot see at all returns 404 ("not accessible" rather than disclosing existence).

Pagination: page defaults to 1 and pageSize defaults to 100 (maximum 1000). meta.totalItems is the count of rows matching the query across all pages, meta.totalPages is ceil(totalItems / pageSize), and data contains at most pageSize rows for the requested page. links.next is present when more pages exist; links.prev is present when not on the first page. Errors follow RFC 7807 (application/problem+json).

Note: Compared to Get Data from Dataset (v1) (get-data-from-dataset-v1), this version uses filter and orderBy request fields instead of the legacy filters and sortBy structures, moves pagination inputs to body fields (page, pageSize) instead of query parameters, returns pagination in links / meta objects instead of a legacy pagination object, and returns RFC 7807 compliant error responses with an X-Request-ID correlation header.