Pagination pattern defined and consistent

An API where /api/users uses cursor-based pagination and /api/orders uses offset/limit forces every consumer to write different pagination logic per endpoint. Worse, an endpoint with no pagination at all returns unbounded result sets that will eventually OOM the server or time out for large collections. iso-25010:2011 compatibility.interoperability is directly impacted: a generic list component cannot be built once and reused, and any SDK wrapping the API must special-case every list endpoint.

Define one pagination response shape as a generic type and apply it to every list endpoint:

interface PaginatedResponse<T> {
  data: T[]
  meta: {
    page: number
    limit: number
    total: number
    totalPages: number
  }
}

// Use identically across all list endpoints:
// GET /api/users?page=1&limit=20
// GET /api/orders?page=2&limit=10
// Same envelope, same parameter names

Enforce a maximum page size (100 items) server-side to prevent consumers from accidentally requesting unbounded results. See the query-param-naming check for consistent parameter naming across these endpoints.