Filtering & Sorting#
When an endpoint returns a list, it often supports filtering and sorting the response.
Note
Not all list endpoints support every field or operator. The set of filterable fields and supported operators varies per resource; refer to each endpoint’s documentation.
Filtering#
Use the $filter query parameter to return only items that meet specific criteria. To match a
value that contains a single quote ('), escape it with an additional single quote.
The $filter parameter supports these operators:
Equal to (
eq)Not equal to (
ne)In a set (
in)Contains a substring (
contains)Greater than (
gt)Less than (
lt)And (
and)Or (
or)Not (
not)
Note
Against a value, ne is the negation of eq: like not (...), it excludes items whose value is
absent, so significance ne 'key' and not (significance eq 'key') are equivalent. To match on
the presence or absence of a value, compare to null: <field> eq null matches items where the
field is unset, and <field> ne null matches items where it is set. The range operators le and
ge are not offered; use lt and gt.
Each field accepts only some of these operators. in takes a parenthesized, comma-separated list.
Nested attributes are filtered with dotted paths that mirror the response body (for example
process.name or locations.id). For controls the filterable fields are:
Field |
Operators |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The relationship fields subProcess, locations, systems, mitigatedRisks, programs and
activeTestingSignal support only a null comparison (eq null / ne null) to test presence or
absence; to match a specific related record, filter on its id (for example locations.id).
overriddenFields accepts either a standard field name or a custom field schema id, where in
matches controls overriding any of the listed fields and eq matches a single overridden field.
An unsupported field, or a supported field used with an operator it does not accept, is rejected
with 400.
$filter Examples#
$filter=significance eq 'key'
$filter=controlType eq 'standalone'
$filter=controlType in ('definition', 'instance')
$filter=name contains 'reconciliation' and significance eq 'key'
Example call using $filter#
curl -X GET "https://api.app.wdesk.com/controls" \
-G --data-urlencode "\$filter=significance eq 'key'" \
-H "Accept: application/json" \
-H "Authorization: Bearer {access-token}" \
-H "X-Version: 2026-09-01.grc.preview" \
-H "Wk-Workspace: {workspace-id}"
http GET https://api.app.wdesk.com/controls \
\$filter=="significance eq 'key'" \
Accept:application/json \
Authorization:"Bearer {access-token}" \
X-Version:2026-09-01.grc.preview \
Wk-Workspace:{workspace-id}
Sorting#
Use the $orderBy query parameter to control ordering. Provide one or more comma-separated
expressions of the form field [asc|desc]; asc is the default. The set of orderable fields
is a curated per-resource list, and an unsupported field is rejected with 400. For controls the
orderable fields are controlId, name, description, process.name, subProcess.name,
significance, frequency, automatedManual, preventiveDetective, and updatedAt. The other
resources order by name, and scoped controls by scopeStatus.
A cursor is only valid under the sort it was issued with, so do not change $orderBy partway
through pagination. Following the @nextLink from the previous response preserves the sort for
you.
$orderBy Example#
$orderBy=name asc
$orderBy=significance desc,name asc
$orderBy=updatedAt desc,controlId asc
Example call using $orderBy#
curl -X GET "https://api.app.wdesk.com/controls" \
-G --data-urlencode "\$orderBy=name asc" \
-H "Accept: application/json" \
-H "Authorization: Bearer {access-token}" \
-H "X-Version: 2026-09-01.grc.preview" \
-H "Wk-Workspace: {workspace-id}"