Free APIs Worth Building On (And How to Tell Before You Commit)

Every "top free APIs" list ages badly, because half the entries stop being free. The useful thing is not the list — it is the judgement.

Three signals worth more than the free tier

1. A published deprecation policy that has been honoured

Anyone can write "we will give twelve months' notice". The question is whether they have. Check whether previous versions were actually retired on the stated timeline, or whether v1 quietly stopped responding one Tuesday.

An API with several versions still running, years later, is telling you something real about how it treats dependants.

2. A paid tier that makes commercial sense

Counter-intuitive, but: a free API attached to a business that clearly makes money from the paid tier is safer than one with no visible revenue at all.

If you cannot work out how the API makes money, you are looking at either a loss leader that will be cut, or a data-collection product where you are the input.

3. Rate limits stated in numbers

"Reasonable use" is not a limit; it is a reservation of the right to cut you off without warning. A documented number — requests per minute, per day, per key — means someone thought about capacity, and it means you can plan.

Categories where free is genuinely reliable

• Public-sector and open data. Weather, geography, transport, statistics. Funded to exist rather than to grow. Often unglamorous to work with, and rarely withdrawn.
• Standards and reference data. Currency codes, country data, time zones. Slow-moving and frequently mirrorable, which removes the dependency entirely.
• Developer infrastructure with strong paid tiers. The free tier is marketing for the paid one, which is a stable arrangement as long as the paid one sells.

Categories where free is a trap

Anything where the data is the product. Company information, contact data, social graphs, aggregated pricing. The free tier exists to demonstrate value before the sales conversation, and it will be narrowed the moment your usage suggests you could pay.

Build so that leaving is cheap

The practical defence is one module and your own types:

// One file knows the vendor. Nothing else does.
export type Forecast = { tempC: number; summary: string; at: Date };

export async function getForecast(lat: number, lon: number): Promise<Forecast> {
  const res = await fetch(`${BASE}/v2/point?lat=${lat}&lon=${lon}`, {
    headers: { authorization: `Bearer ${process.env.WEATHER_KEY}` },
  });
  if (!res.ok) throw new Error(`Weather API ${res.status}`);
  const data = await res.json();
  return { tempC: data.temp_c, summary: data.text, at: new Date(data.ts) };
}

Everything downstream depends on Forecast, not on the vendor's field names. Swapping providers becomes a morning rather than a project. This is a small amount of work up front and it is the entire difference between an inconvenience and a migration.

Read the terms for the two clauses that actually bite

Most API terms are unremarkable. Two clauses decide whether a free tier is usable for what you are building, and both are easy to skip:

• Caching and storage limits. Some providers forbid storing responses beyond a short window, or require a refresh on a schedule. If your design assumes you can cache results for a month, a clause you did not read may make the whole architecture non-compliant.
• Attribution and display requirements. Free tiers frequently require visible credit, sometimes in a specific form, sometimes adjacent to the data itself. Fine if you know up front; awkward once the interface is designed.

A third, less common but more damaging: restrictions on commercial use, or on building something that competes with the provider. Check these before building rather than before launching.

Failure behaviour tells you more than an uptime number

A published uptime figure describes the good case. What matters is what the API does in the bad one, and you can find out in ten minutes:

1. Exceed the rate limit deliberately. Does it return a clear 429 with a Retry-After header, or a generic error you have to guess at? That difference decides whether your retry logic can be correct.
2. Send a malformed request. A useful error names the field. A useless one says "invalid request", and will cost you an afternoon at some point.
3. Request something that does not exist. A 404 is fine. A 200 with an empty body is a bug generator, because your code cannot distinguish "no result" from "broken".
4. Check whether errors ever arrive with a 200 status. Some APIs do this. If yours does, every layer of your error handling has to know.

Watch how the provider communicates

The best available predictor of whether an API will still be there and still be stable is not technical. It is whether the provider behaves like an organisation with customers.

• Is there a changelog, and is it current? A changelog that stops eighteen months ago is a stronger signal than any status page.
• Does the status page have real incident history? One that has never recorded an incident has never been honest.
• How were past breaking changes handled? Find the last major version bump and read what users said at the time. This is the single most informative twenty minutes in the whole evaluation.
• Is there a way to reach a human? Not for support — as evidence that somebody is accountable.

Free tiers rarely disappear overnight. They get quietly worse: limits tighten, the useful endpoint moves behind a paid plan, the docs stop being updated. The signals above catch that trajectory about a year before it becomes your problem.

The check before you commit

1. Find the changelog. Is it maintained?
2. Find the deprecation policy. Has it been honoured?
3. Find the pricing page. Does the business make sense?
4. Search for people complaining about limit changes. There will be some; the question is how they were handled.

Twenty minutes, and it is a better predictor than any list of recommendations, including this one. If what you are building is a small internal workflow rather than a product, you may not need to write code at all.