This is one of the most common API design problems, and it almost always starts with the same sentence: “Don’t worry, it won’t grow that much.”
Then it grows. It always grows. And once it grows, the cost of fixing it is no longer “add a query parameter”. It becomes UI hacks, performance incidents, and angry clients.
What was tested
Rentgen detects a very specific pattern:
a GET endpoint returns a JSON array (a list/collection),
but the request URL contains no query parameters that control size or navigation.
In other words: it looks like an unbounded “return everything” endpoint.
- TEST: Array List Without Pagination
- Trigger:
GET+ JSON array response + no pagination/limit parameters in URL - Expected: supports pagination/limit (query parameters present or documented)
- Actual: missing pagination/limit (no query parameters)
- Status: 🟠 Warning
Why this matters
Collection endpoints must be predictable. When an API returns lists without server-side limits, response size grows linearly with data growth. That means latency, memory usage, and client pain also grow over time — often without any code change.
The worst part is that this failure mode is delayed. Everything works fine in early environments with small datasets. Then production accumulates real data, and suddenly the same endpoint becomes slow, expensive, and unstable.
The classic trap teams fall into
I’ve seen this pattern too many times: developers ship a list endpoint without pagination because “it’s just a small list”. Product assumes the list stays small. Nobody tests scale because there is nothing to test yet.
Months later it turns into: “Frontend, can you add pagination UI?” That usually improves the UX a little, but it does not solve the real problem. Client-side pagination still requires downloading and parsing the full dataset first. By the time the UI paginates, the damage is already done.
Why this is a warning (not an automatic fail)
Because sometimes an endpoint can be bounded by design even without obvious query parameters. Some APIs enforce a hard server-side limit and always return a safe maximum number of items. Others return a small fixed list that truly cannot grow (rare, but possible).
Rentgen flags this as a warning because the signal is about risk and design, not about functional correctness. It is a prompt to confirm that the endpoint is intentionally bounded, not accidentally unbounded.
How to respond to this warning
If the endpoint is expected to grow, add pagination now.
It is cheap early, and expensive late.
Support a familiar approach like ?limit=50, ?page=1, ?offset=0, or a cursor.
Also enforce a safe default limit even when parameters are missing.
If product insists “it will never grow”, put a hard limit in the API anyway. This is the lowest-cost compromise: the response stays safe even if assumptions turn out to be wrong. If one day the limit is reached, the API forces the conversation to happen with evidence, not optimism.
Why this check exists in Rentgen
Because manual testing rarely catches design debt. When a tester sees a list response in Postman, the natural reaction is “it works”. Nobody counts objects. Nobody estimates future growth. Nobody imagines 50,000 records.
Rentgen checks this automatically and makes the risk visible early. And when you want to raise it with the team, Rentgen provides a Copy Bug Report action with the relevant details and suggested remediation, so you don’t have to write the argument from scratch.
Final thoughts
Unpaginated collection endpoints are technical debt that looks harmless until real data arrives. Pagination is not a “nice-to-have”. It is basic damage control for any API that lives longer than a few weeks.
If you see this warning, treat it as a chance to fix a cheap problem before it becomes an expensive one.