Every failure gives HTTP 200, except the one that gives 429

Asking for more than 50 questions gives you 50, not an error

This session sent GET https://opentdb.com/api.php?amount=51. The response carried HTTP 200 and a results array of exactly 50 rows. No error field named the cap, and no header hinted at it.

A client that trusts the amount parameter it sent, instead of counting the rows it got back, will believe it holds 51 questions when it holds 50.

response_code 1 means two different things, and both look identical

This session sent GET https://opentdb.com/api.php?amount=50&category=9&difficulty=hard&type=boolean, a real filter combination with too few matching questions in the pool. It returned HTTP 200 and {"response_code":1,"results":[]}. The same filter with amount=1 returned code 0 and one question, so the pool is not empty. It just holds fewer than 50 matches.

This session then sent GET https://opentdb.com/api.php?amount=1&category=999, a category ID the API has never defined. It returned the same HTTP 200 and the same {"response_code":1,"results":[]}.

A typo in the category ID and an honest shortage of hard boolean questions in category 9 produce the same body. A client cannot tell which one happened without checking the category list itself.

A bad token gives 200, but the rate limit gives a real 429 with a different key

This session sent GET https://opentdb.com/api.php?amount=1&token=bogus, a session token the API never issued. It returned HTTP 200 and {"response_code":3,"results":[]}, the same success status as every other failure this session found.

This session then waited 6 seconds and sent five requests back to back, with no delay between them. The first one returned HTTP 200 and a question. The next four returned HTTP 429, each with the body {"response_code":5,"result":[]}. That body uses the singular key result, not the plural results that every other response here used.

The API sends 200 for every other failure, so a client can easily stop checking the status. Such a client reads results and checks for an empty array. On a 429 there is no results key, so it gets undefined instead of an empty array. Check response_code first, and read results only when that code is 0.