DEV Community: Alex Spinov

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.

8 Free Pop-Culture APIs With No Key (2026)

Alex Spinov — Sat, 11 Jul 2026 03:42:56 +0000

On July 10, 2026 I asked Open Trivia DB for fifty hard true/false questions from one category. It answered HTTP 200. My parser saw the green status, reached for results, and got an empty list. Nothing threw. Nothing logged. The failure was sitting in a field that if response.ok: never reads.

Open Trivia DB, the volunteer-run trivia bank in half the quiz tutorials on the web, puts the real outcome in a response_code field inside the JSON body. On that over-ask it returned {"response_code":1,"results":[]}. Ask for an invalid amount=0 and it returns {"response_code":2,"results":[]}. Both are HTTP 200. The transport says OK while the body says the request never worked.

That is the whole post. Finding a free pop-culture API is the easy ten percent. The hard part: most of them hand you a clean 200 and something subtly wrong, and each one does it in a different way.

A free pop-culture API here means a public entertainment-data endpoint (trivia, TV, anime, games, films, cards) that answers with no API key, no signup, and no card. Not a paid vendor tier. Not a trial that expires. Not a portal that wants your email before it returns a byte. A real REST call you can paste into a terminal right now. I found eight that clear that bar and re-verified each with a live curl on July 10, 2026: real HTTP code, real body, trimmed but never paraphrased. If you are building a Discord bot, a portfolio project, a demo, or teaching yourself HTTP, these are the endpoints you reach for. Every one of them can hand you a 200 that lies.

Here is the pattern before the list. These are eight separate community projects, not one service wearing eight hats. A volunteer runs Open Trivia DB. TVMaze is its own company. Jikan is an unofficial proxy sitting in front of MyAnimeList. PokeAPI, Rick and Morty, SWAPI, and Studio Ghibli are each their own open-source project. Deck of Cards keeps server-side deck state. Eight projects means eight response shapes and eight ways to fail on a 200. What they share is not code. It is a habit: the status line says OK while the truth lives in the body.

Let me be straight about scope, because this is where roundups usually stretch. I have not run these pop-culture APIs in production. My numbers come from a different domain, 2,190 scraper runs including 962 on a single Trustpilot scraper, and I cite them for exactly one lesson those runs drilled into me: parse the payload, do not trust the status code. Every trimmed body below is from a live curl on July 10, 2026, not from operating these services at scale. Where a keyless window looks shaky, I flag it instead of selling it.

Here is the full set at a glance.

#	API	What it answers	Example call	No key?
1	Open Trivia DB	Trivia questions by category	`GET opentdb.com/api.php?amount=1`	Yes
2	TVMaze	TV show metadata and schedules	`GET api.tvmaze.com/search/shows?q=...`	Yes
3	Jikan	MyAnimeList anime and manga data	`GET api.jikan.moe/v4/anime?q=...`	Yes
4	PokeAPI	Pokémon universe data	`GET pokeapi.co/api/v2/pokemon/...`	Yes
5	Rick and Morty	Characters, locations, episodes	`GET rickandmortyapi.com/api/character/...`	Yes
6	SWAPI	Star Wars people, films, ships	`GET swapi.tech/api/people/...`	Yes
7	Studio Ghibli	Ghibli film metadata	`GET ghibliapi.vercel.app/films`	Yes
8	Deck of Cards	Server-side shuffle and draw	`GET deckofcardsapi.com/api/deck/new/draw/`	Yes

Two more names people search for, TMDB and OMDb, look keyless and are not. They get an honest section near the end.

Trivia: the status line is a receipt, not a promise

1. Open Trivia DB: the 200 that lies in `response_code`

Open Trivia DB is a volunteer-maintained bank of trivia questions across categories like Entertainment, Science, and History. It shows up in a huge number of beginner quiz apps because the shape is simple and the data is fun. That simplicity hides the sharpest trap on this list.

# runnable, read-only
curl "https://opentdb.com/api.php?amount=1&type=multiple"

{"response_code":0,
 "results":[{"category":"General Knowledge",
   "question":"Foie gras is a French delicacy typically made from what part of a duck or goose?",
   "correct_answer":"Liver",
   "incorrect_answers":["Heart","Stomach","Intestines"]}]}

The field that matters is response_code, and 0 means success. Now break it two ways. Both come back HTTP 200.

curl "https://opentdb.com/api.php?amount=50&category=32&difficulty=hard&type=boolean"
# -> {"response_code":1,"results":[]}   asked for more than the pool holds
curl "https://opentdb.com/api.php?amount=0"
# -> {"response_code":2,"results":[]}   invalid parameter

The documented codes are 0 ok, 1 no results, 2 bad parameter, 3/4 token errors, 5 rate limited. Every one lives in the body, none in the HTTP status. And there is a second layer I reproduced by firing three requests back to back: Open Trivia DB rate-limits to about one request every five seconds per IP, and on the throttle it returns {"response_code":5,"result":[]} with HTTP 429. Look closely at that body. The field renamed itself from results to result, singular. So a client that does data["results"] throws a KeyError on the exact path where it is already under load. Docs at opentdb.com/api_config.php.

When to use it: quiz apps and trivia prototypes, checking response_code == 0 before you touch results.

TV and anime: fuzzy search and a proxy in the middle

2. TVMaze: two endpoints on one host, two miss contracts

TVMaze serves TV show metadata: air dates, network, status, and cross-IDs to IMDb and TVDB. Keyless, clean JSON, genuinely pleasant to work with.

# runnable, read-only
curl "https://api.tvmaze.com/search/shows?q=girls"

[{"score":0.89859617,
  "show":{"id":139,"name":"Girls","type":"Scripted","status":"Ended",
    "network":{"name":"HBO"},
    "externals":{"imdb":"tt1723816"}}}]

The score field is your first warning: /search/shows is fuzzy and relevance-ranked, so results[0] is the best guess, not necessarily the show you meant. A total miss returns HTTP 200 with an empty array []. Fine so far. The trap is the sibling endpoint. /singlesearch/shows?q=zzzznotarealshow99 returns HTTP 404 with the body null. Same host, two different miss contracts: one endpoint answers a miss with 200 + [], the other with 404 + null. Code written against one blows up on the other. I confirmed both today. TVMaze is keyless with a documented per-IP rate limit, so stay polite in a loop. Docs at tvmaze.com/api.

When to use it: TV metadata and schedules, reading score and handling both the 200 + [] and 404 + null miss shapes.

3. Jikan: the pagination field you cannot ignore

Jikan is an unofficial REST proxy in front of MyAnimeList, serving anime and manga metadata. Unofficial matters here, and it shows up in the failure mode.

# runnable, read-only
curl "https://api.jikan.moe/v4/anime?q=naruto&limit=1"

{"pagination":{"last_visible_page":30,"has_next_page":true,
   "items":{"count":1,"total":30,"per_page":1}},
 "data":[{"mal_id":20,"url":"https://myanimelist.net/anime/20/Naruto"}]}

Two things bite. First, Jikan is a proxy: when MyAnimeList itself is slow or down, Jikan returns 5xx errors you did not cause, and it enforces its own per-IP rate limit with a 429 under load (quiet in a solo test, painful in a loop). Second, look at pagination.has_next_page: true and last_visible_page: 30. Ignore those and you silently keep page 1 of a 30-page result and never notice the other 29. The success case is honest JSON. The way you lose data is by not reading the pagination it hands you. Docs at docs.api.jikan.moe.

When to use it: anime and manga metadata, honoring has_next_page and adding backoff for the proxy's 429.

Fictional universes: same idea, three different failure shapes

4. PokeAPI: the content-type flips on the error path

PokeAPI is the canonical "first API" people learn on: the entire Pokémon universe as linked JSON. The happy path is spotless, which makes the miss path more surprising.

# runnable, read-only
curl "https://pokeapi.co/api/v2/pokemon/ditto"

{"abilities":[{"ability":{"name":"limber"},"is_hidden":false},
              {"ability":{"name":"imposter"},"is_hidden":true}],
 "base_experience":101, "...":"..."}

Now ask for a Pokémon that does not exist:

curl "https://pokeapi.co/api/v2/pokemon/notarealmon"
# -> HTTP 404, body: Not Found   (content-type: text/plain; charset=utf-8, 9 bytes)

The success response is application/json. The miss response is text/plain, nine bytes of Not Found, not JSON at all. So resp.json() on the error path throws a JSONDecodeError, and the content type quietly switched under you between the hit and the miss. PokeAPI is keyless and asks you to cache aggressively because the data is effectively static. Docs at pokeapi.co/docs/v2.

When to use it: teaching HTTP or building a Pokédex demo, asserting the content type before you parse.

5. Rick and Morty: what a consistent error contract looks like

This one is on the list to teach by contrast. Rick and Morty serves characters, locations, and episodes, and it is a favorite first API for good reason.

# runnable, read-only
curl "https://rickandmortyapi.com/api/character/1"

{"id":1,"name":"Rick Sanchez","status":"Alive","species":"Human",
 "origin":{"name":"Earth (C-137)"},
 "location":{"name":"Citadel of Ricks"}}

Ask for a character that does not exist:

curl "https://rickandmortyapi.com/api/character/9999"
# -> HTTP 404, body: {"error":"Character not found"}   (application/json)

The status code and the body agree. The error is machine-readable JSON with a clear message. That is what a consistent contract looks like, and it is rare enough that it is worth seeing next to the others. Hold this beside PokeAPI, which answers a 404 with text/plain, and Open Trivia DB, which answers a broken request with 200 and hides the code in the body. Same failure, three different levels of honesty. Docs at rickandmortyapi.com/documentation.

When to use it: a genuinely pleasant first API, and the reference example of a clean REST error contract.

6. SWAPI: one name, two hosts, two incompatible envelopes

SWAPI is the Star Wars API: people, films, planets, ships. The catch is that there are two live SWAPIs, and they do not agree on the shape of a response.

# runnable, read-only
curl "https://www.swapi.tech/api/people/1"
curl "https://swapi.dev/api/people/1/"

// swapi.tech
{"message":"ok","result":{"properties":{
   "name":"Luke Skywalker","height":"172","mass":"77",
   "created":"2026-07-09T23:57:35.805Z",
   "edited":"2026-07-09T23:57:35.805Z"}}}

// swapi.dev
{"name":"Luke Skywalker","height":"172","mass":"77",
 "homeworld":"https://swapi.dev/api/planets/1/"}

swapi.dev returns the object flat, so data["name"] works. swapi.tech wraps the same data in {"message":"ok","result":{"properties":{...}}}, so on that host the same access throws a KeyError. One "SWAPI," two envelopes, and a client written for one silently fails on the other. There is a smaller tell hiding in the swapi.tech body. I pulled people/1 and people/2 and both carried the identical created timestamp, 2026-07-09T23:57:35.805Z, down to the millisecond. That is a generation artifact, not the day Luke Skywalker's record changed, so do not read it as provenance. Both hosts are keyless; swapi.dev has had uptime wobble over the years, and swapi.tech is the more actively maintained fork. Docs at swapi.tech/documentation and swapi.dev/documentation.

When to use it: Star Wars data, but pin one host and code to that host's exact envelope.

Films and cards: fragile hosting and a happy-looking failure

7. Studio Ghibli: keyless is not the same as always up

The Studio Ghibli API serves metadata for the films: titles, original titles, descriptions, running time.

# runnable, read-only
curl "https://ghibliapi.vercel.app/films?limit=1"

[{"id":"2baf70d1-42bb-4437-b551-e5fed5a87abe",
  "title":"Castle in the Sky",
  "original_title":"天空の城ラピュタ",
  "original_title_romanised":"Tenkū no shiro Rapyuta"}]

The data is a clean 200. The risk is the hosting. This is a community-run project living on vercel.app after it migrated off Heroku when the free dynos shut down in 2022. There is no SLA. A cold serverless function can time out, and the vercel.app in the URL is itself a signal that the provider can move or disappear, the same way SWAPI drifted from a .dev host to a .tech fork. It answered me today. I would still put a timeout and a fallback around it. Docs at ghibliapi.vercel.app.

When to use it: a small, fun film dataset for a demo, wrapped in a timeout for the cold-start miss.

8. Deck of Cards: HTTP 200 with `success: false`

Deck of Cards is a tutorial classic: it holds a real shuffled deck server-side and lets you draw from it by deck_id. It also carries the second-cleanest 200-lie on this list.

# runnable, read-only
curl "https://deckofcardsapi.com/api/deck/new/draw/?count=2"

{"success":true,"deck_id":"jlj13d81p517",
 "cards":[{"code":"7S","value":"7","suit":"SPADES"},
          {"code":"JS","value":"JACK","suit":"SPADES"}],
 "remaining":50}

Now ask a fresh 52-card deck to draw 400 cards:

curl "https://deckofcardsapi.com/api/deck/new/draw/?count=400"
# -> HTTP 200, body: {"success": false, "deck_id":"...", "cards":[ ...52 cards... ]}

HTTP 200, and success: false. The operation could not do what you asked and the status line is perfectly happy about it. Then point it at a deck that does not exist:

curl "https://deckofcardsapi.com/api/deck/notarealdeck/draw/?count=2"
# -> HTTP 404, body: {"success": false, "error":"Deck ID does not exist."}

Same success: false field, different HTTP code (404 this time). One API returns two different status codes for two failures, so the only field you can trust across both is success in the body. Deck of Cards is keyless with no signup; the server tracks deck state by deck_id. Docs at deckofcardsapi.com.

When to use it: card games and shuffle-and-draw demos, branching on success, never on the HTTP code.

The two that look keyless and are not (TMDB, OMDb)

Two names dominate "free movie API" searches, and neither is truly keyless. Both hand out a free key without a card, so they are a natural upgrade once the eight above run thin on films. Naming them keeps this honest.

TMDB (The Movie Database) issues a free key by registration, no card. The keyless probe is instructive:

curl "https://api.themoviedb.org/3/movie/550"
# -> HTTP 401, body: {"status_code":7,"status_message":"Invalid API key: You must be granted a valid key.","success":false}

TMDB also drops success:false into the body, same pattern as Deck of Cards, except here the HTTP status is an honest 401. It is the default for movie and TV data, and the free key is a two-minute signup.

OMDb issues a free key by email, 1,000 requests per day on the free tier.

curl "https://www.omdbapi.com/?t=inception"
# -> HTTP 401, body: {"Response":"False","Error":"No API key provided."}

Simple IMDb-style movie metadata. Both are worth the signup when you need real film coverage, which the keyless eight do not give you.

The catch: keyless is not the same as trustworthy

"No key" tells you nothing about whether the thing is reliable, unlimited, or even alive. Four caveats, each from something above.

Keyless is a snapshot, not a warranty. NumbersAPI was the legendary free number-facts API in a thousand tutorials. Today, July 10, 2026, http://numbersapi.com/42 returns a <!doctype html> ... <title>404 Not Found</title> page instead of the plain-text fact its docs still promise. It quietly died while the documentation says it works. Nobody sent a key wall; the service just stopped. "Free and no key" said nothing about "still running next year."

Keyless is not unlimited. Open Trivia DB caps you near one request every five seconds and returns a 429 with response_code:5. Jikan throttles its proxy per IP. A demo that works fine when you run it once will 429 the moment you put it in a loop.

Community hosts have no SLA. Studio Ghibli runs on vercel.app. SWAPI split from .dev to a .tech fork. The host in the URL is often the clearest hint of how fragile the provider is.

The status line is a transport receipt. Open Trivia DB (200 with response_code), Deck of Cards (200 with success:false), TVMaze (404 + null versus 200 + []), PokeAPI (text/plain on a 404). Four different ways a request can fail while HTTP looks fine or inconsistent. The body is the source of truth.

Parse the body, not the status line

Finding the endpoint is ten percent of the work. Here is the ninety percent, pulled straight from the failures above.

Assert on a body field, not the HTTP code. Open Trivia DB's response_code, Deck of Cards' success, TVMaze's empty array are all wrapped in a 200. The real outcome is a field in the JSON.

Check the content-type before you parse. PokeAPI hands you text/plain on a 404. A blind resp.json() throws, or a lazy try/except swallows it and you index nothing.

Treat the top fuzzy hit as a candidate. TVMaze's score and Jikan's search rank by relevance. results[0] is a guess, not confirmation you found the right show.

Pin one host and one envelope. SWAPI proves a single "API" can ship two incompatible shapes. Code to the exact host you tested against.

Respect the rate limit and the pagination. One request every five seconds on Open Trivia DB, a 429 on Jikan, has_next_page you have to follow. Keyless is not unlimited, and page 1 is not the whole result.

Here is a guard that folds those checks into one function for Open Trivia DB, and the same skeleton drops onto the others by swapping the base URL and the body field.

# runnable local -- trust the body field, not just the status code
import requests

def opentdb_questions(amount=1, **params):
    r = requests.get(
        "https://opentdb.com/api.php",
        params={"amount": amount, **params},
        headers={"User-Agent": "my-quiz-app/1.0"},
        timeout=15,
    )
    r.raise_for_status()                       # honest 4xx/5xx (like the 429), not a 200 with a bad body
    if "application/json" not in r.headers.get("content-type", ""):
        raise ValueError("expected JSON")      # PokeAPI-style text/plain stops here
    body = r.json()
    code = body.get("response_code")           # THE field an HTTP 200 hides
    if code != 0:                              # 1=no results, 2=bad param, 5=rate limited
        raise ValueError(f"OpenTDB response_code={code}")
    return body["results"]

print(len(opentdb_questions(amount=1, type="multiple")))  # -> 1
print(opentdb_questions(amount=0))                         # -> ValueError: response_code=2, not a silent []

raise_for_status catches the honest 429. The content-type line catches PokeAPI's text/plain. The response_code check catches the 200 that lies. Swap the base URL and the field and the same shape guards Deck of Cards (success), TVMaze (empty array), and even Rick and Morty (which is already honest, so the guard mostly agrees with the status code).

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 output is always a table of rows that need trustworthy enrichment columns. Nutrition was one keyless column. Scholarly metadata was another. Pop-culture data is the fun one, but it fails the same way every enrichment source does: a clean 200 that is empty, the wrong entity, or not even the content type you expected.

FAQ

Are pop-culture APIs really free with no key?
Yes. Open Trivia DB, TVMaze, Jikan, PokeAPI, Rick and Morty, SWAPI, Studio Ghibli, and Deck of Cards all return data with no API key and no signup. For films specifically, TMDB and OMDb look keyless but require a free key (no card), so they are labeled honestly rather than counted in the eight.

Why does Open Trivia DB return an empty result with HTTP 200?
Because it reports success in a response_code field in the JSON body, not in the HTTP status. 0 means success, 1 means no results for that query, 2 means a bad parameter, and 5 means rate limited. All of them come back HTTP 200 (except the 429 on rate limit), so a client checking only response.ok reads an empty results as success. Check response_code == 0 first.

What is a free API for movies and TV without a key?
For TV shows, TVMaze is fully keyless and returns air dates, networks, and cross-IDs to IMDb. For anime, Jikan (a MyAnimeList proxy) is keyless. For films, the honest answer is that TMDB and OMDb both need a free key, though no credit card, so they are a one-signup upgrade rather than truly keyless.

Why does PokeAPI throw a JSON error on a missing Pokémon?
Because the miss path is not JSON. A successful lookup returns application/json, but GET /pokemon/notarealmon returns HTTP 404 with the body Not Found as text/plain. Calling resp.json() on that throws a JSONDecodeError. Assert the content type is JSON before you parse, and handle the 404 separately.

Do these free APIs have rate limits?
Yes, keyless is not unlimited. Open Trivia DB caps you near one request every five seconds and returns HTTP 429 with response_code:5 (and quietly renames results to result on that error). Jikan enforces its own per-IP limit. TVMaze documents a per-IP rate limit too. For steady load, send a real User-Agent and add backoff.

Which free API is best for learning to call an API?
PokeAPI and Rick and Morty are the friendliest to start with: clean JSON, good docs, and no key. Rick and Morty in particular has a consistent error contract (a 404 returns machine-readable JSON), which makes it a good example of how a REST API should behave, right up until you meet one that answers a broken request with a happy 200.

Written by Aleksei Spinov. I build web-scraping and data-enrichment tool layers, currently 2,190 runs across 32 actors in production. Every API above was re-verified with a live curl (real HTTP code, real body) on July 10, 2026 before publishing; responses are trimmed, not paraphrased. I have not run these pop-culture APIs in production; the 2,190 runs are a different domain, cited only for the parse-the-body pattern. Drafted with an AI assistant, then fact-checked and edited by me against the raw responses.

Follow for the next keyless API layer I test. And tell me: which free pop-culture or entertainment API should I add to this list, and has one ever handed you a clean 200 with an empty or wrong body? I read every comment.

8 Free Research Paper APIs With No Key (2026)

Alex Spinov — Fri, 10 Jul 2026 03:33:18 +0000

On July 9, 2026 I asked arXiv for one paper about large language models. It answered HTTP 200. My parser took the response, found nothing useful, and moved on without raising a thing. The body was not corrupt. It just was not JSON.

arXiv, the preprint server that carries most of the modern machine-learning literature, replies in Atom XML: <?xml version="1.0"?><feed>.... Run json.loads() on that and you get a JSONDecodeError, or, if the call sits inside a lazy try/except, you get nothing and the code shrugs. Ten seconds of trusting the status line and an empty result goes straight into your index as if the paper never existed.

That is the whole post. Finding a free research-paper API is the easy ten percent. The hard part: each one returns a clean 200 and something subtly wrong, and it does it a different way on almost every endpoint.

A free research-paper API here means a public scholarly-metadata endpoint (papers, DOIs, citations, open-access PDFs) that answers with no API key, no signup, and no card. Not a bulk data dump, not a partner agreement, not a portal that wants your institutional login. A real REST call you can paste into a terminal right now. I found eight that clear that bar. I re-verified each one with a live curl on July 9, 2026: real HTTP code, real body, trimmed but never paraphrased. If you build a RAG index over papers, a citation tool, or an agent that reads the literature, these are the lookups you reach for. Every one of them can hand you a 200 that lies.

Here is the finding before the list. This is not one engine wearing eight hats, which is what most keyless roundups turn out to be. These are eight separate organizations: Cornell runs arXiv, two nonprofit DOI registrars run Crossref and DataCite, OurResearch runs OpenAlex and Unpaywall, CERN runs Zenodo, and DOAJ and OpenCitations are their own nonprofits. That spread is the trap. Eight orgs means eight response shapes: Atom XML, a JSON:API bracket dialect, a bare array with no envelope, a Solr error body wearing a 200. You cannot write one parser and aim it at all of them. What they share is not code. It is a single failure mode: a 200 that is empty, fuzzy, or the wrong entity, almost never an honest 500.

Let me be straight about scope, because this is where roundups usually stretch. Full disclosure: I have not run these scholarly APIs in production. My numbers come from a different domain (2,190 scraper runs, including 962 on a single Trustpilot scraper), and I cite them for exactly one lesson those runs beat into me: parse the payload, do not trust the status code. Every trimmed body below is from a live curl on July 9, 2026, not from operating these services at scale. Where a keyless window looks shaky, I flag it instead of selling it.

Here is the full set at a glance.

#	API	What it answers	Example call	No key?
1	arXiv	Preprint search (physics, CS, math)	`GET export.arxiv.org/api/query?search_query=...`	Yes
2	Crossref	DOI metadata for journal articles, books	`GET api.crossref.org/works?query=...`	Yes
3	OpenAlex	Works, authors, institutions graph	`GET api.openalex.org/works?search=...`	Yes
4	DataCite	DOIs for datasets, software, preprints	`GET api.datacite.org/dois?query=...`	Yes
5	Unpaywall	DOI to legal open-access PDF	`GET api.unpaywall.org/v2/<doi>?email=...`	Yes*
6	DOAJ	Articles in open-access journals	`GET doaj.org/api/v3/search/articles/...`	Yes
7	OpenCitations	Citation graph by DOI	`GET opencitations.net/index/api/v2/references/doi:...`	Yes
8	Zenodo	CERN research-output repository	`GET zenodo.org/api/records?q=...`	Yes

*Unpaywall needs an email= parameter in the query. It is not a secret key, but it is not optional either: drop it and you get a 422, not a 200. Three more names people search for (Semantic Scholar, CORE, and HAL) look keyless and are not, and they get an honest section near the end.

Full-text search, where fuzzy is the real trap

The first three are the ones you reach for to find a paper by words. All three share the same quiet lie: the count looks like a hit, and the top row may not be your paper.

1. arXiv: a 200 that is not even JSON

arXiv is the preprint server for physics, math, computer science, and most of the ML field. Its API takes a search_query and returns results as Atom XML, not JSON. That single fact is the most common way people break an arXiv integration.

# runnable, read-only
curl "https://export.arxiv.org/api/query?search_query=all:large+language+models&max_results=1"

<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
  <title>ArXiv Query: search_query=all:large language models</title>
  <opensearch:totalResults>...</opensearch:totalResults>
  <entry><title>...</title> ... </entry>
</feed>

HTTP 200, content-type: application/atom+xml. There is no JSON mode. Parse it with feedparser or an XML library, not json.loads. The miss case is quieter still: search for something that matches nothing and arXiv returns another 200 with an empty <feed> and <opensearch:totalResults>0</opensearch:totalResults>. No entries, no error. The signal that you found something is totalResults, not the HTTP code. One small transport trap: http://export.arxiv.org answers 301 to the https:// host, so start with https or your first request is a redirect you have to follow. Docs at info.arxiv.org/help/api.

When to use it: preprint discovery in physics, CS, and math, once your client speaks Atom XML and reads totalResults.

2. Crossref: the count says millions, the top hit may not be yours

Crossref is the nonprofit DOI registrar behind a large share of the world's journal articles and books. Its REST API is keyless and returns clean JSON.

# runnable, read-only
curl "https://api.crossref.org/works?query=large+language+models&rows=1"

{"status":"ok",
 "message":{"total-results":3142373,
   "items":[{"publisher":"The MIT Press", ... }]}}

total-results reads 3,142,373 for that query on July 9, 2026, a live counter that ticks up while you read this, so treat the exact digits as a snapshot. It looks like Crossref nailed your paper. It did not necessarily. query= is a fuzzy full-text match ranked by relevance, and items[0] is the best guess, not your specific work. If you paste in a title and grab the first item, you can silently attach the wrong DOI to a citation. Resolve the exact paper by DOI, or by matching precise fields and the returned score, not by trusting position zero. A query that matches nothing returns a normal 200 with total-results: 0 and items: [], again not an error. (An empty query= does the opposite: it matches the whole ~184M-work corpus, so "typed nothing" and "found nothing" are not the same call.)

There is a second, invisible cost. Crossref runs a polite pool and an anonymous pool. Send a mailto (in the query, or a descriptive User-Agent) and you land in the polite pool with more stable service. Skip it and you sit in the anonymous pool that gets throttled first when the service is busy. This is the same lesson MusicBrainz once taught me with a hard 403 on a missing User-Agent: identifying yourself is not politeness, it is data hygiene. Docs at api.crossref.org/swagger-ui.

When to use it: DOI and bibliographic metadata for published literature, with a mailto and exact-match resolution instead of a blind items[0].

3. OpenAlex: pagination that caps at 10,000 (with a loud 400)

OpenAlex, from the nonprofit OurResearch, is the open replacement for Microsoft Academic Graph: works, authors, institutions, and venues, all linked. Keyless JSON, and it honors a polite pool via mailto too.

# runnable, read-only
curl "https://api.openalex.org/works?search=large+language+models&per-page=1&mailto=you@example.com"

{"meta":{"count":3780168,"page":1,"per_page":1, ... },
 "results":[ ... ]}

count is 3,780,168 for that search on July 9. Here is the trap that bites at scale: classic page= pagination is capped at 10,000 records. Ask for page 201 at 50 per page and you get an HTTP 400 with Maximum results size of 10,000 records is exceeded. Cursor pagination is required. Credit where it is due, that is an honest error, not a lying 200, the one spot on this list where the API fails loudly instead of quietly. To walk a full result set you switch to cursor pagination (cursor=*, then follow meta.next_cursor). The search parameter is full-text and fuzzy, same caveat as Crossref: the top result is a candidate, not a confirmed match. And, again, no mailto means the anonymous pool and rougher throttling. Docs at docs.openalex.org.

When to use it: building a citation or author graph, with cursor pagination and a mailto, not page= past 10k.

Datasets, open-access PDFs, and OA journals

The next three narrow from "find any paper" to specific jobs: a dataset DOI, a free PDF, a vetted open-access article. The trap shifts from fuzzy matching to coverage: an empty result means "we do not index this," not "it does not exist."

4. DataCite: the bracket parameter that breaks your URL builder

DataCite is the other big nonprofit DOI registrar. Its DOIs point at datasets, software, and preprints rather than journal articles. Keyless JSON, JSON:API style.

# runnable, read-only (note the encoded brackets)
curl "https://api.datacite.org/dois?query=climate&page%5Bsize%5D=1"

{"data":[{"id":"10.5281/zenodo.21271391","type":"dois", ... }]}

The result is fine. Getting there is the trap. DataCite uses JSON:API bracket parameters like page[size], and a raw [ in a URL breaks naive builders. curl itself refuses it with curl: (3) bad range in URL position .... You have to URL-encode the brackets as %5B%5D, so page[size]=1 becomes page%5Bsize%5D=1. Skip that and your request never leaves the client, or your HTTP library mangles it. On a miss the response is a plain 200 with data: [], which brings up the coverage point that runs through this whole middle section: an empty data array means DataCite has not indexed it, not that the thing does not exist. Docs at support.datacite.org.

When to use it: finding DOIs for datasets and software, with the bracket params URL-encoded.

5. Unpaywall: a 200 with `best_oa_location: null` is not a free PDF

Unpaywall (also OurResearch) does one job: given a DOI, it tells you whether a legal open-access copy exists and where. It is keyless, but it requires an email parameter.

# runnable, read-only -- swap in YOUR real email; example.com is rejected with a 422
curl "https://api.unpaywall.org/v2/10.1038/nature12373?email=you@example.com"

{"best_oa_location":{"host_type":"repository",
   "url":"https://arxiv.org/pdf/1304.106..."},
 "is_oa":true, ... }

Two traps. First, the email is not optional: drop it and you get a 422, not a 200, and a throwaway like example.com is rejected with a 422 too, so it has to be a real address. This is "keyless" only in the sense that the email is not a secret. Second, and quieter: a paywalled article returns a perfectly valid 200 with "best_oa_location": null. The request succeeded; there is simply no free PDF. Code that does resp.json()["best_oa_location"]["url"] throws a TypeError on null, on a 200. Check is_oa and the null before you dereference. One honest note: Unpaywall is now in maintenance, and OurResearch steers new integrations to OpenAlex, which absorbed its open-access data. It still answers today; I would not build something new solely on it. Docs at unpaywall.org/products/api.

When to use it: turning a DOI into an open-access PDF link, with a null guard and OpenAlex as the longer-term home.

6. DOAJ: `total: 0` means "not in an OA journal we index," not "no such paper"

DOAJ, the Directory of Open Access Journals, indexes articles, but only from journals it has vetted as fully open access. Keyless v3 JSON API.

# runnable, read-only
curl "https://doaj.org/api/v3/search/articles/machine%20learning?pageSize=1"

{"total":189602,"page":1,
 "results":[{"bibjson":{"identifier":[
   {"id":"10.46481/...","type":"doi"}, ... ]}}]}

total is 189,602 for that query on July 9, a live count that drifts run to run, so read the exact number as a July 9 snapshot. The trap is the shape of the corpus, not the response. DOAJ covers only declared open-access journals, so a total: 0 is a coverage gap, not proof the paper does not exist. The paper may sit in a hybrid or closed journal DOAJ deliberately does not index. Use DOAJ to confirm something is in a vetted OA venue; do not use an empty result to conclude a work is missing from the literature. Docs at doaj.org/api/v3/docs.

When to use it: filtering for genuinely open-access journal articles, never as a completeness check on all literature.

Citation graphs and research repositories

The last two are less about finding a paper and more about what surrounds it: who cites it, and what artifacts were deposited. Same 200-that-lies theme, two new shapes.

7. OpenCitations: an empty array is "not indexed," and every ID is four IDs

OpenCitations is a nonprofit that publishes open citation data (who cites whom, keyed by DOI). Its v2 API returns a bare JSON array.

# runnable, read-only
curl "https://api.opencitations.net/index/v2/references/doi:10.1186/s13643-016-0384-4"

[{"oci":"061402590389-061901516871",
  "citing":"omid:br/... doi:10.1186/... openalex:W2560438049 pmid:27919275",
  "cited":"..."}]

Two things to notice. First, an empty [] means OpenCitations has not indexed those citations, not that the paper has zero citations. Coverage again, dressed as absence. Second, look at that citing value: it is a single space-separated string carrying four identifiers at once, an OMID, a DOI, an OpenAlex ID, and a PubMed ID, all for the same work. That is the entity-resolution problem made literal. Split on space and treat each token as a separate paper and you have quadrupled your node count with phantom duplicates. Parse the prefixes (omid:, doi:, openalex:, pmid:) and collapse them to one entity. Small transport note: the older opencitations.net/index/api/v2/... path 301-redirects to the canonical host api.opencitations.net/index/v2/... (the one above), and the http:// form 301s too, so call the canonical host directly or let your client follow redirects. Docs at opencitations.net/index/api/v2.

When to use it: open citation-graph edges by DOI, with prefix-aware ID parsing and empty-array-means-uncovered handling.

8. Zenodo: same paper, many versions, one concept

Zenodo is CERN's general-purpose repository for research outputs: datasets, software, posters, and papers, each with a minted DOI. Keyless JSON search.

# runnable, read-only
curl "https://zenodo.org/api/records?q=machine+learning&size=1"

{"hits":{"hits":[{"id":13235113,
   "conceptrecid":"13235112",
   "doi":"10.5281/zenodo.13235113", ... }]}}

Note the double-nested hits.hits envelope: a Solr/Elasticsearch tell, and a different shape from every other entry on this list, which is the whole diversity problem in one field path. Two real traps. Records are versioned: one logical upload has many id values that all share a single conceptrecid. If you index search results without collapsing on conceptrecid, the same dataset shows up three times in your top-k as if the versions were different works. And Zenodo rate-limits harder than it looks: the live response carries x-ratelimit-limit: 30 with retry-after: 60, so anonymous clients get about 30 requests a minute before a 429. Keyless is not the same as unlimited. Docs at developers.zenodo.org.

When to use it: searching research artifacts and software, deduplicated by conceptrecid, with backoff for the 429.

The three that look keyless and are not (and one honorable mention)

Three APIs kept surfacing when I searched for "free research paper API," and all three lie about being keyless in a different way. Naming them is part of keeping this honest.

Semantic Scholar (from the Allen Institute for AI) has a good graph API and a keyless "shared pool." On July 9 that pool answered me with a 429 on the first request:

curl "https://api.semanticscholar.org/graph/v1/paper/search?query=large+language+models&limit=1&fields=title,year"

{"message":"Too Many Requests. ... apply for a key ...","code":"429"}

The "code":"429" sits in the JSON body while the transport is also 429, so at least it is consistent. But the shared keyless pool is congested enough that you cannot rely on it. For anything real, request a free key and add backoff.

CORE (Open University, UK) aggregates open-access full text and, on July 9, actually returned a keyless 200 after a 301 to a trailing slash:

{"totalHits":592803,"limit":1,
 "results":[{"authors":[{"name":"van Rijn J.N."}, ... ]}]}

totalHits was 592,803, so it works keyless today. But CORE's own docs ask for a Bearer key and it throttles hard, so the keyless window is a courtesy that can close without notice. Do not build on it. (For the record: the "301" here is a redirect to a trailing slash, not a key wall. Worth knowing before you assume you are being blocked.)

HAL (the French national open archive) is the cleanest example of "200 lies" I hit all day. Every form of the query I tried, from our datacenter IP, returned HTTP 200 with an error body:

curl "https://api.archives-ouvertes.fr/search/?q=deep&rows=1&wt=json"

{"error":{"msg":"Error. See help : /docs"}}

HTTP 200, and the body is nothing but an error object. I tried three query shapes and got the same error each time, which smells like an API change or an IP filter on datacenter ranges. I did not get a working data call out of HAL today, so I am putting it here honestly rather than pretending it is a clean entry. If you can reach it from a residential or institutional IP, treat that 200 as meaningless and check for an error key first.

Honorable mention, bioRxiv. For life-sciences preprints, bioRxiv's API returned a clean keyless 200:

{"messages":[{"status":"ok","count":30,"total":"141"}],
 "collection":[{"title":"MVA Vector Vaccines ..."}]}

It is genuinely keyless and useful. I left it out of the main eight for two reasons: it is a single-discipline preprint server, not a cross-publisher index, and it sits in a biomedical area distinct from the general scholarly layer these eight cover. Even here it plants a type trap worth noting: count is the number 30 while total is the string "141" in the same object, so cast before you compare. Docs at api.biorxiv.org.

Why the paid giants are not here

The roundup stays honest by naming what it skips. Scopus (Elsevier), Web of Science (Clarivate), and Dimensions (Digital Science) are the big commercial scholarly databases, and every one of them wants an API key tied to a subscription or an approved account. Good coverage, real money, institutional contracts. Exactly the paid tier this list exists to route around, not entries in it. If your employer already pays for one, use it. If you are building on your own, the eight above are your layer.

Parse the payload, not the status code

Finding the endpoint is ten percent of the work. Here is the ninety percent, pulled straight from the failures above.

Check the content-type before you parse. arXiv hands you Atom XML on a 200; HAL hands you an error object on a 200. A blind resp.json() either throws or, worse, a lazy try/except swallows it and you index nothing. Assert application/json first, and look for an error key second.

Assert on a body count, not the HTTP code. Crossref's no-match query, DataCite's data: [], DOAJ's total: 0, and OpenCitations' [] are all 200s. And every one can mean "we do not index this," not "it does not exist." Read the count or total field and treat zero as a coverage gap you might fill from a second source.

Treat the top search hit as a candidate, not your paper. query= and search= on Crossref, OpenAlex, and DataCite are fuzzy full-text ranking. items[0] is a guess. For the exact work, resolve by DOI or match precise fields and the returned score. It is the same one-entity-many-IDs problem OpenCitations shows you outright.

Send a real mailto and User-Agent. Crossref, OpenAlex, and Unpaywall all reward an identified client with the polite pool and punish anonymous callers with the first throttle. No key does not mean no etiquette.

Assume keyless windows drift. CORE answers keyless today and officially wants a key; Semantic Scholar's shared pool is already handing out 429s; Zenodo's live x-ratelimit-limit header caps you near 30 per minute. "Free and no key" is a snapshot from July 9, 2026, not a warranty.

Here is a guard that folds the first four checks into one function.

# runnable local -- validate content-type and body, not just the status code
import requests

def openalex_top(query, email="you@example.com"):
    r = requests.get(
        "https://api.openalex.org/works",
        params={"search": query, "per-page": 1, "mailto": email},
        headers={"User-Agent": f"my-research-tool/1.0 (mailto:{email})"},
        timeout=15,
    )
    r.raise_for_status()                         # honest 4xx/5xx, NOT a 200 with an error body
    if "application/json" not in r.headers.get("content-type", ""):
        return None                              # arXiv-style XML / HAL-style bodies stop here
    body = r.json()
    if isinstance(body, dict) and "error" in body:
        return None                              # HAL returns 200 + {"error": ...}
    if body.get("meta", {}).get("count", 0) == 0:
        return None                              # 200 + empty = coverage gap, not a match
    return body["results"][0]                    # a CANDIDATE -- still verify before trusting

print(openalex_top("large language models"))     # -> a record
print(openalex_top("asdfqwer no such work zxcv")) # -> None, no crash

raise_for_status catches the honest failures. The content-type line catches arXiv and HAL. The error-key line catches HAL's 200. The count line catches the empty coverage gaps. What it deliberately does not do is trust results[0] as your exact paper. That last check is yours to write, because only you know which work you meant.

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 output is always a table of rows that need trustworthy enrichment columns. Company identity was one keyless column. Nutrition was another. Scholarly metadata is this one. Same keyless, no-card layer, different question, and the same failure mode every time: a 200 that is empty, fuzzy, or the wrong entity, almost never an honest 500.

FAQ

Are research paper APIs really free with no key?
Yes. arXiv, Crossref, OpenAlex, DataCite, Unpaywall (with an email parameter), DOAJ, OpenCitations, and Zenodo all return metadata with no API key and no signup. The big commercial databases (Scopus, Web of Science, Dimensions) require a paid key. Semantic Scholar and CORE technically have keyless pools but throttle hard and officially want a key, so they are labeled honestly rather than listed.

Why does arXiv return XML instead of JSON?
arXiv's API predates the JSON-everywhere era and returns Atom XML (content-type: application/atom+xml) with no JSON mode. Parse it with a feed or XML parser, not json.loads, and read <opensearch:totalResults> to tell a hit from a miss, because a no-match query still returns HTTP 200 with an empty <feed>.

What is the difference between Crossref and OpenAlex?
Crossref is the DOI registrar: authoritative bibliographic metadata for registered works. OpenAlex is a graph built on top of Crossref and other sources, adding authors, institutions, and citation links. For a canonical DOI record, use Crossref; for a connected graph of works and authors, use OpenAlex. Both run fuzzy full-text search, so neither guarantees the top result is your exact paper.

Why does a scholarly API return millions of results but not my paper?
Because query= and search= are relevance-ranked full-text matching, not exact lookup. A total-results of 3,142,373 (Crossref) or a count of 3,780,168 (OpenAlex) on July 9, 2026 describes the whole fuzzy match set; items[0] is the best guess. Resolve the exact work by DOI, or by matching precise fields and the returned score.

Which free API gives open-access PDF links?
Unpaywall: pass a DOI and your email, and it returns best_oa_location with a legal open-access URL when one exists. A paywalled paper returns HTTP 200 with best_oa_location: null, so check is_oa and guard the null before you read .url.

Do these free APIs have rate limits?
Yes, keyless is not unlimited. Zenodo caps anonymous clients near 30 requests per minute (its live x-ratelimit-limit: 30 header) before a 429; Semantic Scholar's shared keyless pool was already returning 429 on July 9, 2026; Crossref and OpenAlex run a polite pool that gives identified clients (a mailto) more stable service than anonymous ones. For steady load, send a real User-Agent with contact info and add backoff.

Written by Aleksei Spinov. I build web-scraping and data-enrichment tool layers, currently 2,190 runs across 32 actors in production. Every API above was re-verified with a live curl (real HTTP code, real body) on July 9, 2026 before publishing; responses are trimmed, not paraphrased. I have not run these scholarly APIs in production; the 2,190 runs are a different domain, cited only for the parse-the-body pattern. Drafted with an AI assistant, then fact-checked and edited by me against the raw responses.

Follow for the next keyless API layer I test. And tell me: which scholarly or research API has quietly handed you a clean 200 with the wrong body (arXiv's XML, a fuzzy top hit, an empty coverage gap), and which field finally gave the bug away? I read every comment.

8 Free Food & Nutrition APIs (No Key, Tested 2026)

Alex Spinov — Thu, 09 Jul 2026 03:18:01 +0000

On July 8, 2026 I looked up a barcode that does not exist. Eight zeros. I sent them to Open Food Facts, the largest open nutrition database on the web, and it answered HTTP 200. Green light. Then I read the body: "status":0, "status_verbose":"no code or invalid code". A success code wrapped around a total miss. Ten seconds of trusting the status line and I would have written that empty result into a calorie tracker as if it were food.

That is the whole post. The list of APIs is the easy part. The hard part is that a keyless food API hands you a clean 200 and a wrong answer, and it does it a slightly different way on almost every endpoint.

A free food API here means a public nutrition, ingredient, or recipe endpoint that returns JSON with no API key, no signup, and no card. Not a CSV dump, not a partner form, not a portal from 2012. A real REST call you can paste into a terminal right now. I found eight that clear that bar, plus three worth knowing that quietly lean on a shared key. I re-verified every one with a live curl on July 8, 2026 (real HTTP code, real body, trimmed but never paraphrased). If you build calorie trackers, meal planners, grocery tools, or an AI agent that answers "how much sugar is in this," these are the lookups you reach for. Every one of them can lie to you with a 200.

Here is the uncomfortable finding before the list. Keyless nutrition data in 2026 is mostly one project. Open Food Facts and its sibling databases (Pet Food, Products, Beauty, Prices) are six of the eight entries below: five distinct databases on one shared engine, with Open Food Facts itself showing up twice because it fails two different ways. Only two entries, Fruityvice and Wger, are independent, and Wger re-imports its data from Open Food Facts anyway. That concentration is not a weakness of the roundup. It is the point. Because it is one engine, the data-quality traps below are systemic, not one-offs. Learn them once and they repeat across the whole family.

Let me be straight about scope, because this is where roundups usually stretch the truth. Full disclosure: I have not run these food APIs in production. My numbers come from a different domain (2,190 scraper runs, incl. 962 on a Trustpilot scraper). I'm citing them only for the pattern: parse the payload, don't trust the status code. The status:0-with-HTTP-200 and unit-mismatch examples below are all from live curl calls I ran on 2026-07-08, not from operating these services at scale.

Here is the full set at a glance.

#	API	What it answers	Example call	No key?
1	Open Food Facts	Packaged food by barcode	`GET world.openfoodfacts.org/api/v2/product/<barcode>.json`	Yes
2	Open Food Facts (units)	Per-100g vs per-serving, kJ vs kcal	same endpoint, `nutriments` field	Yes
3	Open Pet Food Facts	Pet food by barcode	`GET world.openpetfoodfacts.org/api/v2/product/<barcode>.json`	Yes
4	Open Products Facts	Non-food products by barcode	`GET world.openproductsfacts.org/api/v2/product/<barcode>.json`	Yes
5	Open Beauty Facts	Cosmetics by barcode	`GET world.openbeautyfacts.org/api/v2/product/<barcode>.json`	Yes
6	Open Food Facts Prices	Crowd-sourced product prices	`GET prices.openfoodfacts.org/api/v1/prices?size=1`	Yes
7	Fruityvice	Nutrition for whole fruits	`GET fruityvice.com/api/fruit/banana`	Yes
8	Wger	1.3M+ ingredients + workouts	`GET wger.de/api/v2/ingredient/?limit=1&language=2`	Yes

Three bonus APIs (TheMealDB, TheCocktailDB, USDA FoodData Central) sit at the end with an honest label, because they ride a shared public key rather than being truly keyless.

Open Food Facts and its five siblings: one engine, six entries

This is the keyless nutrition web, most of it. Same codebase, same response shape, same traps in slightly different clothing.

1. Open Food Facts: the barcode lookup that returns 200 on a missing product

Open Food Facts is a crowd-sourced database of packaged food. Give the v2 product endpoint a barcode and it returns the product with a nested nutriments object. This is the anchor of the whole post, so look closely at what it does when the barcode is real and when it is not.

# runnable, read-only
curl "https://world.openfoodfacts.org/api/v2/product/3017624010701.json"   # Nutella
curl "https://world.openfoodfacts.org/api/v2/product/00000000.json"        # garbage

// real barcode 3017624010701:
{"code":"3017624010701","product":{"nutriments":{ ... }},"status":1}

// invalid barcode 00000000:
{"code":"00000000","status":0,"status_verbose":"no code or invalid code"}

Both requests returned HTTP 200. The only thing that separates a hit from a miss is status in the body: 1 means found, 0 means nothing. There is no 404 to catch. It gets worse if you ask for specific fields. When I requested ?fields=nutrition_data_per on the Nutella barcode, I got back {"product":{},"status":1,"status_verbose":"product found"}: status says found, and product is an empty object. A 200, a "found," and no data. If your code does resp.json()["product"]["nutriments"] on that, it throws a KeyError on a request that technically succeeded. Trust the status field, not the status code. Docs at openfoodfacts.github.io/openfoodfacts-server/api.

When to use it: any barcode-to-nutrition lookup for packaged food. It is the front door of the whole ecosystem.

2. Open Food Facts again: the units trap (kJ vs kcal, per-100g vs per-serving)

Yes, this is the same endpoint. It earns a second slot because the nutriments object fails a second, sneakier way, and this one does not throw at all. It just gives you a plausible wrong number. I pulled Coca-Cola, barcode 5449000000996.

# runnable, read-only
curl "https://world.openfoodfacts.org/api/v2/product/5449000000996.json"

{"nutriments":{
  "energy":180,        "energy-kcal":42,
  "energy-kj":180,     "energy-kcal_serving":139,
  "energy-kj_serving":594,
  "carbohydrates":10.6,"carbohydrates_serving":35}}

Read energy and you get 180. Looks like calories. It is not. That 180 is kilojoules; the calorie value is energy-kcal, which is 42. Grab the naive energy field as "calories per 100g" and your tracker is wrong by a factor of about 4.3 on every Coke in the database. The same field lives four ways at once: _100g, _serving, kJ, and kcal. And notice carbohydrates is 10.6 (per 100g) while carbohydrates_serving is 35 (a full can). Mix the basis and you are comparing a mouthful to a bottle. Pick your unit and your basis explicitly, then normalize before you store anything.

When to use it: whenever you actually read nutrient values, which is always. This is where calorie apps quietly ship the wrong number.

3. Open Pet Food Facts: the same engine, a different status code

Open Pet Food Facts is the sibling database for pet food, same v2 product API. I looked up a barcode it does not have.

# runnable, read-only
curl -i "https://world.openpetfoodfacts.org/api/v2/product/3182550716291.json"

// HTTP/2 404
{"code":"3182550716291","status":0,"status_verbose":"product not found"}

Here is the twist that makes hardcoding dangerous. The main Open Food Facts endpoint returned 200 on a not-found product (entry 1). This one, same engine, returned 404 on a not-found product. Two databases, one codebase, two different transport signals for the exact same situation. What is identical across both is the body: status:0. So if you wrote if resp.status_code == 200: assume_found(), it works on pet food and silently breaks on food. The body status field is the one signal that holds across the whole family. Docs at openpetfoodfacts.org.

When to use it: pet-food barcode lookups, and as your reminder that status codes are not consistent even within one project.

4. Open Products Facts: 404 again, so stop hardcoding the status

Open Products Facts covers non-food consumer products. Same API, and it confirms the lesson from entry 3.

# runnable, read-only
curl -i "https://world.openproductsfacts.org/api/v2/product/3661112538014.json"

// HTTP/2 404
{"code":"3661112538014","status":0,"status_verbose":"product not found"}

Another 404, not a 200, on not-found. So now you have concrete proof from three sibling databases that you cannot assume "this API always returns 200" or "this API always returns 404." The transport code depends on which sibling you hit. Read status from the body every time. Docs at openproductsfacts.org.

When to use it: barcode lookups for household and non-food goods.

5. Open Beauty Facts: status 1, and almost nothing in the record

Open Beauty Facts is the cosmetics sibling. It is not food, and I am flagging that plainly, but it belongs here because it shows the family's other failure mode: a "found" record that is nearly empty.

# runnable, read-only
curl "https://world.openbeautyfacts.org/api/v2/product/3600542525701.json"

{"code":"3600542525701",
 "product":{"product_name":"Shampooing"},
 "status":1,"status_verbose":"product found"}

status:1, "product found," and the product is one field: a name, "Shampooing." No ingredients, no detail. This is the sparse-record trap. On crowd-sourced data, "found" means someone scanned a barcode once, not that anyone filled in the fields you need. A completeness check (does the field I want actually exist and is it non-empty) is a separate test from the status check. Docs at openbeautyfacts.org.

When to use it: cosmetics lookups, and as a warning that status:1 is a floor, not a guarantee of complete data.

6. Open Food Facts Prices: a 200 full of nulls

Prices is a newer Open Food Facts service where people log what products cost. Different host, its own v1 API, still keyless.

# runnable, read-only
curl "https://prices.openfoodfacts.org/api/v1/prices?size=1"

{"items":[{"id":1,"product":{
  "product_name":null,"brands":null,
  "nutriscore_grade":null,"categories_tags":[]}}]}

HTTP 200, valid JSON, an items array with a real row. And the joined product object is almost entirely null: no name, no brand, no grade, an empty categories array. The price record exists; the product it points to was never enriched. This is the classic "200, but the fields are empty" case. A null-coalescing default on every joined field is not optional here, it is the difference between a working feature and a page full of "null." Docs at prices.openfoodfacts.org.

When to use it: crowd-sourced grocery-price features, with heavy null guards on the joined product.

The two keyless APIs that aren't Open Food Facts

Out of eight keyless entries, exactly two come from a different codebase. One of them handles errors better than the whole Open Facts family. The other inherits Open Food Facts' data and adds a fresh bug on top.

7. Fruityvice: the one that gets not-found right

Fruityvice returns nutrition for whole fruits, keyed by name. It is small and single-purpose, and it is the counter-example that proves good behavior is possible.

# runnable, read-only
curl "https://www.fruityvice.com/api/fruit/banana"   # 200
curl -i "https://www.fruityvice.com/api/fruit/pizza" # 404

// banana, HTTP 200:
{"name":"Banana","nutritions":{"calories":96,"fat":0.2,
  "sugar":17.2,"carbohydrates":22.0,"protein":1.0}}

// pizza, HTTP 404:
{"error":"Not found"}

A miss returns an honest 404 with {"error":"Not found"}, not a 200 with a hidden flag. Refreshing after five endpoints that lie about status. But it hides a different assumption: the serving basis is never stated. Those numbers are per 100 grams (a banana is not 96 calories, a 100g portion of banana is), and nothing in the payload says so. Bake in the wrong basis and every fruit in your tracker is off. A silent assumption is still a bug; it just fails quietly instead of throwing. Docs at fruityvice.com.

When to use it: fast fruit-nutrition lookups, once you have confirmed and hardcoded the per-100g basis.

8. Wger: 1.3M ingredients, every nutrient a string

Wger is an open-source workout and nutrition manager with a public REST API. The ingredient endpoint is large and keyless. Two calls below: one for the catalog size, one for a single ingredient pinned by id so you get the exact same row I did.

# runnable, read-only
curl "https://wger.de/api/v2/ingredient/?limit=1&language=2"  # English catalog size
curl "https://wger.de/api/v2/ingredient/33208/"               # one ingredient, pinned by id

// list endpoint, count only (results come back unordered, so I pin an id below):
{"count":1358809, "results":[ ... ]}

// ingredient 33208, fully reproducible:
{"name":"Flammekueche","energy":219,
 "protein":"6.100","carbohydrates":"23.100",
 "fiber":null,"is_vegan":null,
 "source_name":"Open Food Facts"}

That count is 1,358,809 English ingredients. Drop language=2 and it jumps to roughly 3 million rows across all languages, so the "how big is it" number depends entirely on the filter you send. Either way it sounds like a rival to Open Food Facts, until you read source_name: "Open Food Facts." Wger re-imports the same data. So it inherits Open Food Facts' gaps (fiber and is_vegan come back null) and adds one of its own: the nutrients are strings. "6.100", not 6.1. Try to add two of those in Python or JavaScript and + concatenates them into "6.10023.100" instead of summing. Cast every nutrient to a number before you do arithmetic. One more trap the list endpoint hides: it returns rows in no guaranteed order, so a bare ?limit=1 hands you a different ingredient on every call, which is why I pinned id 33208 instead of trusting "the first row." This is the downstream lesson: when one dataset re-imports another, the original's defects flow through and the new layer can add fresh ones. Wger also serves a separate workout catalog if you need exercises. Docs at wger.de.

When to use it: ingredient search at volume, or workout data, with a hard cast on every numeric field.

Three bonus food and recipe APIs that need a shared key

These three are genuinely useful and genuinely popular, so people search for them. But they are not clean keyless: TheMealDB and TheCocktailDB run on a public shared test key 1, and USDA uses DEMO_KEY. Those are shared, rate-limited, and not yours. They can throttle or break without warning. Included honestly, with the label attached.

9. TheMealDB: recipes, and the null-that-isn't-an-array trap

TheMealDB is a free recipe database. The public test key 1 is in the path.

# runnable, read-only (shared public test key "1")
curl "https://www.themealdb.com/api/json/v1/1/search.php?s=arrabiata" # hit
curl "https://www.themealdb.com/api/json/v1/1/search.php?s=zzzzzz"    # miss

// hit, HTTP 200:
{"meals":[{"idMeal":"52771","strMeal":"Spicy Arrabiata Penne"}]}

// miss, HTTP 200:
{"meals":null}

Both are HTTP 200. A miss does not return {"meals":[]}. It returns {"meals":null}. That difference is a crash. for m in data["meals"] throws TypeError: 'NoneType' is not iterable in Python, and data.meals.length throws in JavaScript, on a response that succeeded. Guard for null, not just for empty. Docs at themealdb.com/api.php.

When to use it: recipe search and meal ideas, with a null check before you iterate, and a plan for when the shared key gets rate-limited.

10. TheCocktailDB: same engine, same null trap

TheCocktailDB is TheMealDB's drinks counterpart, same company, same behavior, same shared key 1.

# runnable, read-only (shared public test key "1")
curl "https://www.thecocktaildb.com/api/json/v1/1/search.php?s=margarita"

{"drinks":[{"idDrink":"11007","strDrink":"Margarita",
  "strInstructions":"Rub the rim of the glass with the lime slice ..."}]}

A hit returns a drinks array; a miss returns {"drinks":null}, exactly like TheMealDB. If you already wrote a null guard for meals, reuse it verbatim here. Docs at thecocktaildb.com/api.php.

When to use it: cocktail and drink recipes, same null caveat as TheMealDB.

11. USDA FoodData Central: a DEMO_KEY and contradictory metadata

USDA FoodData Central is the US government's authoritative food-composition database. It needs a key, but DEMO_KEY works for a look (shared and rate-limited, the same demo key NASA uses).

# runnable, read-only (shared DEMO_KEY, rate-limited)
curl "https://api.nal.usda.gov/fdc/v1/foods/search?query=cheddar&pageSize=1&api_key=DEMO_KEY"

{"totalHits":20607,"totalPages":20607,
 "foodSearchCriteria":{"numberOfResultsPerPage":50,"pageSize":1},
 "foods":[{"fdcId":2022017,"description":"CHEDDAR"}]}

The data is excellent. The metadata argues with itself. I asked for pageSize=1 and the response echoes "pageSize":1, then reports "numberOfResultsPerPage":50 and "totalPages":20607 in the same object, for 20,607 hits. Those numbers cannot all be true at once. Do not build pagination logic off the meta block blind; trust the length of the foods array you actually received. Get your own free key from fdc.nal.usda.gov/api-guide before you ship anything real.

When to use it: authoritative US nutrient data, with your own key and a skeptical eye on the pagination metadata.

Why the famous food APIs aren't on this list

The roundup stays honest by naming what it left out.

The big commercial names all want a key or an OAuth handshake: Nutritionix, Edamam, Spoonacular, CalorieNinjas, FatSecret. Good products, but none of them clear the "no key, no signup" bar, so they are the paid tier this list exists to route around, not entries in it.

Two Open Food Facts search paths flaked during verification, and I am not going to pretend otherwise. The legacy search at /cgi/search.pl returned HTTP 503 ("Page temporarily unavailable") twice on July 8, so do not build a product on it. The newer Search-a-licious path I tried returned HTTP 404 with {"detail":"Not Found"}, which means the URL has moved; use the current docs rather than any fixed search URL you find in a blog post, including this one.

Honorable keyless mention that is not nutrition: Foodish (foodish-api.com/api/) returns a random food photo, {"image":"https://.../idly3.jpg"}, HTTP 200, no key. Fun for a demo. It is pictures, not data, so it does not count toward the eight.

Parse the payload, not the status code

Finding the endpoint is ten percent of the work. Here is the ninety percent, pulled straight from the failures above.

Assert on a field in the body, not on the HTTP code. Every trap on this page slips past a status check. Open Food Facts returns 200 with status:0 on a bad barcode. Prices returns 200 with a null product. TheMealDB returns 200 with meals:null. A if resp.status_code == 200 gate waves all three through. Check the thing that actually signals success: status == 1, a non-empty result, a field you expect to exist.

Never hardcode "this API always returns 200." The same Open Facts engine returned 200 on a missing food and 404 on a missing pet food. Transport codes are not consistent even inside one project, so read the body every time instead of branching on the code.

Normalize units and types before you store. Coca-Cola's energy is 180 kJ while energy-kcal is 42. Wger hands you "6.100" as a string. Pick a unit and a basis (per-100g or per-serving), cast every number, and do it at the boundary, before the value reaches your database, not after a bug report.

Send a real User-Agent. Open Food Facts asks clients to identify themselves, and the whole family rewards a descriptive agent and polite pacing over a hammering anonymous one. No key does not mean no etiquette.

Here is a five-line guard that folds most of this into one function.

# runnable local — validate the body, not the status code
import requests

def get_nutriment(barcode, field="energy-kcal"):
    r = requests.get(
        f"https://world.openfoodfacts.org/api/v2/product/{barcode}.json",
        headers={"User-Agent": "my-calorie-app/1.0 (you@example.com)"},
        timeout=10,
    )
    r.raise_for_status()                     # catches 404/500, NOT the 200+status:0
    body = r.json()
    if body.get("status") != 1:              # the real success flag lives here
        return None                          # invalid/missing barcode: 200 + status:0
    value = body.get("product", {}).get("nutriments", {}).get(field)
    if not isinstance(value, (int, float)):  # rejects Wger-style "6.100" and null
        return None
    return value

print(get_nutriment("3017624010701"))  # Nutella kcal/100g -> a number
print(get_nutriment("00000000"))       # invalid barcode  -> None, no crash

That raise_for_status line catches the honest failures. The status != 1 line catches the dishonest 200s. The isinstance line catches string and null nutrients. Three checks, and the empty results stop reaching your data.

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 output is always a table of rows that need trustworthy enrichment columns. Company identity was the registry column. Time and dates were the holiday column. Nutrition is this one. Same keyless, no-card layer, different question, and the same failure mode every single time: a 200 that is empty, stale, or misread, never an honest 500.

FAQ

Are food and nutrition APIs really free with no key?
Yes. Open Food Facts and its siblings (Pet Food, Products, Beauty, Prices), plus Fruityvice and Wger, return JSON with no key and no signup. The popular commercial APIs (Nutritionix, Edamam, Spoonacular) do require a key, and TheMealDB, TheCocktailDB, and USDA ride a shared public or demo key, so they are labeled as bonuses here rather than clean keyless.

Which free food API has the most products?
Open Food Facts is the largest keyless option and the source most others copy. Wger reports 1,358,809 ingredients in its English catalog (about 3 million across all languages), but source_name shows it re-imports from Open Food Facts, so it is the same data with an extra serialization quirk (nutrients arrive as strings like "6.100").

Why does Open Food Facts return HTTP 200 for a barcode that does not exist?
Because the request was handled successfully even though nothing was found. The API signals the miss in the body with "status":0 and "status_verbose":"no code or invalid code", not with a 404. Check the status field, not the HTTP status code. Confusingly, the sibling Pet Food and Products databases do return 404 on a miss, which is exactly why you read the body every time.

What is the difference between energy and energy-kcal in Open Food Facts?
energy is in kilojoules and energy-kcal is in kilocalories (the "Calories" on a US label). For Coca-Cola I measured energy at 180 (kJ) and energy-kcal at 42 (kcal). Reading energy as calories overstates the value by roughly 4.3x, so always read energy-kcal for calories and normalize the per-100g versus per-serving basis before storing.

Which free recipe API needs no key?
TheMealDB and TheCocktailDB work through a public shared test key 1 in the URL path, so they are effectively keyless but not your key: shared, rate-limited, and able to break without notice. Both return {"meals":null} or {"drinks":null} on a miss rather than an empty array, so guard for null before you iterate or you will crash a request that returned HTTP 200.

Can I use Open Food Facts data commercially?
The database is under the Open Database License (ODbL), which permits commercial use but carries attribution and share-alike obligations on the database itself. Fruityvice, Wger, and USDA have their own terms. Check the specific license before you ship, because "keyless" and "unrestricted" are not the same thing.

Written by Aleksei Spinov. I build web-scraping and data-enrichment tool layers, currently 2,190 runs across 32 actors in production. Every API above was re-verified with a live curl (real HTTP code, real body) on July 8, 2026 before publishing; responses are trimmed, not paraphrased. I did not run these food APIs in production; the 2,190 runs are a different domain, cited only for the pattern. Drafted with an AI assistant, then fact-checked and edited by me against the raw responses.

Follow for the next keyless API I test for the enrichment layer. And tell me: which food or nutrition API has quietly handed you a clean 200 with a wrong body, and which field finally gave the bug away? I read every comment.

10 Free Government APIs With No Key or Signup (2026)

Alex Spinov — Wed, 08 Jul 2026 01:20:36 +0000

On July 6, 2026 I asked REST Countries for the United States. It answered HTTP 200. Green light, ship it. Then I read the body: "success":false, "data":null, and a note that the whole API version is deprecated. A 200 that means no. Ten seconds earlier I would have written that straight into a pipeline as country reference data.

Same afternoon, the US Census API handed me an HTTP 302 redirect to a "missing key" page for a shape of query that used to be keyless. Neither of those is an error your if resp.status_code == 200 check will catch.

A free government API is a public-sector or intergovernmental endpoint that returns JSON without a key, a signup, or a card. Not a CSV export, not a FOIA form, not a portal from 2009. A real REST endpoint. The ten below need none of those, and I re-verified each with a live curl on July 6, 2026 (HTTP 200, real body). If you build data pipelines, dashboards, or AI agents that need authoritative ground truth (federal spending, drug safety, the national debt, clinical trials, biodiversity) these are the lookups I reach for. The kind of facts a language model will happily hallucinate if you let it.

Here is the counterintuitive part. People expect government data to be the flaky link. In this batch it was the opposite: the ten government and intergovernmental endpoints returned clean, correct JSON, and the two that failed loudest were the community-run alternative (REST Countries, above) and a Census query that now wants a key. These APIs are primary sources. They do not sunset an endpoint to push a new pricing tier. But keyless does not mean careless, and 200 does not mean success.

Let me be straight about scope, because this is where writers usually lie. I did not run a government-data resolver across all 2,190 of my production runs. That would be false. I called each endpoint once on July 6, 2026, with a single request. The only thing I am carrying over from those 2,190 runs is one narrow, hard-won pattern: enrichment data fails as a confident 200 with a wrong body far more often than as an honest 500, which is exactly why the field-level notes below matter more than the endpoint list. This is a different axis from my recent keyless roundups (company data, holidays, CVEs); zero overlap in providers.

Here is the full set at a glance, grouped by the job each one does.

#	API	What it answers	Example call	No key?
1	USAspending	Federal agencies and their budgets	`GET api.usaspending.gov/api/v2/references/toptier_agencies/`	Yes
2	Treasury FiscalData	US national debt to the penny	`GET api.fiscaldata.treasury.gov/.../debt_to_penny`	Yes
3	Federal Register	Daily US government rules and notices	`GET federalregister.gov/api/v1/documents.json`	Yes
4	openFDA	Drug, device, and food adverse events	`GET api.fda.gov/drug/event.json?limit=1`	Yes
5	PubMed E-utilities	Search 37M+ biomedical papers	`GET eutils.ncbi.nlm.nih.gov/.../esearch.fcgi?...`	Yes
6	ClinicalTrials.gov v2	480k+ clinical study records	`GET clinicaltrials.gov/api/v2/studies?...`	Yes
7	CDC (Socrata)	Public-health datasets via SoQL	`GET data.cdc.gov/resource/pwn4-m3yp.json?$limit=1`	Yes
8	GBIF	Global species and biodiversity	`GET api.gbif.org/v1/species/match?name=...`	Yes
9	USGS Earthquakes	Real-time seismic catalog (GeoJSON)	`GET earthquake.usgs.gov/fdsnws/event/1/query?...`	Yes
10	World Bank	16k+ global development indicators	`GET api.worldbank.org/v2/country/us?format=json`	Yes

What makes this a list and not one API: there is no single "ask the government" endpoint. Money lives at Treasury and USAspending, drug safety at the FDA, seismic risk at USGS, global indicators at the World Bank. Which door you knock on depends entirely on the question. Reading the response correctly is the rest of the job.

Group A: money, debt, and the federal record

Three keyless endpoints that answer "what is the government doing with money and rules," straight from the source.

1. USAspending: every federal agency and what it can spend

Hand USAspending nothing at all and it hands back every top-tier federal agency with its budget authority for the current fiscal year. It is a huge API (award search, recipients, geography), but the agencies reference endpoint is the friendliest first pull.

# runnable, read-only
curl "https://api.usaspending.gov/api/v2/references/toptier_agencies/"

{"results":[
  {"agency_id":1525,"toptier_code":"247","abbreviation":"AAHC",
   "agency_name":"400 Years of African-American History Commission",
   "active_fy":"2026","active_fq":"3",
   "budget_authority_amount":0.0,
   "current_total_budget_authority_amount":15823226897068.67}]}

Two fields matter and they are not the same. budget_authority_amount is that one tiny commission's slice (0.0 here). current_total_budget_authority_amount is the government-wide total, repeated on every row: 15,823,226,897,068.67 dollars, roughly $15.8 trillion of budget authority. Grab the wrong one and your dashboard is off by twelve orders of magnitude. Note active_fy is 2026 and active_fq is 3, so you are reading the current fiscal quarter, not a stale snapshot. No published hard rate limit; it answered on a bare curl user agent, but be polite and cache. Terms at api.usaspending.gov.

When to use it: any US federal spending, award, or recipient question. This is the front door.

2. Treasury FiscalData: the national debt, to the penny

FiscalData is the US Treasury's open data service. The debt_to_penny endpoint returns the total public debt outstanding for a given day, exact to the cent, with rich labels attached.

# runnable, read-only
curl -g "https://api.fiscaldata.treasury.gov/services/api/fiscal_service/v2/accounting/od/debt_to_penny?sort=-record_date&page[size]=1"

{"data":[
  {"record_date":"2026-07-02",
   "tot_pub_debt_out_amt":"39375254020492.22",
   "debt_held_public_amt":"31678903447798.93",
   "intragov_hold_amt":"7696350572693.29",
   "record_fiscal_year":"2026","record_fiscal_quarter":"4"}],
 "meta":{"count":1}}

As of July 2, 2026, total public debt outstanding was $39,375,254,020,492.22. The numbers arrive as strings, so cast before you do math. And there is a curl trap worth flagging: the page[size] parameter has literal square brackets, so plain curl treats them as a glob range and errors with "bad range." Pass -g (or --globoff), or URL-encode the brackets. I have watched people blame the API for that one. Keyless, generous, and it exposes daily operations, exchange rates, and interest rates through sibling endpoints. Docs at fiscaldata.treasury.gov.

When to use it: debt, Treasury operations, official exchange rates, anything fiscal with an audit trail.

3. Federal Register: the government's daily journal

The Federal Register is where US rules, proposed rules, presidential documents, and public notices are published every business day. The API is keyless and filterable by agency, date, and type.

# runnable, read-only
curl "https://www.federalregister.gov/api/v1/documents.json?per_page=1"

{"count":10000,"total_pages":50,
 "next_page_url":"https://www.federalregister.gov/api/v1/documents?...&page=2",
 "results":[
  {"title":"Improvements to Rules on Recoupment of Benefit Overpayments",
   "type":"Proposed Rule",
   "abstract":"The Pension Benefit Guaranty Corporation (PBGC) is proposing..."}]}

One honest caveat: this is a live daily feed, so results[0] moves. On July 6 the top item was a PBGC proposed rule on benefit-overpayment recoupment; run the curl and you will get whatever is newest. The shape is the point, not my one document. Note the pagination is cursor-based via next_page_url, not a simple offset, so follow the link rather than incrementing a page number past the wall. Use fields[] to slim the payload. Keyless. Docs at federalregister.gov/developers.

When to use it: regulatory monitoring, compliance calendars, tracking an agency's rulemaking.

Group B: health, drugs, and clinical data

Four keyless endpoints covering drug safety, the biomedical literature, active trials, and public-health datasets. This is the densest cluster of authoritative data on the list.

4. openFDA: adverse events, recalls, and drug labels

openFDA exposes FDA data on drugs, devices, and food: adverse events, recalls, and labels, with Elasticsearch-style search= and count= queries. It works with no key, and a free key only raises your limit.

# runnable, read-only
curl "https://api.fda.gov/drug/event.json?limit=1"

{"meta":{
  "disclaimer":"Do not rely on openFDA to make decisions regarding medical care...",
  "terms":"https://open.fda.gov/terms/",
  "results":{"total":20328575}},
 "results":[{"safetyreportid":"5801206-7"}]}

That meta.results.total is 20,328,575 adverse-event reports in the drug endpoint alone. The meta block also ships the disclaimer, terms, and license on every response, which tells you exactly how the data may be used. Read the free-tier limit honestly, because this one is real: without a key you get 240 requests per minute and 1,000 per day per IP address. A free key lifts the daily ceiling to 120,000. If you are batching, you will hit the 1,000/day wall fast, so plan for the key before you ship. Terms at open.fda.gov.

When to use it: drug and device safety signals, recall monitoring, label lookups.

5. PubMed E-utilities: search 37 million biomedical papers

NCBI's E-utilities are the programmatic door to PubMed. esearch returns matching article IDs; efetch and esummary pull the records. It is the backbone for any retrieval-augmented system over published science.

# runnable, read-only
curl "https://eutils.ncbi.nlm.nih.gov/entrez/eutils/esearch.fcgi?db=pubmed&term=crispr&retmax=2&retmode=json"

{"esearchresult":{
  "count":"68891","retmax":"2","retstart":"0",
  "idlist":["42402242","42402225"]}}

A search for crispr returned 68,891 matching papers, with the two newest IDs at the top. Feed those IDs to efetch for abstracts. The keyless limit is the one to respect: 3 requests per second per IP, and NCBI does enforce it. A free API key raises that to 10 per second. Pass retmode=json explicitly or you get XML, which is the same "read the response format" trap that bites people on the seismic endpoint below. Docs at ncbi.nlm.nih.gov/books/NBK25501.

When to use it: literature search, science RAG, citation tooling.

6. ClinicalTrials.gov v2: the registry of clinical studies

ClinicalTrials.gov holds more than 480,000 study records: protocols, statuses, sponsors, and results. The v2 API is a clean modern REST interface, a real upgrade over the legacy one.

# runnable, read-only
curl "https://clinicaltrials.gov/api/v2/studies?query.term=diabetes&pageSize=1"

{"studies":[
  {"protocolSection":{
    "identificationModule":{
      "nctId":"NCT03470961",
      "organization":{"fullName":"Tianjin First Central Hospital"},
      "briefTitle":"Observational Study to Evaluate the Safety and Efficacy of Polyclonal Antibodies in Simultaneous Pancreas Kidney Transplant Recipients"}}}]}

Search diabetes and the first record is NCT03470961 from Tianjin First Central Hospital. The data is deeply nested under protocolSection, so the field you want is usually three or four keys down; keep the module names (identificationModule, statusModule, sponsorCollaboratorsModule) handy. Pagination is by pageToken, not a numeric page. Keyless. Docs at clinicaltrials.gov/data-api/api.

When to use it: trial monitoring, sponsor and condition research, medical dashboards.

7. CDC via Socrata: public-health datasets you can query with SoQL

data.cdc.gov runs on Socrata, which means thousands of public-health datasets answer SoQL queries ($where, $select, $limit) at a JSON endpoint. Anonymous access needs no key; an app token only lifts the throttle.

# runnable, read-only
curl "https://data.cdc.gov/resource/pwn4-m3yp.json?$limit=1"

[{"state":"AZ","tot_cases":"2434631.0","new_cases":"3716.0",
  "tot_deaths":"33042.0","new_deaths":"39.0",
  "date_updated":"2023-02-23T00:00:00.000"}]

Here is the honesty check, and it is the same trap as the deprecated REST Countries body from the intro. This dataset (pwn4-m3yp) returns a clean HTTP 200, but look at date_updated: 2023-02-23. It is an archived COVID-19 dataset, frozen in 2023. The Socrata platform is very much alive and keyless; this particular resource is history. So the lesson generalizes: on an open-data portal, a 200 tells you the query ran, not that the data is current. Read the date field before you trust the row. Swap the resource ID for any current dataset from the data.cdc.gov catalog. Keyless requests share a throttled pool; a free Socrata app token removes the throttle.

When to use it: any CDC or municipal open dataset; SoQL makes server-side filtering trivial.

Group C: science, the earth, and the wider world

Three keyless endpoints that reach past US borders: species, seismic activity, and global development indicators.

8. GBIF: the world's species, matched and keyed

GBIF (the Global Biodiversity Information Facility) is an intergovernmental initiative sitting on more than two billion occurrence records. The species/match endpoint resolves a name to a stable taxonomic key.

# runnable, read-only
curl "https://api.gbif.org/v1/species/match?name=Puma%20concolor"

{"usageKey":2435099,"scientificName":"Puma concolor (Linnaeus, 1771)",
 "canonicalName":"Puma concolor","rank":"SPECIES","status":"ACCEPTED",
 "confidence":99,"matchType":"EXACT","kingdom":"Animalia",
 "family":"Felidae","genus":"Puma"}

Match the mountain lion and you get usageKey 2435099 with matchType":"EXACT" and confidence":99. Watch matchType: it also returns FUZZY and HIGHERRANK, so a low confidence or a fuzzy match means "I guessed," and you should not treat it as ground truth. Use the usageKey to pull occurrences from the sibling endpoints. Keyless and generous; for bulk exports use the download API instead of hammering this one. Docs at techdocs.gbif.org.

When to use it: species normalization, biodiversity features, ecology and conservation data.

9. USGS Earthquakes: the real-time seismic catalog

The USGS earthquake feed is a FDSN-standard endpoint returning the seismic catalog as GeoJSON, real-time and historical. It is one of the cleanest public geospatial APIs going.

# runnable, read-only
curl "https://earthquake.usgs.gov/fdsnws/event/1/query?format=geojson&limit=1&orderby=time"

{"metadata":{"api":"2.7.0","status":200},
 "features":[
  {"type":"Feature",
   "properties":{"mag":0.8,"place":"85 km NNW of Karluk, Alaska",
     "status":"automatic","tsunami":0},
   "geometry":{"type":"Point"}}]}

When I ran it, the newest event was a magnitude 0.8 near Karluk, Alaska. It is a live feed, so you will get whatever just happened, not my quake. The gotcha here is format=geojson: drop it and the default response is a different format entirely, so you must set it explicitly or your JSON parser chokes on something that is not JSON. Same lesson as PubMed's retmode. Filter by starttime, minmagnitude, and a bounding box for anything real. Keyless. Docs at earthquake.usgs.gov/fdsnws/event/1.

When to use it: seismic monitoring, geospatial risk features, disaster tooling.

10. World Bank: global development indicators, keyless

The World Bank Indicators API carries more than 16,000 series (GDP, population, poverty) for every country and year. It is the international counterweight to all the US-centric endpoints above.

# runnable, read-only
curl "https://api.worldbank.org/v2/country/us?format=json"

[{"page":1,"pages":1,"per_page":"50","total":1},
 [{"id":"USA","name":"United States",
   "region":{"value":"North America"},
   "incomeLevel":{"value":"High income"},
   "capitalCity":"Washington D.C.",
   "longitude":"-77.032","latitude":"38.8895"}]]

Read that response shape carefully, because it is the sneakiest parse trap on the list. The top-level value is an array of two things: element [0] is pagination metadata, and element [1] is your actual data. Index [0] expecting a country and you get page counts instead, a clean 200 that hands you the wrong object. Always reach into [1]. You must also pass format=json or the default is XML. Keyless. Docs at datahelpdesk.worldbank.org.

When to use it: cross-country economics, development indicators, anything global and comparative.

Why some "free" government APIs did not make the cut

The list stays honest by showing what it rejected. Every code below is from a live curl on July 6, 2026.

REST Countries v3.1 (restcountries.com/v3.1/alpha/us, followed through its redirect) returned HTTP 200 with {"success":false,"data":null,"errors":[{"message":"This API version has been deprecated..."}]}. Not a government API, and now a broken one. It is the cleanest example on this page of a 200 that means no, so it earns its spot as a warning rather than an entry.
US Census (api.census.gov/data/...) returned HTTP 302, redirecting to a missing_key.html page instead of the JSON I asked for. The keyless shape of that query no longer works; it wants a key now. Excluded.
ReliefWeb returned HTTP 410 on v1 (decommissioned) and HTTP 403 on v2 with "not using an approved appname." It is soft-gated behind an appname request, so it is not truly keyless. Excluded.
data.gov CKAN (catalog.data.gov/api/3/action/package_search) returned HTTP 404 Not Found. The central catalog action API was not answering; go to the underlying agency's Socrata or API directly, as with CDC above.
NASA, FEC, Congress.gov, GovInfo all require a free DEMO_KEY or registration. Excellent APIs, but they fail the "no key, no signup" bar of this roundup by definition.
Honorable mentions that are keyless and work: NWS (api.weather.gov) and USGS Water Services both returned clean keyless 200s. I left weather off because I covered it in a previous roundup, and kept USGS to one entry so a single provider does not dominate.

Keeping these right under real traffic

Finding the endpoint is the easy 10 percent. Here is the other 90, distilled from the failures above and from years of watching enrichment data lie quietly in production.

Parse the payload, not the status code. This is the whole post. REST Countries returned 200 with a deprecation notice. The CDC dataset returned 200 with data frozen in 2023. Census returned a 302 to a key page. A status check would have waved all three through. This is the single pattern I carry over from 2,190 production runs, honestly and narrowly: across those runs, enrichment sources fail as a confident 200 with a wrong body far more often than as an honest error. Assert on a field you expect (success, a recent date, a non-empty result), never on 200 alone.

The User-Agent is the real gate, not a key. Almost none of these want a key. What they quietly reward is a descriptive User-Agent and polite pacing. USAspending, GBIF, Treasury, and the World Bank all answered a bare curl, but government services increasingly ask you to identify yourself, and a well-behaved agent is what keeps you unblocked. No key does not mean no etiquette.

Respect the real limits, because some are enforced. openFDA gives you 240 requests per minute and 1,000 per day per IP with no key. PubMed enforces 3 per second. CDC's Socrata pool is throttled without an app token. These are not decorative. Cache aggressively, and get the free key or token before you batch anything.

Learn the three parse traps by heart. World Bank wraps your data as element [1] behind a metadata [0]. Treasury's page[size] needs curl's -g flag. USGS and PubMed hand you XML unless you set format=geojson and retmode=json. Every one of these produces a clean 200 and a broken parse.

The licensing is a genuine gift. Data produced by the US federal government is public domain under 17 U.S.C. Section 105, so USAspending, Treasury, FDA, USGS, and Federal Register data can go straight into a commercial product. World Bank and GBIF use permissive licenses; check the specific dataset. This is rarer than it sounds in the API world.

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 output is always a table of rows that need trustworthy enrichment columns. Location was the geocoding column. Company identity was the registry column. Authoritative facts (spending, drug safety, debt) are this one. Same keyless, no-card layer, different question, and the same failure mode every single time: a 200 that is empty, stale, or deprecated, never an honest 500.

FAQ

Are government APIs really free with no API key?
Yes. Most US federal APIs (USAspending, Federal Register, openFDA, Treasury FiscalData) and intergovernmental ones (World Bank, GBIF) return JSON with no key and no signup. A few (NASA, FEC, Congress.gov) require a free key, and those are excluded from this list by design.

What is the catch with keyless government APIs?
Polite-use throttling and a User-Agent gate rather than a key, plus real per-IP limits on a few (openFDA 1,000/day, PubMed 3/second). And the big one: HTTP 200 does not guarantee usable data. No key does not mean no etiquette, and it does not mean unlimited.

Can I use US government data in a commercial product?
Data produced by the US federal government is public domain under 17 U.S.C. Section 105, so it can go into a commercial product. World Bank and GBIF use permissive licenses; always check the specific dataset's terms before you ship.

Why did an API return HTTP 200 but no usable data?
Because 200 means the request was handled, not that the answer is right. REST Countries v3.1 returns a 200 whose body says "deprecated." A CDC Socrata dataset can return a 200 full of data frozen in 2023. Always assert on a field you expect, not on the status code alone.

Which free government API should I start with?
For US federal spending, USAspending. For the national debt and Treasury data, FiscalData. For drug and device safety, openFDA. For anything global and comparative, the World Bank. All four are keyless with no signup.

Written by Aleksei Spinov. I build web-scraping and data-enrichment tool layers, currently 2,190 runs across 32 actors in production. Every API above was re-verified with a live curl (HTTP 200, real response) on July 6, 2026 before publishing; responses are trimmed, not paraphrased. Two endpoints are live feeds (Federal Register and USGS Earthquakes), so results[0] moves; run the curl yourself for the current value. Drafted with an AI assistant, then fact-checked and edited by me against the raw responses.

Follow for the next batch of keyless APIs I test for the enrichment layer. And tell me: which government or open-data API has quietly handed you a clean 200 with a wrong body, and what field finally gave the bug away? I read every comment.

9 Free Public Holiday & Time APIs With No Key (2026)

Alex Spinov — Mon, 06 Jul 2026 02:36:34 +0000

Finding a free holiday or time API is the easy 10 percent. The trap is the other 90: these APIs quietly disagree, and each one fails in a way that looks like success. On July 4, 2026 I asked sunrise-sunset.org for New York's sunset and it told me 12:32 AM. Not an error. A clean HTTP 200 with a value that reads like a bug. I lost twenty minutes before I scrolled down and saw "tzid":"UTC" sitting in the same response.

A free public holiday or time API answers a temporal question (is this a business day, what is the local time, what is this date in another calendar) without a key, a signup, or a card. The nine below need none of those. I re-verified each with a live curl on July 4, 2026 (HTTP 200), and every response you see is the real output, trimmed for length, not paraphrased. If you build schedulers, billing and SLA calendars, booking flows, HR "next working day" logic, or i18n date displays, these are the lookups I reach for. And every one of them has a field that will silently lie to you if you skip it.

Let me be straight about the scope. I am not claiming I ran a holiday resolver across all 2,190 runs. That would be a lie. I called each endpoint once on July 4, 2026 with a single request. The only thing I am generalizing from 2,190 runs is narrower: enrichment data fails as a 200 with a wrong body far more often than as a clean error, which is exactly why the field-level gotchas below matter more than the endpoint list.

Here is the full set at a glance, grouped by the job each one does, then a section each.

#	API	What it answers	Example call	No key?
1	Nager.Date	Country + year to public holidays	`GET date.nager.at/api/v3/PublicHolidays/2026/US`	Yes
2	OpenHolidays	EU country to holidays with subdivisions	`GET openholidaysapi.org/PublicHolidays?countryIsoCode=DE…`	Yes (EU only)
3	gov.uk Bank Holidays	UK bank holidays, three divisions	`GET gov.uk/bank-holidays.json`	Yes (UK only)
4	Enrico / Kayaposoft	Country + year holidays (community data)	`GET kayaposoft.com/enrico/json/v2.0/?action=getHolidaysForYear…`	Yes
5	TimeAPI.io	IANA zone to current time + DST flag	`GET timeapi.io/api/time/current/zone?timeZone=America/New_York`	Yes
6	WorldClockAPI	Authoritative UTC "now"	`GET worldclockapi.com/api/json/utc/now`	Yes (HTTP only)
7	Hebcal	Gregorian to Hebrew date + Torah portion	`GET hebcal.com/converter?…g2h=1`	Yes
8	Aladhan	Gregorian to Hijri date	`GET api.aladhan.com/v1/gToH/04-07-2026`	Yes
9	Sunrise-Sunset	Lat/lng to sunrise, sunset, day length	`GET api.sunrise-sunset.org/json?lat=40.71&lng=-74.00`	Yes (UTC default)

Here is what makes this a list and not one API. There is no single "what day is it" service. July 4, 2026 is a Saturday everywhere, but ask what that date means and the answers scatter: 19 Tamuz 5786 to Hebcal, 19 Muharram 1448 to Aladhan, one lone holiday (Juneteenth, weeks earlier) in Enrico's US feed, and a New York sunset that is either 12:32 AM or 8:32 PM depending on one query parameter. Which source you hit depends on the question. Reading its fields correctly is the whole job.

Group A: public holidays (fill a calendar, check a business day)

Four keyless holiday sources, four different coverage models, and four different ways to get burned.

1. Nager.Date: country and year to a holiday list

Hand Nager a two-letter country code and a year and it returns that country's public holidays. It is the broadest keyless holiday source I found, and the one I default to.

# runnable, read-only
curl "https://date.nager.at/api/v3/PublicHolidays/2026/US"

[{"date":"2026-01-01","localName":"New Year's Day","name":"New Year's Day",
  "countryCode":"US","global":true,"counties":null,"types":["Public","Bank"]},
 {"date":"2026-02-12","localName":"Lincoln's Birthday","name":"Lincoln's Birthday",
  "countryCode":"US","global":false,
  "counties":["US-CA","US-CT","US-IL","US-IN","US-KY","US-MI","US-NY","US-MO","US-OH"],
  "types":["Observance"]}]

New Year's Day comes back with "global":true. Lincoln's Birthday comes back with "global":false and a counties array of nine states. That is the gotcha, and it is a live one: state-only holidays sit in the same array as nationwide ones. Filter on "global":true (or read counties) or you will show a California observance to a user in Texas. While reading the raw body I also caught Good Friday listed twice, once per set of states that observe it, so a naive count is wrong too. There is a companion GET /api/v3/AvailableCountries that lists every supported code, also keyless. No published hard rate limit; it is an open-source project, so cache and be polite. Verify the current terms at date.nager.at.

When to use it: any country, when you want one consistent shape and can filter on global.

2. OpenHolidays: European holidays with subdivision detail

OpenHolidays is the one to reach for inside the EU, because it carries subdivision-level detail that Nager flattens. Its catch cost me an afternoon once, so I will lead with it: it is European only, and it tells you that with an empty 200, not a 404.

# runnable, read-only
curl "https://openholidaysapi.org/PublicHolidays?countryIsoCode=DE&languageIsoCode=EN&validFrom=2026-01-01&validTo=2026-12-31"

[{"startDate":"2026-01-01","endDate":"2026-01-01","type":"Public",
  "name":[{"language":"EN","text":"New Year's Day"}],"nationwide":true},
 {"startDate":"2026-01-06","type":"Public",
  "name":[{"language":"EN","text":"Epiphany"}],"nationwide":false,
  "subdivisions":[{"code":"DE-ST"},{"code":"DE-BW"},{"code":"DE-BY"}]}]

For Germany you get Epiphany flagged "nationwide":false with the exact states (Saxony-Anhalt, Baden-Wurttemberg, Bavaria) that observe it. Now watch the failure. Change countryIsoCode to US:

# runnable, read-only
curl "https://openholidaysapi.org/PublicHolidays?countryIsoCode=US&languageIsoCode=EN&validFrom=2026-01-01&validTo=2026-12-31"

[]

That is an HTTP 200 with an empty array. I only found this the first time because my calendar view rendered blank and I assumed my own code was broken. It was 200 the whole time; the coverage just stops at Europe's edge. The endpoint also requires both validFrom and validTo, or it will not answer.

When to use it: EU countries where you need which region observes what. Not for the US or Asia.

3. gov.uk Bank Holidays: the UK, straight from the government

The UK government publishes its bank holidays as one static JSON file. No key, effectively unlimited, and it is the primary source rather than a scrape of one.

# runnable, read-only
curl "https://www.gov.uk/bank-holidays.json"

{"england-and-wales":{"division":"england-and-wales","events":[
  {"title":"New Year's Day","date":"2019-01-01","notes":"","bunting":true},
  {"title":"New Year's Day","date":"2026-01-01","notes":"","bunting":true},
  {"title":"Good Friday","date":"2026-04-03","notes":"","bunting":false},
  {"title":"Summer bank holiday","date":"2026-08-31","notes":"","bunting":true}]},
 "scotland":{"division":"scotland","events":[
  {"title":"2nd January","date":"2026-01-02","bunting":true},
  {"title":"St Andrew's Day","date":"2026-11-30","bunting":true}]},
 "northern-ireland":{"events":[…]}}

Two things to read carefully. First, the array runs all the way back to 2019-01-01, so filter by year or you will process seven years of history. Second, this is one endpoint holding three different calendars: england-and-wales, scotland, and northern-ireland genuinely differ. Scotland has 2 January and St Andrew's Day; England does not. Pick the division your user lives in. The bunting boolean is a real field, by the way, telling you whether flags are traditionally flown. Confirmed 2026 dates in my pull included 2026-01-01, 2026-04-03, 2026-05-04, 2026-05-25, 2026-08-31, and 2026-12-25.

When to use it: anything UK. Just pick the right division.

4. Enrico / Kayaposoft: wide country coverage, thin in places

Enrico covers a long list of countries from community-maintained data, which is its strength and its weakness. I include it with a warning attached, because it taught me a lesson worth passing on.

# runnable, read-only
curl "https://kayaposoft.com/enrico/json/v2.0/?action=getHolidaysForYear&year=2026&country=usa&holidayType=public_holiday"

[{"date":{"day":19,"month":6,"year":2026,"dayOfWeek":5},
  "name":[{"lang":"en","text":"Juneteenth National Independence Day"}],
  "holidayType":"public_holiday"}]

That is the entire response. One holiday for the whole of 2026 for the United States. Not one page, one holiday. I almost shipped that as "US holidays for 2026" before cross-checking against Nager, which returned the full set. Community data is sparse in spots, so treat Enrico as breadth-of-countries, not depth, and never trust a suspiciously short list from any single holiday source. Verify current coverage at kayaposoft.com/enrico.

When to use it: reaching a country the others do not cover, with a cross-check in place.

Group B: time zones and current time (schedulers, display, DST math)

Two keyless services answer "what time is it, really, over there," and one of them does the DST arithmetic you would otherwise get wrong.

5. TimeAPI.io: current time for any IANA zone, with a DST flag

Give TimeAPI.io an IANA time zone name and it returns the current local time plus a dstActive flag. That flag is the reason to call it instead of hardcoding an offset.

# runnable, read-only
curl "https://timeapi.io/api/time/current/zone?timeZone=America/New_York"

{"year":2026,"month":7,"day":4,"hour":14,"minute":26,"seconds":30,
 "dateTime":"2026-07-04T14:26:30.2654687","timeZone":"America/New_York",
 "dayOfWeek":"Saturday","dstActive":true}

On July 4 it returned "dstActive":true, because New York is on daylight time in summer. If you had stored a fixed UTC offset for "New York" you would be an hour off for half the year. The service also does zone conversion over POST:

# runnable, read-only
curl -X POST "https://timeapi.io/api/conversion/converttimezone" \
  -H "Content-Type: application/json" \
  -d '{"fromTimeZone":"America/New_York","dateTime":"2026-07-04 14:00:00","toTimeZone":"Europe/London","dstAmbiguity":""}'

{"fromTimezone":"America/New_York","fromDateTime":"2026-07-04T14:00:00",
 "toTimeZone":"Europe/London",
 "conversionResult":{"dateTime":"2026-07-04T19:00:00","timeZone":"Europe/London","dstActive":true}}

2:00 PM in New York maps to 7:00 PM in London, with both ends flagged as on daylight time. One honest note: this is a live clock, so the hour and minute above have already moved. Run the curl yourself; free clock endpoints drift by the second and the shape is the point, not my timestamp. No key on the free tier; be reasonable and verify current limits at timeapi.io.

When to use it: any scheduler or display that must respect DST for a named zone.

6. WorldClockAPI: a plain authoritative "now"

WorldClockAPI is the minimalist option. It hands you an authoritative UTC "now" and a few useful extras, and nothing more.

# runnable, read-only
curl "http://worldclockapi.com/api/json/utc/now"

{"$id":"1","currentDateTime":"2026-07-04T18:26Z","utcOffset":"00:00:00",
 "isDayLightSavingsTime":false,"dayOfTheWeek":"Saturday","timeZoneName":"UTC",
 "currentFileTime":134276632058538289,"ordinalDate":"2026-185","serviceResponse":null}

Two caveats. First, the endpoint I hit is HTTP only, no TLS, so do not send anything sensitive and do not depend on it inside a strict HTTPS-only pipeline. Second, it is deliberately thin; there is no rich zone math here. What it is good for is a quick sanity anchor ("what is the authoritative now?") plus the extras: ordinalDate gives you 2026-185 (day 185 of the year) and currentFileTime gives you a Windows FILETIME if you need one. Same live-clock caveat as above: re-run it, the timestamp has moved. Verify current status at worldclockapi.com.

When to use it: a lightweight UTC anchor and day-of-year, when you do not need per-zone conversion.

Group C: alternative calendars (i18n and religious calendars)

Two keyless converters turn a Gregorian date into a Hebrew or Islamic one. Both are signup-free, and both have a field that decides whether you are right or off by a day.

7. Hebcal: Gregorian to Hebrew, plus the weekly Torah portion

Hebcal converts a Gregorian date to the Hebrew calendar and throws in the week's Torah reading for free.

# runnable, read-only
curl "https://www.hebcal.com/converter?cfg=json&gy=2026&gm=7&gd=4&g2h=1"

{"gy":2026,"gm":7,"gd":4,"afterSunset":false,"hy":5786,"hm":"Tamuz","hd":19,
 "hebrew":"…","events":["Parashat Pinchas"]}

July 4, 2026 is 19 Tamuz 5786, in the week of Parashat Pinchas. The field that matters is afterSunset. The Hebrew date rolls over at sunset, not midnight, so if your event happens in the evening you must pass gs=on (or set afterSunset correctly) or your conversion lands a day early. Miss that and the bug only shows up for evening timestamps, which is a miserable one to debug. Keyless; cache and be polite. Verify at hebcal.com.

When to use it: rendering or converting Hebrew dates, especially near sunset.

8. Aladhan: Gregorian to Hijri, and it tells you its method

Aladhan converts a Gregorian date to the Islamic (Hijri) calendar. Its honesty is the feature: it tells you which calculation method it used.

# runnable, read-only
curl "https://api.aladhan.com/v1/gToH/04-07-2026"

{"code":200,"status":"OK","data":{
 "hijri":{"date":"19-01-1448","day":"19",
  "month":{"number":1,"en":"Muharram","days":29},
  "year":"1448","designation":{"abbreviated":"AH"},"method":"HJCoSA"},
 "gregorian":{"date":"04-07-2026","weekday":{"en":"Saturday"}}}}

July 4, 2026 comes back as 19 Muharram 1448 AH, and the response labels its method as HJCoSA. Here is the caveat that keeps you honest: the Hijri calendar is calculation-method dependent, and month length flips between 29 and 30 days. The API is transparent about which method it applied, so do not treat a single call as the one canonical answer for religious observance, which may depend on local moon sighting. Same date, two calendars: Aladhan says 19 Muharram, Hebcal says 19 Tamuz, and both are correct in their own system.

When to use it: displaying or storing Hijri dates, with the method recorded alongside.

Group D: solar day-length (the bonus temporal utility)

One more keyless endpoint, and it is the one that opened this post.

9. Sunrise-Sunset: sunrise, sunset, and the UTC trap

Sunrise-sunset.org returns sunrise, sunset, solar noon, and day length for any latitude and longitude. It is genuinely useful and it hides the single best example of a silent-wrong response on this whole list.

# runnable, read-only
curl "https://api.sunrise-sunset.org/json?lat=40.7128&lng=-74.0060&date=2026-07-04"

{"results":{"sunrise":"9:28:49 AM","sunset":"12:32:13 AM","solar_noon":"5:00:31 PM",
 "day_length":"15:03:24"},"status":"OK","tzid":"UTC"}

A sunset at 12:32 AM. For New York in July, that is nonsense on its face, and it is a clean HTTP 200. The tell is "tzid":"UTC": the times are in UTC by default, and New York in summer is four hours behind. Pass the zone and it snaps into place:

# runnable, read-only
curl "https://api.sunrise-sunset.org/json?lat=40.7128&lng=-74.0060&date=2026-07-04&tzid=America/New_York"

{"results":{"sunrise":"5:28:49 AM","sunset":"8:32:13 PM",
 "day_length":"15:03:24"},"status":"OK","tzid":"America/New_York"}

Now sunrise is 5:28 AM and sunset is 8:32 PM, which is a real July day in New York. Note day_length was correct both times (15 hours, 3 minutes); only the wall-clock fields shifted. Pass formatted=0 if you want ISO 8601 timestamps instead of the "AM/PM" strings. This is the failure mode the whole post is about: not a 500, not a 404, just a 200 with values that look broken until you read one field.

When to use it: daylight-aware scheduling, solar features, "golden hour" logic. Always send tzid.

Why some "free" holiday and time APIs did not make the cut

The list stays honest by showing what it rejected. Every code below is from a live curl on July 4, 2026.

Calendarific (calendarific.com/api/v2/holidays?country=US&year=2026) returned HTTP 401 {"meta":{"code":401,"error_type":"auth failed","error_detail":"Missing or invalid api credentials..."}}. It is a popular holiday API, but it wants a key. Excluded.
WorldTimeAPI.org (worldtimeapi.org/api/timezone/America/New_York) was the classic keyless time option for years. It returned HTTP 000, connection failed, on repeated retries over both HTTPS and HTTP, including a fresh re-curl right before publishing. It is unreachable at test time, so it stays off the list. Use TimeAPI.io or WorldClockAPI instead, and if worldtimeapi.org comes back, verify it yourself before wiring it in.
ipgeolocation.io time API is key-gated per its docs, so it never made the shortlist for a "no key" roundup.

Keeping these right under real traffic

The endpoint is the easy part. Reading the fields is the job. A few habits that have saved me:

Filter on the scope field, every time. Nager gives you global. OpenHolidays gives you nationwide and subdivisions. gov.uk gives you three divisions. Skip that field and you will show a regional holiday to a national audience, or count Good Friday twice. The scope field is the answer, full stop. Read it every time.

Always pass the zone. Sunrise-Sunset defaults to UTC. Hebcal rolls at sunset via afterSunset. Aladhan records a method. Time is never "just a number," and the query parameter you omit is the bug you ship. Send tzid, send gs, read method.

Never trust a single temporal source blind. Enrico handed me one US holiday for a year. OpenHolidays handed me an empty array for the US. Both were HTTP 200. Cross-check a suspiciously short or empty list against a second source before it reaches a user. This is the same silent-wrong trap I hit with keyless geocoding: the danger is not the honest error, it is the confident 200 with the wrong body.

Cache what is stable, re-fetch what moves. Holiday lists and calendar conversions for a fixed date do not change, so cache them hard. The two live clocks (TimeAPI.io, WorldClockAPI) move by the second, so never cache "now." Mixing those two policies up is its own class of bug.

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 output is always a list of rows that need enrichment columns. Location was the geocoding column. Security posture was the CVE column. Time and calendar is this one. Same keyless, no-card enrichment layer, different question, and the same failure mode every time: a 200 that is empty or wrong, never an honest 500.

FAQ

What is the best free public holiday API with no API key?
It depends on coverage. Nager.Date is the broadest for country-plus-year lists worldwide, OpenHolidays gives the richest EU subdivision detail (but returns an empty 200 outside Europe), and gov.uk covers the UK straight from the government. All are keyless, no signup.

Is there a free time zone API without an API key?
Yes. TimeAPI.io returns the current time for any IANA zone with a dstActive flag and does zone conversion over POST. WorldClockAPI gives a plain authoritative UTC "now" (over HTTP only). Both are keyless.

Why does the holiday API return an empty list for the US?
OpenHolidays covers European countries only. A request with countryIsoCode=US returns HTTP 200 with an empty array [], not a 404, so it looks like "no holidays" when it means "no coverage." Use Nager.Date or Enrico for the US.

How do I get sunrise and sunset times for free?
sunrise-sunset.org, keyless, by latitude and longitude. The times are UTC by default, so a New York sunset can read as "12:32 AM." Pass tzid=America/New_York for local time, and formatted=0 for ISO timestamps.

Can I convert a date to the Hebrew or Islamic calendar without a key?
Yes. Hebcal converts Gregorian to Hebrew (watch the afterSunset field, since the Hebrew day rolls at sunset) and adds the weekly Torah portion. Aladhan converts Gregorian to Hijri and records the calculation method it used. Both are keyless.

Written by Aleksei Spinov. I build web-scraping and data-enrichment tool layers, currently 2,190 runs across 32 actors in production. Every API above was re-verified with a live curl (HTTP 200, real response) on July 4, 2026 before publishing; responses are trimmed, not paraphrased. Holiday and calendar values for a fixed date are stable, but the two live clocks (TimeAPI.io and WorldClockAPI) move by the second, so run the curl yourself before you wire one in. Drafted with an AI assistant, fact-checked and edited by me.

Follow for the next batch of keyless tools I test for the enrichment layer. And tell me: which temporal source has quietly lied to you with a clean 200, and what field finally gave the bug away? I read every comment.

DEV Community: Alex Spinov

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

Where the alarm stops working

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

The residual I could not explain

What I nearly published and had to take back

This is not the response-envelope post

Honest limits

The open question

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

The one idea in this post

The 10, at a glance

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

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

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

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

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

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

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

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

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

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

The field that lies about the law: isPublicDomain

The fix: read the value, not the name

Flagged: three "free" APIs that still want a key

Why not on the list: two that tutorials still recommend

So what do you actually do?

FAQ

11 Free Space & Astronomy APIs With No Key (2026)

The one idea in this post

1. Where the ISS at: the one that was right, and could not have told you

2. CelesTrak: the orbital elements everything else is built from

3. TLE API: the same satellite, twice as stale

4. JPL SSD/CNEOS: four keyless endpoints, and errors hidden inside 200s

5. JPL Horizons: professional ephemerides, wrapped in a lie about JSON

6. NASA Exoplanet Archive: 6,319 planets, 39,978 rows, and a real query language

7. NASA Image and Video Library: the NASA API everyone forgets is keyless

8. NOAA SWPC: the "current" geomagnetic index that cannot be current

9. Launch Library 2: 364 upcoming launches, and a rate limit that will find you

10. SatNOGS DB: the open satellite catalog with an honest updated field

11. SIMBAD: the object database where Andromeda is not a "Galaxy"

Flagged: api.nasa.gov is not keyless, DEMO_KEY is not "no key"

Why not on the list: three APIs the tutorials still recommend

The gate: read the timestamp out of the body

Where the gate fails, and the arbiter I got wrong

The arbiter that proved nothing

The arbiter that is at least a different implementation

So what do you actually do?

FAQ

11 Free Music APIs With No Key or Signup (2026)

1. MusicBrainz: the score of 100 that means "string matched," not "right recording"

2. Cover Art Archive: the hit is a 307 and the miss is a 404, never a plain 200

3. iTunes Search: it never says "no match," it fuzzy-matches your typo

4. Deezer: the 200 that carries an error object in its body

5. Lyrics.ovh: keyless and simple, and the flakiest host on this list

6. lrclib: time-synced lyrics, and the search that ranks a B-side first

7. Radio Browser: a directory that lists dead streams at 200

8. Open Opus: classical metadata that the pop APIs get wrong

9. ListenBrainz: open listening history you can read without a token

10. AcousticBrainz: real audio features, from a dataset frozen in 2022

11. Odesli / song.link: cross-platform links that change by country

Why not on the list: one shared key and five paywalls

Why does results[0] keep handing you the wrong song?

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

1. Open Trivia DB: the 200 that lies in `response_code`

8. Deck of Cards: HTTP 200 with `success: false`

5. Unpaywall: a 200 with `best_oa_location: null` is not a free PDF

6. DOAJ: `total: 0` means "not in an OA journal we index," not "no such paper"