Querying Object-Level GraphQL APIs

Each object has its own GraphQL endpoint derived from the API name defined during object creation, and it becomes available once the Application Group is deployed. Users can select the respective object API from the left-side panel to run queries and retrieve the required fields.

Querying Object Records

Fetching Records

Using GraphQL API created for object, users can retrieve records stored within an object.

• Responses are returned in a structured json format.

• Users can select specific fields (nodes) to include in the response.

• Related or nested fields (edges) can also be queried, where applicable.

Capabilities include:

• Fetching only required fields

• Retrieving related or nested data

• Avoiding over-fetching unnecessary information

Example:

On selecting the object from the explorer a query is formed in the query editor as follows-

query MyQuery {
    standardObj_API
}

After clicking Run, the query is executed and the results are displayed in JSON format. While constructing the query, users can select only the required nodes (fields) from the object.

Filtering and Conditions

Users can refine query results using both filters and conditions.

Conditions

• Apply filters directly on object fields

• Limit results based on specific field values

• Narrow down large datasets efficiently

Example:

For an object, select Condition, choose the required field, and enter the corresponding value as needed to refine the query results.

query MyQuery {
  standardObj_API(condition: {age: 22, name: "value_1"})
}

Filters

• Define logical criteria (e.g., AND / OR combinations)

• Combine multiple rules to control query results

• Retrieve records that meet complex business logic

Example:

For an object, select Filter, choose the required fields, apply conditions to those fields, and combine multiple conditions as needed to refine the query results.

query MyQuery {
  standardObj_API(
    filter: {age: {greaterThan: 22}, and: {name: {notEqualTo: "so_4"}}}
  )
}

Using filters and conditions ensures that only relevant records are returned based on defined query logic.

Pagination

To efficiently manage large datasets, pagination is supported.

• Use limit to control the number of records returned

• Use offset to skip records

Pagination improves performance and enables controlled data retrieval.

Example:

For an object, select pageInfo and specify the first value to define the number of records to be returned in a single execution. After running the query, note the endCursor value from the response, then use this value in the after parameter to retrieve the next set of records. Also select the required fields needed to be displayed from nodes.

query MyQuery {
  standardObj_API(first: 2, after: "WyJwcmltYXJ5X2tleV9hc2MiLFs0XV0=") {
    pageInfo {
      startCursor
      endCursor
    }
    edges {
      node {
        age
        name
        standardObj_id
      }
    }
  }
}

Sorting

Query results can be ordered based on object fields.

• Sort in ascending or descending order

• Order data based on business requirements (e.g., created date, name, status)

Example:

For an object, select orderBy, choose the required fields, from the dropdown and execute.

query MyQuery {
  standardObj_API(orderBy: age_asc)
}

Record Count

The API allows users to request the total count of records stored in an object.

This is useful for:

• Pagination calculations

• Dashboard metrics

• Displaying summary information

Example:

For an object, select totalCount, and execute the query

query MyQuery {
  standardObj_API {
    totalCount
  }
}

Querying Historical Object Data

Historical objects store time-aware data, meaning a single record may have different values based on its validity period. Supported historical object types include:

• Bitemporal

• Transaction Temporal

• Complete Snapshots

• Incremental Snapshots

To query historical data, users must provide the required bitemporal properties in the request headers (available in the bottom section of the screen). These headers determine the validity date used during query execution and ensure that the correct version of the record is returned.

If no validity information is provided, the system returns the current active version of the data.

Below is the Request Headers, here as_of_ts is as of date and valid_ts is the effective date. Here, as_of_ts should be set to present date and valid_ts should be set to effective date.

The following is the request header.

{
"biTemporalProps": "{ \"default\" : {\"as_of_ts\" : \"2026-02-11\",\"valid_ts\" : \"2026-12-31\"}}",
"graphqlOpType":"mutation"
}