Consider what your client does with that body. `raise_for_status()` passes, because 200 is 200. Call `.json()` and you get a decode error raised from inside the parser, several frames away from the request that caused it. Store `resp.text` instead and you have written 5,454 bytes of HTML into a cache keyed as a catalog record [1]. None of those surfaces names the real problem, which is why the content-type check has to sit at the boundary, before anything downstream touches the body [2].
That check buys retryability without diagnosis, and the gap is worth sitting with. The same shell answers a throttle and a malformed request [1]. `limit` is an allowlist of eight values rather than a range, so `limit=3` and `limit=5` come back as shells too [3]. Of the integers from 1 to 100, only six are on the list, which leaves 94 page sizes a reasonable person might type that fail silently [1]. Raise the shell as retryable, as the author's code does [2], and a wrong constant turns into a well-mannered infinite loop. It cost him about an hour, spent looking at status codes [4].
Scale is what makes the gate non-optional rather than tidy. The API underneath is good: unauthenticated JSON under `/proxy/*`, reachable from outside the US [6]. The catalog holds 34,309,409 records [5]. Walk it at the largest allowed page size of 10,000 and that is 3,431 responses [2]; at `limit=100` it is 343,095 [3]. Any one of them can arrive as the shell because you went too fast [1], so the content-type assertion runs on every response, not just the handshake.
The retry-gate lesson repeats one layer up in the same project. Gemini's free tier caps at `GenerateRequestsPerDayPerProjectPerModel-FreeTier value: 20`, twenty requests per day per model per project [9]. The author's evaluation harness used six attempts with exponential backoff, which drew repeatedly from a bucket that was already empty [10]. Six attempts against twenty is up to 30 percent of the day's budget spent on one logical call [4]. His fix inspects the 429's text for daily markers, on the reasoning that a per-minute limit clears if you wait and a per-day limit does not [11]. Both cases share a shape: the transport-layer status is not the thing you need to branch on.
What would have to be true for this to transfer to your stack? Only that your retry layer is configured by status code, which most of them are by default. If the decision to retry lives in middleware that never sees the body, this failure mode is invisible to it, and the request budget drains behind a green dashboard. In my own client I would keep both checks and let them disagree: content type as the gate, the 5,454-byte length as a canary [1][2]. When the length moves, the front-end bundle was rebuilt and everything I believe about this endpoint is one release out of date.
