Is Major Cooked? Free AI risk score + roast for your college major
Solo Era solo activities, solo maxxing, sidequests, challenge
Keepsake Project Management, Freelancers, DesignersAPI project ideas: 12 builds with free public APIs and your own
The best API projects use a free API that needs no payment, handle its limits politely and add something the API alone does not give you. Good starting points are Open-Meteo for weather, the USGS earthquake feeds, Frankfurter for exchange rates, Open Library for books and Nager.Date for holidays. Below are 12 projects, nine that call a documented public API and three where you build one, each with the stack, what it teaches, a first version, a stretch goal and a time estimate.
What makes a good API project?
Any tutorial can fetch JSON and print it. A project worth showing treats the API as an unreliable neighbour: it caches, retries with a delay, reads the usage rules and keeps any secret key on a server. The API's data is the raw material, and the part you add, such as a comparison, an alert or a history, is the product.
| API | Key needed? | The catch, from its own docs |
|---|---|---|
| Open-Meteo | No, for non-commercial use | Commercial use needs a different licence |
| USGS earthquakes | No | Query API caps results at 20,000 events; feeds are meant for display |
| Frankfurter | No | Open source; self-host if you need control |
| Open Library | No | Cache, identify your app in the User-Agent, no bulk single-book calls |
| PokéAPI | No | Fair use: cache resources locally |
| NASA APOD | Yes, free key; DEMO_KEY for trials | Rate limits apply per key |
| Hacker News | No | Documented as having no rate limit at present |
| MusicBrainz | No | Needs a meaningful User-Agent; free for non-commercial use |
| Nager.Date | No | Public holidays only |
Before you pick an API, read its terms page for the three things that break projects: whether commercial use is allowed, whether you must show attribution, and how hard you may call it. Other free options worth a look are the Met Museum collection API (no key; it asks you to stay under 80 requests per second), the Art Institute of Chicago API (with a public-domain filter and image service), TheMealDB (test key 1 for development and learning), the National Weather Service API (requires a User-Agent) and the Sunrise-Sunset API (requires a visible attribution link). A community-maintained index lives in the public-apis repository; verify each entry yourself, since APIs change terms and some now require keys.
Write a small client module for the Open Library search API in TypeScript. Rules: - Send a User-Agent that names the app and a contact email, read from an environment variable. - Cache each response on disk for 24 hours, keyed by the full URL. - Time out after 10 seconds. On a 429 or 5xx, retry up to 3 times with exponential backoff and jitter. - Never fire more than 1 request per second. - Expose one function: searchBooks(query, limit) returning title, authors, firstPublishYear, coverId. Do not build: a UI, a database, scraping of HTML pages. Done when: a test with a mocked fetch shows two identical calls hit the network once, and a 429 triggers a retry.
Not sure which one to build? Pick a real problem. Many posts on the board of ideas boil down to "fetch a thing, compare it, tell me when it changes", which is exactly an API project. For a broader menu, see coding project ideas.
Which API projects call a free public API?
These nine each pair one documented API with a job that gives the data a reason to exist. They are ordered roughly from easiest to most involved.
01 Will my commute be dry?
Show the chance of rain for the two hours you travel, for each day of the coming week.
- API
- Open-Meteo forecast: hourly variables, up to 16 forecast days, no key for non-commercial use.
- Stack
- JavaScript or Python, a small web page, a scheduler for the stretch.
- Teaches
- Query parameters, time zones, hourly arrays, caching.
- Time estimate
- 6 to 10 hours.
First version: hard-code your coordinates and commute hours, request the hourly precipitation probability, and show a red or green dot for each commute window. Pass the timezone parameter so that hours match your local clock.
Stretch: let people save a place and times, cache each location's response for 30 minutes, and send a morning message only when the probability crosses a threshold you choose.
02 Earthquake watch with a threshold alert
A live map of recent quakes that tells you only about the ones above your chosen magnitude near a place you care about.
- API
- USGS GeoJSON feeds, updated every minute, and the event query API.
- Stack
- JavaScript with a map library, or Python with a small web server.
- Teaches
- GeoJSON, polling, deduplication by event ID, distance maths.
- Time estimate
- 8 to 12 hours.
First version: fetch the past-day feed for magnitude 2.5 and up, draw markers sized by magnitude and list the ten latest with time and place.
Stretch: poll every minute, remember event IDs so that you alert once per quake, and handle revisions, because the feed updates magnitudes after the first report. USGS advises automated applications to use the feeds for display rather than the query API.
03 A trip budget in two currencies
Enter a budget in your currency and see each expense in the local one, with the rate and date shown.
- API
- Frankfurter: free exchange rates, no API key, open source and self-hostable.
- Stack
- Any front end, a tiny server route, SQLite for history.
- Teaches
- Money as integers, rounding, historical lookups, caching rates by date.
- Time estimate
- 6 to 10 hours.
First version: one form with an amount, two currencies and a result that states the date of the rate. Store amounts as whole minor units, not floats.
Stretch: plot a 90-day series for a currency pair with the API's time-series endpoint and let users record what they actually paid, so the app shows the gap between the day's rate and their card's rate.
04 ISBN to bookshelf
Type or scan a list of ISBNs and get a shelf of titles, authors and covers you can sort and export.
- API
- Open Library: search, covers and edition APIs; asks you to cache, identify your app and avoid hundreds of single-book calls.
- Stack
- TypeScript or Python, SQLite, a camera barcode library for the stretch.
- Teaches
- Batching, caching, partial matches, data cleaning, rate etiquette.
- Time estimate
- 10 to 15 hours.
First version: one ISBN in, title, author and cover out, stored locally. Reuse the polite client from the prompt above.
Stretch: import 200 ISBNs from a CSV using the search endpoint in batches rather than one call each, flag the ones that do not match, and add a barcode scan on a phone.
05 Type coverage checker for a team of six
Pick six creatures and see which attack types the team resists, which it is weak to and which gaps remain.
- API
- PokéAPI: read-only, no authentication, asks you to cache resources locally.
- Stack
- TypeScript or Python, a JSON file as cache.
- Teaches
- Following links between resources, pagination, the N+1 request problem, offline caches.
- Time estimate
- 8 to 12 hours.
First version: for six chosen names, fetch each one's types, then each type's damage relations, and render a table of weaknesses and resistances with a total per row.
Stretch: build a script that downloads the whole set once into a local JSON file, so the app runs without calling the API at all. That respects the fair use policy and makes the app fast.
06 A space picture archive with your own key proxy
Browse every astronomy picture of the day by date, with a server that keeps the key out of the browser.
- API
- NASA APOD: needs an api.data.gov key from api.nasa.gov; DEMO_KEY works for trials. Dates start on 1995-06-16.
- Stack
- Node or Python server, a static page, a disk cache.
- Teaches
- Keeping keys on the server, rate limits, date edge cases.
- Time estimate
- 6 to 10 hours.
First version: a server route that requests a date and returns the picture, title and explanation, plus previous and next buttons that handle the first and last dates.
Stretch: cache every date on disk after the first request, add a random-date button, and return a helpful message when the key's limit is hit instead of a blank page.
07 Hacker News front page time-lapse
Snapshot the front page every ten minutes and chart how each story rises and falls.
- API
- Hacker News API: top stories list plus one request per item; documented as having no rate limit at present.
- Stack
- Python or Node, SQLite, a scheduled job, a charting library.
- Teaches
- Scheduling, fan-out requests, concurrency limits, time-series storage.
- Time estimate
- 10 to 15 hours.
First version: every ten minutes, read the top 30 story IDs, fetch each item and store its rank, score and comment count with a timestamp.
Stretch: draw a rank-over-time line per story, compute time to peak, and keep your own polling gentle even though the API does not currently force you to.
08 Discography gap finder
Compare an artist's full release list with the albums you own, and list what is missing.
- API
- MusicBrainz: free for non-commercial use, no key, but a meaningful User-Agent is required.
- Stack
- Python or TypeScript, a CSV of your library, SQLite cache.
- Teaches
- Identifiers, fuzzy matching, retries with backoff, working inside a rate limit.
- Time estimate
- 12 to 18 hours.
First version: search for one artist, list their release groups of type album, and mark which titles appear in your CSV after normalising case and punctuation.
Stretch: handle live albums, deluxe editions and reissues so they do not count as separate gaps, retry politely when the server answers with a temporary error, and cache everything.
09 Long-weekend planner
Find the bridge days that turn a midweek holiday into a four- or five-day break, for any country and region.
- API
- Nager.Date: public holidays for over 200 countries, no key, no stated rate limits, CORS enabled.
- Stack
- TypeScript, a calendar view, an iCalendar export for the stretch.
- Teaches
- Date arithmetic, weekends that differ by country, regional filters, ICS files.
- Time estimate
- 8 to 12 hours.
First version: fetch a country's holidays for a year and list those on a Tuesday or Thursday with the single day to take off that creates the longest break.
Stretch: filter by region using the subdivision codes in each holiday record, rank bridge plans by days off gained per day taken, and export the chosen plan as a calendar file.
Which API projects involve building the API yourself?
Calling an API shows you can read documentation. Building one shows you can make the decisions behind it: limits, caching, contracts. These three are the server-side counterpart of the nine above, and each can sit in front of one of them.
01 A rate-limited API with keys and usage metering
A small public API that issues keys, limits each key and shows its owner how much they used.
- Stack
- Node, Go or Python; Postgres or Redis for counters.
- Teaches
- Authentication by key, fixed-window and token-bucket limits, status 429, usage reporting.
- Time estimate
- 20 to 30 hours.
First version: an endpoint that needs an API key header, counts requests per key per minute and answers status 429 with a Retry-After header when the limit is passed. The status itself is defined in RFC 6585.
Stretch: switch to a token bucket so short bursts are allowed, store hashed keys only, add a usage page per key and write a test that fires 200 concurrent requests to prove the counter does not drift.
02 A caching layer for a slow upstream, with ETag support
Put your own API in front of another one so repeated calls are fast and clients can ask whether anything changed.
- Stack
- Any server framework, an in-memory or Redis cache.
- Teaches
- HTTP caching headers, conditional requests, request coalescing, stale data trade-offs.
- Time estimate
- 12 to 20 hours.
First version: wrap one Open Library search in your own route. Return an ETag, and answer a matching If-None-Match header with status 304 and no body.
Stretch: serve stale data for a minute while you refresh in the background, as described under Cache-Control, and make 50 identical simultaneous requests produce a single upstream call.
03 An OpenAPI-first bookmarks API with contract tests
Write the specification before the code, then prove the running server obeys it.
- Stack
- Any language, an OpenAPI 3 file, Schemathesis, oasdiff.
- Teaches
- Contract-first design, validation, error formats, spotting breaking changes.
- Time estimate
- 15 to 25 hours.
First version: write the OpenAPI file for four endpoints (create, list, get and delete a bookmark), including error responses, then implement the server and test every response against the file.
Stretch: run Schemathesis to generate odd inputs from the spec, and add oasdiff to CI so a pull request that breaks existing clients fails the build.
How do you finish an API project and show it off?
- Record one real response in the repository and test against it, so your tests do not need the network.
- Put the API's licence and attribution requirements in your README, in the words its docs use.
- Show the numbers: cache hit rate, calls saved, time to first byte. They prove the engineering.
- Keep keys out of the front-end bundle. A browser can read everything it receives.
- Deploy it, and put the live link above the fold.
If you build with an AI coding tool, paste the polite-client rules into your first prompt and ask for the tests with it. The guide to writing an app build prompt shows how to state limits and a done-when line. For data to analyse rather than serve, see data science project ideas, and for apps with models inside, AI project ideas.
Frequently asked questions
What are good API projects for beginners?
Start with a keyless API and a single screen, such as the commute rain check with Open-Meteo or the trip budget with Frankfurter. They need one request, one result and a clear rule for done. Add caching and error handling once the first version works.
Which free APIs need no API key?
Open-Meteo for non-commercial use, USGS earthquakes, Frankfurter, Open Library, PokéAPI, the Hacker News API, MusicBrainz and Nager.Date all work without a key as of October 2026. Some, like MusicBrainz and Open Library, still ask you to send an identifying User-Agent.
How do I keep an API key secret in a web project?
Call the API from a server route, store the key in an environment variable that is not exposed to the browser, and have the front end call your route. Anything shipped in client code can be read by visitors, including values prefixed for public use by your framework.
How do I handle API rate limits?
Cache responses, send fewer requests per page, retry only on temporary errors with exponential backoff and jitter, and respect any Retry-After header. Read the API's usage page first, because some limits are unpublished and a polite client is the safest choice.
Is it better to call an API or build one?
Do both over time. Calling an API teaches you to read documentation and handle failures. Building one teaches you to design limits, caching and contracts. A strong portfolio pairs them, such as an API of your own that wraps and caches a public one.
Can I use public APIs in a commercial product?
Only if the terms allow it. Open-Meteo and MusicBrainz, for example, have separate arrangements for commercial use. Read the terms page for each API, keep attribution where it is required, and treat this page as general information, not legal advice.
Created with AI assistance and edited for this site. Examples are illustrative and do not represent customer research. About the publisher.