Back to API Practice

Interactive API trainer

Pagination API Testing Practice

Send fake paginated API requests, inspect cursor responses, then write what you would test for stable ordering, boundaries, consistency, permissions, and production reliability.

How to use this trainer

Choose, send, inspect, write, improve

Safe client-side simulator. No real backend is called and no real data is sent.

  1. 1Choose a preset case
  2. 2Send a simulated request
  3. 3Read the response and QA note
  4. 4Write what you would test
  5. 5Check your coverage

Interactive sandbox

Try the API request

Edit query parameters, choose auth conditions, send a simulated GET /api/items request, and inspect cursor pagination behavior. No real data is sent.

Request

Build the paginated request

GET/api/items?pageSize=3&sort=createdAt:desc

Test case presets

Choose a case, inspect the fake response, then write what you would test.

Happy path

Validation / cursor

Auth / reliability

Response

Fake API result

Send a simulated request to see the HTTP status, JSON response, QA note, and the pagination risks this case should make you mention in your answer.

List first, middle, last, and empty pages; page-size boundaries; malformed and expired cursors; stable ordering; duplicates/skips; filters; permissions; performance; logs; metrics; and reliability.

Tip: a stronger answer usually mixes happy path, negative cases, state changes, data, backend, UX, accessibility, and risk.

How to structure your answer

Happy pathNegative casesData rulesSecurity/API risksUX/performance
API ReferenceEndpoint, request fields, responses, and business rulesExpand

API reference

Pagination endpoint

Use this reference while you experiment with cursor, page size, sorting, and auth conditions.

Endpoint

GET/api/items

Purpose

Return a stable, permission-filtered page of items with cursor metadata.

Authentication

Bearer token required for tenant-scoped data.

Success response

200 OK

Query fields

  • pageSize: integer, optional, default 20, max 100
  • cursor: opaque string, optional
  • sort: createdAt:desc by default
  • filter: optional status or owner filters

Success response body

{
  "items": [
    {
      "id": "itm_101",
      "name": "Alpha",
      "createdAt": "2026-07-16T09:00:00Z"
    }
  ],
  "pagination": {
    "nextCursor": "cur_middle_123",
    "hasMore": true,
    "pageSize": 20
  }
}

Errors

  • 400 invalid pageSize or malformed cursor
  • 401 missing or expired token
  • 410 expired cursor if the contract uses cursor expiry
  • 429 too many pagination requests
  • 503 database/search service unavailable

Business rules

  • default page size is applied when pageSize is omitted
  • pageSize must stay within documented minimum and maximum
  • cursor values are opaque and may expire
  • same filters and sort must be used with a cursor
  • ordering must remain stable across page requests
  • items must not duplicate or disappear between pages
  • tenant and permission boundaries apply to every page
  • large datasets must meet the response-time SLA

API interview guide

What this Pagination API practice covers

This scenario trains list endpoint testing where page size, cursors, ordering, filtering, permissions, and metadata must stay stable across large datasets.

Key risks covered

  • - First page, middle page, last page, empty dataset, and out-of-range requests.
  • - Page size limits, invalid cursors, malformed parameters, and stable sort order.
  • - Response schema with items, next cursor, total counts, and pagination metadata.
  • - Permission-filtered results and tenant-scoped list behavior.
  • - Performance for large lists, concurrent data changes, caching, and rate limiting.

Example interview prompt

How would you test a paginated GET endpoint that returns users with cursor or page metadata?

Common mistakes

  • - Only testing page one.
  • - Missing empty, last, invalid cursor, and page-size boundary cases.
  • - Not checking stable ordering, permissions, metadata, or large dataset performance.