How a static API works
— and where it stops.

What "static" actually means

A normal API computes each response on demand: a request comes in, code runs, a database is queried, JSON comes out. A static API flips the order — every possible response is computed ahead of time and written to a file. At request time there is no code and no database, just a CDN handing you a file it already has. Our generator turns curated datasets into one file per collection and one per record, plus an .json twin so browsers render them nicely:

GET /api/animals/lion     # a single record, precomputed
GET /api/animals/index    # the whole collection, precomputed
GET /api/index            # the catalog of every API

Because the answer already exists, serving it is just a file read at the edge. That's why it can't buckle under load, can't rate-limit you, and costs almost nothing to run.

Hosting: GitHub Pages → Cloudflare

We started on GitHub Pages — free and instant, but with a soft ~100 GB/month bandwidth limit meant for modest sites. A "free forever" API can't have a bandwidth ceiling, so we moved the front door to Cloudflare Pages, which serves static assets with unlimited bandwidth from a global edge. GitHub stays the source of truth; Cloudflare serves it. A tiny _headers file makes every clean URL return real application/json with open CORS. The story page has the full journey.

The limitations we know exist

We'd rather tell you the trade-offs than pretend they aren't there. A static API cannot:

• Filter, search or sort on the server. There's no server. You fetch a collection and filter it client-side. (Our datasets are small enough that this is instant.)
• Paginate or return partial responses. A collection is one file — you get all of it. Great for caching, less great for very large datasets.
• Accept writes. It's read-only: only HTTP GET. No POST, no PUT, no auth-gated mutation.
• Authenticate users or rate-limit them. With no server and no keys, there is nobody to identify and nothing to throttle. That's a feature and a constraint.
• Serve volatile/real-time data. Everything is precomputed, so it's reference data (taxonomy, elements, capitals) — never live prices or feeds.
• Do content negotiation. Every record ships as JSON; there's no per-request XML/CSV.

For the data GratisAPI serves, these are the right trade-offs. But some of them are exactly what a second, dynamic API would fix.

The two APIs we offer

The static API will always stay free and unlimited. The dynamic API is the interesting engineering problem: the moment code runs per request, each request has a (tiny) cost, and — without API keys — it's genuinely hard to stop one heavy user from spending the budget. We think that's a solvable, worthwhile problem, and we'd rather solve it in the open. The cost page lays out the numbers and how it'll be funded.

What it costs →   Read the story →