---
title: Pagination
slug: api-docs/pagination
docTags: 
createdAt: 2026-05-11T22:18:04.816Z
---

# Pagination

Conventions vary across modules and protocols. This page documents what's common and where exceptions live.

## REST list endpoints

Most REST list endpoints accept query params:

| Param    | Default     | Notes                                          |
| -------- | ----------- | ---------------------------------------------- |
| `offset` | 0           | Zero-indexed                                   |
| `limit`  | 50 (varies) | Max varies per endpoint; some allow up to 1000 |
| `sort`   | varies      | `field:asc` / `field:desc`                     |
| `filter` | none        | Endpoint-specific                              |

Response shape (typical):

```json
{
  "items": [ ... ],
  "total": 1234,
  "offset": 0,
  "limit": 50
}
```

Use `total` to know how many pages remain.

## GraphQL list operations

Most GraphQL list operations accept an `input` object:

```graphql
query {
  ListDevices(input: {
    Limit: 100,
    Offset: 0,
    Filter: { Name: { Contains: "PLC" } },
    Sort: [{ Field: "Name", Order: "ASC" }]
  }) {
    Items { ID Name }
    Total
  }
}
```

Field casing follows the operation's schema (LE DeviceHub uses PascalCase; LEM uses camelCase). Check the operation on `api.litmus.io` to confirm.

## LEM async-task subtasks

`GET /api/v1/async-task/{taskId}/subtasks` returns **all** subtasks - usually small, no pagination.

`GET /api/v1/async-task/subtasks` (cross-task history) accepts `from` / `to` timestamp filters; pagination via `offset` and `limit`.

## When in doubt

- The endpoint's example on `api.litmus.io` shows the actual parameter names and casing.
- Default limits are conservative - prefer pagination over assuming "all rows fit".
- For very large lists (e.g. tags across thousands of devices), filter at the source (`Filter` in GraphQL, query params in REST) instead of paginating the entire set.