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: