DEV Community: Alex Spinov

A Check You've Never Seen Go Red Isn't a Check — 6 Ways Mine Lied

Alex Spinov — Wed, 09 Sep 2026 18:37:02 +0000

At 18:31:38Z on 8 September I asked one platform the same question twice, from the same machine, seconds apart. Route A said my newest article was from 19 August. Route B said 18:14:58Z that afternoon, seventeen minutes old. Both returned HTTP 200. Both parsed as valid JSON.

My publish-quota check reads a route like A. On 8 September it concluded "0 publications in the last 7 days" while an article had gone out the previous morning. It returned 200. It returned green.

The route can be made to tell the truth. I found that out a day later and I will show the run. But my check had one query parameter frozen into it, and no reason on earth to ever vary it.

That is not reassuring. That is the bug.

Short version. A success from a check that has never gone red on a deliberately broken input carries no information. Ship every check with a negative control: one fixture it is required to fail. Judge by the artifact — file on disk, body length, Age header — not by an exit code. Six modes below, and a runner.

Here is the whole article as a table. Every row is a real verdict from my own tooling, and the last column is the one nobody fills in:

check	what it said	what was true	could it have said otherwise?
newest post, via `/api/articles?username=`	nothing since 19 Aug	two Sept posts, one 17 min old	not at `per_page=5` — and `5` was hard-coded
"this tag has no new posts"	empty	throttled; the body was 12 bytes	no — it never looked at length
`scraper.py \	tail -4; echo $? `→` 0`	script is fine	script exited 1 on HTTP 401
cover renderer → `FAIL exit 1`	render failed	a complete PNG was already on disk	no — it read its own timeout
`echo $GMAIL_SEND_ENABLED` → empty	sending is blocked	the flag was `1` in the file the tool reads	not in that shell — nothing ever exported it there; the mailer inherits what the caller exported and fills the gap from `.env`
`bsky_ops.py notif` count of `20`	read alone: that is all of them	140 existed	no — 20 was the page size I passed

Five of those rows are a flat no. The first is worse than a no: that route can answer correctly, and my check simply never asked it differently. I found that out from my own review pass, not from the check.

None of these was broken in a way a code review would catch. Each was pointed at a surface where the failure it was written to detect cannot appear, either at all or at the one input it was pinned to.

Why a green answer can be structurally empty

Here is the measurement from the top, with commands, because the pair is the whole argument.

t: 2026-09-08T18:31:38Z

GET /api/articles?username=0012303&per_page=5          (public, no key)
  200  Age: 138449   X-Cache: MISS, HIT   Cache-Control: public, no-cache
  newest in body:  2026-08-19T12:37:21Z

GET /api/articles/me/published?per_page=5              (same account, api-key)
  200  Age: none     X-Cache: MISS, MISS  Cache-Control: max-age=0, private
  newest in body:  2026-09-08T18:14:58.775Z

Same account. Same minute. A 38-hour difference of opinion about what exists. The public route was not wrong in any way an assertion could see: 200, well-formed, five articles, correct schema, correct author. It was answering the question as of 04:04Z the previous morning, before either September article existed.

These are not interchangeable endpoints and I am not pretending they are. Vary: Accept-Encoding, Origin, X-Loggedin says the platform splits this answer by login, and only the public half is cacheable. The public half is also the half an unauthenticated check reads.

Add the part that annoys me most. Twenty seconds earlier I had tried the usual reflex, appending a cache-buster, and got Age: 138428 against 138427 for the plain request before it. One pair of numbers proves nothing; any repeat rises by a second. So I did it properly, with three random nonces:

t: 2026-09-08T19:22:32Z
cb=666872067  Age=141505  MISS, HIT  Etag=W/"5f3612accc5479314c311fbd395e9a53"
cb=452385316  Age=141506  MISS, HIT  Etag=W/"5f3612accc5479314c311fbd395e9a53"
cb=822423843  Age=141507  MISS, HIT  Etag=W/"5f3612accc5479314c311fbd395e9a53"

Three distinct parameter values, one shared Etag — the same Etag the plain no-cb request returned thirty seconds earlier. The cache-buster is not part of the cache key here, so it bought nothing. That trick is in everyone's muscle memory and on this route it is decoration.

I wrote about a stale answer from this platform before, in The DEV API Said My New Post Didn't Exist. That article ends with the cause, so I will not pretend here it is a mystery.

The edge obeys x-accel-expires: 172800, a 48-hour ceiling. Forem's EdgeCache::BustArticle purges the ?tag= variants of this API on publish, never the ?username= ones. A 39-hour-old body is a cache doing what it was configured to do.

Which makes this case narrower and worse. The explanation was already published, on my own blog, and the check still walked into it, because the check never read a response header at all.

The part I got wrong while writing this

On 8 September my logs recorded three different Age values from one endpoint: per_page=5 at 76 351 s, per_page=15 at 1 578, per_page=100 at 920. Three parameter values, three cache objects. To quote fresh numbers I re-ran all three, got MISS, MISS and no Age on every one, and wrote: the split did not reproduce.

It reproduced fine. I had re-run them against /api/articles/me/published — the authenticated route, which answers Cache-Control: max-age=0, private, must-revalidate and therefore never carries an Age header, under any input, ever. Here is that bad measurement, repeated on purpose:

t: 2026-09-08T19:26:29Z  GET /api/articles/me/published?per_page=N   (api-key, private)
per_page=5     Age=None   MISS, MISS   max-age=0, private, must-revalidate
per_page=15    Age=None   MISS, MISS   max-age=0, private, must-revalidate
per_page=100   Age=None   MISS, MISS   max-age=0, private, must-revalidate

Three results settled before I typed the command. I pointed an instrument at a surface where the signal cannot appear and filed its absence as a finding.

That is mode 2 of this article, committed by its author, inside the paragraph meant to correct a different mistake. My review pass caught it. I did not.

Here is the public route, the one the split was actually measured on. Twice, ninety-four seconds apart:

t: 2026-09-08T19:26:56Z  GET /api/articles?username=0012303&per_page=N   (public, no key)
per_page=5     Age=141768  MISS, HIT   newest=2026-08-19T12:37:21Z
per_page=15    Age=66995   MISS, HIT   newest=2026-09-07T06:55:08Z
per_page=100   Age=896     MISS, HIT   newest=2026-09-08T18:14:58Z

t: 2026-09-08T19:28:30Z
per_page=5     Age=141862  MISS, HIT   newest=2026-08-19T12:37:21Z
per_page=15    Age=67089   MISS, HIT   newest=2026-09-07T06:55:08Z
per_page=100   Age=990     MISS, HIT   newest=2026-09-08T18:14:58Z

elapsed 94 s | Age deltas: per_page=5:94  per_page=15:94  per_page=100:94

Three objects, three different answers to "what is my newest article", every one ageing at exactly one second per second. per_page is part of the cache key.

Age counts up from the moment a copy was stored, so each object can be dated by subtraction: 04:04:08Z on 7 September for per_page=5, 19:12:00Z for per_page=100. Once stored, a copy is served until its 48-hour ceiling runs out. Asking again does not refresh it.

So the lesson is sharper than the one I first wrote down, and it costs me twice. The route was never incapable of telling the truth: at 19:26:56Z per_page=100 had it, on a copy 896 seconds old against 141 768 for per_page=5.

But that copy was stored at 19:12:00Z, forty minutes after the check that failed at 18:31:38Z. I measured this object twice, fifty-five minutes after that check; what per_page=100 was serving at 18:31Z I did not measure and cannot claim.

And the mechanism cuts both ways. A parameter nobody asks for keeps missing cache and coming back fresh; the one my check hammers is the one whose copy stays warm and stale. Re-pin to per_page=100 and I would earn the same bug in time.

My check was pinned to per_page=5, a value picked long ago because five rows are enough to read a date off. The pin is what made the failure invisible.

Six ways a check lies about the world

Four of these hand you a green that means nothing. Two hand you a red that means nothing. The mechanism is the same in every one: the check is pointed at a surface where the answer it needs cannot appear.

1. It reads a surface that cannot contain the failure. On 8 September my dashboard printed 64 983 views / 3 401 published posts against live values of 65 245 / 3 402. The build script reads key=value lines and a CSV; I had written the measurement down as a markdown table.

For that parser my table does not exist, so it quietly reused yesterday's row. One row behind, not thirty-two; I will come back to where the thirty-two went.

Nastier version of the same shape: echo $GMAIL_SEND_ENABLED in my shell prints nothing, forever, because the flag lives in .env and the mailer loads that file itself at import. Both, in one breath, today:

$ echo "GMAIL_SEND_ENABLED=[$GMAIL_SEND_ENABLED]"
GMAIL_SEND_ENABLED=[]

$ python3 -c "import gmail_tool, os; print(repr(os.environ.get('GMAIL_SEND_ENABLED')))"
'1'

Same variable, same second, opposite answers, and both are honest about the surface they read. On 24 July the shell's answer won, I reported "sending disabled, 0 emails," and a whole day of outreach did not happen.

2. It reads a cached surface, and green is a coincidence. Covered above. The number to keep is 141 862 seconds of Age on a body that looked perfect, from an edge that was following its configuration correctly the whole time.

3. It swallows its own error, and the silence reads as clean. Fire nine tag requests at once and this happens:

t: 2026-09-08T18:32:09Z | 9 tags, all at once
  tag=ai           429  body_bytes=12       b'Retry later\n'
  tag=webdev       429  body_bytes=12       b'Retry later\n'
  tag=python       200  body_bytes=11753    b'[{"type_of":"article",...'
  ... 6 more 200s, 10 905-12 589 bytes each

Same nine tags, sequential, 1.2 s apart: 9/9 with JSON, 38 unique article ids. The throttle reply is 12 bytes; a real reply is around 11 000. A ratio of roughly 900:1, and a check that asks "did I get rows?" instead of "how big was the body?" reads the throttle as a quiet day.

An earlier run of mine the same day logged the throttle body at 28 bytes; mine above says 12. The exact figure moves. The order of magnitude does not, and the order of magnitude is what you gate on.

Silence has other doors. On this Mac, three of them stack in a single line people write without thinking:

$ find . -newermt '-70 minutes' 2>/dev/null | head -3
$ echo "exit=$?  PIPESTATUS[0]=${PIPESTATUS[0]}"
exit=0  PIPESTATUS[0]=1

The tool rejected the flag. 2>/dev/null ate the complaint. The pipe swapped in head's exit code, and head succeeds at reading nothing. Empty output, exit 0, and I read it as "the agents did nothing" while they had done their work.

One more of the client-side kind: strip the User-Agent from an otherwise identical request and you get HTTP Error 403: Forbidden Bots. My failure, wearing the platform's uniform.

4. It measures the ceiling instead of the value. Two runs of one command today:

$ bsky_ops.py notif --limit 20 --pages 1
FETCHED 20 notifications: {"repost": 1, "reply": 12, "like": 7}
!! STOP=budget: hit the --pages budget (1) with a live cursor still open. MORE notifications exist beyond these 20 — this is NOT a total. FIX IS OURS: re-run with a higher --pages.

$ bsky_ops.py notif --limit 100 --pages 3
(paged: 2 pages, page size 100)
FETCHED 140 notifications: {"repost": 1, "reply": 68, "like": 63, "follow": 8}
STOP=cursor_end: server withheld the cursor after a non-empty page. 140 is a COMPLETE total. Nothing to fix.

20 versus 140, same command, different flags. Look at the reply counts in particular: 12 against 68.

That warning text exists because on 26 July the default limit was 80, the run printed a fixed 76, and four cycles in a row wrote "76 again, no movement, zero replies." 76 was the ceiling. It could not grow. A live reply from a real person sat inside that unchanged list the whole time.

The STOP= labels came later, and they came from someone else. On 30 July @dnulkjkjh made the point that a walk like this can end several different ways, and that one signal cannot tell you which fix to reach for.

That line is pinned in the source above the loop. Now every exit is named, the successful one included, because "no warning" is not a diagnosis.

Same family, different tool: our publish-quota gate compared gap_hours for months and never counted per_week, so Telegraph ran 7/week against a cap of 3 and Bluesky 7/week against 5, reporting OPEN throughout. Half a condition, evaluated perfectly.

5. It reads its own exit code instead of the artifact. FAIL … exit 1 printed over a finished PNG. Next section.

6. The control is itself a live action. One test email left the building on 24 July. Last section.

A caveat on the six, since I am the one claiming it. Six is how many distinct modes I can document with a dated run. It is not six-out-of-N. I have never audited every check in this repo, so I have no denominator, and I am not inventing one.

The defect runs both ways

render_cover.py used to print FAIL … exit 1 while a complete PNG sat on disk. Chrome writes the file in a couple of seconds and then hangs on a network @import for Google fonts, never exiting. The script was catching its own 90-second timeout and reporting it as a render failure. Nothing was broken except the verdict.

The fix was not a longer timeout. It was changing what decides:

fresh = p.exists() and p.stat().st_mtime > before and p.stat().st_size > 5000

Exists, newer than before I started, big enough to be an image. The browser's exit code no longer participates. And because a verdict rule that has never failed is exactly what this article is about, I ran its negative control again today:

$ CHROME_BIN=/bin/nonexistent-chrome python3 scripts/render_cover.py --slug nc-probe ...
FAIL: chrome не запустился — [Errno 2] No such file or directory: '/bin/nonexistent-chrome'
rc=1

(My tooling logs in Russian. That line reads "chrome did not start.")

Both false-red cases share a root with the false-green ones. The check answered a question about itself, my timeout or my shell's environment, and reported the answer as a fact about the world.

Green by coincidence is not verification

This is the failure I find hardest to catch, because the output is correct.

On 7 September I confirmed a posted comment by reading a counter: 55 → 56. Correct number, correct conclusion. It was correct because my own write had populated that cache a minute earlier.

The next day the same route served a body with Age: 24211, 6.7 hours old, and it would have answered with exactly as much confidence. The verification worked the way a stopped clock works.

A sharper one, from a recount on 7-8 September. The naive rule "no reply found, so send" would have produced 0 duplicates that day. Sounds like validation.

Except the cached snapshot it read was older than every single send of that day, so its negative answers were evidence of nothing. They landed on exactly the right 15 targets — 12 genuinely unsent, 3 with nowhere to type — by luck.

Which is why a green run is not the artifact I want out of a check. I want a run that came back red on demand.

The check on the check needs one too

scripts/pass_budget.py is a guard: three work passes per day, exit 1 when the budget is gone. Its counter is one line:

cycles = re.findall(r"^##\s*ЦИКЛ\s+(\d+)", txt, re.M)

On 8 September I titled a pass # 🔁 ЦИКЛ 2 instead of ## ЦИКЛ 2. One # and an emoji. The guard did not see the heading, counted one pass instead of two, and would have cheerfully authorised a fourth pass against a hard cap of three — silently, with no error, while printing a perfectly plausible number.

So I added a watchdog for exactly that: find headings that mention a cycle but do not match the counted form, and shout. Then I ran it against fixtures, on a copy, not on the live log:

--- fixture GOOD (two headings in canonical form) ---
омские сутки 2026-09-09 · проходов записано 2 из 3 · осталось 1
rc=0

--- fixture BROKEN (one heading written as '# 🔁 ЦИКЛ 2') ---
🔴 В журнале есть заголовки циклов, которых счётчик НЕ ВИДИТ: 2 — приведите их к форме «## ЦИКЛ N», иначе разрешается лишний проход.
омские сутки 2026-09-09 · проходов записано 1 из 3 · осталось 2
rc=0

Silent on the good fixture, loud on the broken one, and you can watch it undercount from 2 to 1 in the same output. Note the honest part: rc is 0 in both cases. The watchdog warns, it does not block. That is a gap I have not closed.

Now the part worth the section. The first version of that watchdog did not fire on its own negative control. It picked up the "ИТОГ ЦИКЛА" (end-of-cycle summary) headings and subtracted them in a way that cancelled the very finding it existed to report.

A guard written to catch checks that cannot fail, which itself could not fail. I found out only because I ran it on a deliberately broken log before trusting it.

A smaller version of the same lesson happened while I was writing this. Another guard checks that bar lengths on a chart match the numbers printed inside them, and it takes --expect fail so it can be wired up as a standing negative control. I fed it a 24:9 ratio against the pre-fix template:

🔴 ожидался FAIL, а вышло OK — КОНТРОЛЬ СЛОМАН     rc=3

"Expected FAIL, got OK, the control is broken." It was right and I was wrong. A 24:9 ratio draws honestly even under the old template, so my fixture was not actually broken. The documented pair, replayed verbatim, does what it says:

run	true ratio	drawn ratio	deviation	verdict	rc
`--b1v "24 requests" --b2v 1 --tpl <pre-fix> --expect fail`	0.042	0.335	703.1%	FAIL, control fired	0
`--b1v "24 requests" --b2v 1 --expect pass` (current)	0.042	0.042	1.5%	OK	0

Same input, same 12% tolerance, two templates, both verdicts on demand. That is what a check looks like once it has earned its green. The third exit code, rc=3 for "your fixture is not actually broken," mattered more than I expected: without it I would have filed a bug against a working guard.

A 103-line runner that makes a check prove itself

falsify.py. Standard library only, no network, deterministic (two consecutive runs hash identically). Each check is registered with two fixtures: one it must pass, one it must fail. The runner executes both and classifies the check, not the code under test.

If that sounds like mutation testing, the difference is what gets mutated. Mutation testing breaks the code and asks whether the tests notice. This breaks the surface a check reads (response body, exit code, file on disk) and asks whether the check notices. It also needs a verdict mutation testing has no slot for: FALSE-ALARM, red on healthy input.

#!/usr/bin/env python3
"""falsify.py - a check you have never seen go red is not a check."""
import json, shlex, subprocess, sys, tempfile, pathlib

CHECKS = []

def register(name, good, broken):
    """good/broken: zero-arg callables that build the input the check reads."""
    def deco(fn):
        CHECKS.append((name, fn, good, broken))
        return fn
    return deco

def run_one(fn, build):
    try:
        return bool(fn(build())), ""
    except Exception as exc:                      # a check that explodes is red
        return False, f"{type(exc).__name__}: {exc}"

def verdict(green_on_good, green_on_broken):
    if not green_on_good:
        return "FALSE-ALARM"                      # red on input that is fine
    return "CERTIFIED" if not green_on_broken else "UNFALSIFIABLE"

# --- fixture 1: the 12-byte throttle body measured above, replayed under a 200
FULL = json.dumps([{"id": 4584754 + i, "title": "x" * 300} for i in range(5)]).encode()
THROTTLED = b"Retry later\n"

@register("tag_has_posts / v1: 200 and a non-empty body",
          lambda: (200, FULL), lambda: (200, THROTTLED))
def has_posts_v1(resp):
    status, body = resp
    return status == 200 and len(body) > 0

@register("tag_has_posts / v2: length gate, then shape",
          lambda: (200, FULL), lambda: (200, THROTTLED))
def has_posts_v2(resp):
    status, body = resp
    if status != 200 or len(body) < 200:
        return False
    try:
        return isinstance(json.loads(body), list)
    except ValueError:
        return False

# --- fixture 2: the pipe that launders an exit code
OK_CMD = [sys.executable, "-c", "print('rows: 41')"]
FAIL_CMD = [sys.executable, "-c",
            "import sys; print('rows: 0'); sys.stderr.write('HTTP 401\\n'); sys.exit(1)"]

@register("scraper_ok / v1: $? after a pipe", lambda: OK_CMD, lambda: FAIL_CMD)
def scraper_v1(cmd):
    line = " ".join(shlex.quote(c) for c in cmd) + " | tail -1"
    return subprocess.run(line, shell=True, stdout=subprocess.DEVNULL,
                          stderr=subprocess.DEVNULL).returncode == 0

@register("scraper_ok / v2: the command's own code", lambda: OK_CMD, lambda: FAIL_CMD)
def scraper_v2(cmd):
    return subprocess.run(cmd, stdout=subprocess.DEVNULL,
                          stderr=subprocess.DEVNULL).returncode == 0

# --- fixture 3: renderer writes the file, then hangs and is killed (exit != 0)
def _render(writes_file):
    d = pathlib.Path(tempfile.mkdtemp())
    out = d / "cover.png"
    if writes_file:
        out.write_bytes(b"\x89PNG\r\n\x1a\n" + b"\0" * 6000)
    return {"out": out, "exit_code": 1, "size_floor": 5000}

@register("cover_rendered / v1: the process exit code",
          lambda: _render(True), lambda: _render(False))
def cover_v1(r):
    return r["exit_code"] == 0

@register("cover_rendered / v2: the artifact on disk",
          lambda: _render(True), lambda: _render(False))
def cover_v2(r):
    p = r["out"]
    return p.exists() and p.stat().st_size > r["size_floor"]

def main():
    rows, bad = [], 0
    for name, fn, good, broken in CHECKS:
        g, gn = run_one(fn, good)
        b, bn = run_one(fn, broken)
        v = verdict(g, b)
        if v != "CERTIFIED":
            bad += 1
        rows.append((name, g, b, v, gn or bn))
    w = max(len(r[0]) for r in rows)
    print(f"{'check'.ljust(w)}  good  broken  verdict")
    print("-" * (w + 26))
    for name, g, b, v, note in rows:
        print(f"{name.ljust(w)}  {'PASS' if g else 'FAIL'}  "
              f"{'PASS' if b else 'FAIL':6}  {v}" + (f"   [{note}]" if note else ""))
    print(f"\n{len(rows)} checks, {len(rows)-bad} certified, {bad} not.")
    print("What this runner does NOT catch: a broken fixture that is not broken")
    print("the way production breaks, and a check that is right on both fixtures")
    print("while reading a surface that only goes stale under load.")
    return 1 if bad else 0

if __name__ == "__main__":
    sys.exit(main())

Real stdout, Python 3.13.5:

check                                         good  broken  verdict
----------------------------------------------------------------------
tag_has_posts / v1: 200 and a non-empty body  PASS  PASS    UNFALSIFIABLE
tag_has_posts / v2: length gate, then shape   PASS  FAIL    CERTIFIED
scraper_ok / v1: $? after a pipe              PASS  PASS    UNFALSIFIABLE
scraper_ok / v2: the command's own code       PASS  FAIL    CERTIFIED
cover_rendered / v1: the process exit code    FAIL  FAIL    FALSE-ALARM
cover_rendered / v2: the artifact on disk     PASS  FAIL    CERTIFIED

6 checks, 3 certified, 3 not.
What this runner does NOT catch: a broken fixture that is not broken
the way production breaks, and a check that is right on both fixtures
while reading a surface that only goes stale under load.

Exit code 1, so CI fails on anything that is not CERTIFIED.

One deliberate change from the log: the platform sent that 12-byte body with a 429, and the fixture replays it under a 200. A status gate already catches a 429.

It does not catch a refusal wearing a success code, and that is the case I wanted the length gate tested against. If your API only ever refuses with a 4xx, v1 is fine and this fixture is unfair to it.

Read each UNFALSIFIABLE row as a pair with the CERTIFIED row beneath it. Same fixtures, same question, different surface. The naive version passes both fixtures, which is the only symptom it will ever show you in production. cover_rendered / v1 is the false alarm: it fails the good fixture, which is our render bug in four lines.

One more thing it does not catch, same shape as everything above. run_one wraps fn(build()) in a single try, so the handler covers the fixture builder as well as the check. If the broken builder throws, the result is False, False reads as "the check went red", and a check that never looked at anything gets stamped CERTIFIED.

A tool written against checks that cannot fail, counting redness it did not earn. The repair is two lines: catch around build() separately and report a third state. I left the code as printed rather than patch it silently, because the byte-for-byte stdout is the point.

Six one-liners, if you skip the runner entirely:

${PIPESTATUS[0]} or set -o pipefail, never cmd | tail; echo $?
gate on body length before you gate on content: 12 bytes is not an empty result set, it is a refusal
read Age and X-Cache as part of the response, not as trivia
a count that equals the limit you passed is a page boundary; re-run with a bigger limit and look at dates, not totals
verdict from the artifact (exists, mtime newer than start, size above a floor), not from the exit code of whatever produced it
test a safety switch on a stubbed transport, and assert on what would have gone out

That last one has a body count. On 24 July, to prove that a send-guard blocks outbound mail, I ran a real send to nobody@example.invalid. The guard was off. The mail left, bounced against an RFC 2606 reserved domain, and reached nobody, which was luck rather than design. A control that performs the action is not a control.

What I did not measure

No denominator. Six modes, not six out of anything. I have never audited every check in this repo.
I did not measure the CDN, only its behaviour. Age, X-Cache, Etag, Vary, X-Accel-Expires and the response to ?cb= are what I have. Why EdgeCache::BustArticle purges ?tag= and not ?username= is a design decision I can read in Forem's source but cannot speak for.
falsify.py has no track record. I wrote it for this article. Zero incidents prevented so far.
Everything here is one platform and my own tools. Dev.to and a Mac. "All CDNs behave this way" is not a claim I can support.
My 19 July log counts eight instances of this class in one day. Three of them are named above. The other five are a tally, so treat them as a tally.

And one thing I did measure, a day late

For a day I carried a frightening line in my notes: pagination gives 3 402 published articles, the profile counter had read 3 433, so ~31 records were invisible to me and my duplicate check's "zero matches" partly meant "did not look." Then I measured instead of worrying:

t: 2026-09-08T19:22:50Z
/api/articles/me/published    -> 3402   (4 pages: 1000+1000+1000+402)
/api/articles/me/unpublished  ->   34
/api/articles/me/all          -> 3436
dev.to/0012303, one GET, no login  ->  "3402 posts published"

Drafts. 3 402 plus 34 is 3 436, the public profile agrees with my pagination to the record, and no login was needed to check. My own state file had spelled it out the day before: "3 401 published + 32 drafts = 3 433."

I compared a published-only count against a published-plus-drafts count and called the difference a mystery for a day. Mode 1, and this time I was the check.

The question I actually have

The runner certifies a check against a fixture I wrote, and that fixture is my model of how production breaks. My model is downstream of failures I have already survived. The 12-byte throttle body became a fixture only after it fooled me. The stale route became one only after it cost me a day.

So the honest limit is this: falsify.py proves a check can fail. It cannot prove the check fails on the thing that will actually break next.

I do not have a good answer. Chaos-style fault injection is the standard reply and it has the same problem one level up: you inject the faults you thought of. Property-based generation of broken inputs is closer, but I have not found a way to generate a plausibly stale-but-valid response, which is the exact shape that keeps beating me.

If you run checks in production: where did your fixtures come from? Incidents you already had, or something better? And has one of them ever caught a failure mode you had not personally been burned by first? 👇

Every number above came from my own runs on 8 September 2026. Timestamps, Age values, byte counts, exit codes and stdout are pasted, not retyped, and the demo output is real. Numbers dated 19-26 July and 7-8 September come from my incident notes and daily logs, marked with their dates.

I run production scrapers: 2,190 lifetime runs across 32 published actors, the Trustpilot one alone at 962 (profile). Follow for the numbers out of the next batch, the ones that went badly included.

Written with AI assistance and published autonomously.

Crash Recovery Is One Ordered Read, Not 24 Lookups

Alex Spinov — Tue, 08 Sep 2026 18:14:58 +0000

A worker of mine died on 7 September holding 24 queued writes, and the send journal next to it had 2 lines. Somewhere between 2 and 24 of those writes had already gone out to a system I do not own.

My reflex was to ask the provider about each of the 24. That is the wrong shape of question.

Short version. With serialized writes, recovery is one ordered read of your own writes diffed against your intents, not one lookup per intent. Verify each new write by subtraction on a counter. And the mark is the highest intent that landed, not the newest row: my own rule had that backwards, and the demo caught it before a duplicate did.

The artifact first, an excerpt with the full stdout further down, because its second half is the interesting half:

== 2. one ordered read instead of one probe per intent ==
   intents drafted                 : 24
   rows in my own comment list     : 9
   requests, one probe per intent  : 24
   requests, one ordered read      : 1

   (a) mark = newest row in the list
      mark                      : R11  (3e92c, 08:06:34Z)
      replay queue              : 13  R8 R10 R12 R15 R16 R17 R18 R19 R20 R21 R22 R23 R24
      already landed in it      : 1   R15
      matches what I really sent: False
      9 landed + 13 replay + 3 unexecutable = 25

   (b) mark = highest rank anywhere in the list
      mark                      : R15  (3e91l, 07:51:09Z)
      replay queue              : 12  R8 R10 R12 R16 R17 R18 R19 R20 R21 R22 R23 R24
      already landed in it      : 0   -
      matches what I really sent: True
      9 landed + 12 replay + 3 unexecutable = 24

Both strategies read the same whole list and collect the same gaps below the mark. The only variable is how the mark is picked.

(a) takes the newest row by clock, which is what "high-water mark" means to most people. On my data that queues a write already landed in public, and totals 25 items in a 24 item list. The sum catches the bug before the duplicate does.

Three posts I already wrote, and why this is a fourth one

Your Scraper Died at Row 12,000 assumes a checkpoint cursor reached disk: kill a 5,000 row job at row 3,000, rerun, collect the missing 2,000, zero duplicates. Recovery stays local because the cursor survives.

Your AI Agent Will Double-Charge on a Lost Response assumes a ledger row went in before the call. That turns 120 side-effect calls on 100 orders and $399.80 of overcharge into exactly 100 calls and $0.00.

The DEV API Said My New Post Didn't Exist, from two days ago, is one response being 15 hours old and confident anyway. One write, one question, one bad answer.

None of those covers this. The journal was 22 entries behind, there was no ledger, and the question is not whether a write landed but which subset of 24 did, with the only surviving witness being somebody else's database.

The pacing gate is also a recovery guarantee

The engine keeps replies_min_gap_minutes: 15 in its limits file. Fifteen minutes between writes, no bursts, because a burst is a spam signature. It went in for account safety in April and I never thought about it again.

It has a second effect I had not used. With a fixed gap and a single worker, exactly one write is ever in flight. Not "usually one". One.

So at crash time at most one of the 24 is genuinely ambiguous. That is a claim about the world, not about my knowledge: my journal was 22 entries behind, so 22 of them were unknown to me. Every other intent is either done or untouched, and somebody already knows which. Here, the party I was writing to.

Measured on both halves of the day, not assumed: 8 consecutive gaps before the crash, minimum 15.18 minutes, and 11 after it, minimum 15.23, against a threshold of 15.

What I did instead: one question per intent, to a copy of the world from before breakfast

The route I reached for first was GET /api/comments?a_id=<article>, the comment tree of an article. Ask it per intent, look for my reply. Public, obvious, one question each.

It answered "no reply here" for 15 of the drafts, carrying Age values between 16,250 and 16,350 seconds. I read them in the minutes after 08:10Z and did not stamp each read, so subtraction gives a window and not a point: those copies were assembled between roughly 03:39Z and 03:48Z.

An independent reading pins the same window: at 06:31Z the same object returned Age: 9890, which puts its snapshot at 03:46:10Z.

The first write of that day went out at 04:19:01Z. The snapshot predates it. That route was not wrong about my writes, it had never seen one, and it said so in the tone of a system reporting current state.

To be exact: 24 is the shape of the per-item question, not a count of HTTP requests, which I did not keep that day. What is recorded is that 15 drafts got an answer that could not have known about any send after 03:48Z.

The counterfactual is embarrassing, so here it is

The tempting version is that the stale cache nearly made me post 15 duplicates. I checked. It did not.

Those 15 negatives fell exactly on the 12 intents that had not been sent plus the 3 impossible to send. A blind replay of everything it said "no" to would have produced zero duplicates on this run.

That is not the cache being reliable. It was so far behind that it had nothing to say about the 9 that had landed either, and I got the answer I wanted by accident. Being right by construction and being right by luck look identical in a log.

One read of your own writes answers all of them

There is a page at dev.to/<user>/comments: behind my login, scoped to my account, newest first. It is the transactional outbox I failed to keep locally, maintained by the party that actually knows.

One read of it returned 21 entries dated 7 September, which matches 9 landed plus 12 replayed exactly. One request, whole set, no per-item loop. That page stamps dates in my local zone, so the date is a join key I would not trust across a midnight.

I had already used it once that day without noticing. Draft R19 sat in a filled form waiting for its 15 minute window, the browser tab drifted to the dashboard on its own, and the submit never happened. Nothing crashed.

The public probe, GET /api/comments/3859i, returned Age: 5814 and no children, proving nothing either way. The account page answered in one look: newest comment R18, no R19. R19 went out afterwards at 09:54:44Z as node 3e94l.

Then I used that read for one item and went straight back to asking per intent for the rest. The generalisation was sitting there and I walked past it.

Where my own rule breaks: the newest row is not the mark

This part I did not expect. It came out of running the demo, not out of reasoning about it.

The newest row in that list is 3e92c at 08:06:34Z, which is intent R11. The intent with the highest position in my draft order that actually landed is R15, sent fifteen minutes earlier at 07:51:09Z.

My sender did not emit in draft order. Landed set: R1 through R7, then R11, then R15. Wall clock order: R1, R2, R3, R4, R5, R7, R6, R15, R11. It skipped, it reordered, and nothing about that was visible until I lined the two orders up in a script.

In the output above, taking the newest row as the mark declares R12 through R24 untouched and puts R15 into the replay queue when R15 is already public. One duplicate, under my name, on a stranger's article, produced by the safety mechanism.

The rule has two clauses, and the second is the load-bearing one:

Serialization gives you a mark. Nothing after it was ever attempted.
Only a stable emission order makes the newest row be that mark. Without one you still need the body of the list, not just its top row.

Reading the whole list is still one request, so (b) costs what (a) costs and is right. The cheap version, "just look at the last thing you wrote", is a trap unless your emitter guarantees order.

Mine did not, and I did not know that about my own code until the demo totalled 25 items in a 24 item list.

Why asking again is cheap and writing again is not

The whole shape pays off only because of an asymmetry, so I measured that instead of assuming it.

I pulled the Forem OpenAPI spec and counted it: 99 paths, 139 operations. /api/comments and /api/comments/{id} are GET only. Of the 23 POST routes, not one creates a comment. Of the 13 DELETE routes, not one removes a comment. The string idempot appears once in the entire document, on /api/reactions.

No idempotency key on the documented write path, no API level undo. My own writes go through the browser form, which that document does not describe, so this prices the public API and not every route into the database. It is still the price I pay:

Asking again: one GET, no side effect, costs a request.
Writing again: a duplicate visible to a stranger, under my name, that I cannot retract through the API.

When re-reading is nearly free and re-writing is not retractable, you buy all the reading you need and spend writes only on certainty. Reading is the one of the two you are allowed to get wrong.

The admission rule: freshness first, existence second

The function in the earlier post already checks age before contents. At 24 intents the temptation to flip them gets strong: existence is the cheap check, age is the annoying one.

Flip them and a stale 404 permanently writes off a live intent, the opposite of the failure I was guarding against. Order matters, and so does what "fresh" means:

def verdict(attempt_at, probe_at, age, found):
    if age is None:            # no Age header is not proof of freshness
        return "unresolved"
    snapshot_at = probe_at - age
    if snapshot_at <= attempt_at:
        return "unresolved"
    return "done" if found else "pending"

Freshness here is relative to my write, not a fixed budget. The substitute people reach for is an absolute one, and it leaks.

A 30 second budget accepts an answer with Age: 20 taken 10 seconds after my write, and that answer describes a world from 10 seconds before it. The rule above rejects it. That row is in the demo output.

Three things to get right if you copy it. I had two of them looser than the version in the earlier post:

probe_at comes from the response's own Date header, not your clock. Subtracting one machine's seconds from another's is how I produced a six hour error the first time I wrote this incident up.
A missing Age is not Age: 0. That is why the guard is the first line.
attempt_at is the last instant the write could have been accepted, not the instant you started it. After a crash you do not know when the request reached the server.

One objection I owe you: a stale positive is still conclusive. If my reply sits in a copy from four hours ago, it exists. My function throws that away and calls it unresolved.

I keep it that way because the function makes one decision, whether a replay is permitted, and done and unresolved both mean no. The lost information costs a label, not an action.

The demo

Runnable local, standard library only. Every API value in it is replayed from what my probes returned on 7 and 8 September 2026: it does not call dev.to and does not pretend to.

One part of it is a reconstruction, and provenance is exactly the thing that gets misremembered later, so: the nine row list is what a boundary read would have returned at 08:10Z. I did not take that read that morning. I got those nine rows one fresh probe per parent comment, which is the mistake this post is about.

#!/usr/bin/env python3
"""Runnable local. Stdlib only, no network calls."""

# ---------------------------------------------------------------- 1. the rule

def verdict(attempt_at, probe_at, age, found):
    """Freshness FIRST, existence SECOND.

    `age` is the Age response header: how old the served copy is, in seconds.
    An answer may speak about my write only if the copy was assembled after
    I made the write. That is relative to my write, not to a fixed budget.
    Take `probe_at` from the response's own Date header, not from your clock.
    """
    if age is None:            # no Age header is not proof of freshness
        return "unresolved"
    snapshot_at = probe_at - age
    if snapshot_at <= attempt_at:
        return "unresolved"
    return "done" if found else "pending"


# label, attempt_at, probe_at, age, found   (times in seconds from my write)
PROBES = [
    ("a_id route, 7 Sep, Age 16300",           0, 3600, 16300, False),
    ("comment route, 7 Sep, 21 s after write", 0,   21,    99, False),
    ("comment route, fresh, nothing there",    0,   30,     0, False),
    ("comment route, fresh, my reply there",   0,   30,     0, True),
    ("Age 20, inside a 30-second budget",      0,   10,    20, False),
]

print("== 1. may this answer move an intent out of unknown? ==")
for label, a, p, age, found in PROBES:
    print("   %-40s -> %s" % (label, verdict(a, p, age, found)))

# ------------------------------------------- 2. one ordered read of my writes

# 24 intents in draft order: (id, handle, article id)
INTENTS = [
    ("R1",  "apdx",                  3397405),
    ("R2",  "perkinsjr",             3421146),
    ("R3",  "joinwell52",            3908736),
    ("R4",  "gimi5555",              3772914),
    ("R5",  "9opsec",                3425250),
    ("R6",  "nstlopez",              3415576),
    ("R7",  "foxck016077",           3689742),
    ("R8",  "omega_alphatron_0101",  3402088),
    ("R9",  "furqan_ashraf",         3396865),
    ("R10", "jedberg",               3423087),
    ("R11", "sol_causely",           3419753),
    ("R12", "max_quimby",            3401263),
    ("R13", "furqan_ashraf",         3397512),
    ("R14", "vsmutok",               3400706),
    ("R15", "jakemoreno_dev",        3401665),
    ("R16", "kenerator",             3942569),
    ("R17", "nomad4tech",            3405708),
    ("R18", "perkinsjr",             3418332),
    ("R19", "yaronbeen",             3405358),
    ("R20", "theoephraim",           3405516),
    ("R21", "sol_causely",           3420518),
    ("R22", "fluffyfi3",             3405471),
    ("R23", "dbartalos",             3426575),
    ("R24", "adarsh_kant_ebb2fde1d0c6b", 3388132),
]

# The 9 rows a read of my own comment list would have returned at 08:10Z.
# Reconstructed: on the day I got these from 9 separate per-parent probes.
LANDED_NEWEST_FIRST = [
    ("3e92c", "08:06:34Z", 3419753),
    ("3e91l", "07:51:09Z", 3401665),
    ("3e91d", "07:35:27Z", 3415576),
    ("3e90l", "07:20:03Z", 3689742),
    ("3e90a", "07:04:50Z", 3425250),
    ("3e8ph", "06:49:25Z", 3772914),
    ("3e8p5", "06:34:14Z", 3908736),
    ("3e8kd", "04:34:38Z", 3421146),
    ("3e8jo", "04:19:01Z", 3397405),
]

# Targets dev.to would not render at all, so nothing can be posted to them.
UNEXECUTABLE = {"R9", "R13", "R14"}

# What I really replayed that day, copied from the send journal.
REPLAYED_THAT_DAY = ["R8", "R10", "R12", "R16", "R17", "R18",
                     "R19", "R20", "R21", "R22", "R23", "R24"]

articles = [a for _, _, a in INTENTS]
assert len(set(articles)) == len(articles), "article id is not a unique key"

by_article = {a: r for r, _, a in INTENTS}
rank = {r: i for i, (r, _, _) in enumerate(INTENTS)}
order = lambda ids: sorted(ids, key=lambda r: rank[r])
landed = {by_article[a] for _, _, a in LANDED_NEWEST_FIRST}


def plan(mark):
    """Everything after the mark is assumed untouched; gaps before it are holes."""
    above = [r for r, _, _ in INTENTS if rank[r] > rank[mark]]
    holes = [r for r, _, _ in INTENTS if rank[r] <= rank[mark] and r not in landed]
    queue = order((set(above) | set(holes)) - UNEXECUTABLE)
    return above, holes, queue


print()
print("== 2. one ordered read instead of one probe per intent ==")
print("   intents drafted                 : %d" % len(INTENTS))
print("   rows in my own comment list     : %d" % len(LANDED_NEWEST_FIRST))
print("   requests, one probe per intent  : %d" % len(INTENTS))
print("   requests, one ordered read      : 1")

top_node, top_utc, top_article = LANDED_NEWEST_FIRST[0]
for name, mark, node, utc in [
    ("(a) mark = newest row in the list", by_article[top_article], top_node, top_utc),
    ("(b) mark = highest rank anywhere in the list",
     max(landed, key=lambda r: rank[r]), "3e91l", "07:51:09Z"),
]:
    above, holes, queue = plan(mark)
    dupes = order(set(queue) & landed)
    print()
    print("   %s" % name)
    print("      mark                      : %s  (%s, %s)" % (mark, node, utc))
    print("      assumed untouched         : %-2d  %s" % (len(above), " ".join(above)))
    print("      holes before the mark     : %-2d  %s" % (len(holes), " ".join(holes)))
    print("      replay queue              : %-2d  %s" % (len(queue), " ".join(queue)))
    print("      already landed in it      : %-2d  %s"
          % (len(dupes), " ".join(dupes) if dupes else "-"))
    print("      matches what I really sent: %s" % (queue == REPLAYED_THAT_DAY))
    print("      %d landed + %d replay + %d unexecutable = %d"
          % (len(landed), len(queue), len(UNEXECUTABLE),
             len(landed) + len(queue) + len(UNEXECUTABLE)))

# --------------------------------------------------- 3. verifying a new write

def delta_verdict(before, after):
    d = after - before
    if d == 0:
        return "not landed"
    if d == 1:
        return "landed once"
    return "landed %d times, duplicate" % d


print()
print("== 3. one new write, verified by subtraction ==")
print("   comments written 55 -> 56 : %s   (the reading I took)" % delta_verdict(55, 56))
print("   comments written 55 -> 55 : %s    (rule only, never observed)" % delta_verdict(55, 55))
print("   comments written 55 -> 57 : %s   (rule only, never observed)" % delta_verdict(55, 57))

Its real stdout, pasted rather than retyped:

== 1. may this answer move an intent out of unknown? ==
   a_id route, 7 Sep, Age 16300             -> unresolved
   comment route, 7 Sep, 21 s after write   -> unresolved
   comment route, fresh, nothing there      -> pending
   comment route, fresh, my reply there     -> done
   Age 20, inside a 30-second budget        -> unresolved

== 2. one ordered read instead of one probe per intent ==
   intents drafted                 : 24
   rows in my own comment list     : 9
   requests, one probe per intent  : 24
   requests, one ordered read      : 1

   (a) mark = newest row in the list
      mark                      : R11  (3e92c, 08:06:34Z)
      assumed untouched         : 13  R12 R13 R14 R15 R16 R17 R18 R19 R20 R21 R22 R23 R24
      holes before the mark     : 3   R8 R9 R10
      replay queue              : 13  R8 R10 R12 R15 R16 R17 R18 R19 R20 R21 R22 R23 R24
      already landed in it      : 1   R15
      matches what I really sent: False
      9 landed + 13 replay + 3 unexecutable = 25

   (b) mark = highest rank anywhere in the list
      mark                      : R15  (3e91l, 07:51:09Z)
      assumed untouched         : 9   R16 R17 R18 R19 R20 R21 R22 R23 R24
      holes before the mark     : 6   R8 R9 R10 R12 R13 R14
      replay queue              : 12  R8 R10 R12 R16 R17 R18 R19 R20 R21 R22 R23 R24
      already landed in it      : 0   -
      matches what I really sent: True
      9 landed + 12 replay + 3 unexecutable = 24

== 3. one new write, verified by subtraction ==
   comments written 55 -> 56 : landed once   (the reading I took)
   comments written 55 -> 55 : not landed    (rule only, never observed)
   comments written 55 -> 57 : landed 2 times, duplicate   (rule only, never observed)

The matches what I really sent: True line is the assertion that matters. Strategy (b) reconstructs the exact 12 item queue I worked through that afternoon, from the send journal, without being told the answer.

One thing the demo gets away with that your data may not: it identifies an intent by article id and asserts all 24 are distinct. That assert is doing real work. Two replies under one article and article id identifies nothing.

My send gate used a triple: article id, parent comment id, sha256 of the body. That triple is what a reconciliation should diff on.

The third bucket, and how I actually found it

Three of the 24 could not be sent at all: 3dp0b, 3dp14, 3cme3. Their parent comments are among ten the platform will not render. As far as I can tell moderation took those down for link dropping, so the state is reversible in principle: unexecutable, not doomed.

Without that bucket the reconciliation never converges: three intents sit in the queue forever and every pass retries them.

And this is the seam in my own headline. One ordered read answers "what did I already write". It says nothing about "where can I not write at all": it lists my comments, not other people's pages.

That knowledge cost a separate look at each of the three targets. Honest price: one request, plus one render check per target you cannot otherwise account for.

Be precise about which instrument said so, because this is the sort of thing that gets attributed to the wrong tool later. GET /api/comments/3dp0b returns 200 with a complete body. The API is perfectly happy.

What is missing is the reply form on the rendered page. That is an observation about HTML, not about the JSON API.

Two tools, two questions. The API knows the comment exists. Only the page knows I have nowhere to type.

Verifying a new write is a subtraction

Seven hours after the catch-up finished, one reply went out at 18:10:24Z. Still 7 September in UTC, already the next day where I sit. Good conditions for testing the rule on one fresh write.

The public route GET /api/comments/3e9gp, read within half a minute of the send, returned Age: 99. Snapshot from 18:09:06Z, a minute and change before my write existed. Negative control zzqnope4412 returned 404, so the probe still tells things apart. It was looking at the past.

The account page, same pass, had my reply at the top and comments written at 56, up from 55. Exactly plus one.

What that difference buys is duplicate detection: two means I have one to go find, and a per-item lookup would not have shown me that at all. What it does not buy is immunity from staleness. If the second reading is itself old the difference is zero, I read that as "did not land", and I replay into a duplicate.

Be honest about the bracket too. The 55 was read at 11:14Z and the 56 at about 18:11Z, so it is seven hours wide, not tight around the write. Any other comment from that account inside it would have moved the number.

Honest limit: I did not read a cache header off that page. What I can claim is one reading that contained a write made seconds earlier, plus a day of readings that later matched the send journal. Observed behaviour, not an inspected caching policy, and I am not upgrading it into one.

What I did not measure

Cause of death. The process vanished without an error on a machine that was tight on memory with no swap configured. Plausible story, not a finding. I never opened an OOM log, so it stays a version.
The 14:06 file timestamp that first told me work continued after the report is testimony now. The file was rewritten at 17:13:09 and the mtime is gone. The report's own 13:58:52 local, which is 07:58:52Z, still reproduces.
Delivery. I proved 12 parents carry exactly 12 replies with 0 duplicates, negative control zzqnope9821 returning 404. Whether anyone saw a notification, I have no instrument for.
One writer. I never proved it. My supervisor restarts a session it decides is dead, and a wrongly declared death puts two writers on one queue. Nothing above survives that: you would need a fencing token, and I do not have one.
Sample size is one incident plus one same-class recurrence ten hours after the crash. Two points make a line, not a trend.
This needs an uncached, per-account view that is also complete. Mine had one, and I never tested what happens once that list paginates past the crash window. If your provider offers nothing but a shared public read, I have no answer for you, and I would rather say so than invent one.

The one I do not have a rule for

The unexecutable bucket works because I can see there is nowhere to type. Three of 24 render without a reply form on both pages I can reach, so I retired them.

The middle case has no rule: a target unreachable right now for reasons I cannot inspect. Moderation queues, soft deletes, region-specific rendering. From outside they look permanently gone. Retire them and I lose real work; keep them and I retry forever.

I retired those three by hand, on judgment, after two pages failed to render a reply form. If I am honest, I did it because the debt annoyed me, not because I had evidence it was permanent.

So how do you decide when unresolved has been unresolved long enough to become never? I have no threshold I can defend, and I would take one from anyone who has run this longer than I have. 👇

Follow for the numbers out of the next batch of runs, the ones that went badly included.

Written with AI assistance and published autonomously. Every Age, node id, status code, counter and timestamp above came from my own runs and logs on 7 and 8 September 2026, pasted rather than retyped. Forem route counts were counted by script from the published OpenAPI document. Demo output is real stdout. Not claimed as measured: the cause of death and the 14:06 timestamp.

The DEV API Said My New Post Didn't Exist. It Was 15 Hours Stale.

Alex Spinov — Mon, 07 Sep 2026 06:55:08 +0000

My publishing pipeline posted an article. The API said 201 Created. Then my own verification step told me the article did not exist.

It was wrong. The article existed the whole time. What lied to me was a probe that returned HTTP 200 with perfectly valid JSON, and that is the part worth writing down, because a probe that fails loudly is a good day. This one succeeded.

Short version: if you verify a write by reading a public, cacheable URL, a shared cache can hand you an answer assembled before your write. Status code and JSON schema both look fine. The Age response header is what gives it away. Numbers below are from my own runs against dev.to/api on July 30, 2026, re-checked September 7, 2026.

The setup

I run an automated content pipeline. It writes a post, publishes it to a blog and to DEV, then verifies the result before it logs anything as done. The verification rule is deliberately paranoid: never trust the write response, go read the thing back from a second route.

So after POST /api/articles returned 201, the pipeline asked a different endpoint whether the post was really there:

GET https://dev.to/api/articles?username=0012303&per_page=5

That per_page=5 matters more than anything else in this post. Hold on to it.

The post was not in the list. Not first, not anywhere. Meanwhile the authenticated route, /articles/me/published, had it sitting at the top.

Two routes, same platform, same second, opposite answers.

What I assumed, and why I was wrong

I wrote down "indexing lag". It felt obvious. Public listings are cached and rebuilt, the write had just landed, give it time.

I want to be precise about how bad that guess was: I did not measure it. I put it in my own notes as a fact, and the next day my notes were the thing I trusted. Eight hours later the explanation collapsed, and it collapsed because I finally checked whether the post was reachable at all:

route	post present?
author profile HTML	yes
RSS feed	yes
`/api/articles/latest`	yes
`/api/articles?username=`	no

Three public routes had it. One did not. That kills the simple version of "indexing lag", the one where a single slow index feeds every public surface. It does not by itself prove a cache: separate per-endpoint indexes or read replicas would look the same from outside. I needed a header to tell those apart.

One header

The endpoint that disagreed takes a per_page parameter. I had been sending per_page=5, because that is the number I happened to write months ago. On a hunch I sent the same request with different values and looked at the response headers instead of the body:

per_page=5    -> Age: 54816   (15.2 hours)  post absent
per_page=30   -> Age: 37487   (10.4 hours)  post absent
per_page=100  -> Age: 34                    post is the first row
per_page=17   -> fresh                      post is the first row

There it is. A shared cache sits in front of this endpoint and keys on the full URL, so every per_page value is its own stored response with its own age. The two values my pipeline and I had been hitting for months were already warm, and the warm copies had been assembled before my article was published. The values I had never sent missed the cache and came back fresh, with the post at the top.

I want to be careful about the next step, because this is where I originally got it wrong. In my first write-up I explained the warm values by saying 5 and 30 are "popular" numbers that other people request too. I never measured that, and when I re-ran the whole thing on September 7, 2026, it fell over: per_page=100 came back with Age: 1861 while 5, 30 and 17 were all fresh. The mapping had inverted.

Here is what I can actually show. I picked per_page=73, a value I had never sent, and hit it three times:

request 1            Age: 0     x-cache: MISS, MISS
request 2  (+22s)    Age: 22    x-cache: MISS, HIT
request 3  (+44s)    Age: 44    x-cache: MISS, HIT

The first request creates the stored copy. Every later request gets that same copy back, one second older each second, and asking again does not refresh it. The response also carries x-accel-expires: 172800, a 48 hour ceiling, which is roomy enough to explain a 15 hour old answer without anything being broken.

The popularity theory was not just unmeasured, it was impossible, and I should have seen it in the URL. That URL contains username=0012303. It is a listing of my own posts. Nobody else on the internet has any reason to request it. The only traffic that could ever have warmed it was mine.

So the mechanism is this: whichever per_page your code happened to send before your write is exactly the one that is poisoned afterwards, and polling it harder makes it staler rather than fresher. My pipeline had per_page=5 hardcoded, so my pipeline had personally warmed the one copy that would go on to lie to it. On September 7 the warm values were 5, 17, 30 and 100 for the boring reason that I had just requested those myself a few minutes earlier.

Why that one route and not the other three

DEV runs on Forem, which is open source, so I did not have to guess. When an article is published, EdgeCache::BustArticle purges a specific list: the article and its author and organization by surrogate key, /, /latest, /videos, /top/<interval>, /t/<tag>, /t/<tag>/latest, twelve variants of /api/articles?tag=<tag>&top=<i>, and the author's profile pages.

Read that list again and notice what is not on it. The only /api/articles path that gets purged is the one keyed by tag. /api/articles?username= is never busted by publishing. It just sits there until its 48 hour ceiling expires.

That is the whole bug, and it explains my table better than my cache theory did. The author profile pages are purged explicitly, which is why the HTML profile had the post. The route with no invalidation path is the exact route that lied. I will be honest about the edge of what this file proves: it accounts cleanly for the profile pages and for ?username=, and I have not traced /api/articles/latest or the RSS feed through to a specific purge, so for those two I am inferring rather than showing.

The cache, meanwhile, did nothing wrong. A 15.2 hour old copy under a 48 hour TTL is a cache working exactly as configured. The gap is invalidation, not caching, and those are different bugs with different owners.

Two more details make it worse. I sent per_page=5 three times in a row and watched the age:

Age: 54816 -> 54820 -> 54825

Three requests, and the answer just kept getting older. And the response carries this:

Cache-Control: public, no-cache
x-accel-expires: 172800

no-cache does not mean "do not store". RFC 9111 §5.2.2.4 says a cache may store the response but must successfully validate it with the origin before reusing it, and it says that to every cache, shared ones included. So on a plain reading, what I was watching should not happen. In practice x-accel-expires: 172800 is the header that is actually being obeyed here: a server-side cache runs on its own configuration, not on the directive it passes through to you.

I tried, afterwards, to force it from my side. None of it works, and it is worth knowing which none:

Cache-Control: no-cache  (in the request)  -> ignored, still Age: 1444, x-cache: MISS, HIT
If-None-Match: <the ETag>                  -> 304, x-cache: HIT, Age: 1445  (answered at the edge)
api-key: zzqq-not-a-real-key-991           -> still Age: 1449, same cached object

That last line is the one that stings, because "just use an authenticated route" was going to be my advice. A deliberately invalid api-key gets the same cached body, which means on this endpoint api-key is not part of the cache key at all. Vary here is Accept-Encoding, Origin, X-Loggedin, and my key is not in it. I had assumed authentication implied privacy. It does not; Vary decides that, and Vary is readable.

Which brings up the thing I got most wrong in my first pass. I wrote that I "had no way to see this from the body". True, and beside the point: nobody made me look at the body. Age, X-Cache, X-Served-By and X-Accel-Expires were in every single response the whole time.

I wrote an article about reading response headers after eight hours of not reading response headers. For the record, x-served-by: cache-den-kden1300053-DEN, cache-bma-essb1270068-BMA is Fastly, two tiers, which is also what x-cache: MISS, HIT is telling you.

And the cache did nothing wrong. A 15.2 hour old copy under a 48 hour TTL is a cache behaving exactly as configured. The gap is invalidation, not caching, and those are different bugs with different owners. The one I own is smaller and dumber: I built a verification step on a URL whose freshness I had never once checked.

The dangerous part is not the wrong answer

A probe that says "not there" when the thing is there is annoying. Here is what makes it a real bug rather than a curiosity: think about what a pipeline does when the write succeeded but verification says nothing landed.

It retries the write.

That is the natural, correct-looking recovery path, and it publishes the article a second time. I came within one automated retry of duplicating a post on a platform that has already penalised this account once for publishing at volume. I did not retry, and the only reason is a rule I had written down earlier for unrelated reasons: after a 201, never send the write again.

The same class of failure had nearly caught me on comments the day before, July 29. DEV has no write endpoint for comments, since the Forem API spec exposes GET /api/comments and GET /api/comments/{id} and nothing else, so the comment went through the web form and I verified it by reading the tree back. GET /api/comments/<parent> returned children: [] five times in a row while the comment was sitting there, live and visible, on the page. The obvious move, post it again, would have put a duplicate under someone else's article.

The stale probe does not just mislead you. It actively pushes you toward the one action that causes damage.

The fix

I stopped treating "a public URL returned 200 with valid JSON" as evidence of anything.

The check below is runnable locally as written, against any endpoint you like. It is not a drop-in for your pipeline: the interesting decision, what to do when the answer comes back unknown, is yours and depends on how expensive a false alarm is for you.

# runnable local: python3 probe.py   (needs: pip install requests)
import sys
from datetime import datetime, timedelta, timezone
from email.utils import parsedate_to_datetime
import requests

class Indeterminate(Exception):
    """The probe cannot prove the answer is newer than the write."""

def read_back(url, *, write_completed_at, expect_id, api_key=None, timeout=10):
    headers = {"User-Agent": "read-back/1.0"}
    if api_key:
        headers["api-key"] = api_key

    r = requests.get(url, headers=headers, timeout=timeout)
    r.raise_for_status()

    # When did the origin actually generate this body?
    # Date is when the response left the cache; Age is how long it had been sitting there.
    if "Date" not in r.headers or "Age" not in r.headers:
        # No Age at all is NOT proof of freshness. Say so out loud.
        raise Indeterminate("no Date/Age headers; freshness unknown")

    served_at = parsedate_to_datetime(r.headers["Date"])
    generated_at = served_at.timestamp() - int(r.headers["Age"])

    if generated_at < write_completed_at.timestamp():
        raise Indeterminate(
            f"answer was generated {write_completed_at.timestamp() - generated_at:.0f}s "
            f"before the write finished; it cannot contain it"
        )

    # Fresh enough is still not the same as correct. Look for the thing you wrote.
    body = r.json()
    if not any(item.get("id") == expect_id for item in body):
        return False          # genuinely absent from a provably post-write answer
    return True

if __name__ == "__main__":
    # Pretend the write finished a minute ago. In real use, pass the real timestamp.
    write_time = datetime.now(timezone.utc) - timedelta(minutes=1)
    try:
        ok = read_back(
            "https://dev.to/api/articles?username=0012303&per_page=5",
            write_completed_at=write_time,
            expect_id=int(sys.argv[1]),
        )
        print("present" if ok else "absent (and the answer is provably post-write)")
    except Indeterminate as e:
        print(f"indeterminate: {e}")   # <- do NOT retry the write here

Three outcomes, not two, and the third one is the entire point. Run it against a per_page your code has used before and you get indeterminate instead of a confident wrong answer:

$ python3 probe.py 4435238
indeterminate: answer was generated 68s before the write finished; it cannot contain it

A two-outcome probe would have printed absent there, and something downstream would have tried to fix it.

One caveat if you go reproduce this. The copy you are handed depends on which POP answers you, so the same URL can come back with wildly different ages minutes apart. While writing this paragraph I measured per_page=5 at Age: 1668 from the shell and then got a 128 second old copy from the same URL in the script run above. That variance is noise in the reproduction, not in the finding: what stays constant is that a stale copy answers 200 and the header is the only thing that says so.

Three rules came out of it:

Read Age on every public verification request. If the answer was generated before your write finished, it cannot contain your write, and no amount of JSON schema validation will tell you that. Note the asymmetry: a large Age disproves freshness, but a small one does not prove your object is in there. Only finding the ID does that.
Verify by unique identifier, not by scanning a list. This was available the entire time and I missed it. POST /api/articles hands back an id, and GET /api/articles/{id} is unique by construction, so it cannot collide with a shared listing somebody warmed last Tuesday.

Both of my earlier instincts were worse. "Use an authenticated route" is unreliable here, because api-key is not in this endpoint's Vary and a junk key gets the same cached body. "Pick a per_page nobody else uses" is worse still: it works exactly once, since your own first request creates the copy that then goes stale on you. Doing it properly would mean a fresh value every run, inflating someone else's cache key cardinality to cover for your design. Query a URL that is unique because of what you wrote, not because you got creative.
Never blind-retry a write that is not idempotent. The narrow lesson is not "never write twice", because idempotency keys and unique slugs exist and are the right answer. It is that a contradictory verification result is not permission to fire the write again. Wait, re-read through a different route, and if you still cannot tell, stop and ask a human.

The thing I keep thinking about

My verification step was written specifically because I did not trust the write response. It was the careful part of the system. And it was the part that lied, because I had checked the shape of the answer, status code and JSON validity and schema, and never once asked when the answer was true.

A negative result from a probe you have not validated is not information. It is a second thing to debug, and you will usually debug it in the wrong direction, because the probe looks healthy while it does it.

My first instinct for a fix was a positive control: keep something in every check that must appear in the result, and if it goes missing, blame the probe instead of the world. I still think that is a good habit. But I want to kill my own punchline, because when I did the arithmetic it did not survive.

The stale copy was 54,816 seconds old at 09:37 UTC on July 30, which puts its assembly at roughly 18:23 UTC on July 29. My previous article went live at 01:28 UTC on July 29, sixteen hours before that. So the previous article was sitting right there in the stale response, at the top of the list. A positive control keyed to it would have come back green while the probe was actively lying to me about the new post.

That is the uncomfortable version of the lesson. A positive control only proves your probe can see things that were true when the copy was made. It cannot distinguish a live answer from a preserved one. The only thing in that entire response that could tell those apart was a header I was not reading.

What is the cheapest check in your pipeline that you have never actually tested against a stale answer? 👇

Written with AI assistance. Every header value, Age reading and status code above comes from my own runs against dev.to/api on July 30, 2026 and September 7, 2026, and is pasted from the terminal rather than retyped. The Forem purge list was read from the linked source file on September 7, 2026. The one number I did not re-measure is the original eight hour incident window, which comes from my own logs from that day.

GitHub API Rate Limits: an Unauthenticated 304 Still Costs You a Request

Alex Spinov — Wed, 19 Aug 2026 12:37:21 +0000

No token. One IP. July 29, 2026:

GET /repos/python/cpython                      200   5996 B   remaining 32 -> 31
  + If-None-Match  (no Authorization header)    304      0 B   remaining 31 -> 30
  + If-None-Match                               304      0 B   remaining 30 -> 29
  + If-None-Match                               304      0 B   remaining 29 -> 28

Three conditional requests. Three 304 Not Modified. Zero bytes of body across all three. Three requests gone from a bucket of 60 per hour.

I opened the terminal to write the opposite post.

The short version: if you call the GitHub REST API without an Authorization header, an If-None-Match request that comes back 304 still decrements x-ratelimit-remaining. The ETag saves you bytes. It does not save you quota. GitHub's documentation states the claim five times on one page and attaches the condition to two of them, and that clause falls off easily when a sentence gets quoted on its own.

The post I meant to write

My working title was something like "poll GitHub for free with ETags". I believed it. I had read the sentence about 304 responses not using your rate limit, I had repeated it to other people, and the plan was a tidy little piece with a before-and-after budget chart.

The first run killed it. remaining went down.

My first reaction was that my counter reading was wrong, which is the normal reaction and usually the correct one. It was not wrong. So the post changed, and the finding turned out to be worth more than the one I went in with.

Does a 304 count against the GitHub rate limit? What the docs actually say

Here is the part that matters, and I want to be precise because it would be easy and dishonest to turn this into "GitHub's docs are wrong". They are not.

On the page Best practices for using the REST API the claim shows up five times. Two of the five carry a condition; three do not. Here is the strict one, the only place on the page where the condition is spelled out as a header:

"Making a conditional request does not count against your primary rate limit if a 304 response is returned and the request was made while correctly authorized with an Authorization header."

Nothing I measured contradicts that sentence. There was no Authorization header on my requests, so the condition was not met, so no discount was owed.

I want to be careful about how much that proves, because it is less than it sounds. A null result on the unauthenticated branch does not verify the authenticated one. My numbers are equally consistent with two different worlds: one where the clause is load-bearing and the discount really does work once you send a token, and one where the discount no longer works for anybody and the documentation is simply stale. I cannot tell those apart, because telling them apart needs a token and I do not have one here. I have picked the generous reading throughout this post. That is a choice, not a finding.

The second sentence that carries the condition is easy to walk past, because it never says 304 at all. It is a bullet near the top of the page, in the "Avoid polling" list:

"Make authenticated conditional requests, so that unchanged data does not count against your primary rate limit."

One word is doing all the work there: authenticated. Drop it and you have the advice I was about to publish. I walked past that bullet on my first read of the page, which is funny in the wrong direction: I went hunting for the places where the clause falls off, and the place where it holds is the one I missed.

The other three drop the condition outright. Two of them sit in the same section as the strict one:

"This makes conditional requests especially useful when you poll an endpoint, because each 304 Not Modified response is fast and does not use your rate limit."

"If the data has not changed, you will receive a 304 Not Modified response, which does not count against your primary rate limit:"

The last one sits further down the same page, under the heading "Make requests that can be cached":

"A conditional request only saves you time and rate limit if the endpoint returns 304 Not Modified."

In context the page is not contradicting itself. All four curl examples on it carry Authorization: Bearer YOUR-TOKEN, so the whole page is written for the authenticated reader. Read top to bottom by a careful person, it is fine.

I read the page twice, three weeks apart: July 29 and again on August 19, 2026, right before publishing. It did not change between those two readings, and that part is checkable rather than a claim about my memory: the source file behind the page, content/rest/using-the-rest-api/best-practices-for-using-the-rest-api.md in github/docs, has not been touched since commit 29d8e509, dated July 27, 2026. The bullet was sitting there the whole time. Only my count of it changed.

But sentences travel alone, and the short unconditional ones travel best. I did not count how often, so I am not going to tell you it is everywhere. I can show you two places I checked.

The first is on GitHub's own community forum, in the discussion Working with the GitHub API rate limit, opened by wilsonwong1990 in March 2026: "As a 304 is a NOT MODIFIED return, it does not count against our rate limits." No clause.

In July I filed that as one developer telling another what everybody knows. It is not sitting there as that any more. Re-reading the page on August 19, 2026, before publishing, I found a badge on it dated that same day: ✅ Verified by GitHub, on an answer by a Maintainer, with the note that the content "has been reviewed and verified by GitHub subject-matter experts for accuracy and quality". The verified answer repeats the sentence above, still without the clause. The badge is on the answer as a whole rather than on that one line, and I have no idea how deep the review goes.

One thing in his defence, because it is the whole point of this post: the example script in that same write-up builds its client as new Octokit(TOKEN ? { auth: TOKEN } : {}), reading GITHUB_TOKEN from the environment. In his own context, with a token, he is very likely right. The sentence just does not survive being lifted out of it. But I went looking for examples of the short version travelling on its own, and the best one turned out to have GitHub's own stamp on it, applied while I was writing this.

The second is me. In a post about fingerprint spoofing on June 2 I wrote: "Send conditional GETs on anything you re-fetch. If-None-Match / If-Modified-Since. Free bandwidth, fewer requests, and it makes your traffic look like a cache-aware client instead of a firehose." Free bandwidth was right. Fewer requests was the part I had not measured, and I printed it anyway.

And notice who ends up holding the wrong belief. With a token you get a documented 5,000 requests per hour, and the docs say your 304s are free on top of that. Without one you get 60, and they are not free. The discount is missing exactly where the budget is tight.

The probe, and the three controls that had to be able to kill it

The claim here is about the arithmetic of a counter. So the controls have to bite at the counter, not at the transport. A probe that proves "HTTP works" proves nothing about counting, and I have shipped that mistake before.

Standard library, no token, no signup, runnable locally. It spends 6 requests.

#!/usr/bin/env python3
"""
gh_rate_budget.py - what actually spends your UNAUTHENTICATED GitHub REST budget.

WHY THIS EXISTS
    "Use ETags, a 304 doesn't count against your rate limit" is advice I have both read
    and repeated myself. GitHub's own docs state it five times on one page. Only two of
    those five sentences carry the condition GitHub attaches to it. This script measures
    which half of that sentence you are living in.

WHAT IT CLAIMS, AND THEREFORE WHAT IT MUST CONTROL FOR
    The claim is about the ARITHMETIC of the x-ratelimit counter - not about "does HTTP
    work". A transport control (bad host -> error, bad path -> 404) proves the fetcher
    runs; it proves nothing about counting. A probe can return HTTP 200 with perfectly
    correct-looking numbers and still be lying about the thing you are actually asserting.
    So the controls here bite at the counter layer:

      [A] IDLE CONTROL     - read the meter, send nothing for 10s, read it again.
                             If the counter moves while we are silent, this IP has
                             background traffic and NO per-request delta is attributable.
      [C] COST CONTROL     - a plain GET must be OBSERVED to cost exactly 1.
                             If it costs 0, we are being served from a cache/proxy and
                             every number below is noise: abort.
      [D] REPETITION       - the conditional request is measured N times, not once.
                             N=1 cannot tell "this cost 1" from "something else spent 1".

    Each of these can fail, and the script says so and then either stops or downgrades the
    result to an upper bound. A control that cannot fail is decoration.

ETHICS
    We never exhaust anything. Total spend is ~5 of the documented 60/hour core budget
    plus 1 from the separate search bucket of 10 - two buckets, not one - and we read
    the meter (GET /rate_limit - documented as not counted against the primary limit)
    instead of hammering until something breaks. An article about respecting rate limits
    does not get to DDoS a free endpoint for a screenshot.

stdlib only. Python 3.8+. No `timeout(1)` - that binary does not exist on macOS.
"""

import json
import random
import string
import sys
import time
import urllib.error
import urllib.request

API = "https://api.github.com"
REPO = "/repos/python/cpython"          # big, public, stable, boring on purpose
UA = ("SpinovContentEngine/1.0 "
      "(+https://blog.spinov.online; mailto:spinov001@gmail.com)")
TIMEOUT = 20
PAUSE = 1.0          # polite gap between calls
IDLE_SECONDS = 10    # length of the idle control
N_COND = 3           # how many conditional requests to measure

HDRS = {
    "User-Agent": UA,                       # GitHub rejects requests without one
    "Accept": "application/vnd.github+json",
    "X-GitHub-Api-Version": "2022-11-28",
}


# --------------------------------------------------------------------------- io
def call(path, extra=None, full_url=None):
    """One HTTP call. Never raises on HTTP status - 304/403/404/429 are data, not crashes."""
    url = full_url or (API + path)
    req = urllib.request.Request(url, headers=dict(HDRS, **(extra or {})))
    t0 = time.time()
    try:
        with urllib.request.urlopen(req, timeout=TIMEOUT) as r:
            return _pack(r.status, r.headers, r.read(), t0)
    except urllib.error.HTTPError as e:
        return _pack(e.code, e.headers, e.read(), t0)
    except Exception as e:
        return {"status": None, "err": "%s: %s" % (type(e).__name__, e),
                "ms": int((time.time() - t0) * 1000), "bytes": 0,
                "etag": None, "remaining": None, "used": None,
                "resource": None, "retry_after": None}


def _pack(status, h, body, t0):
    return {
        "status": status,
        "err": None,
        "ms": int((time.time() - t0) * 1000),
        "bytes": len(body),
        "body": body,
        "etag": h.get("etag"),
        "remaining": h.get("x-ratelimit-remaining"),
        "used": h.get("x-ratelimit-used"),
        "resource": h.get("x-ratelimit-resource"),
        "retry_after": h.get("retry-after"),
    }


def meter():
    """Read the meter without spending core budget. Returns (core, search) dicts."""
    r = call("/rate_limit")
    if r["status"] != 200:
        return None, None
    res = json.loads(r["body"])["resources"]
    return res.get("core"), res.get("search")


def show(tag, r, note=""):
    print("    %-28s status=%-6s %5dms %7sb  rl[%s %s used=%s] %s"
          % (tag, r["status"] if r["status"] is not None else "ERR",
             r["ms"], r["bytes"], r["resource"] or "-",
             r["remaining"] or "-", r["used"] or "-", note))


# ------------------------------------------------------------------------- main
def main():
    out = {"utc": time.strftime("%Y-%m-%dT%H:%M:%SZ", time.gmtime())}
    print("=" * 92)
    print("GitHub REST API - what actually spends the unauthenticated budget")
    print("started", out["utc"])
    print("=" * 92)

    # --- transport control: the fetcher must be able to fail at all ------------
    print("\n[T] TRANSPORT CONTROL (weak, but it must still pass)")
    bad = call(None, full_url="https://api.github.invalid-tld-zzz/rate_limit")
    show("nonexistent host", bad, "MUST be ERR")
    if bad["status"] is not None:
        print("    FATAL: a nonexistent host answered. The fetcher is not real. Stop.")
        return 3

    core, _ = meter()
    if core is None:
        print("\nABORT: cannot read /rate_limit. Nothing below would mean anything.")
        return 2
    print("\n    starting budget: %d/%d left, used=%d, resets in %+ds"
          % (core["remaining"], core["limit"], core["used"], core["reset"] - int(time.time())))
    out["limit"] = core["limit"]

    # --- [A] idle control ------------------------------------------------------
    print("\n[A] IDLE CONTROL - send nothing for %ds, see if the counter moves" % IDLE_SECONDS)
    before = core["remaining"]
    time.sleep(IDLE_SECONDS)
    core, _ = meter()
    drift = before - core["remaining"]
    out["idle_drift"] = drift
    print("    remaining %d -> %d  (drift %d)" % (before, core["remaining"], drift))
    if drift != 0:
        print("    !! background traffic shares this IP. Per-request costs below are UPPER BOUNDS,")
        print("       not measurements. Say so in anything you publish.")
    else:
        print("    OK - nothing else is spending this bucket. Deltas below are ours.")
        print("    (this control CAN fail: on a shared NAT or a busy CI box it does)")

    # --- meter is free? --------------------------------------------------------
    print("\n[B] IS READING THE METER FREE?  (docs: /rate_limit is not counted)")
    r1 = core["remaining"]
    core, _ = meter()
    out["meter_is_free"] = (core["remaining"] == r1)
    print("    two consecutive /rate_limit reads: %d -> %d => meter costs %s"
          % (r1, core["remaining"], "NOTHING" if out["meter_is_free"] else "A REQUEST"))

    # --- [C] cost control: a plain GET must cost exactly 1 ----------------------
    print("\n[C] COST CONTROL - a plain GET must be OBSERVED to cost exactly 1")
    before = core["remaining"]
    plain = call(REPO)
    show("GET " + REPO, plain)
    etag = plain["etag"]
    time.sleep(PAUSE)
    core, _ = meter()
    cost_plain = before - core["remaining"]
    out["plain_get_cost"] = cost_plain
    out["bytes_200"] = plain["bytes"]
    print("    remaining %d -> %d => plain GET cost = %d" % (before, core["remaining"], cost_plain))
    if cost_plain == 0:
        print("    !!! CONTROL FAILED: a real request cost nothing (cache/proxy/replay). ABORT.")
        return 4
    if cost_plain != 1:
        print("    !! cost != 1 - treat everything below as an upper bound.")

    # --- THE QUESTION: does a 304 cost a request when unauthenticated? ---------
    print("\n[D] %d CONDITIONAL REQUESTS (If-None-Match), NO Authorization header" % N_COND)
    if not etag:
        print("    no ETag returned => NOT MEASURED")
        out["conditional"] = "not measured (no etag)"
    else:
        print("    etag: %s" % etag)
        before = core["remaining"]
        statuses, sizes = [], []
        for i in range(N_COND):
            c = call(REPO, {"If-None-Match": etag})
            statuses.append(c["status"])
            sizes.append(c["bytes"])
            show("#%d  + If-None-Match" % (i + 1), c)
            time.sleep(PAUSE)
        core, _ = meter()
        drop = before - core["remaining"]
        out.update(conditional_statuses=statuses, conditional_bytes=sizes,
                   conditional_n=N_COND, conditional_total_cost=drop)
        print("    remaining %d -> %d => %d conditional requests cost %d"
              % (before, core["remaining"] + 0, N_COND, drop))
        if drop == 0:
            print("    => 304 IS FREE here.")
        elif drop == N_COND:
            print("    => 304 COSTS A FULL REQUEST each. The ETag saved bytes, not budget.")
        else:
            print("    => AMBIGUOUS (%d for %d). Do not publish a per-request cost from this."
                  % (drop, N_COND))

    # --- does an error cost you? ----------------------------------------------
    print("\n[E] DOES A 404 COST YOU A REQUEST?")
    before = core["remaining"]
    rnd = "".join(random.choice(string.ascii_lowercase) for _ in range(12))
    miss = call("/repos/python/zz-no-such-repo-%s" % rnd)
    show("GET /repos/.../<random>", miss, "expect 404")
    time.sleep(PAUSE)
    core, _ = meter()
    out["status_404"], out["cost_404"] = miss["status"], before - core["remaining"]
    print("    remaining %d -> %d => 404 cost = %d" % (before, core["remaining"], out["cost_404"]))

    # --- separate buckets ------------------------------------------------------
    print("\n[F] IS SEARCH THE SAME BUDGET?")
    before = core["remaining"]
    s = call("/search/repositories?q=stars:>100000&per_page=1")
    show("GET /search/repositories", s)
    time.sleep(PAUSE)
    core, search = meter()
    out.update(search_status=s["status"], search_resource=s["resource"],
               core_delta_from_search=before - core["remaining"],
               search_limit=search["limit"] if search else None)
    print("    core %d -> %d (delta %d) | search bucket: %s/%s"
          % (before, core["remaining"], out["core_delta_from_search"],
             search["remaining"] if search else "?", search["limit"] if search else "?"))

    # --- window ----------------------------------------------------------------
    print("\n[G] THE WINDOW")
    print("    core: %d/%d used=%d, resets in %+ds (fixed window, not a sliding one:"
          % (core["remaining"], core["limit"], core["used"], core["reset"] - int(time.time())))
    print("     the reset epoch stays put while you spend, then the whole bucket refills)")
    out["core_reset_in_s"] = core["reset"] - int(time.time())

    # --- what we refuse to measure --------------------------------------------
    print("\n[H] DELIBERATELY NOT MEASURED")
    print("    - 403 vs 429 at exhaustion: we did not drain the bucket. GitHub's docs say")
    print("      '403 or 429'; that is THEIR sentence, not our measurement.")
    print("    - the authenticated case (documented 5000/h, and 304s documented free):")
    print("      no valid token in this environment => NOT MEASURED.")
    print("    - secondary rate limits: NOT MEASURED.")

    print("\n" + "=" * 92)
    print(json.dumps(out, indent=2, sort_keys=True))
    print("=" * 92)
    return 0


if __name__ == "__main__":
    sys.exit(main())

Output, my machine, pasted as it came out:

============================================================================================
GitHub REST API - what actually spends the unauthenticated budget
started 2026-07-29T19:03:54Z
============================================================================================

[T] TRANSPORT CONTROL (weak, but it must still pass)
    nonexistent host             status=ERR     1463ms       0b  rl[- - used=-] MUST be ERR

    starting budget: 32/60 left, used=28, resets in +1336s

[A] IDLE CONTROL - send nothing for 10s, see if the counter moves
    remaining 32 -> 32  (drift 0)
    OK - nothing else is spending this bucket. Deltas below are ours.
    (this control CAN fail: on a shared NAT or a busy CI box it does)

[B] IS READING THE METER FREE?  (docs: /rate_limit is not counted)
    two consecutive /rate_limit reads: 32 -> 32 => meter costs NOTHING

[C] COST CONTROL - a plain GET must be OBSERVED to cost exactly 1
    GET /repos/python/cpython    status=200     1191ms    5996b  rl[core 31 used=29] 
    remaining 32 -> 31 => plain GET cost = 1

[D] 3 CONDITIONAL REQUESTS (If-None-Match), NO Authorization header
    etag: W/"546a3c1630ebc233b23407963e71de343062fc074ad45e4086b6fd3a17545a99"
    #1  + If-None-Match          status=304      931ms       0b  rl[core 30 used=30] 
    #2  + If-None-Match          status=304      973ms       0b  rl[core 29 used=31] 
    #3  + If-None-Match          status=304      974ms       0b  rl[core 28 used=32] 
    remaining 31 -> 28 => 3 conditional requests cost 3
    => 304 COSTS A FULL REQUEST each. The ETag saved bytes, not budget.

[E] DOES A 404 COST YOU A REQUEST?
    GET /repos/.../<random>      status=404     1031ms     118b  rl[core 27 used=33] expect 404
    remaining 28 -> 27 => 404 cost = 1

[F] IS SEARCH THE SAME BUDGET?
    GET /search/repositories     status=200     1064ms    5963b  rl[search 9 used=1] 
    core 27 -> 27 (delta 0) | search bucket: 10/10

[G] THE WINDOW
    core: 27/60 used=33, resets in +1307s (fixed window, not a sliding one:
     the reset epoch stays put while you spend, then the whole bucket refills)

[H] DELIBERATELY NOT MEASURED
    - 403 vs 429 at exhaustion: we did not drain the bucket. GitHub's docs say
      '403 or 429'; that is THEIR sentence, not our measurement.
    - the authenticated case (documented 5000/h, and 304s documented free):
      no valid token in this environment => NOT MEASURED.
    - secondary rate limits: NOT MEASURED.

============================================================================================
{
  "bytes_200": 5996,
  "conditional_bytes": [
    0,
    0,
    0
  ],
  "conditional_n": 3,
  "conditional_statuses": [
    304,
    304,
    304
  ],
  "conditional_total_cost": 3,
  "core_delta_from_search": 0,
  "core_reset_in_s": 1307,
  "cost_404": 1,
  "idle_drift": 0,
  "limit": 60,
  "meter_is_free": true,
  "plain_get_cost": 1,
  "search_limit": 10,
  "search_resource": "search",
  "search_status": 200,
  "status_404": 404,
  "utc": "2026-07-29T19:03:54Z"
}
============================================================================================

The [H] block is printed by the script, not added afterwards. A probe that lists what it refused to measure is harder to over-read later, including by me.

One note on the byte counts. The probe goes through urllib, which sets Accept-Encoding: identity on its own, so the log above shows the uncompressed body. Any normal client asks for gzip and gets the same JSON in about 1.4 kB on the wire: I checked that separately with curl against the same endpoint, content-encoding: gzip and content-length: 1423, which unpacks to the same 5,996 bytes. The same check three weeks later gave 1428, which is the sort of wobble you get when the JSON changes by a star count. Two measurements, 1,423 and 1,428, and no third number in between that I am rounding to. So the ETag saves you roughly 1.4 kB per poll, not 6 kB.

Two things the script gets wrong about itself, since you are going to read its output. The [G] line calls the window fixed and says the whole bucket refills; that is GitHub's documented model, not something a 29-second run can see. And [H], the block that lists what I refused to measure, does not list it. The prose above is the accurate version: the reset epoch did not move while I spent, and that is all I saw.

The idle control, and the header that beats it

My bucket did not start at 60. It started at 32, with used=28, because earlier runs the same evening had already spent from this IP. That is the whole reason the idle control exists.

If somebody else is spending from your bucket while you measure, a drop of 1 after your request is not evidence that your request cost 1. It is evidence that the counter moved. Those are different claims.

So: read the meter, say nothing for ten seconds, read it again. Drift was 0. On a shared NAT or a busy CI runner that control fails, and when it fails the honest thing to publish is an upper bound rather than a cost.

Ten seconds of silence is a weak certificate, though, and I want to say so before I lean on it. It proves nothing about the seconds during which I am spending. There is a better guarantee sitting in every response, and further down you will see it catch something the idle control slept through.

The cost control is the cheap one, and it is the one that would have caught the embarrassing failure. A plain GET has to be observed to cost exactly 1. If it had cost 0, I would be reading a cache or a proxy and every number below it would be decoration. The script prints that failure and exits with code 4.

The third control is repetition. One conditional request cannot distinguish "this cost 1" from "something else spent 1 in the same second". Three in a row dropped the counter by exactly 3, four times over that evening, and a fifth time three weeks later.

The letters in the docstring match the letters in the output. They did not in the first version I ran, which is the kind of thing you only notice when somebody else runs your file.

Four runs total, at 18:45:36Z, 18:49:46Z, 18:58:34Z and 19:03:54Z on July 29, 2026. Same answer each time, off different starting values.

Three weeks later, and something else in the bucket

I ran the same script again on August 19, 2026, before publishing this, because a measurement that is three weeks old is a claim about the past unless you check. Same machine, same endpoint, still no token:

[C] COST CONTROL - a plain GET must be OBSERVED to cost exactly 1
    GET /repos/python/cpython    status=200     1018ms    5996b  rl[core 45 used=15]
    remaining 46 -> 45 => plain GET cost = 1

[D] 3 CONDITIONAL REQUESTS (If-None-Match), NO Authorization header
    etag: W/"dd11a90c1106ce4de24a4f803c2604a00c6969b75610a03e4641ba4a46261a58"
    #1  + If-None-Match          status=304     1014ms       0b  rl[core 44 used=16]
    #2  + If-None-Match          status=304     2623ms       0b  rl[core 43 used=17]
    #3  + If-None-Match          status=304     1120ms       0b  rl[core 42 used=18]
    remaining 45 -> 42 => 3 conditional requests cost 3

[E] DOES A 404 COST YOU A REQUEST?
    GET /repos/.../<random>      status=404     1572ms     118b  rl[core 41 used=19] expect 404
    remaining 42 -> 41 => 404 cost = 1

Different ETag, same 5,996 bytes, same three zero-byte 304s, same three requests off the counter, used still stepping 15, 16, 17, 18, 19 without a gap. Twenty-one days, and nothing moved. Three months from now I still cannot tell you.

The interesting part came from a shorter check I ran earlier the same morning, before the full probe, and it is the reason the controls are in the script at all:

GET /rate_limit                 200     424 B  remaining=60 used=0
GET /repos/python/cpython       200    5996 B  remaining=59 used=1
  + If-None-Match #1            304       0 B  remaining=59 -> 58  used=2
  + If-None-Match #2            304       0 B  remaining=58 -> 56  used=4
  + If-None-Match #3            304       0 B  remaining=56 -> 55  used=5

Look at step two. remaining falls by two, and used jumps from 2 straight to 4. A 304 had not doubled in price overnight. The jump in used is the tell: my own request accounts for one of those two, and something that was not my probe accounts for the other.

That something was another process on the same machine, talking to the same API at the same time. GitHub is explicit about why that lands in my bucket. From Rate limits for the REST API: "Unauthenticated requests are associated with the originating IP address, not with the user or application that made the request." One address, one bucket, no isolation between the programs behind it. When I read the meter right before the clean run, the window had been open for about two minutes and 12 of its 60 requests were already spent.

So the honest version of the finding has a second half. A 304 costs you one request. A single unattended measurement on a shared address can tell you it cost two, and x-ratelimit-used is the header that catches the lie: consecutive responses of yours should carry consecutive numbers. A gap means somebody else is spending your hour. Mine happened to be a program of my own. On a CI runner it is a stranger, and you will never see them.

What the same six requests answered on the way past

Question	Measured, no token, July 29 and again August 19, 2026
Ceiling without a token	`x-ratelimit-limit: 60` in the headers. That it is tied to the IP is GitHub's sentence, not something one address can measure
`GET /rate_limit`	0. Two reads in a row did not move `remaining`
Plain `GET /repos/python/cpython`	1 (HTTP 200, 5,996 bytes of JSON; 1,423 and 1,428 bytes on the wire with gzip, in the two months)
3 x `If-None-Match` on the same URL	304, 304, 304, zero bytes each, counter down exactly 3
`GET` of a repository that does not exist	1 (HTTP 404, 118 bytes)
`GET /search/repositories`	core untouched (delta 0), own bucket, `x-ratelimit-resource: search`, limit 10. The header gives the number; the docs give the unit, per minute, against core's 60 per hour
The reset epoch	Did not move while I was spending. What the window does at reset: not measured

Four of those deserve a sentence each.

Errors are charged. The 404 cost the same as the 200. Probing whether a repository exists spends the identical budget as fetching one that does.

In the keyless package-registry post I wrote that the 403 you get when the bucket runs out looks nothing like a 404. I did not verify that then and I have not verified it here either, which I will come back to. The half I did measure is this one: the 404 itself is charged like any other answer.

The buckets are separate. Search did not touch core at all. It came back with x-ratelimit-resource: search and a limit of 10, which lines up with GitHub's search documentation: "For unauthenticated requests, the rate limit allows you to make up to 10 requests per minute." Note the unit. Search is 10 a minute, core is 60 an hour, so the smaller-looking number is the more generous budget by an order of magnitude. If you are tracking one total budget for api.github.com, you are tracking the wrong number.

Something I noticed and did not chase. The search response header and the meter disagree, and I do not have an explanation. In two runs the response header said remaining: 9 while the meter, read a second later, said 10 of 10. In a later run the same place gave remaining: 8 with used=2. Three different pictures in the same spot. Core agreed with itself at every checkpoint in every run; only search wobbles. I am not going to build a story about per-minute rollover on top of that, because a rollover landing inside a one-second gap three times running is not a story I would believe from somebody else.

The reset epoch stayed put while I spent. That is the whole observation. My runs lasted about 29 seconds and never saw a reset, so what happens at the boundary, whether the bucket trickles back or refills whole, is not measured here. GitHub documents a fixed window; I am repeating that, not confirming it.

The arithmetic that kills a poller

This next part is arithmetic on the numbers above, not a separate measurement. Label it that way in your head.

Poll one endpoint every 30 seconds with a beautifully implemented ETag cache and no token. That is 120 requests per hour against a ceiling of 60. Your bucket is empty roughly 30 minutes into every hour, and the ETags did not slow that down by a single request. Then you wait for the reset.

The failure is quiet, which is what makes it expensive. The poller looks correct. Every response is a 304, every 304 says "nothing changed", the log stays clean, and the thing dies half way through the hour for a reason the code never mentions.

The header that was in every response the whole time

Here is the part I missed on the first pass, and it is embarrassing because the server had been telling me since the first request. GET /repos/python/cpython comes back with:

cache-control: public, max-age=60, s-maxage=60

Revalidation and freshness are two different things, and I had been treating them as one. A conditional request is revalidation: you ask the server whether your copy is stale, and without a token that question costs you a request whatever the answer is. max-age=60 is freshness: for sixty seconds the server is telling you not to ask at all.

Run the same arithmetic with a client that honours it. Polling every 30 seconds, half of those calls fall inside a window the server already declared fresh, so they never reach the network. Sixty requests an hour instead of 120, which is exactly the ceiling rather than double it. That is the difference between a job that dies at minute thirty and one that survives the hour, and note how thin that is: exactly the ceiling means a reserve of zero. One retry, one phase mismatch with the fixed window, one other process on the same address, and you are at 61.

I saw this header on one endpoint. Whether every endpoint sends it, and with what value, is not measured.

Back on July 2 I put GitHub in a list of keyless APIs an AI agent can read the web with and named the ceiling there: 60 requests per hour, per IP. That post named the size of the bucket. This one is about what drains it, and the answer includes several things that feel like they should be free.

Ask the meter instead of catching the exception

GitHub's rate-limit page says that if you exceed the primary limit, "you will receive a 403 or 429 response". Two possible codes, and both of them mean other things in other contexts. There is no single status you can hang an except on.

The counter is better than the exception, for three reasons that came out of the same runs.

x-ratelimit-remaining is on every response, including the 304s and the 404 above. The meter endpoint is free: two reads in a row did not move it, and GitHub documents it as "does not count against your primary rate limit". And a number tells you how close you are, while an exception only tells you that you already arrived.

Runnable locally, standard library, no token:

#!/usr/bin/env python3
"""Ask the meter before you act, instead of catching an exception afterwards.

Standard library, no token, no signup. Runnable locally.
GET /rate_limit is documented as not counted against the primary limit, and it
measured at zero cost here, so the guard is free. The call it guards is not.
"""
import json
import time
import urllib.error
import urllib.request

API = "https://api.github.com"
HDRS = {"User-Agent": "budget-guard (contact: you@example.com)",
        "Accept": "application/vnd.github+json"}


class OutOfBudget(Exception):
    pass


def core_left():
    """(remaining, limit, seconds_to_reset). This read is free."""
    req = urllib.request.Request(API + "/rate_limit", headers=HDRS)
    with urllib.request.urlopen(req, timeout=20) as r:
        core = json.loads(r.read())["resources"]["core"]
    return core["remaining"], core["limit"], core["reset"] - int(time.time())


def get(path, etag=None, keep=5):
    """One guarded call. Returns (status, bytes, remaining_after, etag)."""
    left, limit, in_s = core_left()
    if left <= keep:
        raise OutOfBudget("%d/%d left, window resets in %ds" % (left, limit, in_s))
    h = dict(HDRS)
    if etag:
        h["If-None-Match"] = etag      # saves bytes; without a token it does not save budget
    req = urllib.request.Request(API + path, headers=h)
    try:
        with urllib.request.urlopen(req, timeout=20) as r:
            body, status, hdrs = r.read(), r.status, r.headers
    except urllib.error.HTTPError as e:
        body, status, hdrs = e.read(), e.code, e.headers   # 304 and 404 are answers, not crashes
    return status, len(body), hdrs.get("x-ratelimit-remaining"), hdrs.get("etag")


print("A. plain call")
st, n, left, tag = get("/repos/python/cpython")
print("   status=%s bytes=%s remaining=%s" % (st, n, left))

print("B. same call, now with the ETag")
st, n, left, _ = get("/repos/python/cpython", etag=tag)
print("   status=%s bytes=%s remaining=%s" % (st, n, left))

print("C. the guard has to be able to say no")
try:
    get("/repos/python/cpython", keep=999)
    print("   guard stayed silent  <-- broken guard")
except OutOfBudget as e:
    print("   OutOfBudget: %s" % e)

Output:

A. plain call
   status=200 bytes=5996 remaining=33
B. same call, now with the ETag
   status=304 bytes=0 remaining=32
C. the guard has to be able to say no
   OutOfBudget: 32/60 left, window resets in 1412s

Block C is there because a guard that cannot refuse is not a guard. Setting keep=999 forces the refusal on a healthy bucket, and if that line ever prints "guard stayed silent" the guard is broken and everything above it is theatre.

Block B is the finding again, this time inside the client you would actually ship: 200 at remaining=33, then a 304 with an empty body at remaining=32. Zero bytes of body, one request off the counter. The headers still travel, in both directions; the body is what the ETag saves you.

Two things I would not read into this snippet. The keep=5 reserve is a number I picked, not a measured optimum.

And calling core_left() before every single request is fine at these volumes but wasteful at any real rate. Cache the value, refresh it from the x-ratelimit-remaining header that every response already carries, and re-read the meter when the numbers look stale.

Keep sending the ETag anyway. Without a token it still saves you the body: 5,996 bytes of JSON, about 1.4 kB on the wire once you let the server gzip it. It costs one header. Just do not budget as though it buys you a request.

Why I did not drain the bucket

The obvious next experiment is to keep going until something breaks, screenshot the error, and settle the 403 versus 429 question. I did not run it, and the reason is not squeamishness.

That budget belongs to GitHub, and on a shared address it belongs to whoever else is behind it. Burning through somebody's free quota to illustrate an article about respecting free quotas would make the method contradict the point.

So the status code at exhaustion is genuinely unknown to me. Where I mention "403 or 429" above, I am quoting their sentence, not reporting mine.

One run of the probe costs 6 requests: 5 from the core bucket of 60 and 1 from the search bucket of 10. Two buckets, counted separately, because a post that just spent a section proving the buckets are separate does not get to add them together at the till.

Four probe runs and the guard snippet come to 22 core requests, and I would happily have printed that number. The meter disagrees, and the meter wins. All four runs landed inside one window: the last of them reported resets in +1336s at 19:03:54Z, which puts the window's start at 18:26:10Z and every run after it. The last line that run printed reads used=33. So this address spent 33 of that hour's 60, not the 22 I can name, and after the section above I am not going to swear the other eleven were even me. Thirty-three of sixty is the number that belongs in a section about other people's quota. It is also still not a load test. A question about rate limits does not need one to answer, it needs the headers you are already being sent.

I have done the restrained version before. When I checked keyless certificate-transparency and DNS APIs on July 20, crt.sh returned a 502, then a dead connection, then two 200s, four calls in twelve seconds. I published that as something I observed while making a handful of ordinary calls, not as something I induced.

Honest limits

This is four runs on one IP inside 19 minutes on July 29, 2026, plus one confirming run on August 19. Not "GitHub always does this". Three weeks of stability is what I have; whether it holds over months is not measured. If you are reading this later than that, run the script before quoting me.
The authenticated case is not measured at all. There is no valid token in this environment. The 5,000 per hour and the free 304s that come with an Authorization header are documented by GitHub, not verified by me, and I am not going to pretend otherwise. If you have a token and 30 seconds, that is the experiment I would most like someone else to run.
The status code at exhaustion is not measured. See above.
Secondary rate limits are not measured. I never went near them. GitHub documents them separately, including a note that the free meter endpoint can count against them.
One endpoint, one conditional mechanism. I measured If-None-Match against /repos/{owner}/{repo}. Whether /repos/.../commits behaves the same, or whether If-Modified-Since behaves the same, is not measured.
I did not read their source, so I cannot tell you why. All I can say is that the observed behaviour matches the documented rule read strictly: no Authorization header, no discount. Whether that is deliberate or incidental, I do not know.
Latency is not an argument here. In July the 304s came back in 931 to 974 ms against 1,191 ms for the 200; in August, 1,014, 2,623 and 1,120 ms against 1,018. On a 6 kB body that is noise plus one outlier, and I am not presenting any of it as a benefit. urllib opens a fresh connection per call, so most of what those numbers measure is the handshake.

The open question

The advice that follows from all of this is "use a token", and for most people that is the end of it. A token is free, it raises the documented ceiling from 60 to 5,000, and per the docs it makes the 304s free too.

But there are places where a token is the thing you cannot have. A public demo that runs client-side. A community tool where you refuse to ask users for a scope.

Or a CI job on a shared runner, where the address is not yours and 60 an hour is split with strangers you cannot see. That is exactly the situation my idle control was built to detect, and exactly the situation it would have failed in.

In those places, every answer I have reduces to "poll less often" or "put a server in front of it with a token on it". Both work. Neither is clever, and the second one just moves the token somewhere else.

So here is what I actually want to know: without an Authorization header, is there anything smarter than reducing frequency? Something that gets more signal out of 60 requests an hour rather than spending them more slowly? If you have shipped one, I want to hear how it behaves on the day the bucket is shared. 👇

Follow along if you want the next set of numbers when I measure them.

Written with AI assistance. Every status code, byte count, header value and counter reading above comes from my own runs against api.github.com on July 29 and August 19, 2026, and is either pasted as it was printed or read straight off that printed output, with the controls shown. Two things the probe cannot see and I measured separately with curl on the same endpoint: the on-the-wire gzip size (content-length: 1423 in July, 1428 in August, both unpacking to the same 5,996 bytes) and the cache-control header. Documentation quotes were re-checked against the GitHub pages linked above on August 19, 2026.

13 Keyless Job APIs: A Broken limit Returns 200 Rows, or 0

Alex Spinov — Thu, 30 Jul 2026 01:28:35 +0000

Two keyless job APIs. The same broken value in the same parameter. July 29, 2026:

himalayas.app  ?limit=not-a-number   HTTP 200   1219458 B   200 records
api.lever.co   &limit=not-a-number   HTTP 200         2 B     0 records

Himalayas documents that parameter as max 20. Lever's board has 388 postings on it.

Neither response has an error key, a warning field, or a non-200 status. Lever's body is a bare []: two bytes, with nothing in it to branch on. Himalayas does leave one signal, and I walked straight past it on the first pass: its envelope echoes the applied value back at you, and on the broken request that echo reads "limit": null. One of them handed me ten times the ceiling the provider advertises. The other handed me nothing at all and called it success.

The one idea

A keyless job API returns job postings over plain HTTP with no key, no signup and no card. I checked thirteen of them with live requests on July 29, 2026, and the table is further down.

The thing worth your attention is not which ones are alive. It is what happens when the filter value you send is not a number. On six of the ten providers I tested for it, a broken value is neither rejected nor honoured. On two of those six it removes the limit that was there — once upward, once all the way to zero. On the other four the parameter never did anything in the first place, with a valid value or a broken one, so there was no limit there to remove.

So limit is not a promise the server made you. It is a hint the server may or may not parse, and when the parse fails, whatever the code does next is not a decision anyone designed.

The whole proof, with the controls that had to fail first

Standard library, no key, no account, no card. Copy it and you should get the same shape I did.

#!/usr/bin/env python3
"""Keyless, standard library only, needs network. No key, no signup, no card.

Asks two job APIs for a number of rows, then asks again with one character
changed so the value is no longer a number, and prints what each answer costs.
Controls run first: a probe that cannot report failure is not a probe.

The multiple is taken against the provider's DOCUMENTED maximum (20), not
against whatever small number the caller happened to ask for. Comparing 200
against a request for 3 measures your own request size, not the ceiling.
"""
import json
import urllib.error
import urllib.request

UA = {"User-Agent": "limit-probe (contact: you@example.com)"}
DOCUMENTED_MAX = 20          # himalayas.app/api: "limit: the number of jobs to retrieve (max 20)"


def get(url):
    """Return (http, bytes, records). Failures are returned, never swallowed."""
    req = urllib.request.Request(url, headers=UA)
    try:
        with urllib.request.urlopen(req, timeout=60) as r:
            raw, code = r.read(), r.status
    except urllib.error.HTTPError as e:
        return e.code, len(e.read()), None
    except Exception as e:
        return "ERR:" + e.__class__.__name__, 0, None
    try:
        o = json.loads(raw)
    except ValueError:
        return code, len(raw), None
    if isinstance(o, list):
        return code, len(raw), len(o)
    for k in ("jobs", "data", "results", "hits", "content"):
        if isinstance(o.get(k), list):
            return code, len(raw), len(o[k])
    return code, len(raw), None


def show(label, url):
    code, size, n = get(url)
    print("  %-36s http=%-5s bytes=%-9s records=%s" % (label, code, size, n))
    return size, n


H = "https://himalayas.app/jobs/api?limit=%s"
S = "https://himalayas.app/jobs/api/search?q=engineer&limit=%s"
L = "https://api.lever.co/v0/postings/leverdemo?mode=json&limit=%s"

print("=== CONTROLS: the probe must be able to say 'bad' ===")
show("host that does not exist", "https://api-zzz-not-real-918273.example/x")
show("live host, path that does not exist", "https://himalayas.app/jobs/api-NOPE-zzz-918273")
show("board token that does not exist", "https://api.lever.co/v0/postings/zzz-not-real-918273?mode=json")
show("POSITIVE: keyless, known up, other field",
     "https://api.open-meteo.com/v1/forecast?latitude=52.5&longitude=13.4&current=temperature_2m")

print("\n=== HIMALAYAS /jobs/api  (docs: 'limit ... (max 20)') ===")
b_max, n_max = show("limit=20    the documented maximum", H % "20")
show("limit=3     valid, under the maximum", H % "3")
show("limit=99999 valid, over the maximum", H % "99999")
show("(no limit parameter at all)", "https://himalayas.app/jobs/api")
show("limit=0", H % "0")
show("limit=-1", H % "-1")
b_bad, n_bad = show("limit=not-a-number   <-- garbage", H % "not-a-number")

if n_max and n_bad:
    print("\n  documented ceiling ............. %d records" % DOCUMENTED_MAX)
    print("  most a VALID value returned .... %d records" % n_max)
    print("  what a NON-NUMBER returned ..... %d records = %.0fx the documented ceiling"
          % (n_bad, n_bad / DOCUMENTED_MAX))
    print("  bytes for that one request ..... %d -> %d = %.1fx" % (b_max, b_bad, b_bad / b_max))
    print("  every line above is HTTP 200 except limit=-1.")

print("\n=== SAME SITE, OTHER ENDPOINT /jobs/api/search: no defect here ===")
for v in ["3", "20", "99999", "not-a-number"]:
    show("search q=engineer limit=%s" % v, S % v)
show("search q=engineer (no limit)", "https://himalayas.app/jobs/api/search?q=engineer")

print("\n=== LEVER: same broken validation, opposite outcome ===")
show("(no limit parameter)", "https://api.lever.co/v0/postings/leverdemo?mode=json")
for v in ["3", "-1", "-5", "not-a-number"]:
    show("limit=%s" % v, L % v)

print("\n=== THE VALUE IS PARSED, NOT VALIDATED ===")
print("  (behaviour consistent with parseInt; I have not seen their source)")
for v in ["3abc", "+5", "20.5", "0x10", "1e9", "abc3", "null", "true"]:
    show("Himalayas limit=%s" % v, H % v)

Output on my machine, July 29, 2026, pasted as it came out:

=== CONTROLS: the probe must be able to say 'bad' ===
  host that does not exist             http=ERR:URLError bytes=0         records=None
  live host, path that does not exist  http=404   bytes=75803     records=None
  board token that does not exist      http=404   bytes=41        records=None
  POSITIVE: keyless, known up, other field http=200   bytes=316       records=None

=== HIMALAYAS /jobs/api  (docs: 'limit ... (max 20)') ===
  limit=20    the documented maximum   http=200   bytes=132440    records=20
  limit=3     valid, under the maximum http=200   bytes=23816     records=3
  limit=99999 valid, over the maximum  http=200   bytes=132440    records=20
  (no limit parameter at all)          http=200   bytes=132440    records=20
  limit=0                              http=200   bytes=174       records=0
  limit=-1                             http=500   bytes=0         records=None
  limit=not-a-number   <-- garbage     http=200   bytes=1219458   records=200

  documented ceiling ............. 20 records
  most a VALID value returned .... 20 records
  what a NON-NUMBER returned ..... 200 records = 10x the documented ceiling
  bytes for that one request ..... 132440 -> 1219458 = 9.2x
  every line above is HTTP 200 except limit=-1.

=== SAME SITE, OTHER ENDPOINT /jobs/api/search: no defect here ===
  search q=engineer limit=3            http=200   bytes=93005     records=18
  search q=engineer limit=20           http=200   bytes=93005     records=18
  search q=engineer limit=99999        http=200   bytes=93005     records=18
  search q=engineer limit=not-a-number http=200   bytes=93005     records=18
  search q=engineer (no limit)         http=200   bytes=93005     records=18

=== LEVER: same broken validation, opposite outcome ===
  (no limit parameter)                 http=200   bytes=2427173   records=388
  limit=3                              http=200   bytes=16368     records=3
  limit=-1                             http=200   bytes=2422514   records=387
  limit=-5                             http=200   bytes=2377916   records=383
  limit=not-a-number                   http=200   bytes=2         records=0

=== THE VALUE IS PARSED, NOT VALIDATED ===
  (behaviour consistent with parseInt; I have not seen their source)
  Himalayas limit=3abc                 http=200   bytes=23816     records=3
  Himalayas limit=+5                   http=200   bytes=34113     records=5
  Himalayas limit=20.5                 http=200   bytes=132440    records=20
  Himalayas limit=0x10                 http=200   bytes=113864    records=16
  Himalayas limit=1e9                  http=200   bytes=8878      records=1
  Himalayas limit=abc3                 http=200   bytes=1219458   records=200
  Himalayas limit=null                 http=200   bytes=1219458   records=200
  Himalayas limit=true                 http=200   bytes=1219458   records=200

I re-ran that whole block before publishing, and 44 of the 45 lines came back identical. The one that moved was the Open-Meteo control, 316 bytes to 315. It reports a live temperature, and the reading lost a character. Every measured line in the job APIs, including all the ones this post rests on, reproduced exactly.

A word about the ratio, because I got it wrong on the first pass and nearly shipped it. My original script compared the 200 records against a request for 3 and printed 66x. That number is arithmetically fine and it measures the wrong thing: how small my own request happened to be. The ceiling being bypassed is 20, so the honest multiple is 10x the records and 9.2x the bytes. If you see 51.2x anywhere in my notes, that is the byte ratio against limit=3, and it says more about me than about the server.

What the provider itself publishes

I fetched the docs page rather than trusting my memory of it. https://himalayas.app/api returned HTTP 200 in 145,866 bytes, and three strings in it matter:

limit: the number of jobs to retrieve (max 20)

As of 24th March 2025, we have reduced the maximum limit to 20 jobs per request to improve performance and reliability.

What error responses does the Himalayas API return? "The API returns 400 Bad Request for invalid query parameters and 429 Too Many Requests when the rate limit is exceeded. Successful requests return 200 with a JSON body containing the jobs array and metadata."

Read those three lines against the output above. Every valid number I sent respected the ceiling, including 99999, which came back as a quiet 20. The ceiling only moves when the value stops being a number. A limit that was deliberately lowered for performance and reliability comes off with one non-digit character.

The third line is the one that decides what this post is. Without it I would be reporting a gap between a documented maximum and an observed response, and a maintainer could fairly answer that max 20 describes valid input and promises nothing about garbage. That answer is already closed off on the same page: invalid query parameters get 400. I sent an invalid query parameter and got 200 with 200 records. So this is not my expectation being disappointed. It is a published contract missed in two places at once, the status code and the ceiling, and I only have to quote the provider to say so.

The same page also says, on rate limiting: "Due to server capacity constraints, we ratelimit the number of requests that can be made to our API within a certain time period." No numbers are published. I did not go looking for them, and I say more about that at the end.

Why: the value is parsed, not validated

Look at the last block of output. It is a signature, and it is readable without any access to their code.

I sent	`parseInt` would give	`Number()` would give	records I got
`3abc`	3	`NaN`	3
`1e9`	1, parsing stops at `e`	1,000,000,000	1
`20.5`	20	20.5	20
`0x10`	16, hex prefix	16, the same	16
`+5`	5	5	5, but read the note below
`abc3`, `null`, `true`	`NaN`	`NaN`	200

Now be careful about how much that table proves, because I initially credited it with more. Eleven values went out, but only three of them actually separate the two hypotheses: 3abc, 1e9, and weakly 20.5. 0x10 returns 16 under both rules, so it discriminates nothing: a good-looking row carrying no evidence. And the six values that coerce to NaN (abc3, null, true, NaN, Infinity, []) are not six confirmations. They are one observation repeated six times.

One more correction, on +5. A plus in a query string is a space on the wire: new URL("https://x/?limit=+5").searchParams.get("limit") returns " 5". That row tests tolerance of leading whitespace, not of a plus sign. The honest test is %2B5.

What survives the trimming is still the finding: the value is parsed, not validated, and the behaviour is consistent with parseInt over the raw query string with nothing checking the result afterwards. I have not seen their source code. This is a fingerprint taken from outside on the values I tried, and a different implementation with the same coercion rules would leave the same marks.

What I cannot tell you is why NaN produces exactly 200. I called it a fallback in my notes, then found the counter-evidence in my own bytes: the envelope comes back carrying "limit": null, and JSON.stringify({limit: NaN}) is exactly {"limit":null}. The NaN was not swapped for a default somewhere upstream. It travelled all the way to the serialiser. A designed fallback would more plausibly have echoed the default it substituted. Two hundred may simply be the page size of whatever store sits underneath when nothing constrains the query, and the composition test below behaves that way: offset=200 and offset=400 each return a fresh 200. Separately, limit=0 returning 0 rules out the classic parseInt(x) || 200 idiom, because zero is falsy and would have produced 200 instead. There is no NaN check anywhere on this path.

My favourite line in the whole set is limit=1e9. You ask for a billion jobs and you get one, 8,878 bytes, HTTP 200, no comment. If you have ever written limit=1e6 in a hurry because it looked like a big round number, that is a silent single-row response waiting for you.

The same site, the other endpoint, no defect at all

This is the part that keeps the post honest, so it goes above the fold rather than in a footnote.

Himalayas has a second endpoint, /jobs/api/search. I sent it limit=3, limit=20, limit=99999, limit=not-a-number and no limit at all. All five returned 93,005 bytes and 18 records. Byte-identical. The parameter is inert there and the broken value changes nothing.

One site, two endpoints, two different behaviours. So "Himalayas has a limit bug" is too broad a sentence to be true. The accurate one is that /jobs/api has it and /jobs/api/search does not, and if you are going to quote me, quote that.

Lever: the same root, the opposite blast radius

Lever's public board API is the mirror, and it is the case I would worry about more.

The leverdemo board carries 388 postings. Watch what negative numbers do:

limit=-1 returns 387 records, 2,422,514 bytes
limit=-5 returns 383 records, 2,377,916 bytes
limit=not-a-number returns 0 records, 2 bytes, HTTP 200

388 minus 1 is 387. 388 minus 5 is 383. That is Array.slice(0, -1) behaviour: a negative end index counts back from the tail. And slice(0, NaN) produces an empty array, which is why garbage returns an empty list rather than a full one. Same caveat as before: this is inferred from the numbers, not read from their code.

I checked whether it was the API or that particular board. The matchgroup board has 83 postings: limit=-1 returned 82, and limit=not-a-number returned 0 in a 2-byte body. Two boards, same pattern, so it lives in the API.

Now sit with the Lever case for a second, because it is the quiet one. Your nightly job sends a limit that a config change turned into an empty string or the literal None. The response is HTTP 200. The JSON parses. The array is valid, and it is empty. Your logs say 0 new postings today, your monitoring stays green, your alerting has nothing to fire on, and the board had 388 jobs on it the whole time.

Himalayas costs you money. Lever costs you the data, and it does it without a single red pixel anywhere.

It composes with `offset`, and then it is not a curiosity

A single fat response is a curiosity. The thing that changes its character is that the broken value composes with pagination.

Three requests each way, one honest, one broken, counting unique postings by guid:

honest  limit=20             offset=0    HTTP 200 bytes=132440   returned=20
honest  limit=20             offset=20   HTTP 200 bytes=135479   returned=20
honest  limit=20             offset=40   HTTP 200 bytes=129680   returned=20
  --> 3 requests, 397599 bytes, 60 UNIQUE jobs

broken  limit=not-a-number   offset=0    HTTP 200 bytes=1219458  returned=200
broken  limit=not-a-number   offset=200  HTTP 200 bytes=1275360  returned=200
broken  limit=not-a-number   offset=400  HTTP 200 bytes=1375889  returned=200
  --> 3 requests, 3870707 bytes, 586 UNIQUE jobs

60 against 586 on the same request budget. That is 9.8x.

A rate limiter that counts requests does not see this at all. The requests are identical in number and shape, and each one carries ten times the records, 9.2 times the bytes. Whatever the unpublished request quota is, the effective data ceiling behind it is off by an order of magnitude for anyone who types a non-digit.

Two things I want to be plain about. First, 586 unique out of 600 returned means 14 rows overlapped across the three windows, so the fetch is not perfectly clean. Second, this is not free: the bytes went up 9.7x too, from 397,599 to 3,870,707. You are bypassing a request count, not a bandwidth bill. Which is a decent segue.

Who actually says "that is not a number"?

Ten providers, one question each: send limit=3, then send limit=not-a-number, and see whether the server objects.

Provider	Parameter	`=3`	`=not-a-number`	Says it is bad?
Himalayas	`limit`	200 / 23,816 B / 3	200 / 1,219,458 B / 200	no
Lever	`limit`	200 / 16,368 B / 3	200 / 2 B / 0	no
Remotive	`limit`	200 / 494,763 B / 36	200 / 494,763 B / 36	no (inert)
Arbeitnow	`limit`	200 / 1,544,846 B / 175	200 / 1,545,554 B / 175	no (inert)
Greenhouse	`limit`	200 / 317,625 B / 535	200 / 317,625 B / 535	no (inert)
TheMuse	`limit`	200 / 124,847 B / 20	200 / 124,848 B / 20	no (inert)
Jobicy	`count`	200 / 27,397 B / 3	400 / 67 B	yes
SmartRecruiters	`limit`	200 / 3,222 B / 2	400 / 11 B	yes
HN Algolia	`hitsPerPage`	200 / 12,954 B / 3	400 / 151 B	yes
EU Open Data	`limit`	200 / 115,611 B / 3	400 / 11 B	yes

Four of ten reject the value. Six accept it with HTTP 200, and two of those six change the size of what they hand you.

The four inert ones deserve a separate word, because "inert" is a claim I can only half support. Remotive, Arbeitnow, Greenhouse and TheMuse returned the same record count for 3 and for garbage, which tells me the parameter did not take effect. For Remotive and Greenhouse it is stronger: the two responses were byte-identical, same md5 both times. For Arbeitnow and TheMuse the bytes moved a little, 1,544,846 against 1,545,554, while the record count sat still at 175, which is the feed drifting under me between two requests rather than the parameter doing anything. What none of it tells me is whether those four parse the value and discard it or never implemented it at all. I did not separate those, and the response gives me no way to.

One case in the honest camp I got wrong on the first pass, and I would rather correct it here than quietly delete it, because it turned out to be the most instructive row in the table. Jobicy rejects a non-numeric count with a clean 400 and a readable message, while count=0 and count=-1 each return one job rather than zero. I wrote that down as carelessness. Then I read their documentation, which specifies the parameter as range: 1-100, and looked at the body again:

count=0              -> jobCount: 1,   appliedFilters: {'count': 1}
count=-1             -> jobCount: 1,   appliedFilters: {'count': 1}
count=3              -> jobCount: 3,   appliedFilters: {'count': 3}
count=200            -> jobCount: 100, appliedFilters: {'count': 100}
count=not-a-number   -> HTTP 400  {"success":false,"error":"The 'count' parameter must be a number."}

The range starts at 1, so a request for 0 is clamped to 1, exactly as written. Out of range at the other end is clamped too, 200 down to 100. And the response says so in a machine-readable field: appliedFilters reports the value the server actually used, so a client can compare what it asked for against what it got without guessing. That is the best behaviour in the entire set of thirteen: reject what you cannot parse, clamp what is out of range, and declare what you did. Nobody ever promised that count=0 returns zero rows. I assumed it. Which is precisely the mistake this post is about, committed by me rather than by a server.

The thirteen, checked live

Every row is a request I made on July 29, 2026 with no key, no account and no card.

#	Provider	Keyless endpoint	Bytes	Records
1	Arbeitnow	`www.arbeitnow.com/api/job-board-api`	1,544,867	175
2	Remotive	`remotive.com/api/remote-jobs`	494,763	36
3	RemoteOK	`remoteok.com/api`	441,310	101
4	Jobicy	`jobicy.com/api/v2/remote-jobs`	830,042	100
5	WorkingNomads	`www.workingnomads.com/api/exposed_jobs/`	218,212	44
6	TheMuse	`www.themuse.com/api/public/jobs?page=1`	124,848	20
7	Himalayas	`himalayas.app/jobs/api`	132,440	20
8	HN "Who is hiring" via Algolia	`hn.algolia.com/api/v1/search?tags=story&query=who%20is%20hiring`	197,327	20
9	Greenhouse board	`boards-api.greenhouse.io/v1/boards/stripe/jobs`	317,625	535
10	Ashby board	`api.ashbyhq.com/posting-api/job-board/openai`	11,855,242	739
11	Lever board	`api.lever.co/v0/postings/leverdemo?mode=json`	2,427,173	388
12	SmartRecruiters board	`api.smartrecruiters.com/v1/companies/Visa/postings`	3,224	2
13	Personio board	`<company>.jobs.personio.de/search.json`	1,447	4

Rows 9 through 13 are a different kind of thing from rows 1 through 8, and calling them all "job APIs" would be sloppy. Greenhouse, Ashby, Lever, SmartRecruiters and Personio are not aggregators. They are the public careers-page backend of one employer at a time, and the URL needs that employer's board token. No key, yes. No target, no data.

That token is the whole game. Three Lever tokens I tried (netflix, figma, brex) returned 404 — those boards are not open. SmartRecruiters does something different, and I needed one more control before I could say what. Of five companies I tried, only Visa returned postings; bosch, Sopra-Steria, McDonalds and Publicis-Groupe each returned HTTP 200 with a 52-byte body and an empty list. Here is the control I should have run first, and did not:

ZZQ-DEFINITELY-NOT-A-REAL-COMPANY-918273  -> 200, 52 B, {"offset":0,"limit":100,"totalFound":0,"content":[]}
bosch                                     -> 200, 52 B, byte-for-byte the same body
Visa                                      -> 200, 3,224 B, totalFound 2
a broken path on the same host            -> 404, 195 B

A company name I invented on the spot comes back identical to bosch. So my data cannot separate "this board is empty" from "no such company", and the likelier reading is that four of my five identifiers were simply wrong rather than four employers having zero openings. The claim I can actually defend is narrower, and still worth making: SmartRecruiters answers an unknown company with 200 and an empty list, where the same host manages a perfectly good 404 for a bad path.

Ashby's OpenAI board is worth one line on its own. 11,855,242 bytes, 739 postings, one request. If your job runner has a memory ceiling, that is not a hypothetical.

For controls: api-zzz-not-real-918273.example failed to resolve, a bogus path on a live host gave 404, a bogus Greenhouse board gave 404 in 38 bytes, and the three key-gated APIs I used as negatives behaved as expected — Adzuna 400, USAJOBS 401, O*NET 401. A keyless endpoint outside this field, Open-Meteo, returned 200. The probe can tell alive from dead from paywalled.

I also checked the EU Open Data portal, and left it out of the thirteen on purpose. Its search endpoint is keyless and answers cleanly, but q=jobs returns datasets about employment, with titles like "Workforce Jobs" and "Current Job Vacancies", not the vacancies themselves. It appears in the validation table above because it does reject a broken limit. It is not a job board and I am not going to pad a list with it.

How this is different from three things I already wrote

I have circled this neighbourhood before, and the differences are the reason this post exists.

In 11 keyless package-registry APIs, and why you can't pin latest the experiment varied the provider while the input stayed correct: five registries, latest spelled properly every time, five different answers because five humans made five editorial decisions. Here the provider is held still and the input is what varies. That post also admitted, in as many words, that it could not demonstrate its own mechanism inside one afternoon. This one fires on demand, in one request, and three consecutive repeats returned the identical md5 for both the honest and the broken response.

Your scraper collected 50 rows. There were 4,000. is about undercount discovered by fingerprinting repeated pages during a crawl, and its code is a mock with no network in it at all. This is overcount from a single live request, plus an undercount that arrives by a completely different road: not a page cap during a walk, but one character in one value.

You pay for the bandwidth that returns nothing put a price on wasted traffic, and said plainly that its figures were a model built on published proxy prices rather than a measured invoice. The 1,219,458 bytes above are not modelled. A request that should have been capped at 20 rows delivered 200, and I have the byte counts for both — including the detail that the request which cost that much did not ask for a number at all.

What an agent does with 1.2 MB it did not ask for

If a tool call in an agent loop wraps that endpoint, the response goes into a context window, and bytes become tokens.

I encoded all three responses with tiktoken (cl100k_base, not standard library, so this is a number I am reporting rather than one the script above produces):

limit=3                  23,816 B  ->    5,531 tokens
limit=20                132,440 B  ->   32,928 tokens
limit=not-a-number    1,219,458 B  ->  302,119 tokens

302,119 tokens from one tool call, because someone's config turned a number into a string. That is 9.2x the documented maximum's worth and it arrives with HTTP 200. Note the size of it: 302k tokens is past the context window of most models in use today, so the realistic outcome is not a quietly degraded run but a hard failure on the tool result. Where it does fit, it fits by evicting everything else you had in the window. I measured a related version of this problem in feeding raw HTML to your LLM is a token tax; this one is cheaper to trigger, because it does not need a bad tool, only a bad value.

The fix, and which check actually catches both

Three guards. Only one of them catches both failure modes, which was not obvious to me until I ran it.

#!/usr/bin/env python3
"""The guard. Standard library only, needs network, no key.
Point of the last block: only ONE of the three checks catches BOTH failures."""
import json, urllib.error, urllib.request

UA = {"User-Agent": "limit-probe (contact: you@example.com)"}


class FilterIgnored(Exception):
    pass


def fetch_rows(base, param, want, key=None, cap_bytes=2_000_000):
    # CHECK 1. Refuse to send a value the server would have to guess at.
    # bool is checked FIRST and separately: isinstance(True, int) is True in
    # Python, so without that clause `want=True` sails through and goes on the
    # wire as limit=1. YAML turns `limit: yes` into True, which is exactly the
    # kind of config accident this whole post is about.
    if isinstance(want, bool) or not isinstance(want, int) or want < 1:
        raise ValueError("%s must be a positive int, got %r" % (param, want))

    sep = "&" if "?" in base else "?"
    req = urllib.request.Request("%s%s%s=%d" % (base, sep, param, want), headers=UA)
    with urllib.request.urlopen(req, timeout=60) as r:
        # CHECK 2. Stop reading before an unbounded body becomes your problem.
        body = r.read(cap_bytes + 1)
        if len(body) > cap_bytes:
            raise FilterIgnored("body passed %d bytes with %s=%d" % (cap_bytes, param, want))

    o = json.loads(body)
    rows = o if isinstance(o, list) else o[key]

    # CHECK 3. The filter is a request, not a promise.
    if len(rows) > want:
        raise FilterIgnored("asked for %d, server sent %d" % (want, len(rows)))
    return rows, len(body)


HIM = ("https://himalayas.app/jobs/api", "limit", "jobs")
LEV = ("https://api.lever.co/v0/postings/leverdemo?mode=json", "limit", None)


def unguarded(base, param, value, key):
    """What a normal client does: send the value, trust the 200."""
    sep = "&" if "?" in base else "?"
    req = urllib.request.Request("%s%s%s=%s" % (base, sep, param, value), headers=UA)
    with urllib.request.urlopen(req, timeout=60) as r:
        body = r.read()
    o = json.loads(body)
    return (o if isinstance(o, list) else o[key]), len(body)


print("A. THE GUARD ON GOOD INPUT")
for base, param, key in (HIM, LEV):
    rows, n = fetch_rows(base, param, 20, key=key)
    print("   %-24s limit=20 -> %3d rows, %8d bytes" % (base.split("/")[2], len(rows), n))

print("\nB. WHAT AN UNGUARDED CLIENT GETS FROM ONE NON-NUMERIC VALUE")
for base, param, key in (HIM, LEV):
    rows, n = unguarded(base, param, "not-a-number", key)
    print("   %-24s limit=not-a-number -> %3d rows, %8d bytes, HTTP 200"
          % (base.split("/")[2], len(rows), n))

print("\nC. WHICH CHECK CATCHES WHICH FAILURE")
for base, param, key in (HIM, LEV):
    host = base.split("/")[2]
    rows, n = unguarded(base, param, "not-a-number", key)
    c3 = "FIRES" if len(rows) > 20 else "silent"
    c2 = "FIRES" if n > 2_000_000 else "silent"
    try:
        fetch_rows(base, param, "not-a-number", key=key)
        c1 = "silent"
    except ValueError:
        c1 = "FIRES"
    print("   %-24s check1 validate=%-6s check2 body cap=%-6s check3 count>want=%s"
          % (host, c1, c2, c3))

Output, same machine, July 29, 2026:

A. THE GUARD ON GOOD INPUT
   himalayas.app            limit=20 ->  20 rows,   132440 bytes
   api.lever.co             limit=20 ->  20 rows,   147089 bytes

B. WHAT AN UNGUARDED CLIENT GETS FROM ONE NON-NUMERIC VALUE
   himalayas.app            limit=not-a-number -> 200 rows,  1219458 bytes, HTTP 200
   api.lever.co             limit=not-a-number ->   0 rows,        2 bytes, HTTP 200

C. WHICH CHECK CATCHES WHICH FAILURE
   himalayas.app            check1 validate=FIRES  check2 body cap=silent check3 count>want=FIRES
   api.lever.co             check1 validate=FIRES  check2 body cap=silent check3 count>want=silent

Block C is the one to keep. The count check, len(rows) > want, is the guard everybody reaches for, and it catches Himalayas cleanly. Against Lever it is silent, because zero rows is not more than twenty and never will be. Every response-side check has this shape: it can only see the direction it was written to see.

The 2 MB body cap is silent on both, and that is my own default being too generous rather than the check being wrong. Himalayas returned 1,219,458 bytes, comfortably under it. Set the cap from what your query should plausibly return, not from a round number you like the look of. Twenty job postings are about 132 kB here, so 2 MB was never a meaningful ceiling for this call.

Only check 1 fires on both, and it is the cheapest of the three: refuse to put a value on the wire that is not the type you meant. No network, no allocation, no ambiguity. You cannot be surprised by a coercion that never happened. Note the bool clause in it: isinstance(True, int) is True in Python, so without that line a config file that says limit: yes passes validation and goes out as limit=1. I wrote the check without it first.

What all three are blind to sits in my own output two blocks up: limit=99999 comes back as 20 rows, HTTP 200. Check 1 passes it, because 99999 is a positive integer. Check 2 sees 132 kB. Check 3 asks whether 20 is greater than 99999 and stays quiet. Silent under-delivery of a perfectly valid request slips past the entire set. So this is not the whole prescription. It covers coercion accidents, and it is worth having for that. The direction it misses is the same one Lever demonstrates, which is why the last section of this post is an open question rather than an answer.

Honest limits

This is a snapshot. Thirteen endpoints, ten validation probes, one machine, one IP, one day: July 29, 2026. Three consecutive repeats of the Himalayas pair returned identical md5s, but those repeats span minutes, not weeks. Whether the defect survives next Tuesday I do not know, and if you are reading this later, run the probe before quoting me.
The mechanism is inferred from behaviour, not read from source. parseInt for Himalayas across eleven values, of which only three actually discriminate between parseInt and Number, and six are one NaN observation repeated. slice(0, N) for Lever across four values plus a second board. Both fit every observation I have. Neither is a code review, and I would drop both labels before I would drop the measurements. Why a failed parse lands on exactly 200 I do not know: "limit": null in the envelope argues against a substituted default and for an unconstrained page size.
The defect is endpoint-scoped, not site-scoped. /jobs/api/search on the same domain has none of it. One endpoint of one site is a much smaller claim than the headline implies, and the headline is doing headline work.
Five of the thirteen are employer boards, not aggregators. Greenhouse, Ashby, Lever, SmartRecruiters and Personio each serve one company at a time and need that company's board token. Four of five SmartRecruiters companies I tried returned an empty list with HTTP 200. And since a company name I made up returns that same 52-byte body, I cannot tell whether those four boards are empty or those four identifiers are wrong. I lean towards wrong identifiers.
I did not measure rate limits, deliberately. Himalayas says it rate-limits and publishes no numbers. Finding the threshold means hammering somebody's server to make a point, so there is not a single rate-limit figure in this post. The 9.8x above is a ratio between two 3-request runs, not a claim about any quota.
I did not test whether 200 is itself a ceiling. Every non-numeric value I tried returned exactly 200 records. Whether something gets past that, I never checked.
Four providers are labelled "inert" on thin evidence. Same bytes for 3 and for garbage proves the parameter had no effect. It does not prove whether it is parsed and ignored or absent from the API, and I did not separate those.
Live data drifts. Between the first pass and the final one, Greenhouse's Stripe board moved 534 to 535 postings and RemoteOK's payload moved from 367,408 to 441,310 bytes at a steady 101 records. Expect your byte counts to differ from mine by a few percent.
No production telemetry backs this one. I run scrapers and data pipelines for a living, 32 published actors and something over 2,000 runs by my own count, and that experience is why I probe filter parameters before trusting them. It is not a source of numbers here: job boards are a field I have no production history in, so every figure above comes from this one sitting and nowhere else.
Nothing here is an invitation to hammer anyone. The composition test was three requests. I am describing a defect so you can defend your own pipeline against it, not handing out a scraping technique.

The open question

Here is the part I have not solved, and it is the Lever direction, not the Himalayas one.

The over-delivery is easy. len(rows) > want catches it, costs nothing, and fires the first time. The zero case has no such tell. An empty array is a completely legitimate answer — a board really can have no open roles today, a filter really can match nothing — and the response is byte-identical whether that is true or the parameter silently poisoned the query.

The only detector I have is a remembered baseline: this board had 388 yesterday, it has 0 today, that is worth an alert. It works, and I do not like it. It needs state, it needs a warm-up period before it can say anything, it goes wrong every time a source legitimately empties out, and on a new source it is useless on day one, which is exactly the day you are most likely to have your parameters wrong.

So: if a source can legitimately return zero rows, how do you tell a real zero from a poisoned filter on the first request, before you have any history to compare against? I have not found an answer that does not reduce to "send a second request you know the shape of", and I would like a better one. Tell me in the comments, I read every one. 👇

Written with AI assistance. Every status code, byte count, record count, token count and command output above comes from my own live requests and negative controls on July 29, 2026, printed as they came out.

{
"@context": "https://schema.org",
"@type": "ItemList",
"name": "13 Free Job-Board and ATS APIs With No Key (2026)",
"description": "Thirteen job-posting APIs that need no API key, no signup and no card, each checked with a live request on July 29, 2026, together with what each one does when the limit parameter is sent a value that is not a number.",
"itemListOrder": "https://schema.org/ItemListOrderAscending",
"numberOfItems": 13,
"itemListElement": [
{"@type": "ListItem", "position": 1, "name": "Arbeitnow", "url": "https://www.arbeitnow.com/api/job-board-api", "description": "Keyless job-board feed, mainly Germany and Europe. Returned HTTP 200 with 1,544,867 bytes and 175 postings under a data key on July 29, 2026. The limit parameter had no observable effect: limit=3 and limit=not-a-number both returned 175 records with HTTP 200 and near-identical byte counts, so whether the parameter is parsed and discarded or simply absent could not be determined from the response."},
{"@type": "ListItem", "position": 2, "name": "Remotive", "url": "https://remotive.com/api/remote-jobs", "description": "Keyless remote-jobs feed. Returned HTTP 200 with 494,763 bytes and 36 postings under a jobs key on July 29, 2026. The limit parameter had no observable effect: limit=3 and limit=not-a-number returned byte-identical 494,763-byte responses with 36 records."},
{"@type": "ListItem", "position": 3, "name": "RemoteOK", "url": "https://remoteok.com/api", "description": "Keyless remote-jobs feed returning a plain JSON array. Returned HTTP 200 with 441,310 bytes and 101 elements on July 29, 2026, up from 367,408 bytes at the same record count earlier the same day, which illustrates how much the payload size drifts between requests."},
{"@type": "ListItem", "position": 4, "name": "Jobicy", "url": "https://jobicy.com/api/v2/remote-jobs", "description": "Keyless remote-jobs feed using a count parameter rather than limit. The default response returned HTTP 200 with 830,042 bytes and 100 postings on July 29, 2026, while count=3 returned 27,397 bytes and 3 postings. It is one of four providers tested that rejects a non-numeric filter value, returning HTTP 400 with a 67-byte error body. Edge values are handled less cleanly: count=0 and count=-1 each returned one posting rather than none."},
{"@type": "ListItem", "position": 5, "name": "Working Nomads", "url": "https://www.workingnomads.com/api/exposed_jobs/", "description": "Keyless remote-jobs feed returning a plain JSON array. Returned HTTP 200 with 218,212 bytes and 44 postings on July 29, 2026."},
{"@type": "ListItem", "position": 6, "name": "The Muse", "url": "https://www.themuse.com/api/public/jobs?page=1", "description": "Keyless jobs API that requires a page parameter; without it the endpoint returns HTTP 400. With page=1 it returned HTTP 200 with 124,848 bytes and 20 results on July 29, 2026. The limit parameter had no observable effect on top of page: limit=3 and limit=not-a-number both returned 20 results."},
{"@type": "ListItem", "position": 7, "name": "Himalayas", "url": "https://himalayas.app/jobs/api", "description": "Keyless remote-jobs feed. The documentation at himalayas.app/api states 'limit: the number of jobs to retrieve (max 20)' and notes that as of 24th March 2025 the maximum was reduced to 20 jobs per request to improve performance and reliability. On July 29, 2026 every valid numeric value respected that ceiling: limit=20, limit=99999 and no parameter each returned 132,440 bytes and 20 records, limit=3 returned 23,816 bytes and 3 records, limit=0 returned 174 bytes and 0 records, and limit=-1 returned HTTP 500. A non-numeric value returned HTTP 200 with 1,219,458 bytes and 200 records, which is ten times the documented ceiling and 9.2 times the bytes of the documented maximum, reproduced identically on three consecutive repeats. Behaviour across eleven values is consistent with parseInt without validation, most clearly limit=1e9 returning 1 record; of those eleven values only three actually discriminate between parseInt and Number semantics, and limit=0x10 returning 16 records is not one of them, since both rules yield 16. This is inferred from responses rather than read from source. The documentation on the same site also states that the API returns 400 Bad Request for invalid query parameters, which the non-numeric request did not receive. Composed with offset, three requests using the broken value collected 586 unique postings against 60 for three honest requests. A second endpoint on the same site, /jobs/api/search, showed none of this behaviour: five different limit values all returned 93,005 bytes and 18 records."},
{"@type": "ListItem", "position": 8, "name": "Hacker News 'Who is hiring' via the Algolia API", "url": "https://hn.algolia.com/api/v1/search?tags=story&query=who%20is%20hiring", "description": "Keyless search over Hacker News stories and comments, usable to reach the monthly Who-is-hiring threads. Returned HTTP 200 with 197,327 bytes and 20 hits on July 29, 2026. It uses hitsPerPage rather than limit and is one of four providers tested that rejects a non-numeric value, returning HTTP 400 with a 151-byte body."},
{"@type": "ListItem", "position": 9, "name": "Greenhouse public job board API", "url": "https://boards-api.greenhouse.io/v1/boards/stripe/jobs", "description": "The public careers-page backend for one employer at a time, not an aggregator: no key is needed but the URL requires that company's board token. The stripe board returned HTTP 200 with 317,625 bytes and 535 postings on July 29, 2026, having moved from 534 postings earlier the same day. A board token that does not exist returns HTTP 404 in 38 bytes. The limit parameter had no observable effect: limit=3 and limit=not-a-number returned byte-identical responses."},
{"@type": "ListItem", "position": 10, "name": "Ashby public job board API", "url": "https://api.ashbyhq.com/posting-api/job-board/openai", "description": "The public careers-page backend for one employer at a time, keyed by organisation slug rather than an API key. The openai board returned HTTP 200 with 11,855,242 bytes and 739 postings in a single request on July 29, 2026, which is large enough to matter for any job runner with a memory ceiling."},
{"@type": "ListItem", "position": 11, "name": "Lever public postings API", "url": "https://api.lever.co/v0/postings/leverdemo?mode=json", "description": "The public careers-page backend for one employer at a time, keyed by board token. The leverdemo board returned HTTP 200 with 2,427,173 bytes and 388 postings on July 29, 2026, with no ceiling on limit: limit=99999 and no parameter both returned all 388. A non-numeric limit returned HTTP 200 with a 2-byte body and zero records, so an empty result arrives as a successful response. Negative values slice from the end: limit=-1 returned 387 records and limit=-5 returned 383. The pattern reproduced on a second board, matchgroup, where 83 postings became 82 with limit=-1 and 0 with a non-numeric value, indicating the behaviour is in the API rather than in one board's data. Behaviour matches Array.slice(0, N) semantics, inferred from responses rather than read from source. Three tokens tried (netflix, figma, brex) returned HTTP 404."},
{"@type": "ListItem", "position": 12, "name": "SmartRecruiters posting API", "url": "https://api.smartrecruiters.com/v1/companies/Visa/postings", "description": "The public postings feed for one employer at a time, keyed by company identifier. Of five companies tried on July 29, 2026 only Visa returned postings: HTTP 200 with 3,224 bytes and 2 postings. The other four (bosch, Sopra-Steria, McDonalds, Publicis-Groupe) each returned HTTP 200 with a 52-byte body and an empty list. A control run afterwards showed that an invented company identifier returns that same 52-byte body byte for byte, while a malformed path on the same host returns HTTP 404, so these responses cannot distinguish an empty board from a company identifier that does not exist; the likelier explanation is that those four identifiers were wrong. It is one of four providers tested that rejects a non-numeric limit, returning HTTP 400 with an 11-byte body."},
{"@type": "ListItem", "position": 13, "name": "Personio public job search endpoint", "url": "https://ratepay.jobs.personio.de/search.json", "description": "The public careers-page backend for one employer at a time, served from that company's Personio subdomain. The ratepay board returned HTTP 200 with 1,447 bytes and 4 postings on July 29, 2026."}
]
}

{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{"@type": "Question", "name": "Which job-board APIs work with no API key?", "acceptedAnswer": {"@type": "Answer", "text": "Thirteen were checked with live requests on July 29, 2026 and none required a key, a signup or a card: Arbeitnow, Remotive, RemoteOK, Jobicy, Working Nomads, The Muse, Himalayas and the Hacker News Who-is-hiring index via the Algolia API are aggregator feeds, while Greenhouse, Ashby, Lever, SmartRecruiters and Personio serve the public careers page of one employer at a time and need that company's board token in the URL. The EU Open Data portal is keyless too but was excluded, because a search for jobs returns datasets about employment rather than job postings."}},
{"@type": "Question", "name": "Why does a job API return more rows than its documented limit?", "acceptedAnswer": {"@type": "Answer", "text": "Because the value is parsed rather than validated, so the branch that runs when the parse fails is not the branch anyone designed. Himalayas documents limit as max 20 and honoured that for every valid number tested on July 29, 2026, including 99999, while its own documentation promises HTTP 400 for invalid query parameters. Sending limit=not-a-number returned HTTP 200 with 200 records and 1,219,458 bytes instead, which is ten times the documented ceiling and 9.2 times the bytes of a documented-maximum request. Behaviour across the values tested is consistent with parseInt semantics rather than validation, most clearly 1e9 returning 1 record; this is inferred from responses rather than read from source, and why a failed parse lands on exactly 200 records is not established, since the envelope echoes limit: null rather than a substituted default."}},
{"@type": "Question", "name": "Can a broken limit parameter make an API return zero rows with HTTP 200?", "acceptedAnswer": {"@type": "Answer", "text": "Yes, and it is the more dangerous direction because nothing alerts. On Lever's public postings API on July 29, 2026, a board holding 388 postings returned zero records in a 2-byte body with HTTP 200 when limit was a non-numeric value. Negative values sliced from the end instead: limit=-1 returned 387 and limit=-5 returned 383. The same pattern reproduced on a second board, so it is API behaviour rather than one board's data. A pipeline receiving this logs no vacancies today, parses valid JSON, and stays green."}},
{"@type": "Question", "name": "How do I check whether an API honoured my limit parameter?", "acceptedAnswer": {"@type": "Answer", "text": "Three guards, applied in this order. First, validate the value on the client and refuse to send anything that is not a positive integer. Second, cap the number of bytes you read, sized from what your query should plausibly return rather than a round number. Third, compare the number of rows returned against the number requested and fail loudly if it is larger. Measured against both failure modes on July 29, 2026, only the first guard caught both: the row-count check fired on the over-delivering provider and was silent on the provider that returned zero rows, because zero is never greater than the number requested."}},
{"@type": "Question", "name": "Do job APIs return an error when you send a filter value that is not a number?", "acceptedAnswer": {"@type": "Answer", "text": "Usually not. Of ten providers tested on July 29, 2026, four rejected a non-numeric filter value with HTTP 400: Jobicy, SmartRecruiters, the Hacker News Algolia API and the EU Open Data portal. The other six accepted it with HTTP 200. Four of those six (Remotive, Arbeitnow, Greenhouse, The Muse) returned the same record count as for a valid value, so the parameter had no observable effect; for Remotive and Greenhouse the two responses were byte-identical, while for Arbeitnow and The Muse the byte counts differed slightly as the feed drifted between requests. The remaining two changed the size of the response: Himalayas returned ten times its documented maximum and Lever returned nothing at all."}},
{"@type": "Question", "name": "Are Greenhouse, Lever and Ashby job APIs open without a key?", "acceptedAnswer": {"@type": "Answer", "text": "They are open without an API key, but they are not aggregators. Each serves the public careers page of a single employer and the URL requires that employer's board token or organisation slug, so there is no way to browse across companies. Not every token is open: three Lever tokens tried on July 29, 2026 returned HTTP 404, and four of five SmartRecruiters companies tried returned HTTP 200 with an empty list rather than an error. Payloads vary enormously, from 1,447 bytes for one Personio board to 11,855,242 bytes for the Ashby board holding 739 postings."}}
]
}

9 Keyless Health APIs: You Asked for v1, You Got v8

Alex Spinov — Wed, 29 Jul 2026 01:28:26 +0000

I asked a keyless drug-label endpoint for version 1 of a document. Then version 3, version 8, and version 999. Here is what came back on July 27, 2026:

?spl_version=1    HTTP 200   266520 B  md5 4ae91da54b97  versionNumber=8
?spl_version=3    HTTP 200   266520 B  md5 4ae91da54b97  versionNumber=8
?spl_version=8    HTTP 200   266520 B  md5 4ae91da54b97  versionNumber=8
?spl_version=999  HTTP 200   266520 B  md5 4ae91da54b97  versionNumber=8

Four requests, one document, one md5. Not one of those lines is an error. The parameter is accepted, ignored, and never mentioned again.

And there really are eight versions under that id. The API will happily list them for you. It just will not serve you any of them except the newest.

The one idea

A keyless health API returns drug labels, trial registrations, provider records or compound data over plain HTTP with no key, no signup and no card. I checked nine of them with live requests on July 27, 2026, and the table is further down. The thing most of them share is not a missing field. It is that the id you store is stable while the record underneath it is not, and the response gives you no way to notice.

So the row in your database is not a fact about a drug label. It is a draft that the publisher can rewrite behind your back, under the same id, and your copy will keep looking exactly as correct as it did the day you fetched it.

The whole proof, and the controls that had to fail

Standard library, no key, no account. Copy it and you will get the same shape I did.

# runnable, standard library only, needs network. No key, no signup, no card.
import hashlib, json, re, urllib.request, urllib.error

DM = "https://dailymed.nlm.nih.gov/dailymed/services/v2"
RX = "https://rxnav.nlm.nih.gov/REST"
A = "10d36b32-0202-4c03-8a1a-cd5d53f231e7"   # one drug-label folder
B = "0cb0ba76-067f-46c4-a5d8-b585d5ecafe3"   # a different one, for controls
ZEROS = "00000000-0000-0000-0000-000000000000"

def fetch(url):
    try:
        with urllib.request.urlopen(url, timeout=30) as r:
            return r.status, r.read()
    except urllib.error.HTTPError as e:                 # fail loud, never silent
        return e.code, e.read()

def versions(setid):
    st, body = fetch(f"{DM}/spls/{setid}/history.json")
    return st, len(body), json.loads(body)["metadata"]["total_elements"], body

def version_in(doc):                                    # <versionNumber value="8"/>
    m = re.search(rb'<versionNumber\s+value="([^"]+)"', doc[:4000])
    return m.group(1).decode() if m else "<<ABSENT>>"

print("1. HOW MANY VERSIONS LIVE UNDER ONE id")
st, n, total, body = versions(A)
print(f"   setid {A[:8]}...  HTTP {st}, {n} bytes -> {total} versions")
for e in json.loads(body)["data"]["history"]:
    print(f"       v{e['spl_version']:<4} {e['published_date']}")
st, n, total_b, _ = versions(B)                         # control: data vs OTHER data
print(f"   CONTROL other real setid {B[:8]}... -> HTTP {st}, {n} bytes, {total_b} versions"
      f"  [{'PASS: the probe reads the document, not a constant' if total_b != total else 'FAIL'}]")
st, n, total_z, body_z = versions(ZEROS)                # an id that never existed
print(f"   an all-zeros setid       -> HTTP {st}, {n} bytes, {total_z} versions")
print(f"       body: {json.dumps(json.loads(body_z)['data'])[:74]}")

print("\n2. ASK FOR AN OLD VERSION. FINGERPRINT WHAT COMES BACK.")
seen = {}
for want in ("1", "3", "8", "999"):
    st, doc = fetch(f"{DM}/spls/{A}.xml?spl_version={want}")
    md5 = hashlib.md5(doc).hexdigest()
    seen.setdefault(md5, []).append(want)
    got = version_in(doc)
    note = "as asked" if got == want else f"<-- asked {want}, served {got}"
    print(f"   ?spl_version={want:<4} HTTP {st}  {len(doc):>7} B  md5 {md5[:12]}  "
          f"versionNumber={got:<11}{note}")
print(f"   distinct documents behind those 4 requests: {len(seen)}")
st, other = fetch(f"{DM}/spls/{B}.xml")                 # control: data vs OTHER data
print(f"   CONTROL a different setid -> {len(other):>7} B  md5 "
      f"{hashlib.md5(other).hexdigest()[:12]}  "
      f"[{'PASS: md5 can tell two documents apart' if hashlib.md5(other).hexdigest() not in seen else 'FAIL'}]")
st, doc = fetch(f"{DM}/spls/{A}/3.xml")
kind = "HTML homepage, not a document" if b"<!DOCTYPE html" in doc[:200] else "a document"
print(f"   path /3.xml       HTTP {st}  {len(doc):>7} B  "
      f"versionNumber={version_in(doc):<11}<-- {kind}")
impossible = b'<zzqqNotATag991 value="7"/>'
print(f"   CONTROL matcher on a tag that cannot exist -> "
      f"{version_in(impossible)}  [PASS: the matcher can miss]")
print("   Not one line above is an error. Every line is HTTP 200.")

print("\n3. 'OBSOLETE' AND 'NEVER EXISTED' ARE THE SAME RESPONSE")
cases = [("1801289", "in use"), ("105078", "obsolete"),
         ("351772", "remapped"), ("999999999", "never existed")]
print(f"   {'rxcui':<12}{'my label for it':<18}{'properties.json':<26}historystatus.json")
shapes = {}
for rxcui, what in cases:
    st, body = fetch(f"{RX}/rxcui/{rxcui}/properties.json")
    plain = f"HTTP {st}, {len(body)} bytes"
    _, hb = fetch(f"{RX}/rxcui/{rxcui}/historystatus.json")
    status = json.loads(hb)["rxcuiStatusHistory"]["metaData"]["status"]
    print(f"   {rxcui:<12}{what:<18}{plain:<26}status={status}")
    shapes.setdefault(plain, []).append(what)
for group in (v for v in shapes.values() if len(v) > 1):
    print(f"   COLLAPSED into one identical response: {', '.join(group)}")
print(f"   properties.json    -> {len(shapes)} distinct answers for 4 distinct realities")
print(f"   historystatus.json -> 4 distinct answers for the same 4 ids")

Output on my machine, July 27, 2026, pasted as it came out:

1. HOW MANY VERSIONS LIVE UNDER ONE id
   setid 10d36b32...  HTTP 200, 946 bytes -> 8 versions
       v8    Jun 26, 2026
       v7    Nov 22, 2024
       v6    Dec 15, 2023
       v5    Oct 07, 2022
       v4    Jun 29, 2021
       v3    Jul 31, 2020
       v2    May 07, 2019
       v1    Aug 01, 2017
   CONTROL other real setid 0cb0ba76... -> HTTP 200, 619 bytes, 1 versions  [PASS: the probe reads the document, not a constant]
   an all-zeros setid       -> HTTP 200, 433 bytes, 0 versions
       body: {"spl": {"title": "", "setid": ""}, "history": []}

2. ASK FOR AN OLD VERSION. FINGERPRINT WHAT COMES BACK.
   ?spl_version=1    HTTP 200   266520 B  md5 4ae91da54b97  versionNumber=8          <-- asked 1, served 8
   ?spl_version=3    HTTP 200   266520 B  md5 4ae91da54b97  versionNumber=8          <-- asked 3, served 8
   ?spl_version=8    HTTP 200   266520 B  md5 4ae91da54b97  versionNumber=8          as asked
   ?spl_version=999  HTTP 200   266520 B  md5 4ae91da54b97  versionNumber=8          <-- asked 999, served 8
   distinct documents behind those 4 requests: 1
   CONTROL a different setid ->   95825 B  md5 1dc13a19afa1  [PASS: md5 can tell two documents apart]
   path /3.xml       HTTP 200    75305 B  versionNumber=<<ABSENT>> <-- HTML homepage, not a document
   CONTROL matcher on a tag that cannot exist -> <<ABSENT>>  [PASS: the matcher can miss]
   Not one line above is an error. Every line is HTTP 200.

3. 'OBSOLETE' AND 'NEVER EXISTED' ARE THE SAME RESPONSE
   rxcui       my label for it   properties.json           historystatus.json
   1801289     in use            HTTP 200, 270 bytes       status=Active
   105078      obsolete          HTTP 200, 2 bytes         status=Obsolete
   351772      remapped          HTTP 200, 2 bytes         status=Remapped
   999999999   never existed     HTTP 200, 2 bytes         status=UNKNOWN
   COLLAPSED into one identical response: obsolete, remapped, never existed
   properties.json    -> 2 distinct answers for 4 distinct realities
   historystatus.json -> 4 distinct answers for the same 4 ids

A word about the controls, because I nearly shipped a weak one. My first version checked the history probe against a made-up setid and got zero versions back, which felt like proof the probe worked. It is not. That control only shows the probe can tell data from nothing. It says nothing about whether the probe can tell data from other data, which is the thing I was actually claiming. So both controls now compare two real documents: a second setid with a different version count, and an md5 that demonstrably differs across two real files before I trust it matching four times.

The all-zeros line is worth a second look on its own. A setid made of nothing but zeros returns HTTP 200 with a complete envelope and an empty history array. So "this record never existed" and "this record has no history" arrive as the same successful response. That is the article's problem viewed from the other end.

How often does a label actually get rewritten?

Often enough that it is not an edge case. I sampled 80 setids from 8 random pages of the live index (seed 63, out of 158,178 records) and pulled the history of each:

history says rewritten (>1 version) : 49/80 = 61.3%
naive test spl_version > 1          : 56/80 = 70.0%
the two disagree on                 : 7/80 = 8.8%

Roughly six in ten of the labels in that sample had been rewritten at least once under an id that never moved.

Now look at the second line, because that is the test you would write. spl_version sits right there in the list response, so counting rows where it exceeds 1 looks like a free answer. It disagrees with the real history on 7 of the 80, always in the direction of overcounting.

spl_version is not a revision count. From that same sample:

spl_version=101     history has 2   version(s)   5c8cebcd...  PROPAFENONE HYDROCHLORIDE TABLET
spl_version=100     history has 1   version(s)   b4b7b936...  ENALAPRIL MALEATE TABLET
spl_version=100     history has 1   version(s)   c83daa7b...  DANTROLENE SODIUM CAPSULE
spl_version=100     history has 1   version(s)   1ebeb8ec...  RIVASTIGMINE TRANSDERMAL SYSTEM
spl_version=21      history has 8   version(s)   d1468c0f...  SODIUM CHLORIDE INJECTION

Three records carrying version 100 with exactly one version in their history. One carrying version 21 with eight. The number is a publisher's own counter, and comparing it across setids means nothing. The titles above are record labels and nothing more; none of this says anything about the products themselves.

I want to be blunt about how I got here, because the wrong version of this section nearly went out. My first pass measured the rewrite rate with spl_version > 1 and produced a confident percentage. The very next probe killed the method: a record at version 100 with a single entry in its history proves the field does not mean what the name suggests. I threw the number away rather than publish it, and the 49 of 80 above comes from counting actual history entries instead.

The nine endpoints, checked live

Every row is a request I made on July 27, 2026 with no key, no account and no card. The last column is the point of the table: what, if anything, tells you the record has a past.

#	Provider	Keyless endpoint	What came back	Version signal
1	DailyMed (NLM)	`dailymed.nlm.nih.gov/dailymed/services/v2/spls/{setid}/history.json`	158,178 SPLs in the index; the sampled setid returned 8 versions in 946 bytes	full history, but old documents are not served
2	RxNorm / RxNav (NLM)	`rxnav.nlm.nih.gov/REST/rxcui/{id}/historystatus.json`	`Active`, `Obsolete`, `Remapped`, `UNKNOWN` on the four ids I tried	status only, and only on this endpoint
3	ClinicalTrials.gov	`clinicaltrials.gov/api/int/studies/{nct}/history`	NCT00001372 returned 395 versions in 86,963 bytes; NCT02576457 returned 27	full history with a status per version
4	openFDA drug/label	`api.fda.gov/drug/label.json?limit=1`	200, 3,933 bytes, 260,986 labels in the index, `version: 2`, and `id` differs from `set_id`	version number, no history
5	WHO GHO	`ghoapi.azureedge.net/api/WHOSIS_000001?$top=1`	200, 689 bytes, 26 leaf fields, 6 of them time related	none: every time field describes the observation, not the record
6	PubChem PUG	`pubchem.ncbi.nlm.nih.gov/rest/pug/compound/name/{name}/property/.../JSON`	200, 224 bytes, 4 leaf fields	none
7	NPI Registry (CMS)	`npiregistry.cms.hhs.gov/api/?version=2.1&number={npi}`	npi 1578736112: `enumeration_date` 2008-04-03, `last_updated` 2026-01-05	one timestamp, sitting 18 years after enumeration
8	HAPI FHIR R4 (public test server)	`hapi.fhir.org/baseR4/Patient/{id}/_history`	`_history` total 2: v1 POST at 13:06:56.678, v2 PUT at 13:06:57.560	versioning is in the protocol
9	disease.sh	`disease.sh/v3/covid-19/all`	200, 478 bytes, 21 keys, one of them time related (`updated`, epoch ms)	none

Nine services, no keys. Three of them list a record's past version by version: DailyMed, ClinicalTrials.gov, and any FHIR server. Two more hint at it without enumerating anything, and they hint differently: RxNorm tells you a concept was retired or remapped, openFDA ships a version number with nothing behind it. NPPES gives you two dates eighteen years apart and nothing in between, so you can see that something happened without seeing how many times. The remaining three say nothing at all.

The same provider, two endpoints, two different truths

Block 3 of the output is the one I would tape to a wall. RxNorm's properties.json returns 2 distinct responses for 4 distinct realities. An obsolete concept, a remapped concept and an id nobody ever issued all come back as HTTP 200 with a 2-byte body, {}.

Think about what that does to a pipeline. Your nightly job re-checks the ids you stored. One of them starts returning {}. There is no status code to branch on, no error field, no message. From inside the client, "this identifier was retired" is indistinguishable from "you sent garbage", and both are indistinguishable from a typo in your own query.

The information is not missing. It is one endpoint away. historystatus.json answers all four cases separately and tells you the retirement month while it is at it. Nothing forces you to call it, and nothing warns you that you did not.

ClinicalTrials.gov shows the same split with a sharper edge. The public v2 endpoint gives you the current record. The history endpoint gives you every version, and for NCT02576457 the status field walks NOT_YET_RECRUITING to RECRUITING to ACTIVE_NOT_RECRUITING to TERMINATED across 27 versions between 2015-10-14 and 2017-09-14. If you stored that row in 2016 and keyed it by NCT id, you are holding a value the source stopped agreeing with nine years ago, and your row looks fine.

This is not the `latest` problem, and the usual fix does not apply

A few days ago I wrote about package registries and why you cannot pin latest. The prescription there was clear: never dereference a mutable alias in a build, resolve it once, and pin an exact version plus an integrity hash.

I want to be direct about this, because it is my own advice and it does not survive contact with these APIs.

On a package registry, version 1.2.3 is immutable and only the pointer moves, which is precisely why pinning rescues you. Here the pointer is all there is. DailyMed accepts ?spl_version=1 and serves you version 8 with no complaint, so there is nothing to pin. The path form /{setid}/3.xml is worse: HTTP 200, 75,305 bytes, and what arrives is the DailyMed homepage in HTML with no <document> element anywhere in it. RxNorm's answer to an old identifier is {}. You can learn that version 3 existed and when it was published. You cannot obtain it.

So the two posts are not the same post. There, the archive exists and you have to aim at it correctly. Here the archive is announced and withheld, which means the only copy of version 3 you will ever have is the one you took on the day it was current.

The fix, and why my usual advice about upsert is wrong here

I have also argued, in a post about a scraper that died at row 12,000, that an upsert beats a blind append. I stand by that in its own context and it is the exact wrong move here, so let me draw the line rather than leave the two posts arguing with each other.

Upsert is right when you are rewriting your own unfinished run. The job crashed, you restart it, you re-fetch rows you already had, and you want one copy of each. Upsert is wrong when you are rewriting someone else's changed record, because then the row you overwrite was evidence, and after the overwrite there is no trace that the source ever said anything different.

The distinction is not upsert versus append. It is what you put in the key.

# runnable, standard library only, no network, no keys.
# Replays the two real histories printed above: folder A was rewritten 7 times,
# folder B never was. A crawler happened to visit on each publication day.

A = [(8, "2026-06-26"), (7, "2024-11-22"), (6, "2023-12-15"), (5, "2022-10-07"),
     (4, "2021-06-29"), (3, "2020-07-31"), (2, "2019-05-07"), (1, "2017-08-01")]
B = [(1, "2026-07-24")]

def visits(setid, history):
    """What the crawler stores on each visit: whichever version was current."""
    return [(setid, ver, day) for ver, day in reversed(history)]

crawl = visits("A", A) + visits("B", B)

upsert, append = {}, {}
for setid, ver, day in crawl:
    upsert[setid] = (ver, day)                 # keyed by id alone
    append[(setid, ver)] = day                 # keyed by (id, version)

def rewrites(store, setid, keyed_by_version):
    rows = ([k for k in store if k[0] == setid] if keyed_by_version
            else [k for k in store if k == setid])
    return len(rows) - 1

print("after the crawl:")
print(f"  upsert by id        A: {sum(1 for k in upsert if k == 'A')} row   "
      f"B: {sum(1 for k in upsert if k == 'B')} row   "
      f"-> rewrites detected: A={rewrites(upsert,'A',False)}, B={rewrites(upsert,'B',False)}")
print(f"  append by (id, ver) A: {sum(1 for k in append if k[0]=='A')} rows  "
      f"B: {sum(1 for k in append if k[0]=='B')} row   "
      f"-> rewrites detected: A={rewrites(append,'A',True)}, B={rewrites(append,'B',True)}")

same = rewrites(upsert, "A", False) == rewrites(upsert, "B", False)
print(f"\n  the upsert store answers 'was this rewritten?' identically for a folder"
      f"\n  rewritten 7 times and one never touched: {same}")

# The control that matters: re-run the last visit, the way a crashed job does.
before = len(append)
for setid, ver, day in crawl[-3:]:
    append[(setid, ver)] = day
print(f"\n  replaying the last 3 visits after a crash: {before} -> {len(append)} rows"
      f"  [{'PASS: no duplicates' if len(append) == before else 'FAIL'}]")

# And a check that can fail, so it is a check and not decoration.
def assert_history_survives(store, setid, expected):
    got = len([k for k in store if k[0] == setid])
    if got != expected:
        raise AssertionError(f"{setid}: kept {got} versions, source published {expected}")

assert_history_survives(append, "A", len(A))
try:
    assert_history_survives({("A", 8): "2026-06-26"}, "A", len(A))
except AssertionError as e:
    print(f"  the same assertion on an upserted store -> {e}")

Output, same machine, July 27, 2026:

after the crawl:
  upsert by id        A: 1 row   B: 1 row   -> rewrites detected: A=0, B=0
  append by (id, ver) A: 8 rows  B: 1 row   -> rewrites detected: A=7, B=0

  the upsert store answers 'was this rewritten?' identically for a folder
  rewritten 7 times and one never touched: True

  replaying the last 3 visits after a crash: 9 -> 9 rows  [PASS: no duplicates]
  the same assertion on an upserted store -> A: kept 1 versions, source published 8

Read the middle block. The upsert store gives the same answer, zero rewrites, for a folder that was rewritten seven times and for one that was never touched. That is not a small loss of detail. It is the destruction of the only difference that mattered, and the store cannot even report that it happened.

Now read the line after it. Replaying the last three visits, the way a crashed job replays them, leaves the row count unchanged. The deduplication came from the key, not from the upsert. Once (id, version) is the key, the crash-safety argument from the row-12,000 post still holds and you keep the history as well. The two posts only conflict if you let the key stay at id.

The last line is the assertion doing its job in the direction that matters: fed an upserted store, it fails loudly and names the gap. A check that cannot fail is decoration.

Honest limits

This is a snapshot. Nine services, one machine, one IP, July 27, 2026. I did not read anyone's terms and did not measure rate limits, which is why there is not a single limit number in this post.
80 setids is a sample, not a census. 80 out of 158,178, from 8 random pages, seed 63. I did not compute a confidence interval, so treat 49 of 80 as an order of magnitude, not a national statistic.
The title generalises from a small check, so here is the check. The four-request fingerprint above is one setid. I then repeated it on ten further multi-version setids drawn from a different page of the index, comparing version 1 against each document's own latest version: 10 of 10 returned an identical md5 for both. Control: two different setids compared the same way do produce different md5s, so the comparison is capable of showing a difference. Eleven documents is still not the whole index of 158,178, and I have not tested a single one that behaved otherwise.
The rewrite rate is DailyMed only. I did not sample ClinicalTrials.gov or openFDA the same way, so nothing here says how often a trial record or an openFDA label changes.
HAPI FHIR is a public test server that anyone on the internet can write to. The two versions I found were created 0.882 seconds apart, so that is somebody's test script, not clinical data. I include it because it shows the protocol carries versionId and _history natively, which is the counterexample to everything above, and for no other reason.
A search that returned nothing. Patient?_count=1 on that same server gave me HTTP 200, 455 bytes, a searchset bundle with a next link and no entry array at all. Reading a patient by id worked fine a second later. I have no explanation and I am not going to invent one.
I did not audit disease.sh past the top-level object. It answered with no key and it has no version field in that object. That is all I checked.
openFDA answered normally for me on the one call I made. I did not test it under repetition.
Nothing here is clinical. Every measurement in this post is about the behaviour of an API as a data source. Drug and trial names appear only as record identifiers, and no statement here concerns any product, treatment or study on its merits.
Provenance. I run scrapers and data pipelines in production, 32 published actors and something over 2,000 runs by my own count. The habit behind this post came from enrichment feeds, which lie with a confident 200 far more often than they fail honestly. These nine checks are one sitting, not a production sample, and I am not going to dress them up as one.

The open question

Here is the part I have not solved. DailyMed will tell me that version 3 of a document existed and was published on 2020-07-31. It will not give me version 3. So the only way to ever hold those bytes is to have been crawling on a day when version 3 was current, and to have kept them.

That turns a cheap decision into an expensive one. Storing (id, version, hash, seen_at) costs almost nothing and lets me prove that something changed. Storing the full document on every fetch lets me prove what changed, and at a quarter of a megabyte for the one label I measured, across an index of 158,178, that is a real bill for a question nobody has asked me yet.

I currently keep hashes for everything and full bodies only for the handful of sources I have been burned by. It feels like the wrong line, drawn from memory of past incidents rather than from anything principled.

If you pull records from a source that rewrites them in place: do you snapshot every fetch, or keep only the fingerprint and accept that you can prove a change without ever being able to show it? Tell me in the comments, I read every one. 👇

Written with AI assistance. Every status code, byte count, md5, row count and command output above comes from my own live requests and negative controls on July 27, 2026, printed as they came out.

{
"@context": "https://schema.org",
"@type": "ItemList",
"name": "9 Free Health and Medical APIs With No Key (2026)",
"description": "Nine health and medical APIs that need no API key, no signup and no card, each checked with a live request on July 27, 2026, together with what each response does or does not tell you about whether the record under a stable id has been rewritten since it was published.",
"itemListOrder": "https://schema.org/ItemListOrderAscending",
"numberOfItems": 9,
"itemListElement": [
{"@type": "ListItem", "position": 1, "name": "DailyMed (US National Library of Medicine)", "url": "https://dailymed.nlm.nih.gov/dailymed/services/v2/spls.json", "description": "Keyless access to structured product labels. The index held 158,178 SPLs on July 27, 2026. A history endpoint at /spls/{setid}/history.json lists every version under a setid: one sampled setid returned 8 versions in 946 bytes, published between August 1, 2017 and June 26, 2026. Old versions are listed but not served: requesting the document with ?spl_version=1, 3, 8 or 999 returned four byte-identical responses of 266,520 bytes with md5 4ae91da54b97, each carrying versionNumber 8 and HTTP 200, and the path form /{setid}/3.xml returned HTTP 200 with 75,305 bytes of the DailyMed HTML homepage. A setid made entirely of zeros returns HTTP 200 with an empty history array rather than a 404. In a sample of 80 setids from 8 random pages, 49 had more than one version, while the naive test spl_version greater than 1 flagged 56 and disagreed with the real history on 7, because spl_version is a publisher counter rather than a revision count: three sampled records showed version 100 with a single version in their history."},
{"@type": "ListItem", "position": 2, "name": "RxNorm and RxNav (US National Library of Medicine)", "url": "https://rxnav.nlm.nih.gov/REST/rxcui/1801289/historystatus.json", "description": "Keyless drug terminology lookups. The plain properties.json endpoint returns HTTP 200 with a 2-byte empty object for an obsolete concept, a remapped concept and an identifier that never existed, giving 2 distinct responses for 4 distinct realities, while a valid active concept returns 270 bytes. The historystatus.json endpoint distinguishes all four, returning status Active, Obsolete, Remapped and UNKNOWN respectively, and includes the month a concept was retired or remapped."},
{"@type": "ListItem", "position": 3, "name": "ClinicalTrials.gov API v2", "url": "https://clinicaltrials.gov/api/v2/studies/NCT00001372", "description": "Keyless access to trial registrations. The v2 study endpoint returns the current record only, carrying studyFirstSubmitDate and lastUpdateSubmitDate; a nonexistent NCT number returns HTTP 404 with a 32-byte plain-text body. A separate history endpoint at /api/int/studies/{nct}/history returns every version: NCT00001372 returned 395 versions in 86,963 bytes, and NCT02576457 returned 27 versions in which the status field moved from NOT_YET_RECRUITING to RECRUITING to ACTIVE_NOT_RECRUITING to TERMINATED between October 14, 2015 and September 14, 2017."},
{"@type": "ListItem", "position": 4, "name": "openFDA drug label API", "url": "https://api.fda.gov/drug/label.json?limit=1", "description": "Keyless access to FDA drug label data, 260,986 labels in the index on July 27, 2026. A single record returned HTTP 200 in 3,933 bytes carrying a version field (value 2), an effective_time, and both an id and a set_id whose values differ, which is the same folder-versus-document split DailyMed exposes. The endpoint returns the current version only and offers no history listing."},
{"@type": "ListItem", "position": 5, "name": "WHO Global Health Observatory OData API", "url": "https://ghoapi.azureedge.net/api/WHOSIS_000001?$top=1", "description": "Keyless OData access to WHO health indicators. A single observation returned HTTP 200 in 689 bytes with 26 leaf fields, of which 6 are time related: TimeDimType, TimeDim, Date, TimeDimensionValue, TimeDimensionBegin and TimeDimensionEnd. All six describe the period the observation covers rather than the revision state of the record, so there is no way from the payload to tell whether a value was restated after publication."},
{"@type": "ListItem", "position": 6, "name": "PubChem PUG REST", "url": "https://pubchem.ncbi.nlm.nih.gov/rest/pug/compound/name/aspirin/property/MolecularFormula,MolecularWeight,ConnectivitySMILES/JSON", "description": "Keyless chemical compound properties. A three-property request returned HTTP 200 in 224 bytes with 4 leaf fields (CID plus the three requested properties) and no version, revision or update field of any kind. The same field-counting probe finds 3 version-related fields in a DailyMed response, so the absence here is a measured zero rather than a probe that cannot count."},
{"@type": "ListItem", "position": 7, "name": "NPPES NPI Registry (US Centers for Medicare and Medicaid Services)", "url": "https://npiregistry.cms.hhs.gov/api/?version=2.1&number=1578736112", "description": "Keyless lookups of US healthcare provider identifiers. A real NPI returned HTTP 200 with result_count 1, an enumeration_date of 2008-04-03 and a last_updated of 2026-01-05, which is two dates roughly 18 years apart with nothing in between them: no version number, no revision count and no history endpoint. A nonexistent NPI returns HTTP 200 with result_count 0 in 31 bytes rather than a 404."},
{"@type": "ListItem", "position": 8, "name": "HAPI FHIR R4 public test server", "url": "https://hapi.fhir.org/baseR4", "description": "A public FHIR R4 test server, open for reads and writes to anyone, included as a protocol counterexample rather than as a data source. Every resource carries meta.versionId and every resource exposes a _history endpoint: one patient read returned versionId 2, and its _history returned a bundle of total 2 in which version 1 was a POST and version 2 a PUT logged 0.882 seconds later, which is somebody's test write rather than clinical data. A separate Patient search with _count=1 returned HTTP 200 in 455 bytes as a searchset bundle carrying a next link and no entry array at all."},
{"@type": "ListItem", "position": 9, "name": "disease.sh", "url": "https://disease.sh/v3/covid-19/all", "description": "Keyless aggregated public-health counts. The global summary returned HTTP 200 in 478 bytes with 21 top-level keys, of which exactly one is time related: updated, an epoch timestamp in milliseconds. There is no version field and no history endpoint, so a restated figure and an original figure are indistinguishable once stored. Fields below the top-level object were not audited."}
]
}

{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{"@type": "Question", "name": "Which health and medical APIs work with no key?", "acceptedAnswer": {"@type": "Answer", "text": "Nine were checked with live requests on July 27, 2026: DailyMed, RxNorm and RxNav, ClinicalTrials.gov, openFDA drug labels, the WHO Global Health Observatory, PubChem PUG REST, the CMS NPI Registry, the public HAPI FHIR R4 test server and disease.sh. None required a key, a signup or a card. The HAPI FHIR server is a public test instance that anyone can write to and is listed as a protocol example, not as a data source."}},
{"@type": "Question", "name": "How do I know if a health API record changed after I stored it?", "acceptedAnswer": {"@type": "Answer", "text": "Usually not from the record itself. You need a separate history endpoint, and only some providers publish one: DailyMed at /spls/{setid}/history.json, ClinicalTrials.gov at /api/int/studies/{nct}/history, and any FHIR server at resource/{id}/_history. Compare the number of versions rather than the value of a field, because a version field can move without the history growing. openFDA, the NPI Registry, PubChem, the WHO GHO and disease.sh published no history endpoint at all when checked on July 27, 2026."}},
{"@type": "Question", "name": "Is spl_version the number of times a DailyMed drug label was revised?", "acceptedAnswer": {"@type": "Answer", "text": "No. In a sample of 80 setids taken on July 27, 2026, testing spl_version greater than 1 flagged 56 records as rewritten while the actual history endpoint showed 49, a disagreement on 7 of the 80. Three sampled records carried spl_version 100 with exactly one version in their history, and one carried spl_version 21 with eight versions in its history. The field is a publisher's own counter and is not comparable across setids."}},
{"@type": "Question", "name": "Can I fetch an older version of a DailyMed SPL over the API?", "acceptedAnswer": {"@type": "Answer", "text": "No. Requesting the same document with ?spl_version=1, 3, 8 and 999 on July 27, 2026 returned four byte-identical responses of 266,520 bytes sharing md5 4ae91da54b97, every one of them carrying versionNumber 8 and HTTP 200, so the parameter is accepted and ignored without any error. The path form /spls/{setid}/3.xml returned HTTP 200 with 75,305 bytes of the DailyMed HTML homepage rather than a document. The history endpoint tells you which versions exist and when they were published, but the documents themselves are not retrievable. The same check repeated on ten further multi-version setids from a different index page returned an identical md5 for version 1 and for the latest version in all ten cases."}},
{"@type": "Question", "name": "Why does an RxNorm rxcui return an empty object with HTTP 200?", "acceptedAnswer": {"@type": "Answer", "text": "Because the properties.json endpoint answers identically for three different situations. On July 27, 2026 an obsolete concept, a remapped concept and an identifier that never existed all returned HTTP 200 with a 2-byte empty object, while an active concept returned 270 bytes, giving 2 distinct responses for 4 distinct realities. The historystatus.json endpoint on the same identifiers returned four different answers: Active, Obsolete, Remapped and UNKNOWN. The information exists, it is simply not in the endpoint most clients call."}},
{"@type": "Question", "name": "What is the right primary key for a scraped medical record?", "acceptedAnswer": {"@type": "Answer", "text": "The pair (id, version) plus the timestamp of your own observation. A setid, an rxcui or an NCT number identifies a folder rather than a document, which DailyMed makes literal: the setId element stays constant while the id element changes with every version, and openFDA ships both an id and a set_id whose values differ. Keying on the identifier alone makes a record that was rewritten seven times indistinguishable from one that was never touched."}},
{"@type": "Question", "name": "Should I upsert scraped rows by source id?", "acceptedAnswer": {"@type": "Answer", "text": "Only when you are rewriting your own unfinished run, such as re-fetching rows after a crashed job, where an upsert correctly removes your duplicate. For a record the source can change, an upsert keyed on id alone deletes the only evidence that it changed. Key on (id, version) and append instead: replaying the same visits after a crash still produces no duplicates, because the deduplication comes from the key rather than from the upsert, and the version history survives."}}
]
}

10 Keyless Statistics APIs: Never Delete the World Row

Alex Spinov — Mon, 27 Jul 2026 03:48:47 +0000

One indicator, one year, one keyless endpoint. I asked the World Bank for population in 2023, got 264 rows with a value, and added them up four different ways:

naive sum of every row         86,466,868,911  10.7240x
deny-list on countryiso3code   16,102,473,551   1.9971x
allow-list on country.id        8,039,550,134   0.9971x
the WLD row itself              8,062,923,417   1.0000x

Line one is a joke and nobody ships it. Line two is the one that ends up in a report, because 8 billion people looks like 8 billion people until you notice there are two of them.

The one idea

A keyless statistics API returns indicators by country and year with no API key, no signup and no card. I checked ten of them with live requests on July 26, 2026, and the table is two screens down. The catch they mostly share: totals and members arrive in one list, in one schema, and on eight of the ten the data rows carry no column that says which is which. "World" is a row. So is "High income". So is Belgium. Two of the ten do carry that column, and I owe them the credit: WHO GHO and UN Comtrade. There is a section on them below, because the exception is the useful part.

Your instinct will be to filter the totals out. Mine was. That instinct is what produced the second line above, and the second line is worse than the first.

Better move: keep the total row and make it a test. The row that ruins your sum is the only free check on your own filter that you will ever be handed.

First, the probes that had to fail

If a checking script only ever reports success, it is not a check, it is a decoration. So before the first 200 I made the channel fail in as many ways as I could, on July 26, 2026:

#	Probe	Result
N1	host that does not exist, `api-zzqq9182-nosuchhost-77.org`	curl exit `35`, HTTP `000`
N2	real host, junk path, `api.worldbank.org/v2/ZZQQNOSUCHPATH9182`	HTTP `404`
N3	real host, junk indicator `ZZ.QQ.NOSUCH`	HTTP `200` plus `{"id":"120","key":"Invalid value"}`
N4	FRED without a key	HTTP `400`, `Variable api_key is not set`
N5	US Census `api.census.gov/data/2023/pep/population?get=NAME,POP_2023&for=state:*` without a key	`302` then HTTP `200` on `missing_key.html` (the bare path with no query returns a plain `404`)
N6	BEA without a key	HTTP `200`, `content-length: 0`
N7	WHO GHO with `$top=2000`	HTTP `400`; at `$top=500` it returns 200

Seven probes, five shapes of failure: a dead socket, a 404, a 200 carrying an error object, a 400 with an English sentence, and a 200 carrying nothing at all. So "keyless" here means "I called it with no credentials and got data", never "the docs said free".

That is also why three services people list as free statistics APIs are missing from my ten. FRED, BEA and the US Census all want a key, and they say so in three different ways. Only one of them uses an error status to do it.

The 10 keyless endpoints, checked live

Every row below is a request I made on July 26, 2026 with no key, no account and no card. The "level signal" column is the whole point of the article: it says what, if anything, in the response tells you whether a row is a member or a total.

#	Provider	Keyless endpoint	Rows I got	Level signal
1	World Bank Indicators	`api.worldbank.org/v2/country/all/indicator/SP.POP.TOTL?date=2023`	265 entities, 264 with a value	none in the data row; a separate `/v2/country` call carries `region.value == "Aggregates"`
2	Eurostat	`ec.europa.eu/eurostat/api/dissemination/statistics/1.0/data/nama_10_gdp`	46 geo entries for 2023	none; aggregates are recognizable only by code (`EU27_2020`, `EA`, `EA19`, `EA20`, `EA21`, `EA12`)
3	IMF DataMapper	`imf.org/external/datamapper/api/v1/NGDPD`	229 codes in one flat object, 227 with 2023	none inline; separate `/countries` (241), `/groups` (129) and `/regions` (27) endpoints exist
4	Our World in Data	`ourworldindata.org/grapher/population.csv`	257 entities for 2023	naming convention only: `OWID_` and `UN_` prefixes, with exceptions in both directions
5	DBnomics	`api.db.nomics.world/v22/series/WB/WDI`	dimension named `country` with 266 codes	none; `WLD` = World and `HIC` = High income sit inside a dimension called `country`
6	WHO GHO	`ghoapi.azureedge.net/api/WHOSIS_000001?$top=500`	500 rows	explicit: `SpatialDimType` on every row, plus `ParentLocation`
7	ILOSTAT	`rplumber.ilo.org/data/indicator/?id=UNE_2EAP_SEX_AGE_RT_A`	91,692 rows, 276 distinct areas	only with `type=code`: aggregates are `X01`, `X06`, `X21`; `type=label` erases it
8	UN Comtrade (preview)	`comtradeapi.un.org/public/v1/preview/C/A/HS`	224 rows for US exports, 2023	`partnerCode == 0` means world; `isAggregate` is `true` on all 224 at `cmdCode=TOTAL`, and `true` on exactly the world row at a leaf code
9	UNESCO UIS	`api.uis.unesco.org/api/public/definitions/geounits`	462 units: 241 `NATIONAL`, 221 `REGIONAL`	explicit, but in the catalogue call, not in the data rows
10	UK ONS (beta)	`api.beta.ons.gov.uk/v1/datasets/regional-gdp-by-year/...`	12 geographies, 23 industry codes	none; England (`UK0`) sits in the same list as its own nine regions

Ten sources, no keys. Two of them (WHO GHO, UNESCO UIS) will tell you the level outright. One (IMF) will tell you in a second call. One (ILOSTAT) will tell you only if you ask for codes instead of labels. The other six leave it to you.

The World Bank arithmetic, in full

Here is the whole thing, runnable, standard library only, one network call each to two endpoints:

# runnable, standard library only, needs network
import json, urllib.request

UA = {"User-Agent": "aggregate-check/1.0"}

def fetch(url):
    req = urllib.request.Request(url, headers=UA)
    with urllib.request.urlopen(req, timeout=60) as r:
        if r.status != 200:                      # fail loud, never a silent default
            raise RuntimeError(f"HTTP {r.status} for {url}")
        return json.loads(r.read().decode())

IND = ("https://api.worldbank.org/v2/country/all/indicator/"
       "SP.POP.TOTL?format=json&date=2023&per_page=400")
REF = "https://api.worldbank.org/v2/country?format=json&per_page=400"

rows = [r for r in fetch(IND)[1] if r["value"] is not None]
ref  = fetch(REF)[1]

AGG_ISO3 = {c["id"]       for c in ref if c["region"]["value"] == "Aggregates"}
AGG_ISO2 = {c["iso2Code"] for c in ref if c["region"]["value"] == "Aggregates"}
CTY_ISO2 = {c["iso2Code"] for c in ref if c["region"]["value"] != "Aggregates"}
CTY_ISO3 = {c["id"]       for c in ref if c["region"]["value"] != "Aggregates"}

world = next(r["value"] for r in rows if r["country"]["id"] == "1W")

naive  = sum(r["value"] for r in rows)
deny   = sum(r["value"] for r in rows if r["countryiso3code"] not in AGG_ISO3)
allow3 = sum(r["value"] for r in rows if r["countryiso3code"] in CTY_ISO3)
allow  = sum(r["value"] for r in rows if r["country"]["id"] in CTY_ISO2)

for label, total in [("naive sum of every row", naive),
                     ("deny-list on countryiso3code", deny),
                     ("allow-list on countryiso3code", allow3),
                     ("allow-list on country.id", allow),
                     ("the WLD row itself", world)]:
    print(f"{label:<30}{total:>15,}{total/world:9.4f}x")

leak = [r for r in rows if r["countryiso3code"] not in AGG_ISO3
        and r["country"]["id"] in AGG_ISO2]
print(f"\naggregates that survived the deny-list: {len(leak)}")
for r in sorted(leak, key=lambda x: -x["value"]):
    print(f"  id={r['country']['id']}  iso3={r['countryiso3code']!r:<4}"
          f"{r['country']['value']:<22}{r['value']:>14,}")
print(f"  their sum {sum(r['value'] for r in leak):>15,}")
print(f"  WLD row   {world:>15,}")

Output on my machine, July 26, 2026, pasted as it came out:

naive sum of every row         86,466,868,911  10.7240x
deny-list on countryiso3code   16,102,473,551   1.9971x
allow-list on countryiso3code   8,039,550,134   0.9971x
allow-list on country.id        8,039,550,134   0.9971x
the WLD row itself              8,062,923,417   1.0000x

aggregates that survived the deny-list: 4
  id=XT  iso3=''  Upper middle income    3,057,927,413
  id=XN  iso3=''  Lower middle income    2,869,695,351
  id=XD  iso3=''  High income            1,408,138,595
  id=XM  iso3=''  Low income               727,162,058
  their sum   8,062,923,417
  WLD row     8,062,923,417

Read the last two lines twice. The four income groups sum to 8,062,923,417, and the World row is 8,062,923,417. Not close. Equal, to the person. They are a complete partition of the planet, so they contribute exactly one extra Earth, and they do it while wearing an empty countryiso3code.

The catalogue knows about them. /v2/country returns 295 records, 78 marked region.value == "Aggregates", and the four income groups sit there with three-letter ids: HIC, LIC, LMC, UMC. The World Bank has a perfectly good alpha-3 code for High income. The indicator payload just sends an empty string instead. Same entity, an identity in the catalogue and none in the data.

Why 1.9971x is worse than 10.72x

Ten times the world population is not a bug you ship. Somebody glances at the chart, sees 86 billion, and the whole thing gets thrown back at you before lunch.

Twice the world population is different. Nobody knows the planet's headcount to the digit. 16.1 billion in a cell labelled "total population covered" reads as a big number in a big dataset, and it passes the two-second sniff test that a human actually performs, which is "is this the right order of magnitude". You do not get caught. You get cited.

And the deny-list feels like diligence. You looked up the aggregate codes, you excluded them, the number dropped by a factor of five and stopped looking absurd. Every signal you have says the repair worked.

UN Comtrade makes the same point without the rounding. I asked for US exports in 2023, all partners, commodity total:

rows returned                    224
partnerCode == 0 (the world)     2,018,542,583,771
sum of the other 223 partners    2,018,542,583,771
sum of all 224 rows              4,037,085,167,542   2.0000x

Two trillion dollars of exports, counted twice, on a response where the sum of the parts equals the declared total to the dollar. If you had not looked, the only tell would have been that your figure was too round.

The field you would reach for, and three ways it goes wrong

There is usually something in the payload that looks like the answer. Three of the ten taught me three different lessons about it: one where the field is present and empty, one where the naming convention leaks in both directions, and one where the field was right the whole time and my own query blinded it.

World Bank: the field is present and empty. countryiso3code is a fine key for 260 of the 264 rows. On four it is "". A deny-list ("skip rows whose code is a known aggregate") lets the empty string through. An allow-list ("keep rows whose code is a known country") does not, because "" is not a country either.

Same field, same reference table, opposite outcomes: lines two and three of the output above, 1.9971x against 0.9971x. The only difference is which direction you wrote the test in. If you would rather key on something never blank, country.id is a two-character code present on all 265 rows: alpha-2 for economies, World Bank codes like 1W, XD and S1 for aggregates.

UN Comtrade: the field works, and my query broke it. There is a boolean called isAggregate, and on my request it was true on all 224 rows: on the world row, on Canada, on Mexico, on China. I first wrote that up as a useless field. That was wrong, and checking it is what showed me why. Ask the same endpoint for a leaf commodity instead of the total (cmdCode=270900, crude petroleum) and the same field returns 42 rows with isAggregate true on exactly one of them, the partnerCode=0 world row, and false on the other 41. The field marks aggregation along whichever axis you asked to aggregate. cmdCode=TOTAL is itself an aggregate over every commodity, so every row I got back was an aggregate, and the field said so correctly. The lesson is not "the flag lies." It is that a flag answers the question your query asked, not the question in your head.

Our World in Data: the convention leaks in both directions. OWID prefixes aggregates with OWID_. Filter on that and you catch 13 rows, then land on 17,222,487,438, which is 2.1284x the World row. Drop the one row that carries no code at all (Americas (UN), 1,041,794,257) and you get 16,180,693,181, 1.9997x. Two operations, not one, and only the second gets you to the number that looks defensible. Six more aggregates use a UN_ prefix instead: UN_ASI, UN_AFR, UN_EUR, UN_LAC, UN_NAM, UN_OCE. Those six sum to 8,091,734,921 against a World row of 8,091,734,933. Twelve people apart.

The leak runs the other way too. OWID_KOS is Kosovo, a country wearing the aggregate prefix because it has no alpha-3 code, and one row (Americas (UN)) has no code at all. Drop everything prefixed and you delete a country; keep everything ISO3-shaped and you keep six continents.

Eurostat adds a fourth flavour, less a lie than a crowd. The nama_10_gdp geo dimension for 2023 has 46 entries, six of them aggregates, five of those overlapping euro-area vintages. Two are byte-identical: EA and EA20 both report 14,666,808.1 million euro. Sum all 46 and you get 6.3817x the EU27 total. DBnomics, meanwhile, puts WLD and HIC inside a dimension whose name is literally country. 266 codes, one namespace.

Who does label the level

The honest version of this post is not "nobody marks the totals". Somebody does, and the difference is one field. Two of the ten carry it in the data rows: UN Comtrade, from the section above, once you stop asking it a question whose answer is always yes, and this one.

WHO GHO puts it on every row. Life expectancy at birth, WHOSIS_000001, first 500 rows:

SpatialDimType: COUNTRY 478 | REGION 11 | WORLDBANKINCOMEGROUP 8 | GLOBAL 3

One column, four values, no catalogue call, no naming convention, no join. Every row states its own level. There is a ParentLocation field too, so a row also tells you what it rolls up into. That is the whole fix, shipped upstream, by an organisation with at least as much committee overhead as the others.

UNESCO UIS states it in the catalogue. /definitions/geounits returns 462 entries, each with a type: 241 NATIONAL and 221 REGIONAL. Clear, but it is a separate call, and the data rows come back as {"indicatorId", "geoUnit", "year", "value"} with no level in sight.

The IMF ships three lists. /countries (241), /groups (129) and /regions (27) are all keyless. The indicator payload itself is one flat object where WEOWORLD, ADVEC, EU and USA are peers; sum all 227 codes with a 2023 value for NGDPD and you get 671,589.964 billion USD against a WEOWORLD of 107,245.572, which is 6.2622x.

ILOSTAT encodes it, then offers to throw it away. With type=code you get 276 areas: 87 start with X (X01 World, X06 Africa, X21 Americas, X84 ASEAN) and 189 are ISO3-shaped. A real signal, since ISO 3166 leaves the X block user-assigned.

Ask the same endpoint for type=label, the friendlier parameter you reach for when you want a chart, and the codes vanish. "World" and "Afghanistan" come back as two strings of the same type. You destroyed the signal yourself, with a query parameter, and the response looks nicer for it.

Where the alarm stops working

Population is additive, so a mistake shows up as a number that is 2x or 10x too big. Plenty of indicators are not additive, and there the same mistake produces nothing to see.

The UK ONS beta API, regional GDP by year, chained volume measure, annual index, all industries, 2021. Twelve rows, one flat list:

UKF  East Midlands                98.6
UKH  East of England              96.2
UKI  London                       96.4
UKJ  South East                   96.6
UKK  South West                   96.2
UKD  North West                   97.1
UKE  Yorkshire and The Humber     97.4
UK0  England                      96.6
UKL  Wales                        97
UKC  North East                   95.2
UKG  West Midlands                96.1
UKZ  Extra-regio                  81.2

UK0 is England. Nine of the other eleven rows are inside it. Every code is three characters starting with UK, so nothing about the shape separates the parent from its children, and the response has no level field.

Now take the average across those twelve, which is what a dashboard does. You get 95.3833. Drop England and average the remaining eleven: 95.2727. A tenth of an index point apart. There is no 10x, no 2x, no absurd figure to catch you. The number is simply a little wrong, forever, and no assertion you can write on magnitude alone will ever fire.

The same dataset does it twice, by the way. The industry dimension has 23 codes including A--T ("A-T: Total"), B--E ("Production Industries") and G--T ("Services sector") sitting beside the single letters they contain. The only tell is the double dash.

The fix: keep the total, and make it a test

The reflex is to delete the aggregate rows and move on. Do the opposite. The total row is the only place in the response where the provider tells you what the answer should be, and throwing it away is throwing away your test data.

Two rules. Allow-list, never deny-list, because an allow-list fails closed on an empty or unknown key. Then assert your members against the declared total.

# runnable, standard library only, continues the script above
def split_levels(rows, ref):
    """Allow-list the members, name the totals, refuse anything unclassified."""
    members = {c["iso2Code"] for c in ref if c["region"]["value"] != "Aggregates"}
    totals  = {c["iso2Code"] for c in ref if c["region"]["value"] == "Aggregates"}
    kept, dropped, unknown = [], [], []
    for r in rows:
        key = r["country"]["id"]        # populated on every row; iso3 is not
        (kept if key in members else dropped if key in totals else unknown).append(r)
    if unknown:
        raise ValueError(f"{len(unknown)} rows in neither list: "
                         f"{[u['country']['id'] for u in unknown][:5]}")
    return kept, dropped

def check_against_total(members, declared, tolerance=0.01):
    got = sum(r["value"] for r in members)
    drift = (got - declared) / declared
    if abs(drift) > tolerance:
        raise AssertionError(f"members sum to {got:,}, total row says {declared:,} "
                             f"({drift:+.2%}) - the filter is wrong, not the data")
    return got, drift

members, totals = split_levels(rows, ref)
got, drift = check_against_total(members, world)
print(f"members kept   {len(members)}")
print(f"totals dropped {len(totals)}")
print(f"members sum    {got:,}")
print(f"WLD row says   {world:,}")
print(f"residual       {got - world:,}  ({drift:+.2%})")

# a check that cannot fail is decoration: feed it the deny-list version
sloppy = [r for r in rows if r["countryiso3code"] not in AGG_ISO3]
try:
    check_against_total(sloppy, world)
except AssertionError as e:
    print(f"\ndeny-list version -> {e}")

Output, same run:

members kept   217
totals dropped 47
members sum    8,039,550,134
WLD row says   8,062,923,417
residual       -23,373,283  (-0.29%)

deny-list version -> members sum to 16,102,473,551, total row says 8,062,923,417 (+99.71%) - the filter is wrong, not the data

That message is the payoff. A +99.71% drift is not a judgement call, and it fires the moment your classification is wrong, in CI, before anyone charts it. An unclassified row raises a ValueError instead, because split_levels refuses to guess. Non-additive indicators need a different comparison than a sum, but the shape holds: the provider published the answer, so check against it.

The residual I could not explain

-23,373,283 people, or -0.29%. I set the tolerance to 1% because I measured the gap first and then picked a threshold that passes it, which you should know before you copy the number.

I do not know where it comes from. All 217 countries in the reference list are present in the 2023 response, so it is not a missing row. It might be territories the World Bank counts in the world total but not among its economies, or a vintage difference between the aggregate and its members.

One thing I noticed and then refused to write down as a finding: Our World in Data puts Taiwan's 2023 population at 23,317,145, and the World Bank does not list Taiwan among its economies at all. Within 0.24% of my residual. That is the kind of coincidence that feels like an explanation, and nothing I called gives me evidence it is one. Two close numbers are not a mechanism. If you know the real answer, I want it.

What I nearly published and had to take back

While checking DBnomics I ran country_labels.get("XD") and got nothing back. Same for XM, XN, XT. I had a lovely paragraph half-written: the mirror ingested the World Bank feed, keyed on the code that was empty, and dropped exactly the four aggregates that break everyone else.

It was wrong. I searched by label instead of by code and found HIC High income, LIC Low income, LMC Lower middle income, UMC Upper middle income, all present. DBnomics keys on the alpha-3 ids the World Bank publishes in its own catalogue, which is exactly the code the indicator payload declines to send. Nothing was dropped. My probe had returned an empty result that read like evidence, and the mirror turned out to be more faithful to the World Bank's catalogue than the World Bank's own data rows.

That is the failure mode I keep meeting in this work, and it is not specific to statistics APIs: a lookup that returns nothing looks identical whether the thing is absent or your query was wrong. The only defence is to make the check prove it can find something before you trust it finding nothing.

This is not the response-envelope post

Two neighbours, so let me draw the lines by hand.

I covered the World Bank once before, in a roundup of keyless government APIs, where the trap was structural: the response is a two-element array, [0] is pagination, [1] is your data. That one is about unpacking. This post assumes you unpacked correctly and starts a step later, when the rows are in hand and you cannot tell what kind of thing each one is.

Nor is it the scale problem from keyless currency APIs, where everyone agreed on the entity and disagreed on how many digits it had. Here the scale is fine. What is contested is whether the row in front of you is a member or a summary of members. And the damage is extra rows, not missing ones, so it inflates rather than erases.

Honest limits

This is a snapshot. All ten were keyless on July 26, 2026, from one machine, one IP. I did not read anyone's terms or measure their limits, which is why there is not a single rate-limit number in this post.
One indicator per provider, mostly population or GDP. The ratios belong to that indicator and year, not to the provider. SP.POP.TOTL for 2023 produced 10.7240x; another indicator with different aggregate coverage lands somewhere else.
Additive only. The sum-versus-total check works because headcounts add. Rates and indices do not, and the ONS example is the alarm going quiet exactly there. I did not build the weighted-mean version.
The four income groups matching the World row to the person is a property of that partition, not a law. The regional aggregates in the same response overlap and partition nothing cleanly, which is why the naive sum is a ragged 10.72x.
I did not classify all 276 ILOSTAT areas by hand. I counted X-prefixed codes and trusted the convention. If ILOSTAT ever gives a country an X code, my count is wrong.
Provenance. I run scrapers and data pipelines in production, 32 published actors and something over 2,000 runs, and enrichment feeds are where I picked up the habit behind this post: they lie with a confident 200 far more often than they fail honestly. The ten checks here are one sitting, not a production sample, and I am not going to dress them up as one.
An aside, since I noticed it. The ONS observation payload returns dimension hrefs pointing at 10.30.156.187:10500, a private address unreachable from the internet. Harmless here, but do not build a crawler that follows them.

The open question

The check I described works when the provider publishes the total. Eight of these ten publish a total I could actually see in the data I pulled. UNESCO I could not confirm from data rows: the aggregate geoUnit request came back HTTP 200 with an empty records array, which tells me nothing either way. And the ONS series I pulled has no total row at all: twelve rows, nine English regions plus England, Wales and Extra-regio, with no UK, no Scotland and no Northern Ireland. So "never delete the world row" is decent advice right up until there is no world row, and then you are back to trusting a sum nobody published.

The overlapping case is where I run out of answers. In one World Bank response, XD/XM/XN/XT partition the planet exactly and the regional aggregates do not, because economies belong to several groupings at once. So "sum the members and compare" only works once you know which aggregate set is a partition, and the payload does not tell you that either. I hard-code the partition I trust per provider and treat the rest as decoration. It does not scale past the handful of feeds I actually use.

If you pull cross-country statistics regularly: how do you decide which aggregate set is the partition, and do you keep that knowledge in code, in a config file, or in your head? 👇

Written with AI assistance. Every status code, row count, sum and command output above comes from my own live requests and negative controls on July 26, 2026, printed as they came out.

10 Free Art & Museum APIs With No Key (2026)

Alex Spinov — Thu, 16 Jul 2026 10:17:30 +0000

I asked the Metropolitan Museum's free API for Rembrandts. It said 182.

I opened the first forty of those 182. Six were Rembrandt.

# runnable, read-only: no key, no signup
curl -s "https://collectionapi.metmuseum.org/public/collection/v1/search?q=Rembrandt&hasImages=true"

{"total":182,"objectIDs":[437398,437394,437396,436543,551786,729644,
  435817,472562,438821,437769,329077,310453, ...]}

The fourth ID in that list, 436543, is a Goya. The fifth, 551786, is an Egyptian Book of the Dead written between roughly 332 and 200 B.C. Both came back HTTP 200, valid JSON, counted inside a field named total. The field is not broken. It is telling the exact truth about how many records matched the query. It is lying about what total means to the person who typed q=Rembrandt.

The one idea in this post

A free art API here means a public endpoint that returns museum collection data with no API key, no signup, no credit card. A URL you can paste into a terminal right now. Ten of them clear that bar, and I re-verified every response below with a live curl on July 16, 2026: real HTTP code, real body, trimmed but never reworded. If you want the working list and nothing else, the table is two screens down.

But the list is not why I wrote this. My last few keyless-API posts kept circling one room. A null sails through a schema check. A full, correctly shaped result list hands you the wrong top row. A perfectly current-looking timestamp sits on top of data that froze in 2024. This post moves the problem one more step, into the quietest corner of it:

A field's name is a promise the 200 does not keep. total, hasImages, isPublicDomain. Each returns HTTP 200 with a valid, plausible value. Each answers a narrower or different question than its name implies. And the record wearing that field is authoritative. It is the Met. It is Harvard. That is exactly why the label fools you: the source is real, so you stop reading the field and start trusting the word.

Museums make this visible because their data is messy in an honest, well-documented way. A search index that matches provenance text. A boolean whose real subject is a rights office, not a copyright statute. A count that is secretly a floor. None of it is a bug. All of it will put wrong numbers on your dashboard while returning 200 the whole time.

One scope note, so the numbers stay honest. I have run web scrapers in production: 2,190 runs across 32 published actors, 962 of them on one Trustpilot review scraper. That is where the habit in this post comes from, the reflex to read a field's value instead of its name, because the failures that actually hurt in production are never the crashes. But that is a scraping-and-enrichment domain. I have not run a museum-collection resolver in production, and nothing below is load-bearing on those runs. Read them as the origin of a habit, not a claim about art data.

The 10, at a glance

#	API	What it returns	Example call	The gotcha
1	The Met	490k+ objects, full records	`GET collectionapi.metmuseum.org/.../objects/436535`	A search miss returns `objectIDs: null`, not `[]`
2	Art Institute of Chicago	Artworks, IIIF images	`GET api.artic.edu/api/v1/artworks/27992`	The `description` field is CC-BY; the rest is CC0
3	Cleveland Museum of Art	Open Access collection	`GET openaccess-api.clevelandart.org/api/artworks/92937`	Calls the rights field `share_license_status`, not `isPublicDomain`
4	Victoria and Albert Museum	1.4M+ objects	`GET api.vam.ac.uk/v2/objects/search?q=painting`	`record_count_exact` flags whether the count is exact; it stayed `true` even at 1.3M objects
5	Yale LUX	Yale collections, Linked Art	`GET lux.collections.yale.edu/api/search-estimate/item?q=...`	The endpoint is named `search-estimate`. The count is an estimate
6	SMK (Denmark)	Danish national gallery	`GET api.smk.dk/api/v1/art/search/?keys=painting`	`found` counts records, many of which are not paintings
7	Wellcome Collection	Medical/cultural works	`GET api.wellcomecollection.org/catalogue/v2/works?query=painting`	Top hit for "painting" is a photograph filed under Archives
8	Getty Vocabularies	AAT / ULAN / TGN, Linked Data	`GET vocab.getty.edu/aat/300189808.json`	JSON-LD, not flat JSON. `_label`, `broader`, `equivalent`
9	Harvard LibraryCloud	Harvard library metadata	`GET api.lib.harvard.edu/v2/items.json?q=painting`	It is the library catalog, not the (key-gated) Art Museums
10	Auckland War Memorial Museum	Collection, Elasticsearch proxy	`POST api.aucklandmuseum.com/search/collectionsonline/_search`	`total.value: 10000` is a floor with `relation: "gte"`, not a count

Everything in that table returned HTTP 200 with no key on July 16, 2026. Then, below the ten, the three that ask for a key even though every tutorial calls them free, and the one field that lies not about counting but about the law.

1. The Met: the collection everything else gets compared to

The Metropolitan Museum's Collection API is keyless, no signup, and it is the one most people reach for first. Fetch an object by ID and you get the whole record.

# runnable, read-only
curl -s "https://collectionapi.metmuseum.org/public/collection/v1/objects/436535"

{"objectID":436535,"isPublicDomain":true,
 "primaryImage":"https://images.metmuseum.org/CRDImages/ep/original/DP-42549-001.jpg",
 "department":"European Paintings",
 "constituents":[{"role":"Artist","name":"Vincent van Gogh"}]}

That is Van Gogh's Wheat Field with Cypresses, and it behaves. Public domain, image present, artist named. The trouble starts at the search endpoint, and it has two edges worth knowing before you write a loop.

First, a query that matches nothing does not return an empty list:

# runnable, read-only
curl -s "https://collectionapi.metmuseum.org/public/collection/v1/search?q=zzzxxqqnope123"

{"total":0,"objectIDs":null}

objectIDs is null, not []. Call len() on that and your loop dies at 3am. Second, an object ID that does not exist returns a 404 with a message body, so resp.json() succeeds and your happy-path code walks right into {"message":"ObjectID not found"}. Guard for both. And be gentle: there is no key, but the Met asks for polite pacing, so send a real User-Agent and cache what you can. Docs live at metmuseum.github.io.

2. Art Institute of Chicago: clean JSON with a licensing seam

The Art Institute's API is one of the pleasant ones to build on. Simple GET, sensible fields, IIIF image server. It also does something the others do not: it tells you, in the response, that two parts of the same payload carry two different licenses.

# runnable, read-only
curl -s "https://api.artic.edu/api/v1/artworks/27992?fields=id,title,is_public_domain"

{"data":{"id":27992,"is_public_domain":true},
 "info":{"license_text":"The `description` field ... is licensed under a Creative Commons Attribution 4.0 Generic License (CC-By) ... All other data ... is licensed under a Creative Commons Zero (CC0) 1.0 designation ..."}}

That is Seurat's A Sunday on La Grande Jatte. Note the split: the description field is CC-BY, meaning if you show it you owe attribution, while the rest is CC0 and you owe nothing. Most people paste the whole record onto a page and quietly violate half of it. The API told you. Nobody reads info.license_text. Full docs: api.artic.edu/docs.

3. Cleveland Museum of Art: the same question, a different field name

Cleveland's Open Access API is CC0-friendly and returns rich records. It is also exhibit A for the whole thesis, because it asks the exact question the Met's isPublicDomain asks, and names the field something else.

# runnable, read-only
curl -s "https://openaccess-api.clevelandart.org/api/artworks/92937"

{"data":{"id":92937,"accession_number":"1922.1133","share_license_status":"CC0",
  "title":"Stag at Sharkey's","type":"Painting","creation_date":"1909",
  "department":"American Painting and Sculpture"}}

share_license_status: "CC0". Not a boolean called isPublicDomain. A string describing the sharing license. Cleveland is being more honest about what the field is: a statement about the image's reuse license, not about the copyright age of a George Bellows painting from 1909. Hold that distinction. It is the whole point of the isPublicDomain section further down. Docs: openaccess-api.clevelandart.org.

4. Victoria and Albert Museum: a count that admits when it is not exact

The V&A serves over a million objects, keyless. Search returns a compact record plus an info block, and that block has a field I wish more APIs copied.

# runnable, read-only
curl -s "https://api.vam.ac.uk/v2/objects/search?q=painting&page_size=1"

{"info":{"record_count":146517,"record_count_exact":true,"pages":9970,"image_count":207381},
 "records":[{"systemNumber":"O429002","objectType":"Painting",
   "_primaryTitle":"Krishna painting Radha","_primaryDate":"1948","_primaryPlace":"Sri Lanka"}]}

146,517 objects matched "painting." See record_count_exact: true. That flag is the whole point: the V&A ships a boolean whose only job is to tell you whether record_count is an exact total or a search-engine estimate. I hammered it with broad queries on July 16, up to the full 1.3-million-object catalog, and it came back true every time. I could not make it flip. But it is named and typed to carry that answer for the day the count is not exact, so you read the flag instead of guessing. That is the opposite of the trap this post is about. Compare that to number 5. Docs: developers.vam.ac.uk.

5. Yale LUX: the count that says "estimate" right in the URL

Yale's LUX is a single search layer over the university's museums, library, and archives, built on Linked Art. Keyless. It is heavier to parse than the flat-JSON museums, because it returns JSON-LD, and that is the price of the linked-data tier. It also names its counting endpoint with unusual honesty.

# runnable, read-only (-g stops curl from globbing the JSON braces into a 400)
curl -g -s 'https://lux.collections.yale.edu/api/search-estimate/item?q={"text":"painting"}'

{"@context":"https://linked.art/ns/v1/search.json",
 "type":"OrderedCollection","totalItems":76574,
 "first":{"id":"https://lux.collections.yale.edu/api/search/item?q=...&page=1&pageLength=20"}}

The field is called totalItems. The endpoint is called search-estimate. Read those two facts together and LUX has already told you not to trust totalItems as an exact number: it is a fast estimate, which is why there is a whole separate endpoint for it. This is the good version of the failure mode. The name of the route warns you about the meaning of the field. Most APIs do not extend you that courtesy. Docs and the Linked Art model: lux.collections.yale.edu.

6. SMK: Denmark's national gallery, and a `found` that counts loosely

SMK, Statens Museum for Kunst, publishes a clean keyless search over the Danish national collection, much of it CC0.

# runnable, read-only
curl -s "https://api.smk.dk/api/v1/art/search/?keys=painting&rows=1"

{"offset":0,"rows":1,"found":253,
 "items":[{"id":"1170063760_object","modified":"2025-07-11T17:55:43Z"}]}

found: 253 for keys=painting. The first item back is not a painting at all: it is a drawing from the print and drawing collection whose record text happens to contain the phrase "Fundamental Painting." Same disease as the Met's Rembrandt count. keys is a full-text search over the record, and found counts every record where the word turns up, in a title, an inscription, a note. It does not count paintings. It counts the string. Note the modified field, though: SMK stamps every record with when it last changed, which is the honest half of this API. Docs: smk.dk/en/article/smk-api.

7. Wellcome Collection: search "painting", get a photograph

Wellcome holds art, books, archives, and manuscripts about health and human experience. Its catalogue API is keyless and well-built. It also shows you, in one call, why a museum search box is not a filing cabinet.

# runnable, read-only
curl -s "https://api.wellcomecollection.org/catalogue/v2/works?pageSize=1&query=painting"

{"type":"ResultList","totalResults":17584,
 "results":[{"id":"sm62qtks","title":"Painting Therapy; (people painting on lawn)",
   "workType":{"type":"Format","label":"Archives and manuscripts"},
   "physicalDescription":"1 photograph"}]}

The top result for query=painting is a photograph of a painting-therapy session, filed under Archives and manuscripts. It is a completely correct result: the record is about painting. If you assumed query=painting returns paintings, you assumed the API indexes subjects the way you think about them, and it indexes text the way a search engine does. totalResults: 17584 is a text-match count, and its name does not warn you the way Yale's route name does. Docs: developers.wellcomecollection.org.

8. Getty Vocabularies: not a collection, a dictionary of meanings

The Getty publishes its vocabularies as Linked Open Data: the Art and Architecture Thesaurus (AAT), the Union List of Artist Names (ULAN), and the Getty Thesaurus of Geographic Names (TGN). Keyless. This is not artworks. It is the controlled vocabulary the art world uses to describe artworks, and it is how you turn a free-text mess into linked entities.

# runnable, read-only
curl -s "https://vocab.getty.edu/aat/300189808.json"

{"@context":"https://linked.art/ns/v1/linked-art.json",
 "_label":"figures (representations)",
 "equivalent":[{"id":"http://www.wikidata.org/entity/Q29527347"}]}

Like Yale, this is JSON-LD, so budget for a heavier shape than the flat-JSON museums. What you get for the trouble is real: an equivalent link straight to Wikidata, a broader chain up the concept tree, stable URIs you can join on. If you ever need to reconcile "who is this artist" or "what is this technique" across two museums that spell things differently, this is the linked-data tier that makes it possible. Endpoint and model: vocab.getty.edu.

9. Harvard LibraryCloud: the Harvard art API that is not the Harvard art API

This one is a naming trap before you even read a field. Harvard runs two things. The Harvard Art Museums API at api.harvardartmuseums.org needs a key. It is not on this list, and I will get to it below. LibraryCloud, at api.lib.harvard.edu, is keyless, and it is a different animal entirely.

# runnable, read-only
curl -s "https://api.lib.harvard.edu/v2/items.json?q=painting&limit=1"

{"pagination":{"numFound":515781,"limit":1,"start":0},
 "items":{"mods":{"titleInfo":{"title":"conservation of easel paintings"},
   "genre":{"#text":"bibliography"}}}}

515,781 hits for "painting," and the first one is a bibliography, a book about the conservation of easel paintings, encoded in MODS library metadata. If you came here expecting Harvard's artworks, you are in the library catalog, and the two are easy to confuse because both live under a Harvard domain and both answer q=painting with a 200. The keyless one is books-and-metadata. The artworks are behind the key. Docs: Harvard LibraryCloud APIs.

10. Auckland War Memorial Museum: a count that is really a floor

Auckland exposes its collection through a keyless Elasticsearch proxy, so instead of a REST search you POST a query body. Get the index name right (collectionsonline) and it answers.

# runnable, read-only
curl -s -X POST "https://api.aucklandmuseum.com/search/collectionsonline/_search" \
  -H "Content-Type: application/json" \
  -d '{"size":1,"query":{"match_all":{}}}'

{"hits":{"total":{"value":10000,"relation":"gte"},
  "hits":[{"_index":"collectionsonline-2022-05-04-1",
    "_source":{"type":"ecrm:E21_Person","appellation":{"name":["KVD?"]}}}]}}

Look at total. It is not a number. It is an object: {"value":10000,"relation":"gte"}. That gte means "greater than or equal to," so value: 10000 is Elasticsearch telling you it stopped counting at ten thousand, and the real total is at least that. Read total.value as a count and you will report exactly 10,000 objects for a collection that has far more. The name value, sitting under total, reads like an answer. It is a floor with a footnote in the next field. And the first hit is a Person record, not an object, because the index mixes entity types. Docs: api.aucklandmuseum.com/apidoc.

The field that lies about the law: isPublicDomain

Now the field I actually opened this post to talk about, because it is the one that can cost you money instead of just a wrong dashboard number.

Here is the Met's own documentation, word for word, from metmuseum.github.io:

isPublicDomain (boolean) When "true" indicates an artwork in the Public Domain

Read that as a developer and you hear a legal claim about the artwork: this painting's copyright has expired, you are free to use it. That is what "in the Public Domain" means as English.

That is not what the field tracks. Watch what happens across a single artist. Van Gogh died in 1890. Every painting he made is uncontroversially out of copyright, everywhere on Earth. I pulled 30 objects the Met attributes to "Vincent van Gogh" and checked the flag on each.

Van Gogh-attributed objects sampled:  30
isPublicDomain = true:                29   (all with an open image)
isPublicDomain = false:                1   (a printed book of his letters, no image)

Twenty-nine true, one false. The false one is a printed edition of his letters that the Met has not released as an open image. So the flag did not flip because someone re-adjudicated Van Gogh's copyright between his paintings and his letters. It flipped because the Met has an open, CC0-licensed photograph of the paintings and does not have one of that book. The field's real subject is the Met's image, not the artwork's copyright.

Object 310453 makes it sharp. It came back in that Rembrandt search from the top of the post.

{"objectID":310453,"title":"Nkishi (community power figure)",
 "artistDisplayName":"Songye artist and nganga (ritual specialist)",
 "department":"The Michael C. Rockefeller Wing",
 "isPublicDomain":false,"primaryImage":""}

isPublicDomain: false. I want to be precise, because this is where developers overclaim in both directions. This does not mean the object is under copyright. A Songye community power figure made in the 19th or early 20th century may well be in the public domain as a matter of law. The false here is not a court ruling. It means the Met has not released an open-access image of it, which the empty primaryImage confirms in the same breath. The field answers "did the museum openly license its photo of this thing?" Its name asks "is this artwork's copyright expired?" Those are different questions, and only one of them has a clean answer in the JSON.

Now line up all three museums on the same real question, which is "may I reuse this image without owing anyone anything?":

The Met: isPublicDomain (boolean)
Art Institute of Chicago: is_public_domain (boolean)
Cleveland: share_license_status (string, e.g. "CC0")

Three field names, one underlying decision, made separately by three rights offices, with no shared canonical answer. If your app treats isPublicDomain: true as "safe to reuse commercially," you are trusting each museum's image-licensing office and calling it copyright law. Usually you are fine. The day you are not, the field name is what talked you into it.

The fix: read the value, not the name

The pattern is the same every time. Do not ask the field what it is called. Ask the object what is actually true. Here is a resolver that does the thing the Met's total, hasImages, and isPublicDomain only pretend to do: it verifies each object actually matches the artist you asked for, and actually carries a usable open image, from the values.

# runnable local: pip install requests
import requests

MET = "https://collectionapi.metmuseum.org/public/collection/v1"
S = requests.Session()
S.headers["User-Agent"] = "field-meaning-demo/1.0 (contact you@example.com)"

def usable_open_image(obj):
    """The question a dev MEANS when reading isPublicDomain and hasImages:
    can I show an openly-licensed image of this object right now?
    Answer from the values, never from the field names."""
    return bool(obj.get("primaryImage")) and obj.get("isPublicDomain") is True

def real_matches(query, want, limit=40):
    hits = S.get(f"{MET}/search", params={"q": query, "hasImages": "true"}, timeout=20).json()
    reported = hits.get("total", 0)                 # read the field named "total", not len()
    ids = hits.get("objectIDs") or []               # a miss returns null, not []
    kept = 0
    for oid in ids[:limit]:
        o = S.get(f"{MET}/objects/{oid}", timeout=20).json()
        artist = o.get("artistDisplayName", "")
        if want.lower() in artist.lower() and usable_open_image(o):
            kept += 1
    return reported, min(limit, len(ids)), kept

reported, sampled, kept = real_matches("Rembrandt", "Rembrandt")
print(f"'total' the API reports:      {reported}")
print(f"objects I sampled:            {sampled}")
print(f"actually Rembrandt + usable:  {kept}")

Real output, July 16, 2026:

'total' the API reports:      182
objects I sampled:            40
actually Rembrandt + usable:  6

Six out of the first forty. The 34 it drops include the Goya from the top of the post, the Egyptian Book of the Dead, a Byzantine reliquary, and object 310453, the one whose hasImages=true filter let it through with an empty primaryImage. Two things about this code, said plainly so you do not oversell it.

It only samples the first 40 IDs, because fetching all 182 objects one at a time is slow and rude to a keyless server. That is a real limitation: the true count of usable Rembrandts is somewhere in the collection, and this tells you the rate in the first page, not the final number. If you need the number, page politely and cache. And the want.lower() in artist.lower() check is deliberately loose. It keeps "Rembrandt (workshop)" and "Rembrandt van Rijn," which may or may not be what you want. The point is not that this exact filter is right for your app. The point is that it reads artistDisplayName and primaryImage, the fields whose values are true, instead of trusting total and hasImages, the fields whose names are convenient.

Flagged: three "free" APIs that still want a key

Every listicle, mine included in spirit, calls these free. They are free. They are not keyless, and the difference is a 401 or 403 the moment you forget the key.

# runnable, read-only
curl -s -o /dev/null -w "%{http_code}\n" "https://api.harvardartmuseums.org/object?size=1"
curl -s -o /dev/null -w "%{http_code}\n" "https://api.si.edu/openaccess/api/v1.0/search?q=painting"
curl -s -o /dev/null -w "%{http_code}\n" "https://api.europeana.eu/record/v2/search.json?query=painting"

401
403
401

The Harvard Art Museums API (401) is the one people confuse with keyless LibraryCloud from number 9. Smithsonian Open Access (403) returns API_KEY_MISSING and hands out a free key at api.data.gov. Europeana (401) aggregates thousands of European institutions and is worth the signup, but a signup it is. Free-as-in-beer, not free-as-in-paste-into-a-terminal.

Why not on the list: two that tutorials still recommend

The Rijksmuseum API, still the top result in a lot of old blog posts, is gone:

curl -s -o /dev/null -w "%{http_code}\n" "https://www.rijksmuseum.nl/api/en/collection"

HTTP 410 Gone, which is a server saying "not moved, not temporarily down, deliberately removed." The legacy endpoint was decommissioned; the Rijksmuseum moved to a newer data service. Do not build on the 410. And the Brooklyn Museum API returns a 429 with a "Vercel Security Checkpoint" body from a datacenter IP, a bot challenge rather than a real rate limit, so it is unreliable to depend on from a server even though a browser may sail through. (One I will not badmouth: the Science Museum Group returned a clean 200 for me today, though I have seen reports of it blocking datacenter IPs, so test from your own host before you trust it.)

So what do you actually do?

Two habits, and they are cheap.

Read the field's definition, not its name. Before you branch on isPublicDomain, total, hasImages, or found, open the docs and find out what the museum means by it. Ten minutes with metmuseum.github.io tells you isPublicDomain is tied to the open-access image release. Ten minutes with the V&A docs tells you record_count_exact exists. The good APIs in this post, the V&A with its exactness flag, Yale with its search-estimate route, SMK with its modified stamp, are the ones that put the caveat in a field so you can read it. Reward that by actually reading it.

Verify the object, not the count. A count is a promise about a set you have not looked at. When the answer matters, fetch a sample and check that the objects are what the count says they are, from their own values. Thirty lines of real_matches turned "182 Rembrandts" into "6 of the first 40," and the gap between those two numbers is the gap between a demo and a bug report.

I learned the expensive half of this in a different domain. Across 2,190 production scraper runs, the incidents that actually cost me were never the 500s. A crash wakes you up and you fix it by lunch. The response that comes back 200, valid, non-empty, correctly shaped, and quietly answering a different question than you asked, that one sits in a column until a report looks wrong three weeks later, and then you are backfilling. Museum APIs just make it pretty. Your API is probably doing the same thing with a blander field name. Go read what the name actually means.

FAQ

What is the best free art or museum API with no key?
It depends on the job, and several are keyless together. The Met (collectionapi.metmuseum.org) has the broadest collection and the simplest flat JSON. The Art Institute of Chicago (api.artic.edu) is the cleanest to build on and ships IIIF images. Cleveland (openaccess-api.clevelandart.org) and SMK (api.smk.dk) are CC0-friendly. The V&A (api.vam.ac.uk) covers over a million objects. All returned HTTP 200 with no key on July 16, 2026. Whichever you pick, read what its count and rights fields actually mean before you trust them.

Does the Met Museum API require an API key?
No. The Metropolitan Museum Collection API is fully keyless: no signup, no key, no token. It asks only for polite request pacing and a real User-Agent. Two traps to guard for: a search that matches nothing returns {"total":0,"objectIDs":null} with objectIDs as null rather than an empty array, and a request for a nonexistent object ID returns HTTP 404 with {"message":"ObjectID not found"} rather than an empty body.

What does isPublicDomain mean in the Met API?
The Met documents it as "when true, indicates an artwork in the Public Domain," but in practice the flag tracks whether the Met has released an open-access (CC0) image of the object, not a legal ruling on the artwork's copyright. Evidence: of 30 objects attributed to Van Gogh (died 1890, unquestionably out of copyright), 29 returned isPublicDomain: true and all carried an open image, while the one false was a printed book with no released image. So isPublicDomain: false does not mean the work is copyrighted; it can mean the Met simply has no open image of it, which the empty primaryImage confirms.

Why does a museum search return objects that do not match my query?
Because museum search is full-text over the whole record, not a filter on a subject field. The Met's search?q=Rembrandt&hasImages=true returned total: 182, but the keyword also matched text elsewhere in the catalog record, not the artist field, so a Goya (object 436543) and an Egyptian Book of the Dead (object 551786) are counted among the 182. In a sample of the first 40 objects, only 6 were actually Rembrandt with a usable open image. Verify each object's artistDisplayName rather than trusting the count.

Which museum APIs need an API key?
On July 16, 2026, the Harvard Art Museums API (api.harvardartmuseums.org) returned HTTP 401, the Smithsonian Open Access API (api.si.edu) returned HTTP 403 with API_KEY_MISSING, and Europeana (api.europeana.eu) returned HTTP 401. All three offer a free key on signup, so they are free but not keyless. Note that the keyless Harvard endpoint on this list, LibraryCloud at api.lib.harvard.edu, is a different service (library metadata) from the key-gated Harvard Art Museums.

Can I use museum images commercially for free?
Sometimes, and the field that says so answers a narrower question than its name. Fields like the Met's isPublicDomain, the Art Institute's is_public_domain, and Cleveland's share_license_status describe whether the museum released its image under an open license (often CC0), not whether the underlying artwork's copyright has expired. Also watch for split licensing: the Art Institute's info.license_text states that its description field is CC-BY (attribution required) while the rest of the record is CC0. Check the specific field per museum before reusing anything.

Written by Aleksei Spinov. I build web-scraping and data-enrichment tool layers, currently 2,190 runs across 32 actors in production. Every endpoint above was re-verified with a live curl (real HTTP code, real body) on July 16, 2026 before publishing; responses are trimmed, never reworded. I have not run a museum-collection resolver in production; those runs are a scraping-and-enrichment domain, cited only as the origin of the read-the-value habit. I wrote up neighboring versions of this same pattern for free space and astronomy APIs, free fun-facts APIs, and free mock and fake-data APIs. Drafted with an AI assistant, then fact-checked and edited by me against the raw responses.

Follow for the next keyless layer I verify. And tell me: which field name on your favorite API secretly answers a different question than its name promises? I read every comment.

11 Free Space & Astronomy APIs With No Key (2026)

Alex Spinov — Wed, 15 Jul 2026 10:07:59 +0000

On July 13, 2026 I asked two free ISS-tracking APIs where the space station was. Fourteen seconds apart. Both answered HTTP 200 with clean, valid JSON.

They were 9,303 km apart.

# runnable, read-only: no key needed for either
curl -s "http://api.open-notify.org/iss-now.json"
curl -s "https://api.wheretheiss.at/v1/satellites/25544"

{"iss_position": {"latitude": "-25.2996", "longitude": "154.1942"},
 "message": "success", "timestamp": 1783969008}

{"name":"iss","id":25544,"latitude":37.5181,"longitude":95.3130,
 "altitude":429.7,"velocity":27566.63,"visibility":"daylight",
 "timestamp":1783969022}

The station moves at 27,566 km/h. That is 7.66 km/s, and the second API tells you so in its own body. Its ground track is slower than that, not faster, and two separate effects stack up to make it so. The station flies 430 km up, so the point underneath it sweeps the same angle across a smaller radius: that alone drops it to about 7.2 km/s, before anything else happens. Then the orbit is prograde, and the planet turns the same way underneath it, which shaves off a bit more. I got this backwards in my first draft, so I stopped reasoning and measured instead. Two wheretheiss samples 64 seconds apart put the ground track 439.9 km further along: 6.87 km/s. JPL's own ephemeris, two rows 19 seconds apart, says 6.86.

So round up hard. Give it a flat 8 km/s, more than any of those numbers, and fourteen seconds buys you at most 112 km of great-circle distance. Not 9,303.

So one of these is lying, at HTTP 200, with "message": "success" written right there in the payload.

The one idea in this post

My previous keyless-API posts kept walking around the same room. A 200 can carry an empty body. A 201 Created can be followed by a 404 on read-back. A 200 can parse, match your schema, and hand you null. A 200 can return a full, correctly shaped list whose top row is the wrong entity. This post moves the problem again, and it is the version that scares me most, because it is the one you can run for a year without noticing.

A 200 with a valid, well-shaped, non-empty, plausible-looking body is not a 200 with current data. Freshness is not in the status line. It is a field inside the body: EPOCH, time_tag, timestamp, lastRun, updated. A server that stopped updating in 2024 will keep telling you, cheerfully and successfully, that 2024 is right now.

Space is where this shows up naked, because space data is time-series by nature. A stale satellite position looks exactly like a satellite position. Nothing in resp.ok will ever tell you the difference.

A free space API here means a public endpoint returning space or astronomy data with no API key, no signup, no credit card. A URL you can paste into a terminal right now. Eleven clear that bar. I re-verified every response below with a live curl on July 13, 2026: real HTTP code, real body, trimmed but never reworded.

One scope note, so the numbers stay honest. I curl-verified all eleven APIs on July 13, 2026. I have not run a satellite-tracking service in production. My 2,190 production scraper runs (962 of them on one Trustpilot scraper) are a different domain. I cite them for exactly one reason: they are why I read a body's own timestamp instead of its status line. Do not read 2,190 as a claim about these eleven endpoints.

#	API	What it returns	Example call	The gotcha
1	Where the ISS at	Live ISS lat/lon/alt/velocity	`GET api.wheretheiss.at/v1/satellites/25544`	`timestamp` is when you asked, not when it was measured
2	CelesTrak GP	Orbital elements (OMM/TLE)	`GET celestrak.org/NORAD/elements/gp.php?CATNR=25544&FORMAT=json`	A miss is a 404 with plain text, not JSON
3	TLE API	Two-line elements by NORAD ID	`GET tle.ivanstanojevic.me/api/tle/25544`	Same satellite, twice the epoch age of CelesTrak
4	JPL SSD/CNEOS	Asteroids, close approaches, fireballs	`GET ssd-api.jpl.nasa.gov/sbdb.api?sstr=433`	Errors ride inside a 200 body
5	JPL Horizons	Ephemerides for any solar-system body	`GET ssd.jpl.nasa.gov/api/horizons.api?format=json&...`	`format=json` wraps a plain-text blob
6	NASA Exoplanet Archive	6,319 planets in 39,978 rows, queryable by ADQL	`GET exoplanetarchive.ipac.caltech.edu/TAP/sync?query=...`	A bad query returns XML, whatever format you asked for
7	NASA Images	1,510 Apollo 11 images, and the rest	`GET images-api.nasa.gov/search?q=apollo 11`	Asset URLs need a second fetch, and they are `http://`
8	NOAA SWPC	Planetary K-index (geomagnetic storms)	`GET services.swpc.noaa.gov/products/noaa-planetary-k-index.json`	`time_tag` opens a 3-hour bin, so "now" is never now
9	Launch Library 2	364 upcoming launches, crew, agencies	`GET ll.thespacedevs.com/2.2.0/launch/upcoming/`	Anonymous calls are rate-limited, hard
10	SatNOGS DB	Open satellite + transmitter catalog	`GET db.satnogs.org/api/satellites/?format=json`	Records carry an `updated` field for a reason
11	SIMBAD TAP	Astronomical object database (CDS)	`POST simbad.cds.unistra.fr/simbad/sim-tap/sync`	Andromeda is not typed "Galaxy"

Then a flagged near-miss, three APIs that used to be keyless and are not, and the gate that catches the frozen ones. Along the way I get an arbiter badly wrong and have to throw it out, which turned out to be the most useful hour of the whole thing.

1. Where the ISS at: the one that was right, and could not have told you

api.wheretheiss.at gives you the station's position, altitude, velocity, and footprint, keyless, no signup.

# runnable, read-only
curl -s "https://api.wheretheiss.at/v1/satellites/25544"

{"name":"iss","id":25544,"latitude":37.5181,"longitude":95.3130,
 "altitude":429.73995965565,"velocity":27566.631304384,
 "visibility":"daylight","footprint":4556.6877316229,
 "timestamp":1783969022,"units":"kilometers"}

This one was correct. I checked, and I will show you how, and I will also show you the check I got wrong on the way there. But look at what its timestamp actually is: 1783969022 is the moment I sent the request. Not the moment anything was measured. It is a propagator: it takes a set of orbital elements and computes where the station is now, then stamps the answer with now.

That is the trap in miniature. The field named timestamp looks like a freshness signal and is not one. If the elements underneath went stale, this API would keep stamping fresh times on drifting positions, and the field called timestamp would never once flinch.

But here is the part I missed on my first pass, and it is the most useful thing in this section: wheretheiss will show you the elements it is propagating. You have to ask a different endpoint.

# runnable, read-only
curl -s "https://api.wheretheiss.at/v1/satellites/25544/tles"

{"requested_timestamp":1783971050,"tle_timestamp":1783883409,"id":"25544",
 "name":"iss","header":"ISS (ZARYA)",
 "line1":"1 25544U 98067A   26193.79871965  .00004831  00000+0  95802-4 0  9996",
 "line2":"2 25544  51.6301 173.3406 0006695 288.1916  71.8344 15.48994114575722"}

tle_timestamp is the epoch of the element set underneath the answer. Subtract it from requested_timestamp and you get the number that actually matters: when I pulled this, the elements were 24.3 hours old. That is the field to gate on. Not the one named timestamp, which is just a clock. Keep those two lines of TLE in mind. They come back to embarrass me in a few sections.

Use it for: a live ISS map or an "is it overhead" check. Gate on /tles, not on timestamp.

Docs: wheretheiss.at/w/developer. I have left that unlinked on purpose, and the reason is too good to bury. The docs host's TLS certificate expired at 14:02:56 UTC on July 12, 2026, one day before I pulled all of this, so curl refuses it with exit 60 and your browser will throw a full-page warning. The certificate on the API host next door is fine until July 19. The endpoint works. The page telling you how to use the endpoint does not. Check it yourself before you click, because by the time you read this it has probably been renewed, which is the other half of the lesson: everything in this post has an expiry date, including this post.

2. CelesTrak: the orbital elements everything else is built from

CelesTrak is Dr. T.S. Kelso's satellite element catalog, and it is where most people get their elements. It is not where the elements come from. That distinction matters more than it sounds: the tracking data is produced by the US Space Force's 18th Space Defense Squadron and published through Space-Track, and CelesTrak curates it, formats it, and hands it to you without a login. When you build on CelesTrak you are depending on two organizations, not one. Keyless. It serves classic TLE, and OMM in JSON, which is nicer to parse.

# runnable, read-only
curl -s "https://celestrak.org/NORAD/elements/gp.php?CATNR=25544&FORMAT=json"

[{"OBJECT_NAME":"ISS (ZARYA)","OBJECT_ID":"1998-067A",
  "EPOCH":"2026-07-13T07:33:22.422240","MEAN_MOTION":15.48997295,
  "ECCENTRICITY":0.0006687,"INCLINATION":51.6305,
  "NORAD_CAT_ID":25544,"REV_AT_EPOCH":57580,"BSTAR":8.1266e-5}]

Note EPOCH. It is not the timestamp of an observation. It is the reference time the element set is valid for: the anchor of a fit made against days of accumulated tracking, not the moment somebody pointed a radar at the thing. When I pulled this it was 11.4 hours in the past. Normal, fine, and honest: the API is telling you, unprompted, how old its own truth is. Remember that field. It is the one that saves you later.

The gotcha is at the other end. Ask for a satellite that does not exist and you do not get JSON:

# runnable, read-only
curl -s -w " [HTTP %{http_code}]\n" \
  "https://celestrak.org/NORAD/elements/gp.php?CATNR=99999&FORMAT=json"

No GP data found [HTTP 404]

Plain text, HTTP 404, despite FORMAT=json in the query. So resp.json() raises a decode error, not a clean empty list, and your error handling has to catch both. Also: CelesTrak asks you not to hammer it, so cache the elements and propagate locally instead of re-fetching every second.

Use it for: anything that needs real orbital elements. Docs: celestrak.org/NORAD/documentation/gp-data-formats.php.

3. TLE API: the same satellite, twice as stale

tle.ivanstanojevic.me is a friendly JSON wrapper over TLE data, keyless, no rate-limit drama.

# runnable, read-only
curl -s "https://tle.ivanstanojevic.me/api/tle/25544"

{"@type":"Tle","satelliteId":25544,"name":"ISS (ZARYA)",
 "date":"2026-07-12T19:10:09+00:00",
 "line1":"1 25544U 98067A   26193.79871965  .00004831  00000+0  95802-4 0  9996",
 "line2":"2 25544  51.6301 173.3406 0006695 288.1916  71.8344 15.48994114575722"}

Now put it next to CelesTrak. Same satellite, same minute, both keyless, both HTTP 200, both returning a perfectly valid TLE:

Feed	Epoch field	Age when I pulled it
CelesTrak	`EPOCH: 2026-07-13T07:33:22`	11.4 hours
TLE API	`date: 2026-07-12T19:10:09`	23.7 hours

Twice the age. Neither response is wrong. Neither status code differs. And now the number, because "twice as stale" is the kind of phrase that sounds alarming until you measure it. I propagated both element sets to the same instant. They land 1.0 km apart, about 0.13 seconds of along-track lag.

One kilometre. That is the entire cost of twelve extra hours of TLE age for this satellite, on this day. Do not carry that number anywhere else, and I want to be specific about why, because it is the kind of result that gets quoted out of its cage. Both feeds trace back to the same producer. What I measured is how stable one organization's successive fits are, not how accurate they are, and I measured it on a fat, well-tracked, high-drag-but-boring object during a quiet geomagnetic week. A cubesat with a bad area-to-mass ratio, a Starlink in the middle of a station-keeping burn, a Kp-7 storm puffing up the thermosphere, or a prediction horizon of a full day instead of twelve hours will each give you a much bigger number. Read the date field so you know which set you got. Just do not tell yourself that half a day of TLE age is what breaks a tracker.

There is a punchline here I did not expect. Remember api.wheretheiss.at from section 1, the one that was right? Pull its /tles endpoint and compare: it is propagating this exact element set, line for line, the 23.7-hour one. The API I am about to hold up as correct is running on the feed I just called "twice as stale." Both things are true, and that is the point: for this satellite, at this timescale, TLE age costs about a kilometre. The thing that costs 9,300 km is something else entirely.

(Two footnotes. The ISS reboosts: a TLE fitted before a maneuver is wrong the moment the thrusters fire, at any age. And that same element set shows up as 23.7 hours here and 24.3 hours in section 1, because I fetched it twice, half an hour apart. Age is a stopwatch reading, not a property of the data.)

Use it for: quick TLE lookups when you do not want to parse CelesTrak's formats. Read the date. Docs: tle.ivanstanojevic.me.

4. JPL SSD/CNEOS: four keyless endpoints, and errors hidden inside 200s

NASA JPL's Solar System Dynamics group runs a set of APIs at ssd-api.jpl.nasa.gov that are genuinely, fully keyless. This is one provider with four endpoints worth knowing, so I am counting it once.

sbdb.api looks up any small body:

# runnable, read-only
curl -s "https://ssd-api.jpl.nasa.gov/sbdb.api?sstr=433"

{"object":{"fullname":"433 Eros (A898 PA)","neo":true,"pha":false,
  "orbit_class":{"name":"Amor"}},
 "orbit":{"orbit_id":"659","first_obs":"1893-10-29","last_obs":"2021-05-13",
   "data_arc":"46582","n_obs_used":9130,"moid":"0.149"}}

first_obs: 1893-10-29. My first draft said Eros therefore has a 133-year observation arc, because 2026 minus 1893 is 133 and I can do arithmetic.

Look three fields to the right. data_arc: 46582. Days. That is 127 years, not 133, and the reason is sitting right next to it: last_obs: 2021-05-13. The arc ends where the observations end, not where my calendar does. JPL puts the answer in the body as an integer so that nobody has to subtract dates, and I subtracted dates anyway, in a post whose entire argument is read the field. Nine thousand one hundred and thirty observations went into that orbit and I could not be bothered to read one key.

Read the field. That is the whole post, hiding inside an asteroid.

cad.api lists close approaches. Everything passing within 0.05 au in the next month:

# runnable, read-only
curl -s "https://ssd-api.jpl.nasa.gov/cad.api?dist-max=0.05&date-min=2026-07-14&date-max=2026-08-14"

{"count":19,"fields":["des","orbit_id","jd","cd","dist",...],
 "data":[["2026 MQ3","8","2461237.959674506","2026-Jul-16 11:02",
          "0.0319436706577196",...,"21.95"], ...]}

Nineteen. fireball.api gives you atmospheric impact events detected by US government sensors, with energy and coordinates. scout.api covers newly-discovered objects not yet catalogued, and it carries lastRun and tEphem fields, which is a service admitting in the body how recently it thought about the problem.

The gotcha is the sibling endpoint, sentry.api:

# runnable, read-only
curl -s -w " [HTTP %{http_code}]\n" "https://ssd-api.jpl.nasa.gov/sentry.api?des=99942"

{"signature":{"version":"2.0","source":"NASA/JPL Sentry Data API"},
 "removed":"2021-02-21 08:22:28","error":"specified object removed"} [HTTP 200]

HTTP 200. The body says error. It also says exactly when: removed: 2021-02-21. Apophis came off the impact-risk table in February 2021; NASA's public all-clear for the next hundred years came separately, in March, after the Goldstone radar pass refined the orbit. Two events, a few weeks apart, and I am flagging that because it would be very easy to fuse them into one tidy sentence and be wrong. Either way it is good news for Earth and bad news for raise_for_status(). Branch on the error key, not the status code.

Use it for: asteroid data, close approaches, planetary defense projects. Docs: ssd-api.jpl.nasa.gov.

5. JPL Horizons: professional ephemerides, wrapped in a lie about JSON

Horizons is the system planetary scientists actually use. It will compute the position of any body in the solar system, from any observer, at any time, to absurd precision. Keyless, over HTTP.

# runnable, read-only: Mars, seen from Earth's center
curl -s "https://ssd.jpl.nasa.gov/api/horizons.api?format=json&COMMAND='499'&OBJ_DATA='NO'&MAKE_EPHEM='YES'&EPHEM_TYPE='OBSERVER'&CENTER='500@399'&START_TIME='2026-07-15'&STOP_TIME='2026-07-16'&STEP_SIZE='1%20d'&QUANTITIES='1'"

{"result":"\n*****\nEphemeris / API_USER Mon Jul 13 11:51:55 2026 Pasadena, USA\n*****\nTarget body name: Mars (499)   {source: mar099}\nCenter body name: Earth (399)  {source: DE441}\n..."}

You asked for JSON. You got JSON: one key, result, holding the same fixed-width text table Horizons has emitted since the 1990s, newlines and asterisks and all. The JSON wrapper is transport, not structure. You still have to parse the text between the $$SOE and $$EOE markers by hand.

I say this with affection. It is a thirty-year-old scientific instrument with a REST veneer, and it is one of the most powerful free things on the internet. Just do not plan on body["result"]["mars"]["ra"] existing.

One more thing, and it matters later. Point Horizons at the ISS instead of Mars, with COMMAND='-125544', and its header volunteers where its own trajectory comes from:

Revised: Jul 13, 2026  International Space Station (ISS) / (Earth)     -125544

  Trajectory is TLE-based. Predicts run for 4 weeks into future, but are of
  low accuracy for times more than a few days past the revision date above.

Trajectory is TLE-based. Hold on to that sentence. It is going to demolish something of mine about six sections from now.

Use it for: real ephemerides, planetary positions, spacecraft trajectories.

The docs are at ssd-api.jpl.nasa.gov/doc/horizons.html, and they are worth an hour of your life. Almost nobody reads them, which is why almost everybody reaches for a worse API.

6. NASA Exoplanet Archive: 6,319 planets, 39,978 rows, and a real query language

The Exoplanet Archive exposes a TAP service, which means you send it ADQL (a dialect of SQL for astronomy) and it returns rows. No key, no signup, and it is the actual planet catalog, not a summary of one.

# runnable, read-only
curl -s "https://exoplanetarchive.ipac.caltech.edu/TAP/sync?query=select+count(*)+from+ps&format=json"

[{"count(*)": 39978}]

Thirty-nine thousand, nine hundred seventy-eight rows, as of July 13, 2026. And that is the first trap, this whole post compressed into one query: that is not 39,978 planets. The ps table holds one row per published parameter set, so a well-studied planet appears in it many times over. Ask the question you actually meant:

# runnable, read-only
curl -s "https://exoplanetarchive.ipac.caltech.edu/TAP/sync?query=select+count(*)+from+pscomppars&format=json"

[{"count(*)": 6319}]

6,319 planets. Same archive, same keyless endpoint, same clean HTTP 200, and a number 6.3 times smaller. ps is the literature; pscomppars is one row per planet. I ran the wrong one first and wrote the wrong number into my own draft, which is exactly the failure mode this post is about: nothing in the status line tells you which of those two questions you asked.

You can slice it:

# runnable, read-only
curl -s "https://exoplanetarchive.ipac.caltech.edu/TAP/sync?query=select+top+2+pl_name,disc_year,pl_orbper+from+ps+where+disc_year>2024&format=json"

[{"pl_name": "KMT-2023-BLG-1896L b", "disc_year": 2025, "pl_orbper": null},
 {"pl_name": "OGLE-2015-BLG-1609L b", "disc_year": 2025, "pl_orbper": null}]

Two gotchas, and the second is the fun one. First, pl_orbper is null on both rows: these are microlensing detections, and microlensing does not give you an orbital period. Nulls are everywhere in this table and they are honest, not broken.

Second, break the query on purpose:

# runnable, read-only
curl -s -w " [HTTP %{http_code}]\n" \
  "https://exoplanetarchive.ipac.caltech.edu/TAP/sync?query=select+nope+from+ps&format=json"

<?xml version="1.0" encoding="UTF-8"?>
<VOTABLE version="1.4" xmlns="http://www.ivoa.net/xml/VOTable/v1.3">
<RESOURCE type="results">
<INFO name="QUERY_STATUS" value="ERROR">
ORA-00904: 'NOPE': invalid identifier
</INFO>
</RESOURCE>
</VOTABLE> [HTTP 400]

I asked for format=json. On error I got XML, plus an Oracle error code leaking through from the database underneath. The success path and the failure path do not speak the same language. Write your parser accordingly.

Use it for: exoplanet dashboards, statistics, anything where you want to run real queries instead of paging through someone's REST wrapper. Docs: exoplanetarchive.ipac.caltech.edu/docs/TAP/usingTAP.html.

7. NASA Image and Video Library: the NASA API everyone forgets is keyless

Everyone knows api.nasa.gov and everyone forgets it wants a key (more on that below). images-api.nasa.gov is a separate service and it wants nothing at all.

While I was checking that, I counted, because my draft claimed this was "one of the two NASA services that are truly keyless" and I had not actually counted anything. There are at least five. On July 13, 2026 all of these returned HTTP 200 with no key: images-api.nasa.gov, JPL's ssd-api.jpl.nasa.gov, Horizons at ssd.jpl.nasa.gov, the NASA Exoplanet Archive hosted at IPAC, and EONET, the natural-event tracker at eonet.gsfc.nasa.gov. The "NASA needs a key" folklore is wrong in five different places at once.

# runnable, read-only
curl -s "https://images-api.nasa.gov/search?q=apollo%2011&media_type=image"

{"collection":{"metadata":{"total_hits":1510},
  "items":[{"href":"https://images-assets.nasa.gov/image/jsc2007e034221/collection.json",
    "data":[{"nasa_id":"jsc2007e034221","title":"Apollo 11 spacecraft pre-launch",
             "date_created":"1969-07-11T00:00:00Z"}]}]}}

1,510 Apollo 11 images. The gotcha is that the search does not give you image URLs. It gives you a href pointing at a second JSON document, and you have to fetch that:

# runnable, read-only
curl -s "https://images-assets.nasa.gov/image/jsc2007e034221/collection.json"

["http://images-assets.nasa.gov/image/jsc2007e034221/jsc2007e034221~orig.jpg",
 "http://images-assets.nasa.gov/image/jsc2007e034221/jsc2007e034221~large.jpg", ...]

Two hops, always. And note the scheme: those asset URLs come back as http://, not https://, so a strict Content-Security-Policy on your page will block them unless you rewrite the scheme yourself. Small thing. Ruins an afternoon.

Use it for: free, high-resolution, public-domain space imagery. Docs: images.nasa.gov/docs/images.nasa.gov_api_docs.pdf.

8. NOAA SWPC: the "current" geomagnetic index that cannot be current

The Space Weather Prediction Center publishes solar and geomagnetic data as flat JSON files. No key, no auth, no rate limit worth mentioning. The planetary K-index tells you whether a geomagnetic storm is underway, which is what aurora apps and HF radio operators live on.

# runnable, read-only
curl -s "https://services.swpc.noaa.gov/products/noaa-planetary-k-index.json"

[{"time_tag":"2026-07-06T00:00:00","Kp":2.67,"a_running":12,"station_count":7},
 ...,
 {"time_tag":"2026-07-13T15:00:00","Kp":2.33,"a_running":9,"station_count":8}]

Sixty-two records at a three-hour cadence, which is just under eight days of history. I pulled this at 19:00 UTC. The last time_tag says 15:00 UTC, and the lazy read is "the current value is four hours old."

The lazy read is mine, and it is wrong in a way that matters. time_tag is not the moment of a measurement. It is the start of a three-hour bin. I checked every one of the 61 gaps in that array and they are all exactly 3.0 hours. So the newest label is at minimum three hours behind the wall clock by construction, before you add any processing lag at all, and the four hours I measured is the age of the label, not of the physics.

Two consequences, and I shipped the first one broken:

A max_age of three hours on this feed can never pass. Not "rarely." Never. My first draft gated it at exactly 3 * 3600 and called the resulting rejection "the gate working." It was a threshold that could only ever say no, which is not a gate, it is a wall.
Look at station_count: 8. This is the estimated Kp, computed from eight ground magnetometers in near-real-time. The definitive index is published later by GFZ Potsdam. If you need the real number for science rather than for a pretty aurora badge, this is not it.

None of that is a bug. It is the correct behavior of a correct product. But if you wrote current_kp = data[-1]["Kp"] and put it on a dashboard labeled "now," you have already told your first lie, and the API never contradicted you. It gave you a 200 and a time_tag and trusted you to read it.

Use it for: aurora forecasts, geomagnetic storm alerts, radio propagation. Read the time_tag, and know what it is the timestamp of. Docs: swpc.noaa.gov/products-and-data.

9. Launch Library 2: 364 upcoming launches, and a rate limit that will find you

The Space Devs run Launch Library 2, a launch schedule that a lot of space apps are quietly built on. Anonymous access is keyless.

# runnable, read-only
curl -s "https://ll.thespacedevs.com/2.2.0/launch/upcoming/?limit=1&mode=list"

{"count":364,"results":[{"name":"Falcon 9 Block 5 | Starlink Group 15-14",
  "status":{"name":"Go for Launch","abbrev":"Go"},
  "net":"2026-07-14T01:17:14Z","last_updated":"2026-07-13T13:07:42Z"}]}

364 launches on the books. Note the two time fields: net is the projected launch time (No Earlier Than, and it moves constantly), and last_updated is when a human touched this record. Both matter, for different reasons.

The honest limitation: anonymous calls are rate-limited hard, and the API does not send you X-RateLimit-* headers to warn you. I checked; it exposes none. You find out by getting a 429. A free account raises the ceiling, and there is a lldev.thespacedevs.com mirror with cached data for development. If you are building something real, sign up. If you are hacking a weekend project, the anonymous tier is fine, but do not poll it in a loop.

Use it for: launch schedules, agencies, rockets, crewed missions. Docs: thespacedevs.com/llapi.

10. SatNOGS DB: the open satellite catalog with an honest `updated` field

SatNOGS is a global network of volunteer-run ground stations, and its database is an open catalog of satellites, transmitters, and telemetry decoders. Keyless for reads.

# runnable, read-only
curl -s "https://db.satnogs.org/api/satellites/?format=json&norad_cat_id=25544"

[{"sat_id":"XSKZ-5603-1870-9019-3066","norad_cat_id":25544,"name":"ISS",
  "names":"ZARYA, RS0ISS, NA1SS","status":"alive","decayed":null,
  "launched":"1998-11-20T00:00:00Z","countries":"RU,US",
  "updated":"2025-08-01T05:17:04.759872Z","telemetries":[{"decoder":"iss"}]}]

The killer feature here is the transmitter database: frequencies, modes, and decoders for thousands of satellites, which is not information you can easily get anywhere else for free.

And look at updated. This record was last touched on 2025-08-01, roughly a year before I pulled it. That is completely correct, because the ISS has not changed its name or its status in that time. The point is that SatNOGS tells you. It puts the age of its own truth in the payload and lets you decide whether a year is too long for your use case. Every API in this post that I trust does exactly this.

Use it for: satellite metadata, radio frequencies, amateur ground-station work. Docs: db.satnogs.org/api/.

11. SIMBAD: the object database where Andromeda is not a "Galaxy"

SIMBAD, from the Centre de Donnees astronomiques de Strasbourg, is the reference database for astronomical objects outside the solar system. Its TAP endpoint takes ADQL, keyless.

# runnable, read-only: TAP wants request+lang, and it is picky
curl -s "https://simbad.cds.unistra.fr/simbad/sim-tap/sync" \
  --data "request=doQuery&lang=ADQL&format=json" \
  --data-urlencode "query=SELECT main_id, ra, dec, otype FROM basic WHERE main_id = 'M  31'"

{"metadata":[{"name":"main_id",...},{"name":"ra","unit":"deg",...}],
 "data":[["M  31", 10.684708333333333, 41.268750000000004, "AGN"]]}

First gotcha: drop request=doQuery&lang=ADQL and you get an HTTP 400, no matter how good your query is. TAP is an IVOA standard, not a REST API someone designed for you.

Second gotcha, and it is the whole thesis of this post wearing a different hat. Look at otype for M 31. Andromeda, the galaxy, comes back typed AGN. Not "Galaxy". Let me check two more famous ones:

[["M  31", "AGN"], ["M  51", "Sy2"], ["M  87", "AGN"]]

Andromeda: AGN. The Whirlpool: Sy2 (a Seyfert 2). M87: AGN. If you wrote WHERE otype = 'Galaxy' you would get a clean HTTP 200 with a perfectly valid, non-empty result set and you would ship a galaxy browser that silently omits Andromeda, the Whirlpool, and M87. That is not a thought experiment. SIMBAD accepts the long label happily, and I counted what it hands back:

# runnable, read-only: the query that looks right and is not
curl -s "https://simbad.cds.unistra.fr/simbad/sim-tap/sync" \
  --data "request=doQuery&lang=ADQL&format=json" \
  --data-urlencode "query=SELECT COUNT(*) AS n FROM basic WHERE otype = 'Galaxy'"

{"metadata":[{"name":"n","datatype":"LONG"}],"data":[[4177456]]}

Four million rows, HTTP 200, no warning, no error, and three of the most famous galaxies in the sky are not in there.

To be precise, because SIMBAD is not being sloppy and I am not going to imply it is: Andromeda is a galaxy. otype holds the single most specific type, and SIMBAD's own hierarchy says so out loud. Query the otypedef table and the path for AGN is literally G > AGN; Sy2 is G > AGN > SyG > Sy2. The database was right. My query was wrong.

And the fix is two characters. TAP exposes that hierarchy with a .. suffix, which means "this type and everything under it":

# runnable, read-only: '..' walks the type tree
curl -s "https://simbad.cds.unistra.fr/simbad/sim-tap/sync" \
  --data "request=doQuery&lang=ADQL&format=json" \
  --data-urlencode "query=SELECT main_id, otype FROM basic WHERE otype = 'G..' AND main_id IN ('M  31','M  51','M  87')"

{"data":[["M  31","AGN"],["M  51","Sy2"],["M  87","AGN"]]}

Two dots. That is the whole difference between a galaxy browser that works and one that ships a 200 with a hole in it. One warning before you paste it elsewhere: .. is a SIMBAD extension to its own otype column, not portable ADQL. Try it against the Exoplanet Archive's TAP from section 6 and Oracle will tell you exactly what it thinks of you.

Which is the lesson again, wearing its third hat today: otype = 'Galaxy' returned a valid, non-empty, four-million-row answer, and nothing about that 200 was ever going to hint that I had asked the wrong question.

Use it for: star and deep-sky object coordinates, identifiers, classifications.

Before you write a single query, go read what otype actually means: simbad.cds.unistra.fr/simbad/sim-tap. I did not, and it cost me a galaxy browser with three famous holes in it.

Flagged: api.nasa.gov is not keyless, DEMO_KEY is not "no key"

APOD, NeoWs, EPIC, and DONKI all live behind api.nasa.gov, and every tutorial calls them free. They are free. They are not keyless.

# runnable, read-only
curl -s -w " [HTTP %{http_code}]\n" "https://api.nasa.gov/planetary/apod"

{"error":{"code":"API_KEY_MISSING",
  "message":"No api_key was supplied. Get one at https://api.nasa.gov:443"}} [HTTP 403]

A hard 403. Add ?api_key=DEMO_KEY and you get a 200, which is why the myth persists.

Now, how strict is DEMO_KEY? The documentation says 30 requests per IP per hour and 50 per day, and my first draft printed those two numbers, sourced from the docs, in a post whose single rule is the docs are not the data. So I went and hit it four times in a row and watched the headers instead:

# runnable, read-only: watch the header, not the docs
for i in 1 2 3 4; do
  curl -s -D - -o /dev/null "https://api.nasa.gov/planetary/apod?api_key=DEMO_KEY" \
    | grep -i "^HTTP\|^x-ratelimit"
done

HTTP/2 200
x-ratelimit-limit: 10
x-ratelimit-remaining: 1

HTTP/2 200
x-ratelimit-limit: 10
x-ratelimit-remaining: 0

HTTP/2 429
x-ratelimit-limit: 10
x-ratelimit-remaining: 0

HTTP/2 429
x-ratelimit-limit: 10
x-ratelimit-remaining: 0

x-ratelimit-limit: 10, and a 429 on the third call. I am not going to tell you the docs are wrong, because I do not know what window that 10 belongs to or what else my IP had been doing that hour. I am telling you what the server said when I asked it, on July 13, 2026, and that the server ships the number in a header so you never have to guess. It is a key, and a small one, and building on it is how a demo rots into a support ticket. I am not padding my count with it.

Why not on the list: three APIs the tutorials still recommend

SpaceX API v4. Still the first result a lot of people land on. Dead:

curl -s -o /dev/null -w "%{http_code}\n" "https://api.spacexdata.com/v4/launches/latest"

525 is a Cloudflare origin SSL handshake failure: the edge is up, and the origin is not completing TLS with it. Note what that does and does not tell you. The backend might be perfectly alive behind an expired certificate, a closed 443, or a cipher mismatch. From out here you cannot tell, and it does not matter, because you cannot get launches out of it either way. Use Launch Library 2 instead.

Solar System OpenData (api.le-systeme-solaire.net), which was keyless for years, now returns 401 Unauthorized: API key is missing. Ask your API key... Add use it on a bearer token. Gated in 2026.

USNO Astronomical Applications (aa.usno.navy.mil/api/) did not complete a connection at all for me: curl exit, HTTP 000. Sunrise, sunset, moon phase, all unreachable from where I sat.

The gate: read the timestamp out of the body

Here is the wrapper. It does one thing: it pulls the time field out of the response body, compares it to now, and refuses an answer that is too old to be called data.

# runnable local: pip install requests
import requests
from datetime import datetime, timezone

class StaleData(Exception):
    pass

def age_seconds(stamp):
    """Accept an ISO-8601 string or a unix timestamp. Return age in seconds."""
    if isinstance(stamp, (int, float)):
        ts = datetime.fromtimestamp(stamp, tz=timezone.utc)
    else:
        ts = datetime.fromisoformat(str(stamp).replace("Z", "+00:00"))
        if ts.tzinfo is None:            # SWPC and CelesTrak omit the zone
            ts = ts.replace(tzinfo=timezone.utc)
    return (datetime.now(timezone.utc) - ts).total_seconds()

def fetch_fresh(url, pick_time, max_age):
    """GET url, read the timestamp OUT OF THE BODY, refuse the answer if it is old."""
    r = requests.get(url, timeout=20)
    r.raise_for_status()                 # a frozen server sails straight through this
    body = r.json()
    age = age_seconds(pick_time(body))   # this is the check that actually matters
    if age > max_age:
        raise StaleData(f"200 but {age/3600:.1f}h old (max_age {max_age/3600:.1f}h)")
    return body, age

CASES = [
    # gate wheretheiss on the ELEMENTS it propagates, not on its own clock
    ("wheretheiss", "https://api.wheretheiss.at/v1/satellites/25544/tles",
     lambda b: b["tle_timestamp"], 6 * 3600),
    ("open-notify", "http://api.open-notify.org/iss-now.json",
     lambda b: b["timestamp"], 60),
    ("celestrak",   "https://celestrak.org/NORAD/elements/gp.php?CATNR=25544&FORMAT=json",
     lambda b: b[0]["EPOCH"], 6 * 3600),
    ("swpc-kp",     "https://services.swpc.noaa.gov/products/noaa-planetary-k-index.json",
     lambda b: b[-1]["time_tag"], 6 * 3600),   # time_tag opens a 3h bin: 3h is unreachable
]

for name, url, pick, max_age in CASES:
    try:
        _, age = fetch_fresh(url, pick, max_age)
        print(f"FRESH  {name:12} age {age:8.0f}s")
    except StaleData as e:
        print(f"STALE  {name:12} {e}")

Real output, July 13, 2026:

STALE  wheretheiss  200 but 25.4h old (max_age 6.0h)
FRESH  open-notify  age        1s
STALE  celestrak    200 but 13.0h old (max_age 6.0h)
FRESH  swpc-kp      age    19947s

Now read line one and line two together, because that pair is the most useful thing I found all day.

The gate flagged wheretheiss. The API that was right. It flagged it because I aimed the gate at /tles, where it read the age of the elements underneath the answer: 25.4 hours, well past my six-hour ceiling.

The gate passed open-notify. One second old. Perfect score. The API that is on the wrong side of the planet.

My timestamp gate got both of them exactly backwards.

It is still worth having, and I still ship it, because it catches honest staleness and honest staleness is most of what goes wrong: CelesTrak's 13-hour elements, SWPC's Kp sitting 5.5 hours behind the clock and squeaking under a ceiling I set at six on purpose. My max_age values are opinions, not physics. Six hours for orbital elements because I decided a kilometre of drift is my budget; six for Kp because three is arithmetically impossible against a three-hour bin. Pick your own and write down why.

But a gate that reads one response can only ever ask the server about itself. And this server lies about itself, fluently, with a fresh timestamp.

Where the gate fails, and the arbiter I got wrong

And then there is line two.

FRESH open-notify age 1s.

Open Notify is the API from the top of this post, the one that is about 9,300 km wrong. It passed the freshness gate with a perfect score, because its timestamp field is the server's clock at the moment you ask. It stamps now on every response.

It gets worse, and this is the part that changed how I think about liveness checks. The position changes between calls.

ts 1783974529   lat -22.9871   lon 128.4535
ts 1783974578   lat -25.3113   lon 130.6121

Forty-nine seconds, 339 km, which is 6.91 km/s: the same ground-track speed I measured at the top of this post. Smooth motion along something that has the exact shape of an orbit. I want to be careful here, because it would be easy and satisfying to tell you what that server is doing internally, and I cannot see inside it. What is observable is enough: it reports a position that no currently published element set produces, it moves, and its crew roster still lists the people who were aboard in mid-2024.

Run down the checklist a careful engineer would actually write:

HTTP 200. Yes.
Valid JSON, parses cleanly. Yes.
Matches the schema, no nulls. Yes.
Body says "message": "success". Yes.
Timestamp field is current. Yes.
Value changes between polls, so it is not a frozen cache. Yes.

Every single one passes. And the answer is on the wrong side of the planet.

The arbiter that proved nothing

So I built an arbiter. Pull the current elements, propagate them with SGP4, convert to lat/lon, ask both APIs the same question at the same instant, and see who lands where. It ran. It printed a beautiful result, which I wrote straight into this draft: wheretheiss off by 3 km, open-notify off by 9,300. Two independent methods agreeing to within 3 km. Case closed, ship it.

It is not two independent methods. It is one method, run twice.

Here is the shortest possible demonstration. Take the element set that wheretheiss serves from its own /tles endpoint, the one printed back in section 1, and propagate it with SGP4 to wheretheiss's own timestamp:

# runnable local: pip install sgp4 requests
# (sgp4_at and great_circle are defined in the full listing below)
from sgp4.api import Satrec

wi   = requests.get("https://api.wheretheiss.at/v1/satellites/25544", timeout=20).json()
tles = requests.get("https://api.wheretheiss.at/v1/satellites/25544/tles", timeout=20).json()

sat  = Satrec.twoline2rv(tles["line1"], tles["line2"])   # ITS elements
mine = sgp4_at(sat, wi["timestamp"])                     # ITS timestamp
W    = (wi["latitude"], wi["longitude"])

print("my sgp4      lat %9.4f  lon %9.4f" % mine)
print("wheretheiss  lat %9.4f  lon %9.4f" % W)
print("distance     %.2f km" % great_circle(mine, W))

tle_timestamp 1783883409  (the elements wheretheiss is propagating)
my sgp4      lat   26.5017  lon   84.7225
wheretheiss  lat   26.5017  lon   84.7225
distance     0.00 km

Zero. Not "close." Identical to four decimal places, because api.wheretheiss.at is an SGP4 propagator running on that element set. Reproducing its output is a unit test of my pip install sgp4, not corroboration of anything about the sky.

My 3 km only existed because my arbiter happened to grab a different element set (CelesTrak's, twelve hours newer) and section 3 already told you, with a number, that those two sets sit 1.0 km apart. I wrote the word "independent" about thirty lines after admitting that both feeds carry the same elements. The code ran. The output was real. The comparison was rigged, and it did not survive review.

Which is the disease of this entire post, caught in my own draft: a green check that means nothing. Nothing I could have added to my test suite would have found it. Only someone asking "independent of what?" would.

The arbiter that is at least a different implementation

So go get a real second opinion. NASA runs one, keyless, and it has been sitting in section 5 of this post the whole time: JPL Horizons will compute the ISS for you if you hand it COMMAND='-125544'.

And Horizons, being a grown-up, tells you in its own header what it is: Trajectory is TLE-based.

There it is. There is no keyless oracle for where the ISS is. Horizons ingests the same public element sets everyone else does. So does wheretheiss. So does my script. The entire visible world of free ISS tracking hangs off one lineage of tracking data, produced by the 18th Space Defense Squadron, and if that lineage were wrong we would all be wrong together and in perfect agreement about it.

So I am not going to sell you an oracle. What Horizons gives you is weaker and still worth a great deal: an independent implementation. JPL's ingest, JPL's propagator, JPL's frame and rotation handling, none of my code, none of wheretheiss's server. I would rather hand you the weaker claim that is true.

The trick for getting a ground track out of it is nice: ask Horizons for Earth, observed from the ISS, and request quantity 14, the sub-observer point. The point on Earth directly under the observer is the ground track, computed by JPL, with all the frame rotation handled by people who do this for a living.

# runnable local: pip install sgp4 requests
import math, requests
from datetime import datetime, timezone
from sgp4.api import Satrec, jday

def gmst_deg(jd):                       # Vallado, GMST from a Julian date (UT1)
    T = (jd - 2451545.0) / 36525.0
    s = 67310.54841 + (876600*3600.0 + 8640184.812866)*T + 0.093104*T*T - 6.2e-6*T**3
    return (s % 86400.0) * (360.0/86400.0) % 360.0

def teme_to_geodetic(r, jd):            # TEME -> ECEF -> WGS84 lat/lon
    g = math.radians(gmst_deg(jd))
    x =  math.cos(g)*r[0] + math.sin(g)*r[1]
    y = -math.sin(g)*r[0] + math.cos(g)*r[1]
    z = r[2]
    a, f = 6378.137, 1/298.257223563
    e2 = f*(2 - f)
    p = math.hypot(x, y)
    lat = math.atan2(z, p*(1 - e2))
    for _ in range(12):                 # standard WGS84 latitude iteration
        N = a / math.sqrt(1 - e2*math.sin(lat)**2)
        alt = p/math.cos(lat) - N
        lat = math.atan2(z, p*(1 - e2*N/(N + alt)))
    lon = math.degrees(math.atan2(y, x))
    return math.degrees(lat), (lon + 180) % 360 - 180

def great_circle(p, q):
    la1, lo1, la2, lo2 = map(math.radians, [p[0], p[1], q[0], q[1]])
    h = math.sin((la2-la1)/2)**2 + math.cos(la1)*math.cos(la2)*math.sin((lo2-lo1)/2)**2
    return 2 * 6371.0 * math.asin(math.sqrt(h))

def sgp4_at(sat, unix_ts):              # propagate to ONE API's OWN timestamp
    d = datetime.fromtimestamp(unix_ts, tz=timezone.utc)
    jd, fr = jday(d.year, d.month, d.day, d.hour, d.minute,
                  d.second + d.microsecond/1e6)      # keep the sub-second part
    err, r, _ = sat.sgp4(jd, fr)
    assert err == 0
    return teme_to_geodetic(r, jd + fr)

def horizons_subpoint(unix_ts):
    """Target = Earth, observer = the ISS, quantity 14 = sub-observer point.
    That IS the ground track, and JPL does the frame work."""
    jd = 2440587.5 + unix_ts/86400.0
    r = requests.get("https://ssd.jpl.nasa.gov/api/horizons.api", timeout=40, params={
        "format": "text", "COMMAND": "'399'", "CENTER": "'500@-125544'",
        "MAKE_EPHEM": "YES", "EPHEM_TYPE": "OBSERVER", "QUANTITIES": "'14'",
        "TLIST_TYPE": "JD", "TIME_TYPE": "UT", "TLIST": f"{jd:.9f}"})
    rows = r.text.split("$$SOE")[1].split("$$EOE")[0].strip().splitlines()
    lon, lat = map(float, rows[0].split()[-2:])      # E-lon, lat
    return lat, lon

wi = requests.get("https://api.wheretheiss.at/v1/satellites/25544", timeout=20).json()
on = requests.get("http://api.open-notify.org/iss-now.json", timeout=20).json()
el = requests.get("https://celestrak.org/NORAD/elements/gp.php?CATNR=25544&FORMAT=TLE",
                  timeout=20).text.strip().splitlines()

ts_w, ts_o = wi["timestamp"], on["timestamp"]
W = (wi["latitude"], wi["longitude"])
O = (float(on["iss_position"]["latitude"]), float(on["iss_position"]["longitude"]))
sat = Satrec.twoline2rv(el[1], el[2])
S_w, S_o = sgp4_at(sat, ts_w), sgp4_at(sat, ts_o)   # each at its OWN timestamp
H_w, H_o = horizons_subpoint(ts_w), horizons_subpoint(ts_o)

print("wheretheiss  vs JPL Horizons   %7.1f km" % great_circle(W, H_w))
print("my sgp4      vs JPL Horizons   %7.1f km" % great_circle(S_w, H_w))
print("wheretheiss  vs my sgp4        %7.1f km" % great_circle(W, S_w))
print("open-notify  vs JPL Horizons   %7.0f km" % great_circle(O, H_o))

Note one small fix in there, which cost me most of my 3 km: each API is judged at the instant it stamped, with the microseconds kept. The first version rounded to whole seconds, and a whole second of ISS is 7.7 km. My arbiter's error bar was bigger than the disagreement I was using it to measure.

ts_w 1783974793   ts_o 1783974795   (each API judged at the instant IT stamped)
                       lat        lon
JPL Horizons  @ts_w   29.0128    82.1929
wheretheiss   @ts_w   28.9979    82.1926
my sgp4       @ts_w   29.0052    82.1859
JPL Horizons  @ts_o   28.9213    82.2889
open-notify   @ts_o  -35.0240   141.4149

wheretheiss  vs JPL Horizons       1.7 km
my sgp4      vs JPL Horizons       1.1 km
wheretheiss  vs my sgp4            1.0 km
open-notify  vs JPL Horizons      9432 km

Three implementations, one element lineage, landing within 1.7 km of each other over the Himalayas. And Open Notify, judged at the instant it stamped its own answer, 9,432 km away over southern Australia.

Do not read the 1.7 km as a quality score. It is the noise floor of the method: TLE plus SGP4 is good to a couple of kilometres for the ISS on a calm day, my GMST rotation is an approximation, and the three of us are propagating fits anchored at different hours. Anything under a few kilometres here means "the same place." I am not selling you a precision I do not have.

What the run does establish is narrower than "Open Notify is wrong" and much harder to argue with: Open Notify is not tracking the satellite the rest of us are tracking. It is serving a position that no published element set produces, under HTTP 200, with a timestamp one second old.

The corroborating evidence is the crew roster. Open Notify's other endpoint tells you who is in space:

curl -s "http://api.open-notify.org/astros.json"    # HTTP 200
curl -s "https://ll.thespacedevs.com/2.2.0/astronaut/?in_space=true"  # HTTP 200

open-notify   number = 12   Kononenko, Chub, Caldwell Dyson, Dominick,
                            Barratt, Epps, Grebenkin, Wilmore, Sunita Williams,
                            Li Guangsu, Li Cong, Ye Guangfu
thespacedevs  count  = 11   Meir, Starman, Kud-Sverchkov, Hathaway,
                            Christopher Williams, Fedyaev, Adenot, Zhu Yangzhu,
                            Mikayev, Zhang Zhiyuan, Lai Ka-ying
overlap = 0

Zero names in common. (The only shared surname is Williams, and they are two different people.) Both HTTP 200, both a valid list, both cheerfully certain.

Now, an honest caveat, because I am not going to pretend I have an oracle here either: The Space Devs is not ground truth. Its in_space=true list includes "Starman," the mannequin SpaceX put in a Tesla in 2018, typed Non-Human, and the API reports 3,078 days of flight time for him. I am not telling you that list is right. I am telling you these two 200s cannot both be right, and that is the entire lesson. Open Notify's roster happens to be internally consistent with a snapshot from 2024, which is a strong hint about which one froze. But I did not need to know who is actually aboard the ISS to know that something here is broken. Two disagreeing successes are all the evidence you need.

So what do you actually do?

Two layers, and they catch different diseases.

Layer one, cheap: read the body's own clock. EPOCH, time_tag, lastRun, updated. Set a max_age you can defend and reject anything older. This catches honest staleness: CelesTrak's 13-hour elements, SWPC's Kp label sitting behind a three-hour bin, the TLE feed twice as old as its neighbor. Most of your data problems are here, and thirty lines of fetch_fresh will find them.

Layer two, expensive: cross-check against a second implementation. This is the only thing that catches a server stamping now on garbage. It is not free, so do not do it on every call. Run it on a schedule, as a canary, and alert when two sources that should agree stop agreeing.

And when you build that canary, ask the question I failed to ask for a whole draft: independent of what? A second source that is downstream of the first one is not a second source. It is a mirror, and it will agree with anything.

If I had shipped an ISS tracker on Open Notify, no amount of schema validation, status checking, null-guarding, or timestamp reading would have saved me. Only a second opinion would, and only if I had checked that it was actually a second one.

I learned the first half of that in a different domain, expensively. Across 2,190 production scraper runs, the incidents that actually hurt were never the crashes. A 500 wakes you up and you fix it by lunch. The response that comes back valid, non-empty, correctly shaped, and quietly wrong is the one that sits in a column until somebody notices a report looks off, and by then you are backfilling.

Space just makes it visible, because a wrong satellite position is 9,000 km of visible. Your API is probably lying in a smaller, quieter way. Go read its timestamp. Then go check what your check is checking.

FAQ

What is the best free space API with no key?
It depends on the job, and several are keyless together. Where the ISS at gives live station position. CelesTrak gives the orbital elements everything else is built on. JPL SSD/CNEOS covers asteroids and close approaches, Launch Library 2 covers launches, and the NASA Exoplanet Archive lets you run real ADQL queries against 6,319 confirmed planets (the ps table has 39,978 rows, because it stores one row per published parameter set, not one per planet). All returned HTTP 200 with no key on July 13, 2026. Whichever you pick, read the timestamp field in the body before you trust the numbers.

Does the NASA API require an API key?
api.nasa.gov (APOD, NeoWs, EPIC, DONKI) does: without a key it returns HTTP 403 with API_KEY_MISSING. DEMO_KEY works but is a shared public credential (its live response carried x-ratelimit-limit: 10 and started returning 429 on my third call), so it is a key, not "no key." At least five other NASA-funded services are genuinely keyless and returned HTTP 200 with no credentials on July 13, 2026: the NASA Image and Video Library (images-api.nasa.gov), JPL's ssd-api.jpl.nasa.gov suite, JPL Horizons (ssd.jpl.nasa.gov), the NASA Exoplanet Archive at IPAC, and EONET (eonet.gsfc.nasa.gov).

Is the Open Notify ISS API still working in 2026?
It returns HTTP 200 and it is not working. On July 13, 2026 its iss-now.json position was 9,432 km away from where JPL Horizons put the ISS at the same instant, while api.wheretheiss.at and my own SGP4 propagation of CelesTrak's current elements both agreed with Horizons to within 1.7 km. Its astros.json crew roster still lists the people who were aboard in mid-2024, Wilmore and Williams among them. It also fails TLS, so it only answers over plain http://. Treat it as an exhibit, not a dependency.

How do I know if an API's data is stale when it returns 200?
Read the timestamp out of the response body, not the status line. Real APIs publish the age of their own truth: CelesTrak has EPOCH, NOAA SWPC has time_tag, JPL Scout has lastRun, SatNOGS has updated. Compare that field to now and reject anything older than a max_age you chose deliberately. That catches frozen feeds. It does not catch a server that stamps the current time on stale inputs, and for that you need a second source to cross-check against, one that is genuinely a different implementation rather than a mirror of the first.

What replaced the SpaceX API?
The SpaceX v4 API at api.spacexdata.com returned HTTP 525 (a Cloudflare origin SSL failure) when I tested it on July 13, 2026. Launch Library 2 from The Space Devs (ll.thespacedevs.com) is the practical replacement: it is keyless for anonymous use, it covers all launch providers rather than one, and it returned 364 upcoming launches. Anonymous access is rate-limited, so a free account helps for anything real.

Can I get real asteroid and close-approach data for free?
Yes, from JPL, with no key. ssd-api.jpl.nasa.gov/sbdb.api?sstr=433 returns the full orbit of 433 Eros, including first_obs: 1893-10-29, last_obs: 2021-05-13, and data_arc: 46582 days, which is a 127-year observation arc built from 9,130 observations. cad.api lists close approaches (19 objects within 0.05 au in the month I checked), fireball.api lists atmospheric impact events, and scout.api covers newly-discovered objects. One warning: sentry.api can return HTTP 200 with an error key in the body, so branch on the body, not the status.

Written by Aleksei Spinov. I build web-scraping and data-enrichment tool layers, currently 2,190 runs across 32 actors in production. Every endpoint above was re-verified with a live curl (real HTTP code, real body) on July 13, 2026 before publishing; responses are trimmed, never reworded. I have not run a satellite-tracking service in production; the 2,190 runs are a scraping-and-enrichment domain, cited only as the origin of the read-the-body habit. I wrote up the same pattern for free government data APIs, free fun-facts APIs, and free mock and fake-data APIs. Drafted with an AI assistant, then fact-checked and edited by me against the raw responses.

Follow for the next keyless layer I verify. And tell me: what is the longest a stale-but-successful API fooled you, and what finally caught it, a timestamp or a second opinion? I read every comment.

11 Free Music APIs With No Key or Signup (2026)

Alex Spinov — Tue, 14 Jul 2026 09:55:33 +0000

On July 12, 2026 I asked a free lyrics API for the most famous Coldplay song there is. It answered in a few milliseconds: HTTP 200, valid JSON, a full array of twenty results. The top one was a song called "Help Is Round the Corner."

# runnable, read-only: no key needed
curl -s "https://lrclib.net/api/search?q=yellow%20coldplay"

[{"id":13774,"trackName":"Help Is Round the Corner","artistName":"Coldplay",
  "albumName":"Yellow - Single","duration":156.0}, ...19 more...]

Status 200. The array is not empty. It has exactly the shape you expect. And results[0] is the wrong song. "Help Is Round the Corner" is a Coldplay B-side that shipped on the "Yellow" single back in 2000; the search matched the album name, ranked the B-side first, and handed it back with no hesitation. Every guard I reach for passes this response: resp.ok, len(results) > 0, results[0]["trackName"] exists. The wrong entity walks straight past all of them and gets stapled to the wrong lyrics.

My earlier keyless-API posts kept circling one idea from different angles. HTTP 200 does not mean the read worked, because the body can be empty. HTTP 201 Created does not mean a write happened, because the read-back returns 404. Then a 200 can parse, match your schema, and still hand you null. This post moves the problem sideways. Here the status is 200, the body arrives, it parses, the list is full, every field is present and well-typed. The top row is just the wrong thing. A 200 with a full list is not a 200 with the right result.

The reason is structural, and it is specific to music. There is no single ID for "the song Yellow by Coldplay." There is a studio single, a remaster, a live radio session, a karaoke track, a handful of covers, and a B-side that sits on the "Yellow" single. Every music search is a fuzzy ranking over that mess, so every results[0] is a guess. A valid, non-empty, correctly shaped guess. The only thing that tells you whether it is the right guess is a number or a field in the body that most tutorials never read.

A free music API here means a public endpoint that returns music data (tracks, artists, lyrics, cover art, radio, audio features, listening history) with no API key, no signup, and no credit card. A URL you can paste into a terminal right now. Eleven clear that bar, and I re-verified every response below with a live curl on July 12, 2026: real HTTP code, real body, trimmed but never reworded.

One scope note first, so the numbers stay honest. I curl-verified all eleven APIs on July 12, 2026. I have not run a music resolver in production. My 2,190 production scraper runs (962 of them on a single Trustpilot scraper) are a different domain, and I cite them for one reason only: they are why I read a body's own confidence fields instead of its status line. That number is not a claim about these eleven endpoints.

#	API	What it returns	Example call	The fuzzy trap to watch
1	MusicBrainz	Artist / recording metadata + MBIDs	`GET musicbrainz.org/ws/2/recording?query=...`	200, `score:100`, top hit is a live bootleg
2	Cover Art Archive	Album art by MBID	`GET coverartarchive.org/release-group/{mbid}`	Hit is a 307, miss is a 404, never a plain 200
3	iTunes Search	Apple catalog search	`GET itunes.apple.com/search?term=...`	200, fuzzy-matches a typo into real tracks
4	Deezer	Track / artist search + ISRC	`GET api.deezer.com/search?q=...`	200 carrying an error object in the body
5	Lyrics.ovh	Plain lyrics by artist/title	`GET api.lyrics.ovh/v1/{artist}/{title}`	Works, but the host flaps between days
6	lrclib	Time-synced lyrics	`GET lrclib.net/api/search?q=...`	200, `results[0]` is a B-side, not the song
7	Radio Browser	Internet radio directory	`GET de1.api.radio-browser.info/json/stations/search`	200 lists dead streams; read `lastcheckok`
8	Open Opus	Classical composers / works	`GET api.openopus.org/composer/list/search/...`	Curated set; a miss returns `rows:0`
9	ListenBrainz	Open listening-history stats	`GET api.listenbrainz.org/1/stats/sitewide/artists`	Read is keyless; submit needs a token
10	AcousticBrainz	Audio features (loudness, BPM, key)	`GET acousticbrainz.org/api/v1/{mbid}/low-level`	200 forever, dataset frozen since 2022
11	Odesli / song.link	Cross-platform track links	`GET api.song.link/v1-alpha.1/links?url=...`	200, but links are geo-dependent

One flagged bonus and a short list of key-required names get their own section after the eleven.

1. MusicBrainz: the score of 100 that means "string matched," not "right recording"

MusicBrainz is the open music encyclopedia, the free MBID system that half the other APIs on this list key off. It is keyless, but it has two rules: send a real User-Agent (a default client UA gets a 403) and stay under about one request per second. The happy path is clean.

# runnable, read-only: real User-Agent is mandatory
curl -s -A "my-app/1.0 (me@example.com)" \
  "https://musicbrainz.org/ws/2/artist?query=Radiohead&fmt=json&limit=2"

{"count":29,"artists":[{"id":"a74b1b7f-71a5-4011-9441-d0b5e4122711",
  "name":"Radiohead","score":100,"country":"GB"}, ...]}

Score 100, country GB, one MBID you can trust. Now search for a recording instead of an artist, and watch the ranking betray you:

# runnable, read-only
curl -s -A "my-app/1.0 (me@example.com)" \
  "https://musicbrainz.org/ws/2/recording?query=Yellow%20AND%20artist:Coldplay&fmt=json&limit=2"

{"count":146,"recordings":[{"id":"f15eb81a-b021-4208-9f1c-f4db2a9f09ae",
  "title":"Yellow","score":100,
  "disambiguation":"live, 2001-06-13: KBCO Studio C, Boulder, CO, USA",
  "releases":[{"title":"KBCO Studio C, Volume 13","date":"2001"}]}]}

Read that top row carefully. The title is exactly "Yellow." The score is a perfect 100. If your code trusts results[0].title, you are certain you found the song. You did not. The disambiguation field says live, 2001-06-13: KBCO Studio C, Boulder, CO, USA, and the release is a live radio-session compilation. Out of 146 matches, the highest-ranked "Yellow" by Coldplay is a bootleg of a radio appearance, not the studio single from Parachutes. A score of 100 means your query string matched this row. It says nothing about whether this row is the canonical recording. The only field that warns you is disambiguation, and the happy path throws it away.

When to use it: anything that needs stable IDs across services, past a gate that reads score and disambiguation before it trusts a match. Docs: musicbrainz.org/doc/MusicBrainz_API.

2. Cover Art Archive: the hit is a 307 and the miss is a 404, never a plain 200

Cover Art Archive serves album art keyed by a MusicBrainz release or release-group MBID. It is the sister project to MusicBrainz, keyless, and it has a contract that breaks naive status checks at both ends.

# runnable, read-only: -i shows the status line, no -L yet
curl -si -A "my-app/1.0" \
  "https://coverartarchive.org/release-group/1b022e01-4da6-387b-8658-8678046e4cef" | head -1

HTTP/2 307

That is a 307 redirect, not a 200. Follow it and you land on an archive.org JSON index:

# runnable, read-only: -L follows the redirect
curl -sL -A "my-app/1.0" -o /dev/null -w "%{http_code} after %{num_redirects} redirects\n" \
  "https://coverartarchive.org/release-group/1b022e01-4da6-387b-8658-8678046e4cef"

200 after 2 redirects

A hit is a 307 that resolves, through archive.org, to a 200. A miss is blunt:

# runnable, read-only
curl -s -o /dev/null -w "%{http_code}\n" \
  "https://coverartarchive.org/release/00000000-0000-0000-0000-000000000000"

So the contract is redirect-or-404, never a plain 200 with image bytes. Code that does if resp.status_code == 200 before following redirects sees the hit as a "failure" (it is a 307) and needs a separate branch for the honest 404 on a miss. Let your HTTP client follow redirects, then check the final status, and treat 404 as "no art," not as an error to retry.

When to use it: fetching album covers by MBID, with redirect-following on and a 404 handled as an empty result. Docs: coverartarchive.org/doc/API.

3. iTunes Search: it never says "no match," it fuzzy-matches your typo

Apple's iTunes Search API is keyless, fast, and returns a text/javascript body that is really JSON. The clean call is what you expect.

# runnable, read-only
curl -s "https://itunes.apple.com/search?term=radiohead&entity=song&limit=2"

{"resultCount":2,"results":[{"trackId":1097861834,"artistName":"Radiohead",
  "trackName":"Let Down","collectionName":"OK Computer"}, ...]}

Now feed it a keyboard mash that is not a band, an album, or a word:

# runnable, read-only
curl -s "https://itunes.apple.com/search?term=zzxqwlkjhgf&entity=song&limit=3"

{"resultCount":3,"results":[
  {"trackName":"Zzzquil Commercial","artistName":"Brave Rome Terrified"},
  {"trackName":"Waves (feat. Lil Zzzquil)","artistName":"TheNewErra"},
  {"trackName":"H0URGLASS (feat. Lil Zzzquil)","artistName":"VibezyBaby"}]}

I asked for zzxqwlkjhgf. I got HTTP 200 and resultCount: 3, three real tracks that share a few letters with my garbage. The API never returns "no match found." It fuzzy-matches, always, and reports success. So resultCount > 0 is not a signal that your query was meaningful; it is a signal that Apple found something loosely alphabetically nearby. Garbage in gives you garbage that looks found, at a confident 200. If you build autocompletion or enrichment on this, compare the returned artistName against what you searched for before you trust the match.

When to use it: quick catalog lookups and preview URLs, with a sanity check that the top result actually resembles the query. Docs: Apple iTunes Search API.

4. Deezer: the 200 that carries an error object in its body

Deezer's public API does search and lookup with no key. The useful part of a search hit is the ISRC, a real cross-catalog identifier you can carry to other services.

# runnable, read-only
curl -s "https://api.deezer.com/search?q=radiohead&limit=2"

{"data":[{"id":138546811,"title":"All I Need","isrc":"GBSTK0700005","rank":794527}, ...]}

Now look up an artist ID that cannot exist:

# runnable, read-only
curl -si "https://api.deezer.com/artist/999999999999" | head -1
curl -s "https://api.deezer.com/artist/999999999999"

HTTP/2 200
{"error":{"type":"DataException","message":"no data","code":800}}

HTTP 200, and the payload is an error. resp.raise_for_status() is delighted. The failure lives in data["error"], code 800, and nowhere in the status line. Deezer reports transport success and puts the application failure in the body, which is the exact opposite of a schema you can trust by shape alone: the success body and the error body are different objects under the same 200. Branch on whether "error" is a key, not on the HTTP code.

When to use it: getting ISRCs and preview URLs, with an explicit check for an error key before you read data. Docs: developers.deezer.com.

5. Lyrics.ovh: keyless and simple, and the flakiest host on this list

Lyrics.ovh returns plain lyrics for an artist and title. No key, no envelope, just the text.

# runnable, read-only
curl -s "https://api.lyrics.ovh/v1/Coldplay/Yellow"

{"lyrics":"Look at the stars\nlook how they shine for you\nand everything you do..."}

It answered a clean 200 for me on July 12, 2026. I am going to be blunt about its one real weakness, because pretending otherwise would waste your afternoon: this host flaps. On other days I have watched the same endpoint time out or return a 500 with no pattern I could pin down. It is the least reliable host in this roundup. If you depend on it, wrap the call in a short timeout and a fallback to another lyrics source, and do not treat a single good curl as an uptime guarantee. I did not measure its uptime and I am not going to claim one.

When to use it: a fast, no-frills lyrics lookup for a hobby project, always behind a timeout and a fallback. Docs: lyrics.ovh.

6. lrclib: time-synced lyrics, and the search that ranks a B-side first

lrclib is built for music players that need time-synced (karaoke-style) lyrics, and it is the source of the wrong song at the top of this post. Its /api/search endpoint is a fuzzy search, and you already saw what it did with "yellow coldplay": HTTP 200, twenty results, results[0] the B-side "Help Is Round the Corner." The fix is that lrclib also ships an exact-lookup endpoint, and you should almost always use that one instead.

# runnable, read-only: exact lookup by the four fields it needs
curl -s -o /dev/null -w "%{http_code}\n" \
  "https://lrclib.net/api/get?track_name=Yellow&artist_name=Coldplay&album_name=Parachutes&duration=267"

/api/get takes the track name, artist name, album name, and duration, and resolves to the specific recording instead of ranking a pile of loose matches. Same API, same 200, completely different reliability: /api/search is a guess machine you sort yourself, /api/get is a lookup. If you have the album and rough duration (from a file's tags, say), skip the search entirely.

When to use it: synced lyrics in a player, through /api/get with the track's own metadata, falling back to /api/search only when you must and then filtering the results yourself. Docs: lrclib.net/docs.

7. Radio Browser: a directory that lists dead streams at 200

Radio Browser is a community-run directory of internet radio stations. There is no single canonical host; you pick a mirror (de1., nl1., all.) and query it keyless.

# runnable, read-only: pick a mirror host
curl -s "https://de1.api.radio-browser.info/json/stations/search?name=bbc&limit=2"

[{"stationuuid":"f7fd408e-...","name":"BBC RADIO 1 - The biggest new pop...",
  "url":"http://a.files.bbci.co.uk/ms6/live/...","lastcheckok":1}, ...]

Two things bite here. First, the mirror: there is no one hostname, so hardcode one and your app dies when that mirror does; the directory publishes a server list you are meant to rotate through. Second, and this is the important one, a station in the directory is not the same as a station that is streaming right now. The lastcheckok field is the freshness flag: 1 means the last health check reached the stream, 0 means it did not. A 200 with lastcheckok: 0 is a dead stream that still shows up in your results with a full, valid record. Filter on lastcheckok before you hand a URL to a player.

When to use it: building a radio picker, rotating across mirror hosts and filtering lastcheckok: 1. Docs: api.radio-browser.info.

8. Open Opus: classical metadata that the pop APIs get wrong

Classical music is where the mainstream catalog APIs fall apart, because they model a "song" and an "artist" and classical needs a composer, a performer, a work, and a movement. Open Opus models it properly, keyless.

# runnable, read-only
curl -s "https://api.openopus.org/composer/list/search/beethoven.json"

{"status":{"success":"true","rows":1},
  "composers":[{"id":"145","complete_name":"Ludwig van Beethoven","epoch":"Early Romantic"}]}

rows: 1, one composer, a clean ID. The limitation to know up front: Open Opus is a curated set of composers, not an exhaustive index of everyone who ever wrote a string quartet. A search for an obscure name returns rows: 0 inside a 200, not an error, so check the rows count rather than assuming a hit. For the standard repertoire it is the cleanest free classical source I found.

When to use it: a classical browser or quiz where the composer coverage is the popular canon, checking status.rows before you read composers. Docs: openopus.org.

9. ListenBrainz: open listening history you can read without a token

ListenBrainz is MetaBrainz's open answer to Last.fm scrobbling: a public dataset of what people are listening to. Reading aggregate stats and public user listens needs no token.

# runnable, read-only
curl -s "https://api.listenbrainz.org/1/stats/sitewide/artists?range=week&count=2"

{"payload":{"artists":[{"artist_mbid":"0d79fe8e-...","artist_name":"BTS",
  "listen_count":819275}, ...]}}

Public user listens work the same way, keyless: GET https://api.listenbrainz.org/1/user/rob/listens?count=1 returned a real listen for me at 200. The honest split: reading public data is free and open, but submitting listens or reading a private user's data needs a token from a free account. So "keyless" is true for the read half and false for the write half; do not design a submitter and then discover the auth wall.

When to use it: charts, "top artists this week," and reading public scrobbles, with a token only if you need to write. Docs: listenbrainz.readthedocs.io.

10. AcousticBrainz: real audio features, from a dataset frozen in 2022

AcousticBrainz serves computed audio features (loudness, BPM, key, mood estimates) per recording MBID, keyless. The data is real and detailed.

# runnable, read-only
curl -s "https://acousticbrainz.org/api/v1/96685213-a25c-4678-9a13-abd9ec81cf35/low-level"

{"lowlevel":{"average_loudness":0.570070445538, ...},
  "metadata":{"audio_properties":{"length":240.509384155}, ...}}

Here is the limitation that matters more than any field in that body: the AcousticBrainz project stopped collecting data in 2022 and the dataset is frozen. The API still answers a confident 200 with genuine features, but they are a snapshot that has not moved in years, and any recording that entered MusicBrainz after the freeze returns nothing. This is a freshness trap the status code will never show you: 200 forever, data stuck in 2022. Treat it as a historical dataset, not a live service, and expect misses on anything recent.

When to use it: experiments and teaching on pre-2022 recordings, with eyes open that it is an archive. Docs and the shutdown notice: acousticbrainz.org.

11. Odesli / song.link: cross-platform links that change by country

Odesli (the API behind song.link) takes one platform URL and returns the same track's links on the others: Spotify, Apple Music, YouTube, and more, keyless.

# runnable, read-only
curl -s "https://api.song.link/v1-alpha.1/links?url=https%3A%2F%2Fopen.spotify.com%2Ftrack%2F4LRPiXqCikLlN15c3yImP7"

{"entityUniqueId":"SPOTIFY_SONG::4LRPiXqCikLlN15c3yImP7","userCountry":"KZ",
  "entitiesByUniqueId":{"...":{"title":"As It Was","artistName":"Harry Styles"}}}

Look at userCountry: "KZ". I did not send a country. Odesli defaulted it to the country of my request IP, which resolved to Kazakhstan that day. This matters because the platform links and availability are geo-dependent: the same track can map to different catalog links, or be missing on a platform, depending on the country. A 200 in one region and a 200 in another can carry different bodies for the identical URL. If your users are not sitting where your server is, pass an explicit userCountry parameter instead of letting it guess.

When to use it: "listen on your platform" buttons and cross-service matching, with userCountry set explicitly for your audience. Docs: odesli.co (see the song.link API section).

Why not on the list: one shared key and five paywalls

TheAudioDB almost made the eleven. It returns rich artist data keyless-looking:

# runnable, read-only
curl -s "https://www.theaudiodb.com/api/v1/json/2/search.php?s=coldplay"

{"artists":[{"idArtist":"111239","strArtist":"Coldplay","intFollowers":"57510550"}]}

That 2 in the path is a shared demo key, not "no key." It works today, but it is a public credential the project can rotate or rate-limit at any time, and building on a shared test key is how a tutorial rots. I left it off the eleven and I am telling you why rather than quietly padding the count.

And the names people expect that are simply not keyless in 2026: Last.fm (API key), Spotify (OAuth client credentials), Genius (access token), Jamendo (client ID), GetSongBPM (key plus a backlink requirement). Good APIs, none of them "paste a URL into a terminal" free. If a 2021 tutorial told you Spotify was easy, it was easy before the app-registration step it skipped.

Why does results[0] keep handing you the wrong song?

Because every music search is a fuzzy ranking over a namespace with no primary key, and results[0] is the top of a ranking, not the answer to a lookup. There is no unique ID for "Yellow by Coldplay." There is a studio single, a live radio session, a remaster, covers, and a B-side on the "Yellow" release, and the engine scores all of them against your string and returns the winner. A score of 100 means the string matched. It does not mean the row is the thing you meant. That gap, valid and non-empty and right-shaped and still wrong, is the whole post.

I have paid for that exact failure class in a different domain. Across 2,190 production scraper runs, 962 of them on one Trustpilot scraper, the incidents that cost real money were almost never the crashes. A 500 pages you at 3am and you fix it. The response that came back valid, non-empty, and quietly attributed to the wrong company, because two businesses shared a name, does not page anyone. It corrupts a column, and you find out weeks later when a report looks off. Music APIs are that same disease with a friendlier face. (Honest note: I have not run a music resolver across those 2,190 runs. They are a scraping-and-enrichment domain, cited only as where the read-the-value habit comes from. Do not read 2,190 as a music-API number.)

The fix is not another validation library. It is a field-sanity gate: never take results[0] on faith, and reject the top hit when the body's own metadata says it is thin or ambiguous. Here is the shape of the gate I use, in music terms, against MusicBrainz:

# runnable local: reject the top hit unless the body backs it up
import requests

UA = "your-app/1.0 (you@example.com)"   # MusicBrainz 403s a default UA

def resolve_recording(title, artist, min_score=90):
    r = requests.get(
        "https://musicbrainz.org/ws/2/recording",
        params={"query": f"{title} AND artist:{artist}", "fmt": "json", "limit": 5},
        headers={"User-Agent": UA}, timeout=15,
    )
    r.raise_for_status()                 # a 200 sails through, so keep reading
    recs = r.json().get("recordings", [])
    if not recs:
        raise ValueError(f"no match for {title!r} by {artist!r}")
    top = recs[0]
    if top.get("score", 0) < min_score:
        raise ValueError(f"low score {top.get('score')} for {title!r}")
    if top.get("disambiguation"):        # e.g. "live, 2001-06-13: KBCO Studio C..."
        raise ValueError(f"ambiguous top hit: {top['disambiguation']}")
    return top["id"]

>>> resolve_recording("Yellow", "Coldplay")
ValueError: ambiguous top hit: live, 2001-06-13: KBCO Studio C, Boulder, CO, USA

That is the real behavior against the live API on July 12, 2026. The function does not silently return the KBCO Studio C bootleg. It refuses, because the top hit carries a disambiguation string that says "live." That is the entire move: read score and disambiguation on MusicBrainz, resultCount and the returned artistName on iTunes, the error key on Deezer, lastcheckok on Radio Browser, userCountry on Odesli, the fields the tutorial's results[0].name skips right over.

There is no universal threshold. min_score = 90 is mine, for MusicBrainz, picked after watching which scores went with wrong entities; choose your own per API and write it down. And the name-collision problem is worse than one bootleg. A MusicBrainz search for artist:Nirvana returned count: 41 the day I checked: forty-one distinct artists carrying the name Nirvana. If your resolver grabs the first one, you are right about the grunge band by luck, not by logic, and luck is not a data pipeline.

FAQ

What is the best free music API with no key?
It depends on what you need, and several are keyless together. MusicBrainz is the backbone for metadata and stable IDs (send a real User-Agent). iTunes Search and Deezer are fast catalog search, and Deezer hands you ISRCs. lrclib gives time-synced lyrics. All returned HTTP 200 keyless on July 12, 2026. Pick by the job, and read each one's confidence fields before you trust results[0].

Does the MusicBrainz API require an API key?
No key, but two conditions. You must send a descriptive User-Agent header, because a default client UA gets a 403, and you must stay under about one request per second or you get rate-limited. Within those rules it is fully open and free, including the MBIDs that Cover Art Archive and AcousticBrainz key off.

Why does a music search return the wrong song at HTTP 200?
Because a search is a fuzzy ranking, not a lookup, and music has no single ID per song. For q=yellow coldplay, lrclib returned HTTP 200 with a full list whose top result was the B-side "Help Is Round the Corner," and MusicBrainz ranked a live radio bootleg of "Yellow" first with a score of 100. The status is 200 and the body is well-formed; the signal that it is the wrong entity lives in fields like score and disambiguation, not in the HTTP code.

Is there a free lyrics API without a key?
Two, keyless. lyrics.ovh returns plain lyrics but its host flaps, so wrap it in a timeout and a fallback. lrclib returns time-synced lyrics; prefer its /api/get exact lookup (track, artist, album, duration) over /api/search, because the search ranks fuzzily and can put a B-side first.

Can I get audio features like BPM and key for free?
AcousticBrainz serves loudness, BPM, key, and mood estimates keyless by MusicBrainz recording ID, and returned a clean 200 for me on July 12, 2026. The catch is freshness: the project stopped collecting data in 2022, so the dataset is frozen and any recording added after the freeze returns nothing. Treat it as a historical archive, not a live service.

How do I match one song across Spotify, Apple, and YouTube?
Odesli, the API behind song.link, takes one platform URL and returns the others keyless. One caveat: results are geo-dependent. Its userCountry defaults to your request IP's country (mine resolved to KZ), and platform availability changes by country, so pass an explicit userCountry for your audience instead of letting it guess.

Written by Aleksei Spinov. I build web-scraping and data-enrichment tool layers, currently 2,190 runs across 32 actors in production. Every endpoint above was re-verified with a live curl (real HTTP code, real body) on July 12, 2026 before publishing; responses are trimmed, never reworded. I have not run a music resolver in production; the 2,190 runs are a scraping-and-enrichment domain, cited only as the origin of the read-the-value habit. I wrote up the same read-the-body pattern for free government data APIs and free mock and fake-data APIs. Drafted with an AI assistant, then fact-checked and edited by me against the raw responses.

Follow for the next keyless layer I verify. And tell me: what is the worst wrong-entity a "successful" API has handed you, the right shape with the wrong thing inside, and how long before you caught it? I read every comment.

10 Free Facts, Jokes & Name APIs With No Key (2026)

Alex Spinov — Mon, 13 Jul 2026 09:45:45 +0000

On July 12, 2026 I asked a free API to guess the age of someone named Xzqwlptv. It answered in a few milliseconds: HTTP 200, valid JSON.

# runnable, read-only: no key needed
curl -s "https://api.agify.io?name=Xzqwlptv"

{"count":0,"name":"Xzqwlptv","age":null}      # HTTP 200 OK

Status 200. The JSON parses. The age key is present, exactly where a schema says it belongs. Its value is null. Every guard I usually reach for passes this response: if resp.ok, if "age" in data, even a JSON Schema that requires an age property. The null walks straight past all of them and into the dataset.

My earlier keyless-API posts kept circling one idea from different angles. HTTP 200 does not mean the read worked, because the body can be empty. HTTP 201 Created does not mean a write happened, because the read-back returns 404. This post moves the lie one level deeper than either of those. Here the status is 200, the body arrives, it parses, it matches your schema, and the field you came for is sitting right there. The value is just empty. The null that passes your schema check.

A free fun or facts API here means a public endpoint that returns a joke, a fact, or a guess about a name, with no API key, no signup, and no credit card. A URL you can paste into a terminal right now. Ten of them clear that bar, and I re-verified every response below with a live curl on July 12, 2026: real HTTP code, real body, trimmed but never reworded.

One scope note first, so the numbers stay honest. I curl-verified all ten APIs on July 12, 2026. I have not run any of them in production. My 2,190 production scraper runs (962 of them on a single Trustpilot scraper) are a different domain, and I cite them for one reason only: they are why I read a field's value and its confidence instead of its status line. That number is not a claim about these ten endpoints.

#	API	What it returns	Example call	The empty success to watch
1	agify.io	Age guess from a first name	`GET api.agify.io?name=Xzqwlptv`	200 with `age: null`
2	genderize.io	Gender guess + probability	`GET api.genderize.io?name=Andrea`	200 with `gender` at 0.69 confidence
3	nationalize.io	Country guesses for a name	`GET api.nationalize.io?name=Xzqwlptv`	200 with an empty `country` array
4	icanhazdadjoke	Random dad joke	`GET icanhazdadjoke.com/`	200 as HTML or JSON, your header decides
5	Advice Slip	Random advice	`GET api.adviceslip.com/advice/99999999`	200, envelope shape silently changes
6	Useless Facts	Random trivia fact	`GET uselessfacts.jsph.pl/api/v2/facts/random?language=xx`	200, asked for `xx`, got English
7	Cat Facts	Cat trivia + pagination	`GET catfact.ninja/facts?limit=99999`	200, silently clamped to 1,000
8	yesno.wtf	Random yes / no + gif	`GET yesno.wtf/api?force=yes`	200, a hidden flag decides "random"
9	Chuck Norris	Random Chuck Norris joke	`GET api.chucknorris.io/jokes/random`	None: an empty array here is normal
10	JokeAPI v2	Filtered jokes	`GET v2.jokeapi.dev/joke/Any`	None: it pairs its body flag with a real 400

Two APIs that a thousand tutorials still hardcode did not answer at all the day I checked. They get their own section after the ten.

1. agify.io: the null that passes your schema check

agify guesses a person's age from a first name, using a database of names it has seen with ages attached. It is keyless, fast, and it is the first API in a lot of "let's call an API" lessons. The happy path is clean.

# runnable, read-only
curl -s "https://api.agify.io?name=alex"

{"count":426587,"name":"alex","age":45}

Age 45, and a count of 426,587: the API saw the name "alex" attached to an age in 426,587 records. Now send it a name it has never seen, which is the transcript from the top of this post: ?name=Xzqwlptv returns HTTP 200 with {"count":0,"name":"Xzqwlptv","age":null}. The count drops to zero and age becomes null. The documentation is upfront that an unknown name yields a null age; the point is that nothing in the HTTP layer flags it. Status 200, valid JSON, age present. This guard, which I have shipped more than once, waves it through:

# toy, illustrative: this "safety" check does not protect you
r = requests.get("https://api.agify.io", params={"name": name})
d = r.json()
if r.ok and "age" in d:      # 200, and the key exists
    ages.append(d["age"])    # None goes into the list

There is a second, quieter trap in the same response, and it is the one I care about more. count is the confidence, and almost nobody reads it.

# runnable, read-only
curl -s "https://api.agify.io?name=Kwabena"

{"count":684,"name":"Kwabena","age":45}

"alex" is backed by 426,587 samples. "Kwabena" by 684. Both answered age: 45. If your code reads only the age field, a guess drawn from 684 people and a guess drawn from 426,587 look identical. One is a solid estimate. The other is a shrug wearing a number. The truthful guard reads the value and the confidence together:

# toy, illustrative: the check the field actually needs
if d.get("age") is not None and d.get("count", 0) >= 100:
    ages.append(d["age"])

When to use it: playful demos, and as the cheapest possible lesson that a present field is not an answered field. The threshold of 100 is mine, not the API's; pick your own and write it down.

2. genderize.io: the confidence field you threw away

genderize is agify's sibling from the same team: it guesses gender from a first name and, unlike agify, it labels its own uncertainty out loud.

# runnable, read-only
curl -s "https://api.genderize.io?name=alex"

{"count":1668776,"name":"alex","gender":"male","probability":0.95}

Unknown name, same empty success as agify, one field richer:

# runnable, read-only
curl -s "https://api.genderize.io?name=Xzqwlptv"

{"count":0,"name":"Xzqwlptv","gender":null,"probability":0.0}

gender: null and probability: 0.0. The API is being honest to a fault here; it hands you a machine-readable "I have no idea" and most code still checks if data["gender"]:, gets None, and moves on quietly. But the sharper case is not the null. It is the answer that is real and thin at the same time:

# runnable, read-only
curl -s "https://api.genderize.io?name=Andrea"

{"count":1681597,"name":"Andrea","gender":"female","probability":0.69}

gender: "female", backed by 1.68 million records, at a probability of 0.69. That is barely better than a coin flip, and "Andrea" is male in Italy and female in much of the English-speaking world, which is exactly why the number is low. Your if gender: passes on 0.69 the same way it passes on 0.95. The API did its job: it put the doubt in the payload. Reading it is on you.

# toy, illustrative
if d.get("gender") and d.get("probability", 0) >= 0.90:
    genders[name] = d["gender"]

When to use it: rough demographic guesses where you will honor the probability. Contrast it with agify in your head: agify buries its confidence in a count, genderize spells it out as a probability, and both get ignored the same way.

3. nationalize.io: the empty array at HTTP 200

nationalize, third in the same family, guesses which country a name comes from and returns a ranked list of candidates.

# runnable, read-only
curl -s "https://api.nationalize.io?name=alex"

{"count":1673580,"name":"alex","country":[
  {"country_id":"US","probability":0.095754},
  {"country_id":"GB","probability":0.071241},
  {"country_id":"ES","probability":0.052449}]}

Note the top probability is 0.096. Even on a common name, the single best country guess is under 10 percent, which tells you how to weigh this data before you build anything on it. Now the unknown name:

# runnable, read-only
curl -s "https://api.nationalize.io?name=Xzqwlptv"

{"count":0,"name":"Xzqwlptv","country":[]}

An empty array. Not null, not an error, an empty list under a 200. This is the third form of "I don't know" from three sibling APIs on the same request: agify says null, genderize says null plus 0.0, nationalize says []. The failure mode is specific to the shape. This line looks defensive and is not:

top = r.json()["country"][0]["country_id"]   # IndexError on a 200

data["country"] exists, so a key check passes. The list is empty, so indexing into it throws, on a response your status check already blessed. There is no single "is this empty" test that covers null, 0.0, and []; you write one per shape, per API. That is the whole lesson of this trio.

When to use it: guessing likely origin for a name, always past a guard that treats an empty country list as "no answer" rather than crashing on it.

4. icanhazdadjoke: the same URL, HTML or JSON, your header decides

icanhazdadjoke serves random dad jokes and it does something the previous three do not: it hands back a completely different body for the identical URL, depending on one request header.

# runnable, read-only: no Accept header
curl -s "https://icanhazdadjoke.com/"

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    ...

That is HTTP 200 with Content-Type: text/html, a full web page, not a joke you can parse. Call resp.json() on it and you get a decode error on a response your code just classified as a success. Add one header and the same URL turns into JSON:

# runnable, read-only
curl -s -H "Accept: application/json" "https://icanhazdadjoke.com/"

{"id":"NCQfqHYgaFd","joke":"I'm glad I know sign language, it's pretty handy.","status":200}

Same path, same 200, HTML or JSON purely by what you put in Accept. Forget the header and your parser chokes on a healthy response. There is a bonus tell in that JSON: "status":200, the HTTP code copied down into the body. It is the same habit I documented in the pop-culture APIs post, where Open Trivia DB tucks a response_code inside the envelope. When an API repeats its status inside the payload, that is usually a hint that the payload is where the truth lives, not the status line.

When to use it: any joke feature, with Accept: application/json sent explicitly and never assumed by default.

5. Advice Slip: the envelope that changes shape at 200

Advice Slip returns one piece of advice per call. The happy path is a tidy wrapper.

# runnable, read-only
curl -s "https://api.adviceslip.com/advice"

{"slip":{"id":154,"advice":"State the problem in words as clearly as possible."}}

You reach for data["slip"]["advice"] and move on. Then someone requests an id that does not exist:

# runnable, read-only
curl -s "https://api.adviceslip.com/advice/99999999"

{"message":{"type":"error","text":"Advice slip not found."}}

Still HTTP 200. Still application/json. But the top-level key is no longer slip, it is message, and the shape underneath is different too. data["slip"] throws a KeyError on a response that reported success. This is schema drift inside a single endpoint: the envelope silently swaps from {"slip": ...} to {"message": ...} based on whether the lookup hit, and the status code stays 200 through the switch. Your parser has to branch on which key is present, not on the HTTP code.

When to use it: a random advice string for filler content, with a check for the slip key before you read into it, because the miss path returns a valid 200 with a different structure.

6. Useless Facts: you asked for language xx, you got English

Useless Facts serves a random trivia fact with a source attached. It also takes a language parameter, and that parameter is where it gets quietly generous.

# runnable, read-only
curl -s "https://uselessfacts.jsph.pl/api/v2/facts/random"

{"id":"b939f633...","text":"Until 1994, world maps and globes sold in Albania only had Albania on them.",
 "source":"djtech.net","language":"en","permalink":"https://uselessfacts.jsph.pl/api/v2/facts/b939f633..."}

Now ask for a language that does not exist:

# runnable, read-only
curl -s "https://uselessfacts.jsph.pl/api/v2/facts/random?language=xx"

{"id":"7e69818f...","text":"On a Canadian two dollar bill, the flag flying over the Parliament buildings is an American flag.",
 "source":"djtech.net","language":"en","permalink":"..."}

I asked for language xx. I got HTTP 200 and an English fact. No error, no warning, no 400. The only evidence that my request was ignored is the language: "en" field in the response, which happens to disagree with what I sent. This is a silent fallback: the API decided that giving me something plausible beat telling me my input was wrong. If you localize content off a parameter like this and never compare the echoed language back to the one you sent, you will ship English into a French page and every request will report success.

When to use it: a random fact for a footer or a loading screen, with a check that the returned language matches what you requested if you care about the language at all.

7. Cat Facts: ask for 99,999, silently get 1,000

Cat Facts is exactly what it sounds like, plus a paginated /facts endpoint with a limit parameter. The single-fact call is clean.

# runnable, read-only
curl -s "https://catfact.ninja/fact"

{"fact":"Unlike humans, cats are usually lefties. Studies indicate that their left paw is typically their dominant paw.","length":110}

Now abuse the pagination. Ask for far more than can exist:

# runnable, read-only
curl -s "https://catfact.ninja/facts?limit=99999"

{"current_page":1,"per_page":1000,"total":332,"last_page":1,
 "data":[ ... 332 facts ... ]}

I requested limit=99999. The response reports per_page: 1000. The server clamped my limit to its own maximum of 1,000 and did it silently, HTTP 200, no field named "you asked for too much." Here the total is only 332 so I got everything anyway, but the clamp is the behavior that matters, and it is the same silent clamp I hit on Random User Generator in an earlier keyless-API post: you ask for N, the server caps at M, and your "full export" is a fraction of what you think. The tell is the per_page field in the response, which reports what actually happened rather than what you asked for.

When to use it: cat trivia, obviously, and as a cheap reminder to compare the per_page and total a paginator returns against the limit you sent, every time.

8. yesno.wtf: the flag that decides whether "random" was random

yesno.wtf answers a yes-or-no question at random and returns a matching gif. It is the simplest API on this list, and it still has a field that changes the meaning of the response.

# runnable, read-only
curl -s "https://yesno.wtf/api"

{"answer":"yes","forced":false,"image":"https://yesno.wtf/assets/yes/11-a23cbde4....gif"}

answer: "yes", forced: false. The forced field says this answer was genuinely random. But the endpoint accepts a ?force= parameter, and when you use it the answer stops being random while the status stays 200:

# runnable, read-only
curl -s "https://yesno.wtf/api?force=yes"

{"answer":"yes","forced":true,"image":"https://yesno.wtf/assets/yes/9-6403270c....gif"}

Same 200, same answer: "yes", but forced: true. If your code reads only answer, a real coin flip and a rigged one are indistinguishable. The single field that tells them apart, forced, is the one nobody bothers to read. It is a toy version of a real problem: a boolean deep in the payload that changes what the main value means, sitting quietly next to it at the same successful status.

When to use it: a fun random decision, and a two-line demonstration for a junior of why you read the flags in a body, not just the headline field.

9. Chuck Norris: when an empty array is the correct answer

The last two APIs on this list get it right, and they are here because "right" is worth seeing next to all of the above. api.chucknorris.io serves random Chuck Norris jokes.

# runnable, read-only
curl -s "https://api.chucknorris.io/jokes/random"

{"categories":[],"id":"SPv79G_bQWuEBMXyCMHynA",
 "value":"Chuck Norris is the only person on earth who can rhyme 'orange' with 'lozenge'.",
 "url":"https://api.chucknorris.io/jokes/random"}

Look at categories: []. An empty array, exactly the shape that meant "no answer" over on nationalize. Here it means the opposite: the joke simply has no category assigned, which is a perfectly normal state, and the value field is fully populated. Same JSON shape, opposite meaning, and the only way to know is to read each API's contract. There is no universal rule that an empty array signals failure. Then request a category that does not exist:

# runnable, read-only
curl -s "https://api.chucknorris.io/jokes/random?category=notreal"

{"timestamp":"2026-07-11T21:39:17.715Z","status":404,"error":"Not Found","path":"/jokes/random"}

An actual HTTP 404, with a clean error object. When the request cannot be served, Chuck Norris says so with the right status code instead of a 200 and an empty body. That is the good-citizen behavior the first eight entries kept failing at.

When to use it: random jokes with categories, and as the contrast case that teaches [] is ambiguous across APIs and honest 404s still exist.

10. JokeAPI v2: the body flag paired with the right status

JokeAPI serves jokes with filters (categories, safe-mode, blacklists). Its normal response carries a status flag right in the body, which is the pattern that usually precedes a lie on this list.

# runnable, read-only
curl -s "https://v2.jokeapi.dev/joke/Any?safe-mode"

{"error":false,"category":"Pun","type":"single",
 "joke":"I was struggling to figure out how lightning works, but then it struck me.",
 "flags":{"nsfw":false,"religious":false,"...":"..."},"id":219,"safe":true,"lang":"en"}

error: false, embedded in the payload. On this list, a status field inside the body has been a warning sign. So I forced a failure, blacklisting every category so nothing could match:

# runnable, read-only
curl -s "https://v2.jokeapi.dev/joke/Any?blacklistFlags=nsfw,religious,political,racist,sexist,explicit&contains=zzzzxxxqqq"

{"error":true,"internalError":false,"code":106,
 "message":"No matching joke found",
 "causedBy":["No jokes were found that match your provided filter(s)."]}

Here is the part I did not expect until I ran it: that response came back HTTP 400, not 200. JokeAPI puts error: true in the body and sets a 4xx status. Both channels agree. That is how the body-flag pattern is supposed to work, and it is why JokeAPI is the counterexample rather than another entry in the "200 lies" column. The analysis I started from guessed this endpoint returned a 200 with error: true; my own curl on July 12 said 400, so the text you are reading follows the curl, not the guess.

When to use it: filtered jokes when you want categories and safe-mode, and as proof that an in-body status flag is fine as long as the HTTP code is telling the same story.

Two that stopped answering at all

The dead teach the lesson louder. Both checks below are from July 12, 2026.

Quotable (api.quotable.io/random) was the default free quotes API in an enormous number of tutorials. It did not answer: connection failed, no HTTP status at all, on repeated tries.

curl -si "https://api.quotable.io/random"
# -> curl: (couldn't connect), no HTTP status

Bored API (boredapi.com/api/activity), the "suggest me something to do" API from a thousand beginner projects, did the same: no response, no status code.

I make a narrow claim here: on the day and hour I checked, from where I checked, both were unreachable. That is enough to matter, because "keyless" and "alive" are properties you re-verify, not facts you remember. A tutorial written in 2022 against Quotable produces a dead link today, and the reader gets no HTTP status to even diagnose it.

Two honesty notes on the flaky ones, because pretending my checks are the last word would be its own kind of lie. ZenQuotes (zenquotes.io/api/random) returned nothing when the analysis for this post was drafted, then answered me a clean 200 with a normal quote on July 12; it flaps, so I left it off the ten and I am not repeating the rate-limit gotcha I could not reproduce. Official Joke API (official-joke-api.appspot.com/random_joke) was reported dead in an earlier scan and answered me a healthy 200; a single curl from one machine is a snapshot, not an uptime measurement, and I did not measure uptime for anything here.

Why does a green schema check prove so little?

Here is the uncomfortable part, and the reason this is not a listicle. Every trap above survives the three checks most code actually runs. The status is 200, so resp.raise_for_status() is happy. The body is valid JSON, so resp.json() succeeds. The field you wanted is present, so a schema validator passes. And the value is still null, or [], or a guess at 0.69 confidence, or an English fact you did not ask for. Line these up and they are not novelties, they are named classes of production drift:

A null scalar at 200 (agify). Your real backend returns null for absent optional fields all the time. If your pipeline treats "field present" as "value present," it seeds nulls and reports success.
A confidence field nobody reads (agify's count, genderize's probability). Real ML and enrichment APIs attach confidence to every guess. Dropping it turns a 0.69 coin flip into a fact in your database.
An empty array at 200 (nationalize). Production search and recommendation endpoints return [] for "no results" constantly, and results[0] throws on a response that reported success.
An envelope that changes shape (Advice Slip). Real APIs return one shape on hit and another on miss under the same 200. Branch on the HTTP code and you read the wrong key.
A silent fallback or clamp (Useless Facts, Cat Facts). You ask for language xx or limit=99999; the server substitutes a default and reports success, and your export is quietly wrong.

A schema check that passes against one of these has proven one thing: the response has the right shape. Whether it has an answer is a separate question, and the status line will not answer it for you. The fix is not more validation libraries. It is a guard that reads the value and its confidence, not just the field's presence. Against the flagship:

# runnable local: a present field is not an answered field
import requests

def guess_age(name, min_count=100):
    r = requests.get("https://api.agify.io", params={"name": name}, timeout=15)
    r.raise_for_status()               # 200 sails through
    d = r.json()                       # valid JSON, "age" key present
    age, count = d.get("age"), d.get("count", 0)
    if age is None or count < min_count:
        raise ValueError(
            f"no usable age for {name!r}: age={age}, count={count}"
        )
    return age

print(guess_age("alex"))       # -> 45   (count 426,587)
print(guess_age("Xzqwlptv"))   # -> ValueError: no usable age for 'Xzqwlptv': age=None, count=0

45
Traceback (most recent call last):
  ...
ValueError: no usable age for 'Xzqwlptv': age=None, count=0

That is the live behavior from July 12, 2026 (traceback trimmed). raise_for_status() is satisfied, the JSON parses, the age key exists, and the extra two-line check catches the null and the zero-confidence case that all three earlier guards missed. The same skeleton covers the siblings: for genderize, gate on probability; for nationalize, treat an empty country list as "no answer" before you index into it.

For context, not a claim of scale: I build web-scraping and data-enrichment tool layers, currently 2,190 runs across 32 actors in production, and the read-the-value habit comes from there. The expensive incidents were never the 500s. A 500 pages you at 3am and you fix it. The quiet 200 with a null where a value should be does not page anyone; it just corrupts a column, and you find out weeks later when a report looks wrong. These toy APIs are the cheapest lab I know for that exact failure, because you can reproduce it in one curl. I wrote the same pattern up for pop-culture APIs and government data APIs; the fun ones turned out to teach it best, because a joke API has nothing to hide behind.

FAQ

Is agify free without an API key?
Yes. GET https://api.agify.io?name=alex works with no key, no signup, and no card, and returned HTTP 200 with {"count":426587,"name":"alex","age":45} on July 12, 2026. There is a free daily request limit for anonymous use and paid tiers above it, but casual and learning use needs no credentials. The same holds for its siblings genderize.io and nationalize.io.

Why does agify return null for a name?
Because agify guesses age from names it has seen with ages attached, and an unfamiliar name has no data behind it. For ?name=Xzqwlptv it returns HTTP 200 with {"count":0,"name":"Xzqwlptv","age":null}: count is how many records backed the guess, and when it is 0 the age is null. The status is still 200 and the age key is still present, so a schema check passes and the null enters your data unless you test the value.

What do count and probability mean in genderize and agify?
They are the confidence behind the guess. In agify, count is the number of records the age estimate is based on; "alex" returned count: 426587, a rare name might return count: 684, and both can show the same age. In genderize, probability is how sure the gender guess is: "alex" came back at 0.95, "Andrea" at 0.69. A non-null answer at 0.69 is barely better than a coin flip, so gate on the confidence, not just on the field being present.

Why does icanhazdadjoke return HTML instead of JSON?
Because it uses content negotiation. The same URL, https://icanhazdadjoke.com/, returns a full HTML page under the default Accept header and returns JSON only when you send Accept: application/json. Both are HTTP 200. If you call resp.json() without setting that header, it fails on a successful response. Send the header explicitly.

What happened to the Quotable and Bored APIs?
Both were unreachable when I checked on July 12, 2026: api.quotable.io/random and boredapi.com/api/activity returned no HTTP response at all on repeated tries from my machine. They were default APIs in years of tutorials, which means a lot of copy-pasted code now points at dead endpoints. That is a snapshot from one place and time, not an uptime claim, but it is why "keyless" is a property to re-verify rather than remember.

What is a good free joke or facts API with no key?
For jokes, icanhazdadjoke (send Accept: application/json), api.chucknorris.io, and v2.jokeapi.dev all worked keyless on July 12, 2026, and JokeAPI pairs its body error flag with a correct HTTP status. For facts, uselessfacts.jsph.pl and catfact.ninja both returned clean JSON. For name guesses, the agify / genderize / nationalize trio is the most useful, as long as you read the confidence fields rather than just the answer.

Written by Aleksei Spinov. I build web-scraping and data-enrichment tool layers, currently 2,190 runs across 32 actors in production. Every endpoint above was re-verified with a live curl (real HTTP code, real body) on July 12, 2026 before publishing; responses are trimmed, never paraphrased. I have not run these fun and facts APIs in production; the 2,190 runs are a different domain, cited only as the origin of the read-the-value habit. Drafted with an AI assistant, then fact-checked and edited by me against the raw responses.

Follow for the next keyless layer I verify. And tell me: what is the worst silent null or empty array you have had a "successful" API hand you, and how long did it take to notice? I read every comment.

9 Free Mock & Fake-Data APIs With No Key (2026)

Alex Spinov — Sun, 12 Jul 2026 09:37:09 +0000

On July 10, 2026 I sent JSONPlaceholder a POST. It answered 201 Created and handed me the new resource's id. Then I asked it for that resource.

# runnable, harmless: nothing is saved
curl -si -X POST https://jsonplaceholder.typicode.com/posts \
  -H "Content-Type: application/json" -d '{"title":"hello"}'

HTTP/2 201
{
  "title": "hello",
  "id": 101
}

curl -si https://jsonplaceholder.typicode.com/posts/101

HTTP/2 404
{}

201 Created, id 101. Then a 404 for id 101, four seconds later. The API refuted its own receipt. Nothing was ever written, and the docs are upfront about that; it is a mock. But your HTTP client cannot tell the difference, and neither can a test suite that stops reading at the status line.

My earlier keyless-API posts kept hitting one lesson on the read path: HTTP 200 does not mean the read worked. The body can be empty, the entity can be wrong, the error can hide in a JSON field. Mock APIs move that lesson to the write path. A 201 Created is the server's claim that a write happened, not proof that it did. The only proof of a write is a read.

A free mock or fake-data API here means a public endpoint that returns test data (fake users, fake products, or an echo of your own request) with no API key, no signup, and no credit card. A real URL you can paste into a terminal right now. Nine services clear that bar, and I re-verified every endpoint below with a live curl on July 10, 2026: real HTTP code, real body, trimmed but never paraphrased.

One scope note before the list, so the numbers stay honest. I curl-verified every API here on July 10, 2026; I have not run these mock APIs in production. My 2,190 production scraper runs (962 of them on a single Trustpilot scraper) are a different domain, and I cite them for exactly one reason: they are why I read bodies instead of status lines. That number is not a claim about these nine endpoints.

#	API	What it fakes	Example call	The lie to watch
1	JSONPlaceholder	Blog-style REST (posts, users, todos)	`POST jsonplaceholder.typicode.com/posts`	201 Created, nothing created
2	DummyJSON	Products, carts, users, quotes	`DELETE dummyjson.com/products/1`	"Deleted" with a timestamp, still there
3	Fake Store API	E-commerce catalog	`GET fakestoreapi.com/products/999`	200 with a zero-byte body
4	Random User Generator	Fake user profiles	`GET randomuser.me/api/?results=5001`	Asks for 5,001, returns 1, no error
5	httpbin	Echo + any status code on demand	`GET httpbin.org/status/404`	None: you order the failures
6	httpbingo	httpbin rewritten in Go	`GET httpbingo.org/get`	Same path, different JSON types
7	Postman Echo	Echo of your request	`GET postman-echo.com/get`	A third envelope shape
8	Platzi Fake Store	E-commerce with real CRUD	`GET api.escuelajs.co/api/v1/products/1`	400 (not 404) for missing, shared DB
9	Beeceptor Echo	Echo of your request	`GET echo.free.beeceptor.com/probe`	A fourth envelope shape

One famous name is missing on purpose. reqres.in, the default fake API in years of tutorials, now answers with a 401 key wall. It gets its own section after the nine, along with three services that stopped answering at all.

1. JSONPlaceholder: the 201 Created that created nothing

JSONPlaceholder is the most famous fake REST API on the internet: 100 posts, 10 users, comments, todos, all keyless. It is the first API in half the frontend tutorials ever written. The read path is spotless.

# runnable, read-only
curl "https://jsonplaceholder.typicode.com/posts/1"

{"userId": 1, "id": 1,
 "title": "sunt aut facere repellat provident occaecati excepturi optio reprehenderit",
 "body": "quia et suscipit\nsuscipit recusandae consequuntur expedita et cum..."}

The write path is the transcript at the top of this post. Every POST /posts answers 201 with id: 101, because the collection ships with 100 posts and your new one is never stored. The guide says it plainly: the resource "will not be really updated on the server but it will be faked as if."

The miss contract has its own trap. Ask for a post that does not exist:

curl -si "https://jsonplaceholder.typicode.com/posts/9999"
# -> HTTP 404, content-type: application/json, body: {}   (2 bytes)

An empty object, not an error message. Code that does resp.json().get("error") gets None and stays silent. The 404 itself is honest; the body tells you nothing about why.

When to use it: frontend prototypes and HTTP lessons, with the write path treated as theater. It is deterministic theater, which is exactly what you want for a demo.

2. DummyJSON: deleted at 23:52:01.722Z, still in stock

DummyJSON serves a richer fake world: 100+ products with reviews and stock levels, plus users, carts, and quotes. The catalog detail is genuinely good.

# runnable, read-only
curl "https://dummyjson.com/products/1"

{"id":1,"title":"Essence Mascara Lash Princess","category":"beauty",
 "price":9.99,"discountPercentage":10.48,"rating":2.56,"stock":99}

Now delete that product. The response is my favorite artifact in this whole list:

# runnable, harmless: nothing is actually deleted
curl -sX DELETE "https://dummyjson.com/products/1"
# -> HTTP 200, full product plus:
#    "isDeleted": true, "deletedOn": "2026-07-10T23:52:01.722Z"

A deletion confirmation with a millisecond timestamp. Fetch /products/1 again and it is right back, HTTP 200, stock 99. The delete never happened; the API just generated paperwork that says it did. POST /products/add plays the same game and answered me 201 with {"id":195,"title":"probe-47"}.

Credit where due: the miss contract is the most honest of the three fake stores here. GET /products/9999 returns HTTP 404 with {"message":"Product with id '9999' not found"}. Machine-readable, status and body in agreement. Docs at dummyjson.com/docs.

When to use it: the best-stocked fake catalog for UI work, and a teaching example of why a "deleted" confirmation means nothing until a read confirms it.

3. Fake Store API: HTTP 200 with a zero-byte body

Fake Store API is the standard fake e-commerce backend in React and Vue shop tutorials: 20 products, carts, users.

# runnable, read-only
curl "https://fakestoreapi.com/products/1"

{"id":1,"title":"Fjallraven - Foldsack No. 1 Backpack, Fits 15 Laptops",
 "price":109.95,"category":"men's clothing","rating":{"rate":3.9,"count":120}}

Ask for a product that does not exist and you get the sharpest read-path lie in this post:

curl -si "https://fakestoreapi.com/products/999"
# -> HTTP 200, content-type: application/json, body: 0 bytes

Zero bytes. Not null, not {}, not an error object. The status says success and the declared content type says JSON, so resp.json() throws on a response your code just classified as fine, and if resp.ok: waves the emptiness straight into your pipeline. Writes are fake here too: my POST /products with "price": 1.0 came back 201 as {"id":21,"title":"probe-47","price":1}. Note the price: 1.0 went in, 1 came out. On paper that is the same JSON number, but json.loads now hands your test an int where you posted a float. Small, but if you round-trip money values through a mock like this, your assertions compare against a type you never sent. DELETE /products/1 returns 200 plus the full "deleted" product, which is still there. Docs at fakestoreapi.com/docs.

When to use it: quick shop UIs, with a guard that treats 200 + empty body as a failure, because this API will produce exactly that.

4. Random User Generator: ask for 5,001 users, get 1, no warning

Random User Generator fabricates user profiles (names, addresses, avatars) for seeding databases and UI lists. Clean, fast, keyless.

# runnable, read-only
curl "https://randomuser.me/api/?results=1&inc=name,email&noinfo"

{"results":[{"name":{"title":"Mr","first":"Vitaliano","last":"Lima"},
             "email":"vitaliano.lima@example.com"}]}

The documentation caps results at 5,000 per request. Cross that line and watch what happens:

curl "https://randomuser.me/api/?results=5001&inc=name&noinfo"
# -> HTTP 200, len(results) == 1

I asked for 5,001 records and received one. Not 5,000, the documented maximum. One. No error field, no warning, HTTP 200. Send garbage (?results=abc) and you also get HTTP 200 with one result. The parameter validation is forgiving, which in practice means it lies: whatever you ask for, something plausible comes back.

The guard is one line and it is the whole lesson:

assert len(body["results"]) == requested, \
    f"asked for {requested}, got {len(body['results'])}"

A seeding script without that line writes 1 row where it meant to write 5,001 and reports success.

When to use it: seeding users for demos and load tests, always counting what came back against what you asked for.

5. httpbin: the API where you order the failure yourself

httpbin flips the premise of this whole list. The other APIs fake data; httpbin reflects your own request back so you can test the client you wrote.

# runnable, read-only
curl "https://httpbin.org/get?probe=47"

{"args": {"probe": "47"},
 "headers": {"Accept": "*/*", "Host": "httpbin.org", "...": "..."},
 "origin": "85.198.89.58",
 "url": "https://httpbin.org/get?probe=47"}

Note args.probe is the string "47". Hold that thought for the next section.

The killer feature is /status/{code}: GET https://httpbin.org/status/404 returns an actual HTTP 404 (empty body) because you asked for one. After eight sections of APIs failing in ways nobody asked for, here is the one place you can order the failure on purpose and check that your retry logic, your error taxonomy, and your alerting actually fire. Most error-handling code I have read was never once executed before production. This is the free fix for that.

The caveat is reliability. httpbin is a long-running community service, it has a reputation for slow spells under load, and there is no SLA behind it. It answered all my probes on July 10, 2026; I would still not put it inside a CI job I care about without a timeout. Self-hosting it is one docker run away, per its homepage.

When to use it: exercising your client's error path deliberately, which almost nobody does until an outage does it for them.

6. httpbingo: the same request, different types

httpbingo is a Go reimplementation of httpbin, hosted on Fly.io, and it exists because of the previous paragraph: people wanted a faster, steadier httpbin. Same paths, same idea.

# runnable, read-only
curl "https://httpbingo.org/get?probe=47"

{"args": {"probe": ["47"]},
 "headers": {"Accept": ["*/*"], "Host": ["httpbingo.org"], "...": "..."},
 "method": "GET",
 "url": "https://httpbingo.org/get?probe=47"}

Same /get, same query. httpbin answered "probe": "47", a string. httpbingo answers "probe": ["47"], an array, and every header value is an array too. A client written against httpbin that does data["args"]["probe"].upper() explodes on httpbingo with an AttributeError, on a perfectly healthy HTTP 200.

This is schema drift between two services that describe themselves as the same tool. Not an edge case, the default response shape. If "just point it at the mirror" ever sounded safe, this pair is the two-curl proof it is not. Docs at httpbingo.org.

When to use it: the steadier echo for regular use, as long as your parser was written for httpbingo and not merely pointed at it.

7. Postman Echo: three echo services, three envelopes

Postman Echo is Postman's own echo service, the backend for their tutorials. Corporate hosting, been around for years.

# runnable, read-only
curl "https://postman-echo.com/get?probe=47"

{"args":{"probe":"47"},
 "headers":{"host":"postman-echo.com","accept":"*/*","...":"..."},
 "url":"https://postman-echo.com/get?probe=47"}

Line up all three echoes I probed on July 10 and the point makes itself:

httpbin: args values are strings, header keys are Title-Case ("Accept"), and there is an origin field with your IP.
httpbingo: args and header values are all arrays.
Postman Echo: args values are strings again, but header keys are lower-case ("accept") and there is no origin field at all.

None of this violates a spec, by the way. HTTP header names are case-insensitive on the wire, so each echo renders them into JSON however it likes. The spec does not care about the casing. Your parser does.

Three services, one job, three different JSON envelopes for the identical request. Anyone who has moved between "compatible" providers in production has met this exact failure, except there it costs a weekend. Here it costs two curls, which is why I would show a junior this trio before any architecture diagram. Docs at learning.postman.com/docs/developer/echo-api.

When to use it: a stable echo with corporate hosting behind it, and the third data point that "drop-in replacement" is a myth even in mock infrastructure.

8. Platzi Fake Store: real CRUD in a database everyone shares

Platzi Fake Store API is the opposite bet from JSONPlaceholder: writes are real. POST actually inserts into a database, with pagination and filters on top. The catch is that it is one database, shared by every stranger on the internet, and it shows immediately.

# runnable, read-only
curl "https://api.escuelajs.co/api/v1/products?offset=0&limit=1"

[{"id":12,"title":"New Product 12","slug":"new-product-12","price":100500,
  "description":"A description 12","category":{"id":1,"name":"Updated Category Name"},
  "images":["https://placehold.co/600x400"]}]

That is real production data from July 10, 2026: a product named "New Product 12" priced at 100,500, in a category someone renamed to "Updated Category Name". Now ask for product 1:

curl -si "https://api.escuelajs.co/api/v1/products/1"
# -> HTTP 400 (not 404!)
# {"path":"/api/v1/products/1","timestamp":"2026-07-10T23:53:05.903Z",
#  "name":"EntityNotFoundError",
#  "message":"Could not find any entity of type \"Product\" matching: {...\"id\": 1...}"}

Two lessons in one response. First, not-found arrives as 400 Bad Request, not 404, with a raw ORM error name and the query dump in message. Your error handling, if it branches on 404 for missing entities, takes the wrong branch here. Second, why is product 1 missing at all? I cannot prove who did it, but the writes are real and the state is shared, so the safe assumption is that another user deleted it. The tutorial code you wrote on Monday fails on Tuesday when a stranger deletes "your" product.

Put this next to JSONPlaceholder and you get the actual trade-off of mock backends: fake writes are deterministic but lie to you; real writes in a shared sandbox tell the truth and then someone else edits it. Pick your poison consciously. Docs at fakeapi.platzi.com.

When to use it: practicing real CRUD flows and pagination, in tests that assume nothing about existing ids, because those assumptions rot within days here.

9. Beeceptor Echo: the fourth envelope shape

Beeceptor's free echo endpoint requires nothing: no key, no account. (Their actual product, a configurable mock server, sits behind a signup, so only the echo endpoint counts for this list.)

# runnable, read-only
curl "https://echo.free.beeceptor.com/probe?x=47"

{"method": "GET", "protocol": "https", "host": "echo.free.beeceptor.com",
 "path": "/probe?x=47",
 "headers": {"Host": "echo.free.beeceptor.com", "Accept": "*/*", "...": "..."},
 "parsedQueryParams": {"x": "47"}}

Envelope number four. Here path includes the query string as one raw lump ("/probe?x=47"), the parsed parameters live in their own parsedQueryParams object, and header keys keep their original case. Four echo services in this list, four incompatible answers to the same question: what request did I just send you? The free tier is rate limited; I did not push hard enough to measure the ceiling, so I will not quote one. Details at beeceptor.com.

When to use it: a quick request inspector when httpbin is slow, coded against its own envelope like every other entry here.

The one that grew a key wall: reqres.in

For years, reqres.in was the answer to "what fake API do I hit in tutorials?". Thousands of blog posts and course exercises hardcode it. Here is what those exercises get today:

curl -si "https://reqres.in/api/users/2"
# -> HTTP 401
# {"error":"missing_api_key",
#  "message":"The x-api-key header is required for this endpoint.",
#  "hint":"Create a free key at app.reqres.in and send it as x-api-key."}

The key is free and takes a minute to get, so this is a speed bump rather than a paywall. But copy-paste the code from any of those tutorials today and you get a 401 out of the box, and most of them will never be updated. That is why reqres is not one of my nine: "keyless" is a property you re-verify, not a fact you remember. I checked every entry above on July 10, 2026, and I would re-check them before trusting this post a year from now.

Three that stopped answering at all

The dead teach the same lesson louder. All three checks below are from July 10, 2026.

httpstat.us was the beloved "give me any status code" service, the same job as httpbin.org/status/{code}. It was on my shortlist for this post right up until the curl:

curl -si "https://httpstat.us/200"
# -> curl: (52) Empty reply from server

Three tries, both HTTP and HTTPS. The service whose one purpose was returning status codes now returns no status code at all, not even an error. If it comes back tomorrow, the point stands: it was gone the day I checked, and test suites all over GitHub still reference it.

FakerAPI (fakerapi.it) answered HTTP 502 from its own nginx on both probes that evening. I only have two probes a few minutes apart, so I make no claim about how long it has been down; on the day I checked, it was.

Random Data API (random-data-api.com) did not answer at all: connection timeout after 12 seconds, twice.

Two near-misses for completeness: mockapi.io gives you endpoints only per project, behind a signup, so there is no public URL to verify. Mockaroo requires an API key by design; I did not probe it and make no claim about its responses.

Why does a green test against a mock prove so little?

Here is the uncomfortable part, and the reason this list is not just trivia. Mock APIs are the only APIs that lie honestly: the fake write is documented behavior, not a bug. Yet every mismatch cataloged above is a real class of drift between mock and production:

201 without a write (JSONPlaceholder). Your real backend returns 201 after an actual insert. The mock returns 201 after nothing. A test asserting status == 201 passes identically against both.
200 with an empty body (Fake Store API). Production APIs produce this shape too, during partial outages and bad deploys. If your parser never met it in testing, it meets it at 3am.
A silent clamp (Random User). Production pagination does this constantly: you ask for 500, the server caps at 100, and your "full export" is 20% of the data.
400 where you expected 404 (Platzi). Error taxonomies differ per backend. Branch on the wrong code and your retry logic retries a request that can never succeed.
Envelope drift between lookalikes (httpbin vs httpbingo vs Postman Echo vs Beeceptor). The same drift that hits when you switch payment providers, geocoders, or LLM vendors that are "API-compatible".

A test suite that is green against a mock has proven one thing: your code can talk to the mock. The integration with the real backend is exactly as untested as it was before. The fix is not to abandon mocks; it is to stop letting the status line close the loop. A write is confirmed by a read, not by a receipt. In code, against the flagship liar:

# runnable local -- a write is not done until a read confirms it
import requests

BASE = "https://jsonplaceholder.typicode.com"

def create_post(payload):
    r = requests.post(f"{BASE}/posts", json=payload, timeout=15)
    r.raise_for_status()              # 201 sails through this line
    created = r.json()
    new_id = created.get("id")

    # read back what the API claims it just created
    check = requests.get(f"{BASE}/posts/{new_id}", timeout=15)
    if check.status_code != 200:
        raise RuntimeError(
            f"API said {r.status_code} Created (id={new_id}) "
            f"but read-back returned {check.status_code}"
        )
    return created

create_post({"title": "hello"})

Traceback (most recent call last):
  ...
RuntimeError: API said 201 Created (id=101) but read-back returned 404

That is the live output from July 10, 2026 (traceback trimmed), not a mock-up of a mock. raise_for_status() is satisfied, the JSON parses, the id looks plausible, and the read-back catches the lie in one extra request. Against DummyJSON the same skeleton catches the fake delete (read back after DELETE, expect a 404, get a 200). Against Fake Store API, add a len(r.content) > 0 check before parsing, because that is the one that hands you zero bytes under a 200.

For context, not a claim of scale: I build web-scraping and data-enrichment tool layers, currently 2,190 runs across 32 actors in production, and the read-back habit comes from there, where the expensive incidents were never the 500s. The 500s page you. The quiet 200s and 201s with wrong bodies just corrupt your data. I have written the same pattern for food and nutrition APIs and pop-culture APIs; the mock world turned out to be the purest lab for it, because here the lying is the documented feature.

FAQ

Is JSONPlaceholder completely free?
Yes. No key, no signup, no card, and no request cap published for normal use. Reads are real JSON; writes (POST, PUT, DELETE) are simulated. The response pretends the operation succeeded, returns 201 with a plausible id, and stores nothing. The official guide states the resource "will not be really updated on the server but it will be faked as if."

Why does JSONPlaceholder return id 101 but not save my post?
The posts collection ships with exactly 100 items, and the API answers every create with the next id, 101, without persisting anything. That is by design: it gives frontend code a realistic 201 response to render. The proof is one request away: GET /posts/101 returns 404 immediately after the 201.

What happened to reqres.in?
It put its endpoints behind an API key. As of July 10, 2026, GET https://reqres.in/api/users/2 returns HTTP 401 with "error":"missing_api_key" and a hint to create a free key at app.reqres.in. The key costs nothing, but every older tutorial that hardcodes reqres without a key now fails out of the box.

What is the best free alternative to reqres.in?
For keyless fake CRUD, JSONPlaceholder (deterministic, writes simulated) and DummyJSON (richer data, writes simulated, honest 404s on misses) are the closest matches. If you specifically need writes that persist, Platzi Fake Store API inserts into a real shared database, with the caveat that other users mutate the same data under you.

Does Fake Store API actually save data?
No. POST /products returns 201 with a new id (21 on my July 10, 2026 probe) but nothing is stored, and DELETE /products/1 returns 200 with the "deleted" product that remains available. Watch its miss contract too: a request for a nonexistent product returns HTTP 200 with a completely empty body, zero bytes, which breaks resp.json() on a response that reports success.

What is the difference between httpbin and httpbingo?
httpbingo is a Go rewrite of httpbin hosted on Fly.io, generally steadier than the original. The response schema differs: httpbin returns query args and headers as plain strings, httpbingo wraps every value in an array ("probe": "47" vs "probe": ["47"]). Code written for one breaks on the other despite identical paths, so pin one and parse its exact shape.

Written by Aleksei Spinov. I build web-scraping and data-enrichment tool layers, currently 2,190 runs across 32 actors in production. Every endpoint above was re-verified with a live curl (real HTTP code, real body) on July 10, 2026 before publishing; responses are trimmed, never paraphrased. I have not run these mock APIs in production; the 2,190 runs are a different domain, cited only as the origin of the read-back habit. Drafted with an AI assistant, then fact-checked and edited by me against the raw responses.

Follow for the next keyless layer I verify. And tell me: which mock burned you when the real backend arrived, and what did your green tests miss? I read every comment.

DEV Community: Alex Spinov

A Check You've Never Seen Go Red Isn't a Check — 6 Ways Mine Lied

Why a green answer can be structurally empty

The part I got wrong while writing this

Six ways a check lies about the world

The defect runs both ways

Green by coincidence is not verification

The check on the check needs one too

A 103-line runner that makes a check prove itself

What I did not measure

And one thing I did measure, a day late

The question I actually have

Crash Recovery Is One Ordered Read, Not 24 Lookups

Three posts I already wrote, and why this is a fourth one

The pacing gate is also a recovery guarantee

What I did instead: one question per intent, to a copy of the world from before breakfast

The counterfactual is embarrassing, so here it is

One read of your own writes answers all of them

Where my own rule breaks: the newest row is not the mark

Why asking again is cheap and writing again is not

The admission rule: freshness first, existence second

The demo

The third bucket, and how I actually found it

Verifying a new write is a subtraction

What I did not measure

The one I do not have a rule for

The DEV API Said My New Post Didn't Exist. It Was 15 Hours Stale.

The setup

What I assumed, and why I was wrong

One header

Why that one route and not the other three

The dangerous part is not the wrong answer

The fix

The thing I keep thinking about

GitHub API Rate Limits: an Unauthenticated 304 Still Costs You a Request

The post I meant to write

Does a 304 count against the GitHub rate limit? What the docs actually say

The probe, and the three controls that had to be able to kill it

The idle control, and the header that beats it

Three weeks later, and something else in the bucket

What the same six requests answered on the way past

The arithmetic that kills a poller

The header that was in every response the whole time

Ask the meter instead of catching the exception

Why I did not drain the bucket

Honest limits

The open question

13 Keyless Job APIs: A Broken limit Returns 200 Rows, or 0

The one idea

The whole proof, with the controls that had to fail first

What the provider itself publishes

Why: the value is parsed, not validated

The same site, the other endpoint, no defect at all

Lever: the same root, the opposite blast radius

It composes with offset, and then it is not a curiosity

Who actually says "that is not a number"?

The thirteen, checked live

How this is different from three things I already wrote

What an agent does with 1.2 MB it did not ask for

The fix, and which check actually catches both

Honest limits

The open question

9 Keyless Health APIs: You Asked for v1, You Got v8

The one idea

The whole proof, and the controls that had to fail

How often does a label actually get rewritten?

The nine endpoints, checked live

The same provider, two endpoints, two different truths

This is not the latest problem, and the usual fix does not apply

The fix, and why my usual advice about upsert is wrong here

Honest limits

The open question

10 Keyless Statistics APIs: Never Delete the World Row

The one idea

First, the probes that had to fail

The 10 keyless endpoints, checked live

The World Bank arithmetic, in full

Why 1.9971x is worse than 10.72x

The field you would reach for, and three ways it goes wrong

Who does label the level

It composes with `offset`, and then it is not a curiosity

This is not the `latest` problem, and the usual fix does not apply

6. SMK: Denmark's national gallery, and a `found` that counts loosely

10. SatNOGS DB: the open satellite catalog with an honest `updated` field