Ask for 1,000 articles and the server quietly hands back 500

The limit parameter silently corrects itself

This session sent GET https://api.spaceflightnewsapi.net/v4/articles/?limit=1000. The response carried HTTP 200 and a results array of exactly 500 rows, and its next link read limit=500&offset=500. Requests for limit=600 and limit=2000 also returned 500 rows each. The server caps any limit above 500 at 500 rather than rejecting it.

This session then sent limit=abc, limit=0, and limit=-1 on separate calls. Each one returned HTTP 200 with the default page of 10 rows, as if no limit parameter had been sent at all. None of the three raised an error.

So a client that asks for a big page, or sends a bad one by mistake, never sees a 400. It has to read the next link or count results to learn what it actually got.

Two shapes of 404, one shared CORS header

GET https://api.spaceflightnewsapi.net/v4/articles/99999999/, an id the catalog has never assigned, returned HTTP 404 with a JSON body: {"detail":"No Article matches the given query."}. GET https://api.spaceflightnewsapi.net/v4/nosuch/, a path the API never defined, returned HTTP 404 with a full HTML error page instead.

Neither response carried a CORS header on a plain curl request. Adding an Origin header, as a browser would, changed both: each 404 came back with access-control-allow-origin: *.

A browser-based client can read either 404 body across origins. A server-side client that skips the Origin header, and checks only for the header's presence, would wrongly conclude CORS is unsupported on error paths.

Paging past the end returns an empty page, not an error

This session sent GET https://api.spaceflightnewsapi.net/v4/articles/?offset=999999 against a catalog of 36,225 articles. The response was HTTP 200, with count still reporting 36225, next set to null, previous pointing one page back, and results an empty array.

So running off the end of the list looks exactly like a normal, successful page that simply has nothing left on it. A client that stops paging on a non-200 status will loop forever here; it has to check for an empty results array instead.