Real‑world examples of using query parameters for pagination

The most common examples of using query parameters for pagination

If you scan public APIs from Stripe, GitHub, Twitter/X, and Shopify, you’ll notice something fast: almost everyone leans on query parameters for pagination. The best examples cluster into a few patterns:

• Page/size style: ?page=2&page_size=50
• Offset/limit style: ?offset=100&limit=25
• Cursor/limit style: ?cursor=abc123&limit=50
• Time‑based or ID‑based pagination: ?since_id=5000&limit=100
• Mixed patterns with filters and sorting

Let’s walk through real examples of examples of using query parameters for pagination, including how the responses look and why some patterns work better than others once your data hits millions of rows.

Classic page + size: simple examples of using query parameters for pagination

The friendliest example of pagination for front‑end developers is the classic page/size pattern:

GET /articles?page=3&page_size=20

In this example of query‑parameter pagination:

• page=3 means “give me the third page”
• page_size=20 means “20 results per page”

A typical JSON response might look like:

{
  "data": [ /* 20 article objects */ ],
  "page": 3,
  "page_size": 20,
  "total_items": 482,
  "total_pages": 25
}

This is one of the best examples when you’re building a UI with numbered pages: think admin dashboards, reporting tools, or any interface where users expect to click through pages 1, 2, 3, and so on.

Pros in practice

• Easy to reason about: designers, PMs, and devs all understand “page 3 of 25.”
• Works nicely with server‑side rendered tables and classic web apps.

Hidden downsides

Once your dataset grows, this example of pagination starts to hurt:

• Large page values often require the database to scan or skip a lot of rows.
• If data changes rapidly, page 3 might show different records between requests.

That’s why many 2024 APIs still support this pattern for convenience, but recommend cursor‑based pagination for anything that needs performance or strict ordering.

Offset + limit: SQL‑friendly examples of using query parameters for pagination

If you’ve written SQL like LIMIT 20 OFFSET 40, you’ve basically used the offset/limit style. In API form, one of the cleanest examples of using query parameters for pagination looks like this:

GET /products?offset=40&limit=20

In this request:

• offset=40 means “skip the first 40 records”
• limit=20 means “return up to 20 records”

The response might include metadata to help the client:

{
  "data": [ /* 20 product objects */ ],
  "offset": 40,
  "limit": 20,
  "next_offset": 60,
  "total": 937
}

Many developers consider this one of the best examples for internal APIs because it maps almost directly to SQL and is trivial to implement.

Where this shines

• Analytics or reporting APIs where you need arbitrary jumping, like offset=10000.
• Back‑office tools where performance is acceptable and correctness matters more than cutting‑edge scalability.

Where it falls short

Offset‑based examples of pagination break down at scale:

• Large offsets can get expensive: the database still has to walk a lot of rows to reach offset=100000.
• As rows are inserted or deleted, the same offset might return different items over time.

This is why many API design guides now nudge developers toward cursor‑based pagination. For a deeper discussion of offset performance in databases, you can look at resources like PostgreSQL documentation.

Cursor‑based: modern examples of using query parameters for pagination

Cursor‑based pagination is the workhorse of modern, high‑volume APIs. Instead of asking for “page 3,” the client says, “Start from this specific position.” A typical example of using query parameters for pagination with cursors looks like this:

GET /events?limit=50

The first call might return:

{
  "data": [ /* 50 events */ ],
  "limit": 50,
  "next_cursor": "eyJpZCI6IDEwMDB9"
}

The client then fetches the next set using the cursor:

GET /events?limit=50&cursor=eyJpZCI6IDEwMDB9

Here, cursor is an opaque token—often a base64‑encoded pointer to the last record or sort key. The client doesn’t need to understand it; it just passes it back.

Why this pattern dominates 2024 APIs

Real examples include:

• Stripe’s API, which uses starting_after and ending_before style cursors
• GitHub’s GraphQL API, which uses after and before cursors
• Many social feeds, where new items are constantly being added

These examples of examples of using query parameters for pagination are popular because:

• They scale better with large datasets.
• They produce more stable results when data changes between requests.
• They work naturally with strict ordering (by ID, timestamp, or custom key).

The trade‑off: they’re slightly harder to implement and test, and harder for humans to reason about than “page 3.” But if you care about performance and consistency, cursor‑based patterns are usually the best examples to copy.

Time‑based examples: pagination with since, until, and timestamps

Some APIs don’t talk about pages at all. Instead, they paginate over time. A common example of using query parameters for pagination in logging or audit APIs looks like this:

GET /logs?since=2024-11-01T00:00:00Z&until=2024-11-01T23:59:59Z&limit=100

Another variant for incremental syncs is:

GET /orders?updated_after=2024-11-01T00:00:00Z&limit=200

This style is especially common in integrations and ETL pipelines where the client wants “everything changed since last time.”

These examples include some important design choices:

• Use ISO 8601 timestamps in UTC.
• Combine time filters with limit so responses stay bounded.
• Return a next_since or next_cursor value so clients can resume efficiently.

This pattern shows up in health, finance, and government APIs that need predictable, auditable data access. For instance, many public data APIs exposed by agencies like the U.S. Census Bureau use query parameters to filter and slice large datasets over time.

Mixed filters + pagination: real examples from everyday APIs

In real applications, pagination rarely lives alone. You almost always combine it with filters and sorting. Consider this example of using query parameters for pagination on a search endpoint:

GET /search?q=wireless+headphones&sort=price_asc&page=2&page_size=25

Here you have:

• q for the search query
• sort for ordering
• page and page_size for pagination

Another example from a typical SaaS dashboard might look like:

GET /users?status=active&role=admin&created_after=2024-01-01&limit=50&cursor=YWJjMTIz

This mixes:

• Filters (status, role, created_after)
• Cursor‑based pagination (limit, cursor)

These mixed patterns are some of the best examples of real‑world design because they match how people actually query data. The trick is to keep the pagination parameters predictable:

• Use consistent names (page + page_size, or offset + limit, or cursor + limit).
• Don’t silently switch styles between endpoints.

When teams ignore this, clients end up juggling three different styles of pagination in the same API, which is a quiet form of technical debt.

API response metadata: examples of helpful pagination fields

Query parameters are only half the story. The response needs to tell clients how to keep going. Here are real examples of what APIs return alongside data:

{
  "data": [ /* items */ ],
  "page": 4,
  "page_size": 25,
  "total_items": 1234,
  "total_pages": 50,
  "has_next": true,
  "has_previous": true
}

For cursor‑based patterns, examples include:

{
  "data": [ /* items */ ],
  "limit": 100,
  "next_cursor": "c3RhcnRfYWZ0ZXJfaWQ9MTAwMA==",
  "previous_cursor": null
}

These examples of examples of using query parameters for pagination show a few best practices:

• Tell the client if there is a next or previous page (has_next, next_cursor).
• Avoid forcing the client to recompute offsets; give them direct links or tokens.
• Keep cursors opaque so you can change the implementation later.

Some hypermedia‑oriented APIs even add links objects:

{
  "data": [ /* items */ ],
  "links": {
    "self": "/articles?page=2&page_size=20",
    "next": "/articles?page=3&page_size=20",
    "prev": "/articles?page=1&page_size=20"
  }
}

This pattern lines up with the broader REST and HATEOAS discussions you’ll find in university and standards‑focused materials, such as REST tutorials from institutions like Harvard and other .edu resources discussing web architecture and API design.

Rate limiting meets pagination: defensive examples for 2024–2025

In 2024 and 2025, rate limiting and pagination are tightly connected. Cloud providers and large platforms are increasingly strict about request budgets, which means bad pagination design can burn through your limits fast.

Consider two examples of using query parameters for pagination against a rate‑limited API:

GET /transactions?limit=100
GET /transactions?limit=10

If the API allows up to 10,000 items per minute, the first example of pagination lets you fetch that in 100 calls. The second needs 1,000 calls, which is far more likely to hit a rate limit.

Well‑designed APIs often:

• Document safe limit ranges (for example, 1–100 per page).
• Encourage clients to pick a stable, moderate limit and reuse cursors.
• Return rate‑limit headers (like X-RateLimit-Remaining) so clients can throttle themselves.

You see this pattern in health and research APIs where data volume is high but responsible access is non‑negotiable. For instance, NIH and CDC APIs that expose large datasets often combine pagination with guidelines on safe request patterns. While those APIs are domain‑specific, the examples of pagination behavior apply broadly across industries.

Practical design tips with real examples

Putting these examples together, here’s how teams usually decide which style to adopt in 2024–2025:

• Internal tools and small datasets often use page/size or offset/limit. Example:

  GET /internal-reports?page=1&page_size=50
  

• Public, high‑traffic APIs lean toward cursor‑based patterns. Example:

  GET /public-feed?limit=25&cursor=ZjEyMzQ1
  

• Data sync and ETL APIs frequently use time‑based filters. Example:

  GET /records?updated_after=2024-10-01T00:00:00Z&limit=500
  

When you evaluate examples of examples of using query parameters for pagination, ask three blunt questions:

1. How big will this dataset get in the next 2–3 years?
2. How fast does it change?
3. Do clients need numbered pages, or just “next” and “previous”?

Your answers will usually push you toward one of the patterns we’ve just walked through.

FAQ: common questions and examples

Q: What are some simple examples of using query parameters for pagination in a REST API?
A: A straightforward example of pagination is:

GET /posts?page=1&page_size=20

or, in offset form:

GET /posts?offset=0&limit=20

Both are easy to implement and explain, which is why they show up in a lot of tutorials and starter projects.

Q: Can I mix filtering and sorting with pagination parameters?
A: Yes, and most real APIs do. For example:

GET /orders?status=paid&sort=created_at_desc&limit=50&cursor=bmV4dF9pZD0xMDAw

This combines filters (status), sorting (sort), and cursor‑based pagination (limit, cursor). The key is to keep parameter names consistent across endpoints.

Q: Which example of pagination is best for mobile apps?
A: For mobile apps that scroll through feeds or lists, cursor‑based examples are usually the best examples. They handle infinite scrolling well, cope with changing data, and avoid the heavy jumps that offset‑based pagination can cause.

Q: How many items should I return per page?
A: There isn’t a single right answer, but many APIs default to 20–100 items per page and cap at something like 1,000. The “best” limit depends on payload size, network conditions, and rate limits. Start conservative, measure real usage, and adjust.

Q: Do I need to expose total counts like total_items or total_pages?
A: Only if clients truly need it. Computing a total count can be expensive on very large tables. Many large‑scale APIs skip total_items for cursor‑based pagination and instead just tell clients whether there is a next page.

Pagination is one of those boring problems that quietly defines how usable your API feels. By grounding your design in real examples of using query parameters for pagination—page/size, offset/limit, cursor‑based, and time‑based—you give clients predictable tools to move through data without fighting your backend. Copy from the best examples, understand the trade‑offs, and your API consumers will thank you with fewer support tickets and fewer angry Slack messages.