Skip to main content

Collections

This page is about collections in the Journyx REST API. A collection is a group of resources of the same type, such as users, projects, or user time entry sheets.

See also the Collections tutorial

This is the main reference page about Collections in the Journyx API. There is also a Collections tutorial available which introduces the key concepts here in a more easily digestible format.

About collections​

Collections are the main way to pull data from the Journyx REST API, and offer ways to sort, filter (search) and select which fields are returned. In addition, collections are paginated, which means that only a certain number of resources are returned at a time. This helps both the client and server manage the amount of data being transferred.

Not all GET or data retrieval endpoints in the Journyx API are "collections" under this definition. For example, some endpoints are designed to retrieve data about a single object only, like /api/v1/users/<id_user>.

Also, there are some endpoints in the API to retrieve data that do not follow the collection conventions outlined here for various reasons. Either they are not paginated, or do not support filtering, or other reasons. In general, these endpoints are marked as "non-RESTful" in the API reference section.

Encoding the URL​

Most of the examples below are written in a plain non-encoded style which is easier to read and understand, but when you actually make a request to the API, you will need to encode the URL properly. This is especially important when dealing with special characters like spaces, quotes, and brackets.

Usually, programming languages provide facilities to encode URLs, and you will need to look up the documentation for the specific language or tool you are using to see how to do this. In general, you need to replace spaces with %20, double quotes with %22, and other special characters with their respective percent-encoded values. Other tools like Postman which are designed to work with APIs will usually handle this for you.

Examples of how to perform this encoding operation in Python and JavaScript are shown on the client programming tutorial page and also in the "Complex example" section below.

You must ensure that the entire URL, including the $filter, $orderBy, and other query parameters, are properly URL-encoded to prevent misinterpretation by the web server. Characters such as spaces, double quotes, and brackets must be percent-encoded.

  • Example:

    Unencoded filter:

    $filter=name contains "Alice"

    Encoded URL:

    GET https://example.apps.journyx.com/api/v1/users?$filter=name%20contains%20%22Alice%22

Pagination​

Pagination refers to the process of breaking up or slicing a large set of data into smaller chunks, or "pages". This is done to make it easier to manage and transfer large amounts of data, and to improve performance.

In the Journyx REST API, paginated collections use the following query parameters to control the slice of data returned:

  • $top - The number of resources to return in the current response (page).

    • In effect, this is the "page size" or the number of items (results) that will be returned in a single response.

    • If not specified, most endpoints have a default page size of 100.

    • In addition, most endpoints have a maximum page size of 1000, although both of these limits may vary and should be noted in the endpoint docs if different.

  • $skip - The number of resources to skip over in the collection in the current response.

    • In effect, this is like a "page number". If you're querying a collection with 50 total results, and a $top value of 10, and a $skip value of 0, you'll get the first 10 results. If you set $skip to 10, you'll get the next 10 results (results 11-20), and so on.

    • This will always default to 0 if not specified.

In the PagedResponse schema, returned by all collections, the $top and $skip values are included in the response to help you manage pagination.

In addition, the PagedResponse will show the $count value, which is the total number of resources in the collection. This can be used to calculate the number of pages in the collection, or the number of individual requests needed to retrieve all the data.

In order to assist you with moving through the pages of a collection, the PagedResponse also includes a @nextLink field. This is a URL that you can use to retrieve the next page of data in the collection. If there are no more pages, this field will not be present or may be null. The @nextLink includes any other query parameters, such as $skip as well as the current $filter. Please note there is currently no @previousLink supplied, but you can calculate this by subtracting the $top value from the $skip value.

Filtering​

Most collection endpoints support filtering or searching within the resources, although not necessarily using every possible field, especially those fields that are considered "extended" fields; mainly those that either belong to another related record, or else are computed values or other special cases. Most "base" fields belonging directly to an object can be filtered, although the distinction between these fields, and the list of fields available for filtering in general, is not well documented yet. To some extent you may have to use trial and error to determine which fields are filterable.

Filter basics​

In order to filter (search) within a collection, you must use the $filter query parameter. This parameter uses a simple query language that allows you to specify conditions that must be met by the resources returned. The syntax is described below and supports simple expressions, logical operators, and parentheses for grouping.

About JSON and string literals

Within the $filter query parameter, you must use JSON-style string literals for string values. This means that you must use double quotes (") around string values, not single quotes ('). For example, to filter for a user with the name "Alice", you would use the following syntax:

$filter=fullname contains "Alice"

The following with single-quotes would not work:

$filter=fullname contains 'Alice'

In addition, the overall URL including query parameters must be properly encoded, so that the double quotes are not misinterpreted by the web server. How to do this depends on the programming language or tool you are using to make the request. So, for example, a complete request URL might look something like:

GET https://example.apps.journyx.com/api/v1/users?$filter=fullname%20contains%20%22Alice%22

Constructing Filters​

The $filter query parameter allows you to refine the results returned by collection endpoints by specifying conditions that the resources must meet. This section provides a detailed guide on how to construct filters, including syntax rules, supported operators, data types, and examples.

A filter expression consists of three components:

  1. Field: The name of the field you want to filter on.

  2. Operator: Defines how the field should be compared to the value.

  3. Value: The value to compare the field against.

The general syntax is:

$filter=field operator value

  • Example:

    $filter=age gt 30

    This filter retrieves resources where the age field is greater than 30.

Supported Operators​

Operators are case-sensitive and must be used exactly as defined. In other words, you must spell the operators in lowercase as shown here.

Comparison Operators​

Used for numeric and string fields:

  • eq: Equal to

  • ne: Not equal to

  • gt: Greater than

  • ge: Greater than or equal to

  • lt: Less than

  • le: Less than or equal to

  • Example:

    $filter=salary ge 50000

    Retrieves resources where the salary field is greater than or equal to 50,000.

String Operators​

Used exclusively with string fields:

  • contains: Field contains the specified substring

  • startswith: Field starts with the specified substring

  • endswith: Field ends with the specified substring

  • Example:

    $filter=fullname contains "Smith"

    Retrieves resources where the fullname field contains "Smith".

String operators are case-insensitive

Note that when using string operators like contains, startswith, and endswith, the comparison is case-insensitive. This means that the search is not sensitive to the case of the characters in the field value. In the example above, it would match records like "SMITH", "Smith", "smith", etc.

Iterable Operators​

Used with lists and strings:

  • in: Field value is in the specified list
  • notin: Field value is not in the specified list
  • intersects: Field value intersects with the specified list

When using iterable operators, the value must be a JSON-encoded array.

  • Example:

    $filter=id in ["123", "456", "789"]

    Retrieves resources where the id field is either "123", "456", or "789".

Logical Operators and Grouping​

You can combine multiple filter expressions using logical operators and group them using parentheses to control the order of evaluation.

Logical Operators​

Logical operators are not case-sensitive, which means they can be any mix of uppercase and lowercase letters:

  • and: Both conditions must be true

  • or: At least one condition must be true

  • Example:

    $filter=status eq "active" and age lt 30

    Retrieves resources where status is "active" and age is less than 30.

Grouping with Parentheses​

Use parentheses () to group expressions. You can use nested groups of parentheses to create complex filter expressions.

  • Example:

    $filter=(department eq "Sales" or department eq "Marketing") and status eq "active"

    Retrieves resources that are in the "Sales" or "Marketing" department and have a status of "active".

  • Example

    $filter=(
        (department eq "Sales" or department eq "Marketing") and (status eq "active")
        or
        (department eq "Development" and status eq "inactive")
      )

    The above example uses nested parentheses to create a more complex filter expression where we find active users in Sales or Marketing, or inactive users in Development.

Data Types and Value Literals​

The value in a filter expression must match the data type of the field you're filtering on.

String Values​

  • Must be enclosed in double quotes " following JSON encoding rules.

  • Single quotes ' are not accepted.

  • Correct:

    $filter=city eq "New York"

  • Incorrect:

    $filter=city eq 'New York'

Numeric Values​

  • Use unquoted numbers.

  • Example:

    $filter=quantity gt 100

Boolean Values​

  • Use true or false without quotes.

  • Example:

    $filter=isActive eq true

Lists (Arrays)​

  • Must be JSON-encoded arrays.

  • Use square brackets [] and double quotes for string elements.

  • Example:

    $filter=role in ["admin", "editor"]

Examples of Filter Expressions​

Filtering by String Fields​

  • Contains:

    $filter=description contains "urgent"

    Retrieves resources where description contains "urgent".

  • Starts With:

    $filter=title startswith "Annual"

    Retrieves resources where title starts with "Annual".

  • Ends With:

    $filter=fileName endswith ".pdf"

    Retrieves resources where fileName ends with ".pdf".

Filtering by Numeric Fields​

  • Greater Than or Equal To:

    $filter=score ge 85

    Retrieves resources where score is greater than or equal to 85.

  • Less Than:

    $filter=duration lt 60

    Retrieves resources where duration is less than 60.

Combining Multiple Conditions​

  • AND Operator:

    $filter=category eq "electronics" and price lt 500

    Retrieves electronic items priced under 500.

  • OR Operator:

    $filter=status eq "pending" or status eq "in_review"

    Retrieves resources where status is either "pending" or "in_review".

  • Complex Grouping:

    $filter=(type eq "full-time" or type eq "part-time") and location eq "Remote"

    Retrieves full-time or part-time positions that are remote.

Using Iterable Operators​

  • IN Operator:

    $filter=department in ["HR", "Finance", "IT"]

    Retrieves resources where department is either "HR", "Finance", or "IT".

  • NOT IN Operator:

    $filter=region notin ["North", "South"]

    Retrieves resources where region is neither "North" nor "South".

  • INTERSECTS Operator:

    $filter=tags intersects ["urgent", "high_priority"]

    Retrieves resources that have at least one tag from the list.

Important Notes on Filters​

  • Field Availability: Not all fields may support filtering. Fields that are "extended," computed, or belong to related records might not be filterable.

  • Operators Are Case-Sensitive: Operators like eq, gt, contains, etc., must be in lowercase.

  • Logical Operators Are Not Case-Sensitive: and, or can be used in any case (e.g., AND, And, and).

  • No Support for not Operator: The unary not operator is currently not supported.

  • JSON Objects Not Supported: Value literals cannot be JSON objects (dictionaries). Only strings, numbers, booleans, and arrays of these types are allowed.

  • Error Handling: If an invalid filter is provided, the API will return a FilterError. Ensure all parts of your filter are correctly formatted.

Tips for Constructing Filters​

  • Verify Field Names: Use exact field names as defined in the resource. Field names are case-sensitive.

  • Match Data Types: Ensure the value's data type matches the field's data type.

  • Use Proper JSON Encoding: All string values must be double-quoted. Arrays must be JSON-encoded.

  • Test Your Filters: If unsure whether a field is filterable, you may need to use trial and error.

  • Handle URL Encoding: Always URL-encode your filter strings to ensure they are transmitted correctly.

Common Mistakes to Avoid in Filtering​

  • Using Single Quotes: Do not use single quotes around string values.

    • Incorrect:

      $filter=name eq 'Alice'

  • Misusing Operators: Ensure you're using the correct operator for the data type.

    • Using contains with numeric fields is invalid.

  • Unencoded Characters: Forgetting to URL-encode special characters can lead to errors.

  • Invalid Field Names: Attempting to filter on non-existent or unsupported fields.

Future Enhancements​

  • Extended Field Filtering: Support for filtering on extended fields may be added in future updates.

  • Additional Operators: Operators like not may be supported in the future.

  • Nested Filtering: Enhanced filtering capabilities on nested properties and related records.

Sorting​

The $orderBy query parameter allows you to specify the order in which resources are returned from collection endpoints. This section shows how to use $orderBy to sort results based on one or more fields, including specifying sort directions and handling case sensitivity.

Basic $orderBy Syntax​

A sort expression consists of the field name you want to sort by, optionally followed by the sort direction.

The general syntax is:

$orderBy=field_name [direction]

  • field_name: The name of the field you want to sort by.

  • direction (optional): The sort direction, either asc for ascending or desc for descending. If omitted, the default is ascending (asc).

  • Example:

    $orderBy=lastName

    This sorts the results in ascending order based on the lastName field.

Specifying Sort Direction​

You can specify the sort direction for each field:

  • Ascending Order: Use asc or omit the direction.
  • Descending Order: Use desc.

The direction is not case-sensitive. You can specify it as ASC, Asc, DEsc, etc.

  • Examples:

    • Ascending:

      $orderBy=firstName asc

    • Descending:

      $orderBy=createdDate desc

Sorting on Multiple Fields​

You can sort by multiple fields by separating each sort expression with a comma. The sorting is performed in the order the fields are specified.

  • Syntax:

    $orderBy=field1 [direction],field2 [direction],...

  • Example:

    $orderBy=department asc,lastName desc

    This sorts the results first by department in ascending order, and then by lastName in descending order within each department.

Case Sensitivity​

By default, string sorting is case-insensitive. That means uppercase and lowercase letters are treated as the same when sorting. However, you can specify case-sensitive sorting if needed.

  • Case-Insensitive Sorting: Default behavior.

  • Case-Sensitive Sorting: Append _cs to the sort direction.

  • Syntax:

    • Case-Insensitive Ascending: asc (default)
    • Case-Insensitive Descending: desc
    • Case-Sensitive Ascending: asc_cs
    • Case-Sensitive Descending: desc_cs

  • Examples:

    • Case-Insensitive:

      $orderBy=title asc

    • Case-Sensitive:

      $orderBy=title asc_cs

Examples​

Sorting by a Single Field​

  • Ascending Order:

    $orderBy=age

    Sorts results by age in ascending order.

  • Descending Order:

    $orderBy=salary desc

    Sorts results by salary in descending order.

Sorting by Multiple Fields​

  • Example:

    $orderBy=department asc,joiningDate desc

    Sorts results first by department in ascending order, then by joiningDate in descending order within each department.

Case-Sensitive Sorting​

  • Ascending Order:

    $orderBy=firstName asc_cs

    Sorts results by firstName in ascending order, considering case differences.

  • Descending Order:

    $orderBy=lastName desc_cs

    Sorts results by lastName in descending order, considering case differences.

Complex Sorting Example​

  • Example:

    $orderBy=category asc,priority desc_cs,createdDate
    • Sorts by category in ascending order (case-insensitive).
    • Within each category, sorts by priority in descending order (case-sensitive).
    • Within each priority level, sorts by createdDate in ascending order (default).

Important Notes on Sorting​

  • Field Names: Must use exact field names as defined in the resource. Field names are case-sensitive.

  • Sort Direction Defaults to Ascending: If no direction is specified, the default sort order is ascending (asc).

  • Fields available for sorting: Most "base" fields that belong directly to an object are available for sorting. Extended fields, computed fields, or related fields may or may not be available for sorting. If a field is unavailable for sorting or filtering, any request that uses those fields will generate a 400 Bad Request response.

  • Nested Properties: To sort by a nested property, use dot notation.

    • Example:

      $orderBy=address.city asc

      Sorts by the city property within the address object. However, it's important to note that not all endpoints support nested property sorting on all possible fields.

Tips for Constructing Sort Parameters​

  • Specify Multiple Fields for Fine-Grained Control: When sorting results that may have identical values in one field, specifying additional fields helps to determine the exact order.

    • Example:

      $orderBy=status asc,priority desc,createdDate asc

  • Use Case Sensitivity When Necessary: If your data requires distinguishing between uppercase and lowercase letters, use the _cs suffix.

  • Consider Default Sorting: If no $orderBy parameter is provided, the API may use a default sort order, but it is not guaranteed to be useful. It's best to specify your desired sort order explicitly.

Common Mistakes to Avoid in Sorting​

  • Incorrect Sort Direction Syntax: Ensure you use asc, desc, asc_cs, or desc_cs correctly.

    • Incorrect:

      $orderBy=name ascending

    • Correct:

      $orderBy=name asc

  • Misspelling Field Names: Double-check field names for typos.

  • Ignoring Case Sensitivity: Be aware that field names are case-sensitive, but sort directions are not.

  • Not URL-Encoding the Query: Remember to URL-encode the entire query string to avoid issues with special characters.

    • Example:

      GET https://example.apps.journyx.com/api/v1/users?$orderBy=lastName%20asc

Selecting fields​

Aside from pagination, filtering, and sorting the results, the other major operation common to collection is selecting which fields to return.

You can do this with the $keys query parameter. This selects which fields, or keys, are returned in the response. This can be useful if you only need a subset of the fields, or if you want to reduce the amount of data being transferred. However, it does not currently offer fine-grained control over the exact fields being returned. Certain "base" fields are always returned no matter what. The $keys parameter is mainly used to turn on additional or "extended" fields that may be more expensive to look up or compute, and so are not returned by default.

If you do not specify $keys, a default set of fields is returned, which often corresponds to the "base" fields but may sometimes include some additional fields.

If there are additional fields available that you want to see, especially in the *_properties sub-keys, that are not returned by default, you may need to specify those fields in the $keys parameter.

In addition to directly naming the fields, as shown in the examples below, there are a few special keywords recognized by the $keys parameter:

  • $base - this selects the minimal possible set of fields to return, and therefore offers the highest performance. As the name suggests, this returns "base" fields that are directly part of the object or resource in question.

  • $extended - this selects the maximum possible set of fields to return, and therefore will be less performant. This returns all available extended fields and Custom Fields, with a few exceptions. Some individual endpoints may note that there are certain keys that must be requested manually and are not included in the $keys=$extended selector due to their especially high computation cost.

    In these cases, you can select the additional fields with a syntax like this:

    $keys=$extended,actual_hours

    That would select all extended fields, plus the actual_hours field.

Field selection examples​

  • Selecting a single field:

    $keys=firstName

    This will return only the firstName field in the response.

  • Selecting multiple fields:

    $keys=firstName,lastName,email

    This will return only the firstName, lastName, and email fields in the response.

  • Selecting all base fields:

    $keys=$base

    This will return only the base fields in the response.

  • Selecting all extended fields:

    $keys=$extended

Putting it all together​

In this section, we'll demonstrate how to combine pagination, filtering, sorting, and selecting fields in a single API request. We'll also revisit the importance of URL encoding when constructing complex query parameters.

Complex Example​

Suppose you want to retrieve a list of users who are active employees in the "Engineering" or "Product" departments, sorted by last name in ascending order, then by first name in ascending order. You only need their id, firstName, lastName, and email fields. You also want to retrieve the first 50 records, skipping the first 100 records (i.e., getting the third page of results with a page size of 50).

Here's how you can construct the request using the various query parameters:

Unencoded Query​

GET https://example.apps.journyx.com/api/v1/users?
    $filter=(status eq "active") and (department eq "Engineering" or department eq "Product")&
    $orderBy=lastName asc,firstName asc&
    $keys=id,firstName,lastName,email&
    $top=50&
    $skip=100

Let's break down each part of this request:

  • $filter: Filters users who have a status of "active" and whose department is either "Engineering" or "Product".

    $filter=(status eq "active") and (department eq "Engineering" or department eq "Product")

  • $orderBy: Sorts the results first by lastName in ascending order, then by firstName in ascending order.

    $orderBy=lastName asc,firstName asc

  • $keys: Indicate that the id, firstName, lastName, and email fields need to be returned in the response. Note: currently, this does not ensure only these fields are returned. You can also set $keys=$base or $keys=$extended to return only the base or extended fields, respectively.

    $keys=id,firstName,lastName,email

  • $top and $skip: Implements pagination by retrieving 50 records ($top=50) and skipping the first 100 records ($skip=100).

    $top=50
    $skip=100

URL Encoding​

When making the actual API request, you must ensure that the entire URL is properly URL-encoded. Special characters such as spaces, parentheses, double quotes, and commas need to be percent-encoded.

Here's the encoded URL:

GET https://example.apps.journyx.com/api/v1/users?%24filter=%28status%20eq%20%22active%22%29%20and%20%28department%20eq%20%22Engineering%22%20or%20department%20eq%20%22Product%22%29&%24orderBy=lastName%20asc%2CfirstName%20asc&%24keys=id%2CfirstName%2ClastName%2Cemail&%24top=50&%24skip=100

Let's break down how each part of the query string is encoded:

  • $filter:

    • Spaces are encoded as %20.

    • Parentheses ( and ) are encoded as %28 and %29, respectively.

    • Double quotes " are encoded as %22.

    • The entire $filter parameter becomes:

      %24filter=%28status%20eq%20%22active%22%29%20and%20%28department%20eq%20%22Engineering%22%20or%20department%20eq%20%22Product%22%29

  • $orderBy:

    • The comma , is encoded as %2C.

    • Spaces are encoded as %20.

    • The $orderBy parameter becomes:

      %24orderBy=lastName%20asc%2CfirstName%20asc

  • $keys:

    • Commas are encoded as %2C.

    • The $keys parameter becomes:

      %24keys=id%2CfirstName%2ClastName%2Cemail

  • $top and $skip:

    • These parameters do not contain special characters and can remain as is, except that the $ sign should be encoded as %24.

    • The $top parameter becomes:

      %24top=50

    • The $skip parameter becomes:

      %24skip=100

Final Encoded URL​

Combining all the encoded parameters, the full URL is:

GET https://example.apps.journyx.com/api/v1/users?%24filter=%28status%20eq%20%22active%22%29%20and%20%28department%20eq%20%22Engineering%22%20or%20department%20eq%20%22Product%22%29&%24orderBy=lastName%20asc%2CfirstName%20asc&%24keys=id%2CfirstName%2ClastName%2Cemail&%24top=50&%24skip=100

Alternatively, you can use a URL encoding function provided by your programming language or tool to automatically encode the query parameters.

Example in Python​

Here's how you might construct and encode this URL using Python's urllib.parse module:

import urllib.parse
import json

base_url = 'https://example.apps.journyx.com/api/v1/users'

# Define the values
status_value = "active"
department_values = ["Engineering", "Product"]

# Use json.dumps to JSON-encode string literals
filter_expression = f'(status eq {json.dumps(status_value)}) and (department eq {json.dumps(department_values[0])} or department eq {json.dumps(department_values[1])})'

params = {
    '$filter': filter_expression,
    '$orderBy': 'lastName asc,firstName asc',
    '$keys': 'id,firstName,lastName,email',
    '$top': '50',
    '$skip': '100'
}

# URL-encode the query parameters
encoded_params = urllib.parse.urlencode(params, safe='(),')

full_url = f"{base_url}?{encoded_params}"

print(full_url)

This would output:

https://example.apps.journyx.com/api/v1/users?%24filter=%28status+eq+%22active%22%29+and+%28department+eq+%22Engineering%22+or+department+eq+%22Product%22%29&%24orderBy=lastName+asc%2CfirstName+asc&%24keys=id%2CfirstName%2ClastName%2Cemail&%24top=50&%24skip=100

The above example also illustrates the need to properly JSON-encode string literals in the $filter parameter. The json.dumps function is used to ensure that the string values are properly quoted and escaped. There are multiple JSON encoding libraries and techniques available in Python; the above is just one example.

Example in JavaScript​

Using JavaScript's encodeURIComponent function:

const baseUrl = "https://example.apps.journyx.com/api/v1/users"

const statusValue = "active"
const departmentValues = ["Engineering", "Product"]

// Use JSON.stringify to JSON-encode string literals
const filterExpression = `(status eq ${JSON.stringify(statusValue)}) and (department eq ${JSON.stringify(departmentValues[0])} or department eq ${JSON.stringify(departmentValues[1])})`

const params = {
  $filter: filterExpression,
  $orderBy: "lastName asc,firstName asc",
  $keys: "id,firstName,lastName,email",
  $top: "50",
  $skip: "100",
}

// Encode the query parameters
const queryString = Object.keys(params)
  .map((key) => encodeURIComponent(key) + "=" + encodeURIComponent(params[key]))
  .join("&")

const fullUrl = `${baseUrl}?${queryString}`

console.log(fullUrl)

This would output:

https://example.apps.journyx.com/api/v1/users?%24filter=%28status%20eq%20%22active%22%29%20and%20%28department%20eq%20%22Engineering%22%20or%20department%20eq%20%22Product%22%29&%24orderBy=lastName%20asc%2CfirstName%20asc&%24keys=id%2CfirstName%2ClastName%2Cemail&%24top=50&%24skip=100

As with the Python example, this JavaScript example uses JSON.stringify to properly encode string literals in the $filter parameter. The encodeURIComponent function is then used to encode the query parameters.

Making the Request​

With the properly encoded URL, you can now make a GET request to the API endpoint. Here's an example using curl:

curl -X GET "https://example.apps.journyx.com/api/v1/users?%24filter=%28status%20eq%20%22active%22%29%20and%20%28department%20eq%20%22Engineering%22%20or%20department%20eq%20%22Product%22%29&%24orderBy=lastName%20asc%2CfirstName%20asc&%24keys=id%2CfirstName%2ClastName%2Cemail&%24top=50&%24skip=100" \
     -u "username:password"

Interpreting the Response​

The API will return a PagedResponse containing the requested user data, along with pagination metadata such as @nextLink, $top, $skip, and $count. Since you've specified $keys, only the id, firstName, lastName, and email fields will be included for each user.

Summary​

Remember to:

  • Use json.dumps in Python or JSON.stringify in JavaScript for encoding string literals, or the equivalent in your programming language, when building the $filter parameter.

  • URL-encode the entire query string to handle special characters.

  • Test your queries to ensure they return the expected results.

This approach helps you build robust API requests that effectively combine pagination, filtering, sorting, and field selection to efficiently retrieve exactly the data you need from the Journyx REST API.