Pagination
Traverse page-based catalog and search results.
GET /v1/search, GET /v1/movies, and GET /v1/series use one-based page pagination.
| Parameter | Default | Range | Behavior |
|---|---|---|---|
page | 1 | 1 to 1,000,000 | Selects the page using an offset of (page - 1) * limit. |
limit | 20 | 1 to 20 | Sets the number of titles returned. |
Both parameters are coerced from query strings and must resolve to integers. Unknown query parameters are rejected.
Page metadata
{
"meta": {
"request_id": "req_01J7EXAMPLE",
"page": 2,
"per_page": 20,
"total_results": 53,
"total_pages": 3
}
}Request the next page while meta.page < meta.total_pages. A page beyond the available results returns status 200 with an empty data array. An empty result set reports total_pages: 0.
let page = 1;
while (true) {
const response = await fetch(
`https://api.swipeformovie.com/v1/movies?page=${page}&limit=20`,
{ headers: { Authorization: `Bearer ${apiKey}` } },
);
if (!response.ok) throw new Error(`Request failed: ${response.status}`);
const result = await response.json();
for (const title of result.data) {
console.log(title.title);
}
if (result.meta.page >= result.meta.total_pages) break;
page += 1;
}Source documentation mismatch
The API service README still describes signed cursor pagination and a nextCursor field. The current routes, catalog service, tests, and OpenAPI implementation use page and limit with SQL offsets and reject cursor as an unknown parameter. This guide follows the executable implementation. Update the stale API README.
Consistency TODO
No snapshot or consistency guarantee is implemented. If catalog data changes between page requests, the source does not define whether callers can observe duplicate or skipped titles.