The most cited requirement in the study, 22 of 26 clients
Anyone can call an endpoint.
Run it twice and watch.
When clients say API integration they are never asking whether you can call an endpoint. The screening questions say it plainly: how did you handle authentication, rate limiting, input validation and auditing, and how did you handle queues, retries and idempotency.
So type a repository. Every request is shown as it happens, with the status, the rate budget left, and the time it took. It is read-only, so running it twice changes nothing at GitHub, which is the point.
Any public repository. Run it twice: the second time is where the interesting behaviour is.
What it is doing, and why each part is there
Authentication, and what it costs to skip it
A token turns 60 requests an hour into 5,000. The run says which one it used, and the Authorization header is redacted before any request detail leaves the server, so the log below is safe to paste into a message.
Pagination by Link header, not by counting
The server decides where a collection ends, so the client follows rel="next" rather than incrementing a page number until something looks empty. The parser does not split the header on a comma, because a URL is allowed to contain one and a naive split truncates it into an address that 404s.
Rate limits read before being refused
The budget comes back on every response. Sprinting until a 429 arrives means you have already been throttled, and on GitHub it also burns into the secondary limit, which is measured per minute and far less forgiving. When the budget runs low the remaining requests are spread across the time left instead of fired at once.
Retries that tell the difference between two kinds of 403
GitHub answers 403 for "your token cannot do this" and for "you are going too fast". The status is identical and the headers are not. Treating them the same either stalls on a rate limit or hammers a permission error.
Conditional requests, so an unchanged page costs nothing
Every response carries an ETag. Sending it back as If-None-Match gets a 304 and, on GitHub, spends no rate budget at all. Run it twice above and watch the budget stop moving.
The bug caching introduced, found by running it twice
The first version walked three pages and returned 90 commits. The second run returned 30 from a single page and reported success. A 304 carries no body and, on GitHub, no Link header either, so next came back undefined and the walk stopped after one page.
Nothing failed. Every request answered 304, the run was faster, it cost no rate budget, and it silently returned a third of the data. Faster, cheaper, no error, and wrong is the worst shape a defect can have, because nothing about it asks to be looked at.
The Link header is stored beside the body now and replayed on a 304. Run it twice above: same pages, same commits, and the budget does not move.
What this is not
The ETag store is in memory and per instance, so it exists to show a 304 happening rather than to be a cache. A real one would be shared and would have an eviction policy and a size bound.
Three pages and thirty per page, on a deadline. That is a demonstration budget, not a limit of the client.
Everything here reads. Idempotency is free when nothing writes, and the hard version of that question is about retrying a write safely, which this does not show. The MCP server is where the writes are.
62 tests cover the decisions with no network anywhere near them. Two of those tests exist because the official Anthropic SDK gets Retry-After wrong in two ways, which is written up in what broke.
The whole list is 41 requirements taken from 114 job posts, with the gaps shown at the same size as the wins. This endpoint describes itself in a browser.