Pagination

Most list fields in the Rad TV API return a Relay-style connection, not a bare array. You paginate with first / after / last / before and read rows from edges → node.

Why connections look different

A connection wraps the list so the API can expose pagination metadata (pageInfo, totalCount) and stable cursors alongside the actual items. Fields such as assets, metadata, and id live on each node (for example Feature, Channel), not on the connection object itself.

Connection shape

Every *Connection type exposes:

Field	Purpose
`edges`	Ordered list of `*Edge` objects
`pageInfo`	Whether more pages exist and cursor strings
`totalCount`	Approximate total count for the current filter (when available)

Each edge includes:

Field	Purpose
`cursor`	Opaque cursor for this row (use with `after` / `before`)
`node`	The actual object — query `assets`, `metadata`, etc. here

pageInfo includes hasNextPage, hasPreviousPage, startCursor, and endCursor.

Arguments

Argument	Type	Typical use
`first`	Int	Forward page size
`after`	String	Cursor from previous `pageInfo.endCursor`
`last`	Int	Backward page size (less common)
`before`	String	Cursor for backward pagination

Cursors are opaque. Treat them as strings from the API; do not construct them by hand.

Example — top-level `features`

{
  features(first: 10) {
    totalCount
    edges {
      cursor
      node {
        id
        metadata {
          title
          summary
        }
        assets {
          videos {
            url
            width
            height
          }
        }
      }
    }
    pageInfo {
      hasNextPage
      endCursor
    }
  }
}

Use pageInfo.endCursor as after in the next request to fetch the following page.

Example — nested on `channel`

{
  channel(id: "did:rad.live:channel/abc123") {
    id
    features(first: 5) {
      edges {
        node {
          id
          metadata { title }
        }
      }
      pageInfo {
        hasNextPage
        endCursor
      }
    }
  }
}

Empty results

If nothing matches, edges is an empty array. Your client should handle an empty list without assuming edges[0] exists.

Migrating from older examples

Some older snippets used offset-style arguments (limit, start) or queried list fields as if they returned [Feature] directly. The current schema uses connections for those lists. Replace:

features(limit: 10, start: 0) { id }

with:

features(first: 10) {
  edges { node { id } }
}

For more query names and types, see Catalog and Identity.

Comments on content and catalog types also use CommentConnection — same edges / node pattern. See Engagement.