Take a mobile screen that lists orders: a customer name, a status, a total, a date. The endpoint behind it returns 100 KB for one page, because the vendor’s schema carries about sixty fields per order, plus nested addresses, hypermedia links and an audit trail. The phone downloads all of it over whatever connection it has, parses all of it, and keeps five fields. You can’t change the vendor’s API. You can change what reaches the phone.

You’re about to refactor the billing endpoints. The service has a few dozen tests, mostly happy paths, and nobody trusts them to catch a changed rounding rule or a renamed field. Writing better ones by hand means reading every handler and inventing inputs. Meanwhile production receives thousands of real inputs a minute, and each one comes labelled with the response your current code gives.

Capturing that traffic is the easy part; a proxy, a packet tap or a log line with the body in it will do. The product is everything after. Ten minutes of traffic holds thousands of near-duplicate requests and a handful that exercise something different, and a tool is only useful if it can tell them apart. Cluster by endpoint, request shape and response shape. Pick representatives that cover the status codes and branches. Assert only on fields that are stable. Mock the downstream calls. What comes out is a few dozen characterization tests (Michael Feathers’ name for tests that pin down what code does today).

An API’s documentation lists the fields a record can have. It rarely tells you how many records actually have them. Those are different numbers, and on open data APIs the gap is often enormous.

The failure looks like this. You read the schema, spot a field that would make a great feature, build the feature, and then discover the field is populated on four percent of the data. By then the feature is written and the pitch has been made.

Build-time fetching handles most third-party data on a static site. It falls down in one specific case: content that should change on a schedule you are not rebuilding on. A page showing twelve rotating items each day, with a weekly deploy cadence, cannot get its data from the build.

The naive fix puts a fetch in the browser. Every visitor then hits the upstream API directly, which burns through rate limits, exposes any key you are using, and leaves the page empty when the provider has a bad afternoon.

Most tutorials that put third-party API data on a static site reach for client-side JavaScript. The page loads, a fetch runs, and content appears a moment later. It works, and it throws away most of what a static site is for. Search engines see an empty container, every visitor costs you an upstream request, and a rate limit or an outage at the provider becomes a broken page for everyone.

GBIF is one of the better open data APIs. No key, no registration, generous limits, and well over a billion species occurrence records, a large share of them carrying photographs. It is an obvious source if you need images of living things and you do not want to pay a stock library.

There is a trap in the default response, and it is the kind that does not surface until someone sends you a letter.

USAspending publishes every federal award the United States government makes, and the API needs no key, no registration and no authorization header. That combination is rare enough on government data that it is worth saying twice.

The thing that stops most people is the shape of the request. The interesting endpoints are POST, the body is a nested object, and a wrong field name gets you a 400 with little explanation. Here is the working version.

The Space Devs run Launch Library, a REST API covering orbital and suborbital launches worldwide, past and upcoming. No key, no signup, and a forward schedule that currently runs to 369 launches. If you need a dated calendar of something genuinely interesting, this is one of the easiest open APIs to consume.

The Endpoints

Base URL carries the version in the path:

https://ll.thespacedevs.com/2.3.0/

The three that matter:

launches/upcoming/     everything scheduled ahead
launches/previous/     everything flown
launches/              both
events/upcoming/       spacewalks, dockings, test fires

A minimal call:

Stripe charges per transaction. Twilio charges per message and per minute. OpenAI charges per token. Three companies, three completely different units of value, three pricing models built around what actually costs them money or reflects what the customer gets. Picking a monetization model for an API isn’t a marketing decision bolted on at the end — it shapes how the API gets designed in the first place.

Pay-per-call

The simplest model: charge a flat fee for every request, sometimes with volume discounts at higher tiers. Google Maps and most geocoding APIs work this way. It’s easy for a customer to understand and easy for a provider to bill, since usage tracking is just a request counter.

An API can pass every unit test in its suite and still break every client that calls it, because unit tests check that functions do what the code says they do, not that the API does what the contract says it does. That gap is where most production API incidents actually come from: a field renamed, a status code changed from 200 to 204, a required parameter quietly made optional. Testing an API well means testing at several different levels, because each one catches a different class of failure.