The requests query — filters, pagination, and when to use it

How to filter, paginate, and choose between request (one Request) and requests (many Requests).

request vs requests

Use request when you already have id or uuid (for example after createCompensations). Use requests when you need lists, filters, or paged results (by ticket, status, dates, etc.).

Data scope

Results only include Requests for your organization. You cannot see another customer's Requests.

Pagination

Call requests with limit and offset.

Requests are returned in ascending order by id.

The response is a pagination object (not a plain array). Ask your client tooling for the exact type name from the schema; it includes:

• edges — each item has node (the Request) and a cursor
• pageInfo — includes total, hasNextPage, hasPreviousPage, perPage, totalPages, and cursor helpers

Use limit / offset to move through pages (for example: page size 20 → second page uses offset: 20).

Example — second page of 20:

query RequestsPage2 {
  requests(limit: 20, offset: 20, filter: { requestFilters: { runStatus: "PROCESSING" } }) {
    pageInfo {
      total
      hasNextPage
      hasPreviousPage
    }
    edges {
      node {
        id
        uuid
        ticketNumber
        runStatus
      }
    }
  }
}

Example — shape of the response:

{
  requests(limit: 20, offset: 0, filter: { ... }) {
    edges {
      cursor
      node {
        id
        uuid
        ticketNumber
        runStatus
      }
    }
    pageInfo {
      total
      hasNextPage
      hasPreviousPage
      perPage
      totalPages
      startCursor
      endCursor
    }
  }
}

Filters

Pass an optional filter with requestFilters:

filter: {
  requestFilters: {
    # filter fields — see below
  }
}

Available fields match the Request type (for example id, uuid, ticketNumber, runStatus, PNR fields, timestamps, linked ids). Use schema introspection (or your API explorer) for the full list and types on your environment.

How operators work

• Equal value: use the field name once, e.g. runStatus: "PROCESSING". (runStatus is the status field on Request.)
• Other operators: use fieldName_suffix, for example runStatus_in, ticketNumber_contains, persistedAt_gte. The schema lists the exact suffixes per field (strings vs numbers/dates differ slightly).

Logical groups: the filter input supports AND and OR arrays when you need grouped conditions.

Examples

Exact ticket (13 digits):

requestFilters: {
  ticketNumber: "1234567890123"
}

One status:

requestFilters: {
  runStatus: "PROCESSING"
}

Several statuses:

requestFilters: {
  runStatus_in: ["PROCESSING", "NEW"]
}

Numeric id range:

requestFilters: {
  id_gte: 1000
  id_lt: 2000
}

If you set several fields in the same requestFilters object, they are combined with AND. Use OR / AND when you need explicit OR logic.

No filter: omit filter (or use an empty requestFilters) to list Requests for your organization, still subject to limit / offset.

Full example

query MyRequests {
  requests(
    limit: 25
    offset: 0
    filter: {
      requestFilters: {
        ticketNumber: "1234567890123"
        runStatus_in: ["PROCESSING", "NEW"]
      }
    }
  ) {
    pageInfo {
      total
      hasNextPage
      perPage
      totalPages
    }
    edges {
      node {
        id
        uuid
        ticketNumber
        runStatus
        persistedAt
      }
    }
  }
}

Authentication

request and requests require authentication. See How to authenticate.

See also

• README.md — createCompensations and fetching a single Request with request.