new to free APIs?
here's the whole idea.
An API is a machine-readable way to ask someone else's computer for fresh data — weather, exchange rates, photos, facts. You send a request to a web address; it sends back a structured answer your project can use.
think of it as a waiter: you order "weather for London", the kitchen (the API) brings the numbers — not a full restaurant website.
What is an API?
A normal website is built for human eyes — layout, buttons, ads. An API is the same company's data shelf, opened for programs. Instead of HTML pages you getJSON: neat labeled fields like temperature: 14.2 that software can read instantly.
Thousands of organizations publish free public APIs — no payment for modest use, often no account. Students, hobby sites, and startups use them to add live features without running their own weather station or currency feed.
How a request works
- 01You choose a URL
Every API documents an address to call — like
api.open-meteo.com/…/forecast. That's the menu item. - 02You ask a question in the query
Parameters narrow it down: city, currency pair, how many results. The docs list what's allowed — latitude, symbol, limit, etc.
- 03The server answers with JSON
If it's working, you get a 200 response and a JSON body — text wrapped in
{ }brackets with keys and values. - 04Your project displays or stores it
A chart, a table, a chatbot, a phone widget — the API did the fetching; you decide how it looks.
A real answer (weather)
Paste a URL in your browser tab and you'll often see raw JSON. Here's what a small slice looks like — the kind of payload behind a "14°C in London" label:
{
"latitude": 51.5,
"longitude": -0.12,
"current_weather": {
"temperature": 14.2,
"windspeed": 12.4,
"weathercode": 2
}
}every listing here links to the provider docs and, when we probe it, a live sample you can run in the browser.
Website vs API
- Designed for people reading in a browser
- Pages, images, navigation, styling
- Example: a news homepage
- Designed for apps and scripts fetching data
- Usually JSON — keys and values, no layout
- Example: the same site's headline feed as JSON
Do you need to code?
No, to explore. Open any API page here, read what it returns, and hit Run live when we support it — you'll see real JSON without writing a line.
A little, to ship. Most projects use a few lines in JavaScript, Python, or similar to fetch the URL and place the result on screen. Tutorials usually start with "no key" APIs like the ones we flag in browse.
Filters that help beginners: No key · Free key · Browser OK · Probed by us
Pick one example project — each opens a listing with docs, health, and a sample call.
What shipapis adds
Directories alone are lists of links. We probe endpoints on a schedule — did it respond? how fast? did the JSON shape change? — and show uptime, latency, and a health score on every listing. When an API dies, we log it in the graveyard so old tutorials make sense.
317 APIs are actively probed today; 720 more are catalogued with docs links while we expand coverage. Filter for probed when you want numbers backed by checks.
What you can make
Pick a topic
How to read a listing
- Health score
- 0–100 blend of uptime, speed, and whether responses still match the documented shape. Higher is safer to depend on.
- Status
- Healthy = passing checks. New = recently added to monitoring — early scores still settling. Dying / Dead = failing or gone (see graveyard).
- Probed vs catalogued
- Probed = we run scheduled checks. Catalogued = verified docs link, not yet on the probe rotation.
- No key
- No signup or API token required for basic use — the friendliest starting point.
- Browser OK (CORS)
- Callable directly from a web page without your own backend proxy.
- Uptime
- Share of our probes that succeeded over the last 90 days (probed APIs only).
Next steps
You know what an API is — here's where to go from here.
methodology and probe rules live on /methodology — this page is the plain-English layer on top.