Limit Parameter Behavior in KDE Neon App Store API

Question

What is the maximum value that the "limit" query parameter can accept for a single request to the KDE Neon App Store API before the server enforces a lower bound or returns an error?
The API documentation confirms that a "limit" value can be supplied to bound the number of results per page and that pagination is supported via a "page" or cursor token. However, the maximum permissible limit is not documented, and it is unclear how the server responds when a request exceeds an internal threshold.
Specifically, if a client requests a very large limit (e.g., 10,000), does the API: • truncate the result set to an internal maximum, • return an error indicating the limit is too high, • or silently adjust the limit to a default value?
Additionally, what is the recommended safe default limit to use in client applications to avoid potential throttling or unexpected responses?

Tasadduq Burney · Answer

Direct answer
The maximum value for the "limit" query parameter in the KDE Neon App Store API is not documented in the available public specification. It is unknown whether the server truncates an oversized request such as limit=10000, returns a validation error, or silently substitutes a default page size. No specific cap, error code, or default can be confirmed without live server testing.
Confirmed facts

The API accepts a "limit" parameter to bound results per page.
Pagination is supported through "page" or cursor tokens.
No published maximum limit, enforcement threshold, or error schema for oversized limits is available.

Likely explanation (unverified)
Common REST API patterns suggest three possible behaviors when a limit exceeds an internal threshold: the server may clamp the result set to a hard maximum, return a client error status such as 400 or 422, or ignore the value and apply a default. Which behavior the KDE Neon App Store API implements has not been verified.
Scope and assumptions
Behavior may differ between API versions, environments, or authentication contexts. The verification steps below apply to the endpoint you are currently calling.
Verification steps

Send a baseline request with a modest limit, for example limit=25, and record the status code and returned item count.
Send incrementally larger requests, such as limit=100, limit=1000, and limit=10000, substituting your actual endpoint path.
Inspect the HTTP status code, response headers, and response body for error messages, clamped limit fields, or pagination metadata.
If the returned count is lower than requested, treat the difference as server-side truncation unless an error body states otherwise.

curl -i "https://api.kde.org/YOUR_ENDPOINT?limit=10000"
Recommended safe default
Until the server behavior is confirmed, use a conservative client-side default of 25 or 50 results per page. This range is typical for paginated store APIs and reduces the risk of timeouts, throttling, or unexpected truncation. Use the documented "page" or cursor token to fetch additional pages rather than requesting very large single-response sets.
Missing diagnostic detail
What HTTP status code and response body do you receive when sending limit=10000? This detail determines whether your client should retry with a lower limit, parse an error message, or rely on pagination tokens.

Limit Parameter Behavior in KDE Neon App Store API

1 answer

Direct answer

Confirmed facts

Likely explanation (unverified)

Scope and assumptions

Verification steps

Recommended safe default

Missing diagnostic detail

Your perspective belongs here.

0 question comments