API Pagination: What 51 Public APIs Actually Do

Quick answer: API pagination comes in four shapes: offset and limit, page numbers, opaque cursors, and a ready-made next URL. We measured 51 live public APIs and found that 33 of them return no pagination metadata whatsoever. When an API does paginate, the single most common thing it hands you is a complete URL for the next page.

Every guide to API pagination explains the four styles from first principles and then stops, which tells you nothing about what you will actually meet when you call a real API tomorrow morning.

So we measured it. We run a directory of public APIs, and 233 of the 1,566 live APIs we list (14.9%) are both keyless and CORS-enabled: callable from a browser console with no signup. We picked 76 collection endpoints from that corpus, called every one on 8 September 2026, and recorded what came back.

What do real APIs actually return?

51 endpoints answered with a usable JSON collection. Here is what their responses gave you to reach page two:

| What the response hands you | APIs | Share | |---|---|---| | Nothing at all | 33 | 65% | | A ready-made next URL | 9 | 18% | | Page numbers only | 4 | 8% | | offset and limit echoed back | 3 | 6% | | A Link: header | 1 | 2% | | An opaque cursor | 1 | 2% |

Two findings jump out.

The majority of public APIs do not paginate. Two thirds of the endpoints we called returned the entire collection in one response, or returned a page with nothing in it saying so. Coinpaprika handed back 61,368 coins in a single array. openSenseMap returned 17,077 sensor boxes. EmojiHub returned 1,791 emoji. No page counts, no next link, no total. Just the whole thing.

Cursor pagination is almost absent here. Exactly one of the 51, Wiktionary, used an opaque continuation token. Cursors dominate the paid API layer, where Stripe, GitHub and Shopify all use them, but on the free public API layer they barely exist. If you are writing a client for public data, offset and page numbers are what you will hit.

Where does the next page hide?

Among the 18 endpoints that did paginate, we found 15 different places to look. This is the real cost of consuming public APIs, and no amount of reading about pagination theory prepares you for it:

| API | Where the next page lives | |---|---| | SWAPI, PokéAPI, Spaceflight News, Launch Library 2 | next | | Rick and Morty | info.next | | Disney | info.nextPage | | Scryfall | next_page, guarded by has_more | | Art Institute of Chicago | pagination.next_url | | Arbeitnow | links.next | | jsDelivr | Link: response header, rel="next" | | XIVAPI | Pagination.PageNext | | STAPI | page.pageNumber and page.lastPage | | CheapShark | x-total-page-count response header | | OpenPLZ | x-page and x-total-pages headers | | GBIF | offset, limit, endOfRecords | | Nobel Prize | meta.offset, meta.limit, meta.count | | first.org Country | offset, limit, total | | Wiktionary | continue.apcontinue |

Three of those put the answer in a response header rather than the body, which is the failure mode nobody warns you about. If you parse only the JSON, CheapShark and OpenPLZ look unpaginated and you will silently take page one for the whole dataset.

What are the four pagination styles?

Offset and limit

You ask for ?offset=100&limit=50 and get records 101 to 150. Recognise it by offset and limit coming back in the response, as GBIF and Nobel Prize both do.

It breaks when the data changes mid-loop. Delete a record on page one and every later page shifts up by one, so you skip an item. Insert one and you read an item twice. For museum holdings or species records this rarely matters. For a live feed it does.

Page numbers

Same idea, coarser units: ?page=3. Recognise it by page, totalPages or pageSize in the response, or by the x-page style headers OpenPLZ uses. It has exactly the same drift problem as offset, because page numbers are offsets with the arithmetic hidden.

The upside is that page numbers are the only style you can put in a UI. If a human needs to jump to page 40, this is the style that supports it.

Cursors

The server hands you an opaque token that means "resume from here", and you send it back. Recognise it by a value you cannot interpret: Wiktionary's apcontinue was !O!ung on our call.

Cursors are stable under inserts and deletes, which is why every high-write API uses them. The cost is that you can only go forwards, you cannot jump to an arbitrary page, and the token can expire mid-loop.

A ready-made next URL

The response contains the complete URL of the next page and you follow it until it is null. This is the most common style we measured, and it is the easiest to consume correctly, because you never build a URL yourself.

Do not try to be clever with it. The next URL frequently carries query parameters you did not send: Scryfall's included format, include_extras, include_multilingual, include_variations and order. Follow the string you were given.

How do you loop through a paginated API safely?

Four rules, in order of how often ignoring them bites:

1. Follow the URL if you are given one. Reconstructing it from page + 1 throws away parameters the server added.
2. Check the headers, not just the body. Three of our 18 paginating APIs put the page state only in headers.
3. Cap the loop. Not on the total the API reports, on your own counter. A malformed cursor that returns the same page forever is a real failure mode, and an unbounded while loop will happily hammer someone's free API until you are blocked.
4. Rate limit yourself between pages. Pagination is the single most common way a well-meaning script turns into an accidental flood. See our guide to API rate limiting for what the receiving end sees.

What if the API does not paginate at all?

Two thirds of the time, this is your situation, and it needs the opposite instincts. Check the response size before you load it into memory, because a 61,000-item array is not what a naive client expects. And cache it: where there is no pagination there is usually no filtering either, so you will otherwise pull the entire dataset every time you need three records.

Where an API offers limit as a query parameter but returns no metadata, as Radio Browser and Open Brewery DB do, you are paginating blind: you can ask for 50 records but nothing tells you how many exist. Increment the offset until you get a short page or an empty one. That is the only signal available.

What else did we learn from calling 76 APIs?

25 of the 76 endpoints did not answer at all. Six that our directory records as keyless returned 401 Unauthorized: balldontlie, Pinball Map, URLhaus, Econdb, Movebank and OpenSanctions. Free public APIs quietly add authentication and rarely announce it. Five more had vanished at DNS level, their domains no longer resolving.

The lesson for anyone building on public data: your pagination loop is not the fragile part. The API still being free and still existing is. Write the loop to log and continue past a 401, not to crash on it.

Frequently asked questions

What is pagination in an API?

Pagination is how an API splits a large collection across multiple responses instead of returning everything at once. You request a slice, using an offset, a page number or a cursor, and the API tells you how to request the next one. It protects the server's memory and your download.

What is the best pagination method for a REST API?

For an API you are building, cursor pagination is the most correct, because it does not drift when records are added or removed while a client is reading. For an API you are consuming, the best method is whichever one the API gives you, and the best implementation follows the next URL rather than constructing one.

How do I know how many pages there are?

Often you cannot. Only 8 of the 51 endpoints we called reported a total count or page count anywhere. Where a total exists it may be in the body, in meta, or in an x-total-count header. Where it does not, the loop terminates when a page comes back short or empty, and your code needs to handle that rather than trusting an announced total.

Is offset pagination bad?

Not for stable data. Offset pagination is fine for reference datasets that change slowly, which is most of the public API layer. It becomes a real problem only when the collection is being written to while you read it, at which point you will silently skip or duplicate records. Two of the three offset APIs we measured serve exactly the kind of slow-moving archival data offset is safe for.

How do I test an API's pagination before I write the loop?

Call the first page and read the whole response, headers included, before writing any code. That single step tells you which of the four styles you are dealing with, and it is where the header-only cases give themselves away. Our guide to testing an API covers the rest of the first-call checklist, and you can practise on any of the keyless APIs in our development category.