Source: https://sprinto-test.docs-staging.pageloop.ai/api-reference/getting-started/pagination

# Pagination

The Sprinto Developer API uses **cursor-based pagination** to help you efficiently work with large datasets. Pagination allows you to fetch smaller, manageable subsets of data, improving response time and overall API performance.

Sprinto’s pagination model aligns with the **Relay Cursor Pagination specification**, making it predictable and easy to work with in GraphQL-based integrations.

For a hands-on experience, Sprinto recommends using the API Playground to explore paginated queries interactively.

---

### Important notes

- The Sprinto Developer API is currently in beta, and pagination behaviour may evolve as new features are introduced.
- API requests are rate-limited to **10 requests per minute**. Exceeding this limit results in an error response.
- Pagination parameters and response structures are enforced at the schema level.

---

### Pagination model

Sprinto uses **cursor-based pagination**, where each record is associated with a unique cursor. Instead of relying on page numbers, cursors allow you to reliably navigate forward and backward through a dataset.

This approach ensures consistency even when underlying data changes.

---

### Supported pagination arguments

The following pagination arguments are supported across paginated queries.

| Argument | Description                                                                            |
| -------- | -------------------------------------------------------------------------------------- |
| `first`  | Specifies the number of records to fetch in a single request.                          |
| `after`  | Fetches records that appear after the specified cursor. Used for forward navigation.   |
| `before` | Fetches records that appear before the specified cursor. Used for backward navigation. |

---

### Pagination response structure

Paginated responses follow a consistent structure based on connections and edges.

| Field        | Description                                                        |
| ------------ | ------------------------------------------------------------------ |
| `edges`      | A list representing individual records in the result set.          |
| `cursor`     | A unique identifier for each edge, used for pagination navigation. |
| `node`       | The actual data object returned by the API.                        |
| `totalCount` | The total number of records available for the query.               |

---

### Example: Paginated query

The following example retrieves the first five workflow checks that appear after a specific cursor.

#### Query

```javascript
query WorkflowChecksPaginated($first: Int, $after: String) {
  workflowChecksPaginated(first: 5, after: "dfsdfdscdsfsadcdsafasdcdsfcddsfc--00fdc") {
    edges {
      cursor
      node {
        title
      }
    }
    totalCount
  }
}
```

#### Response

```python
{
  "data": {
    "workflowChecksPaginated": {
      "edges": [
        {
          "cursor": "dsfasfsdfewrfdcdGRFGVSAVS=CV==",
          "node": {
            "title": "Periodic review of the users having access to Lokmat"
          }
        }
        // ... additional workflow checks
      ],
      "totalCount": 110
    }
  }
}
```

---

### How pagination works in practice

1. Use the `first` argument to define how many records you want to retrieve.
2. Extract the `cursor` value from the last edge in the response.
3. Pass that cursor value as the `after` argument in the next request to fetch the next set of records.
4. Repeat the process until all required records are retrieved.

For backward navigation, use the `before` argument with the cursor from the first edge in the current response.

---

### Next steps

After understanding pagination, you can:

- Combine pagination with filters and arguments for more precise queries
- Use pagination consistently when building reports or dashboards
- Explore paginated queries directly in the API Playground