There is a particular moment in a small project when an API goes from being exciting to being a problem.
Everything works.
The request returns JSON.
The interface looks good.
The feature is finally doing what I wanted.
Then suddenly I start thinking about questions I should have asked before building it:
How many requests can I actually make?
What happens when I hit the limit?
Do I need an API key?
Can I use the free tier commercially?
Is the data licensed for what I’m doing?
Will the API still be available six months from now?
And perhaps the most important question:
What happens when someone other than me starts using the application?
That’s the part of working with free APIs that isn’t obvious from a five-minute tutorial.
A free API can be incredibly useful. It can also come with rate limits, attribution requirements, authentication rules, commercial-use restrictions, changing quotas and undocumented behaviour that becomes painfully obvious at the worst possible time.
So for WorkSmarto, I prefer looking at APIs from a practical angle.
Not simply:
“Here are 10 free APIs you can try.”
But:
“What can I realistically build with these, and what should I watch before putting them into a real project?”
This is my practical shortlist.
First: “free API” doesn’t mean “unlimited API”
This is the first thing I check.
There are several very different meanings of free:
- free for personal projects,
- free for non-commercial use,
- free up to a request limit,
- free with attribution,
- free during development,
- or genuinely free with an open-data licence.
Those are not interchangeable.
For example, Open-Meteo currently provides a free API for non-commercial use without requiring an API key, but its published free limits include 600 calls per minute, 5,000 per hour and 10,000 per day. Commercial use requires a paid plan.
That is a completely different proposition from “unlimited weather API.”
The API may cost me nothing.
My usage still has boundaries.
The free APIs worth knowing
For practical freelance and small-project work, I would keep an eye on APIs in these categories:
| API | Best use | Key needed? | Important limitation |
| GitHub REST API | Developer/project data | Optional for public data | Unauthenticated: 60/hour |
| Open-Meteo | Weather | No for non-commercial use | 10,000/day free limit |
| NASA APIs | Space/science data | DEMO key or own key | DEMO_KEY: 30/hour, 50/day |
| OpenWeather | Weather applications | Yes | Free plan has defined quotas |
| Dog API | Testing/image demos | No | Better for demos than business-critical data |
| Open-Meteo Geocoding | Location search | No for non-commercial use | Same usage/licensing considerations |
The table is deliberately conservative.
I’d rather recommend six APIs with clearly documented limits than give you twenty questionable “free API” websites whose terms haven’t been checked.
1. GitHub REST API
GitHub’s API is one of the most useful APIs I would reach for when building something around software projects, repositories, developer activity or public GitHub data.
And there’s an important distinction here.
You can make unauthenticated requests for public information, but GitHub currently limits those requests to 60 per hour.
Authenticated requests have a much larger primary limit of 5,000 requests per hour for a personal access token.
That difference is enormous.
The quick comparison
Authentication doesn’t mean “I can send unlimited requests.”
GitHub also has secondary rate limits. The documentation notes limits involving concurrency, requests to individual endpoints and compute resources.
The gotcha
Don’t build a loop that assumes:
“The API allows 5,000 requests, therefore I can fire 5,000 requests immediately.”
That’s not a good production strategy.
Cache results.
Paginate intelligently.
Avoid repeatedly requesting information that hasn’t changed.
And inspect GitHub’s rate-limit response headers.
GitHub specifically exposes headers such as:
- x-ratelimit-limit
- x-ratelimit-remaining
- x-ratelimit-reset
so an application can understand its current primary rate-limit status.
My practical verdict
Excellent API.
But I treat rate-limit handling as part of the feature rather than something to add later.
2. Open-Meteo
Open-Meteo is particularly interesting because it removes one of the annoying barriers developers often encounter with APIs:
API keys
For non-commercial use, its API doesn’t require a key or account.
It provides weather forecasts through a straightforward JSON API and can return hourly weather information for locations around the world.
The service currently integrates weather models from numerous national meteorological services, including ECMWF, NOAA, DWD, Météo-France, JMA and others.
That makes it much more interesting than a toy weather endpoint.
Current free limits
Open-Meteo publishes:
- 600 requests/minute
- 5,000 requests/hour
- 10,000 requests/day
- 300,000 requests/month
for its free API, with the free service restricted to non-commercial use.
That is plenty for many prototypes.
But don’t overlook the phrase:
non-commercial use
That’s one of the biggest gotchas in this entire article.
If I’m building something for a business, monetized website or client project, I need to read the current licence and commercial-use terms rather than assuming “free” means “free for everything.”
3. NASA APIs
NASA’s APIs are a fantastic example of how useful public data can become when it is made accessible through an API.
You can explore NASA data without authenticating, but NASA recommends signing up for a developer key if you’re going to use the APIs intensively.
The default rate limit for an API key is currently:
1,000 requests per hour.
There’s also a special DEMO_KEY for experimentation.
And this is where things get interesting.
The DEMO_KEY is much more restricted:
- 30 requests per hour per IP
- 50 requests per day per IP.
So if I’m just experimenting, that’s fine.
If I’m building a real application, I’d register for my own key.
The gotcha
Don’t accidentally leave DEMO_KEY in a real application simply because the prototype worked.
The documentation exists for exploration.
Production usage deserves its own credentials and proper rate-limit planning.
4. OpenWeather
OpenWeather is another widely known weather API.
I like it as an example because it demonstrates something important:
“Free” can mean several different things within the same API provider.
OpenWeather’s current pricing information lists a free weather-access option with 60 calls per minute and 1,000,000 calls per month for its free current-weather/forecast access.
At the same time, individual products have different limits and pricing.
For example, the provider’s current One Call 4.0 pricing describes the first 1,000 API calls per day as free, with additional calls handled under its paid model.
That’s why I wouldn’t write:
“OpenWeather gives you one million free calls.”
without explaining which product I’m talking about.
The quota is attached to the product and plan.
The gotcha
Always check the pricing page for the exact endpoint you intend to use.
Don’t assume the free allowance for one OpenWeather product automatically applies to another.
5. Dog API
This one is different.
I wouldn’t choose the Dog API for a serious business-critical system.
I would choose it because it’s a wonderfully simple API for learning.
The project provides an open collection of dog images and endpoints for:
- random images,
- breeds,
- sub-breeds,
- breed-specific image collections,
- and more.
It’s ideal for:
- learning fetch(),
- testing JSON parsing,
- building a simple API demo,
- testing cards and galleries,
- practicing asynchronous requests,
- or making a beginner project more interesting.
The gotcha
The problem with beginner-friendly APIs is that developers can start treating them as production infrastructure.
I wouldn’t.
If the project is genuinely dependent on the API, I want to understand its operational guarantees, availability and usage expectations.
For a tutorial?
Fantastic.
For the core backend of a business?
I’d look elsewhere.
6. Open-Meteo Geocoding API
This is worth mentioning separately because location search appears in far more projects than people initially expect.
You might need to turn:
“Guwahati”
into coordinates.
Or:
“London, UK”
into latitude and longitude.
Open-Meteo’s geocoding endpoint can search globally by city or postal code and return matching locations, coordinates, country information and related metadata.
That makes it useful for weather dashboards, location-based tools and prototypes.
The gotcha
Location names are messy.
A user may enter:
- a city with the same name in multiple countries,
- a spelling variation,
- a partial location,
- a postal code,
- or a name in another language.
Don’t blindly take the first result and assume it is correct.
Give the user a way to confirm the location when accuracy matters.
A bigger number doesn’t automatically mean a better API.
A 10,000-per-day allowance isn’t directly comparable with a 5,000-per-hour allowance.
The useful lesson is simply that rate-limit units matter.
The first gotcha: rate limits are not always one number
This is probably the most important lesson in this article.
Developers often say:
“The API limit is 5,000 requests.”
But that statement is incomplete.
It might mean:
- 5,000 per hour,
- 5,000 per day,
- 5,000 per month,
- 5,000 requests from one IP,
- 5,000 requests per authenticated user,
- or 5,000 requests for one specific endpoint.
And sometimes there are multiple layers.
GitHub is a good example.
Its documentation distinguishes primary rate limits from secondary rate limits.
So when I evaluate an API, I ask:
What is the unit?
What is the authentication scope?
Does the limit apply to my account, IP, application or endpoint?
Those questions matter more than the headline number.
The second gotcha: 429 is not a bug
Eventually, you’ll probably encounter:
HTTP 429 — Too Many Requests.
It’s easy to interpret that as:
“The API broke.”
Usually, it means your application asked for too much too quickly.
OpenWeather explicitly documents 429 responses when configured call limits are exceeded.
GitHub also documents 403 or 429 responses when primary or secondary rate limits are exceeded.
So my application shouldn’t panic.
It should respond intelligently.
Depending on the API, that may mean:
- respecting Retry-After,
- waiting,
- using exponential backoff,
- caching previous responses,
- reducing unnecessary requests,
- or waiting until the documented reset time.
The third gotcha: don’t put API keys in the frontend
This is an easy mistake when building a small project.
Suppose I have:
Browser
↓
API
and the API requires a secret key.
If I put the key directly into JavaScript shipped to the browser, the key isn’t really secret anymore.
Anyone who can inspect the application can potentially find it.
The safer architecture is usually:
Browser
↓
My backend
↓
Third-party API
The backend keeps the credential away from the client.
There are exceptions and special cases, but as a general production rule:
Secrets belong on the server, not inside publicly delivered frontend code.
GitHub makes the same point in its API documentation: client secrets should never be included in client-side code or code running on a user’s device.
The fourth gotcha: caching is your friend
One of the easiest ways to reduce API usage is also one of the easiest to forget.
Don’t request information that hasn’t changed.
Imagine I build a weather dashboard.
A user opens the page.
I request the weather.
Fine.
But then suppose the user refreshes the page five times in two minutes.
Do I really need five identical API requests?
Probably not.
Depending on the application, I might cache the response for a few minutes.
The same principle applies to:
- GitHub repository statistics,
- exchange rates,
- location metadata,
- public profile information,
- weather,
- and many other relatively slow-changing datasets.
Caching isn’t only about performance.
It can also protect your API quota.
The fifth gotcha: one user can become 1,000 users very quickly
A local prototype behaves differently from a public application.
Imagine my application makes one API request every time a visitor opens a page.
With one visitor:
1 request.
With 100 visitors:
100 requests.
With 1,000 visitors:
1,000 requests.
And if each visitor causes several requests, the numbers multiply.
That’s why I don’t calculate API usage based on:
“How many requests did my laptop make today?”
I calculate:
How many requests will one user generate, and how many users might I have?
Then I add a safety margin.
A simple API-capacity calculation
Suppose one user generates:
5 API calls per session.
And I expect:
500 sessions per day.
That’s:
5 × 500 = 2,500 API calls/day.
If the API’s documented free allowance is 10,000 calls per day, I appear to have room.
But that doesn’t mean I’m finished.
I’d still consider:
- traffic spikes,
- retries,
- background jobs,
- multiple API endpoints,
- failed requests,
- development traffic,
- and future growth.
A quota isn’t a target.
It’s a boundary.
The sixth gotcha: “free” may have a licence attached
This is where Open-Meteo provides an excellent example.
Its free API is currently designated for non-commercial use, while the underlying weather data is licensed under CC BY 4.0 and requires appropriate attribution.
That means I shouldn’t simply see:
“No API key.”
and conclude:
“I can use this however I want.”
Those are completely different statements.
Before using an API in a client project or monetized website, I check:
- commercial-use terms,
- attribution requirements,
- redistribution rules,
- data licence,
- API terms of service,
- and any restrictions on caching or storing data.
Five minutes of reading can prevent a much bigger problem later.
The seventh gotcha: API documentation changes
An API is not a static object.
Endpoints change.
Models change.
Limits change.
Pricing changes.
Authentication methods change.
Sometimes an API provider introduces a new version while keeping the old one around temporarily.
That’s why I prefer linking directly to official documentation rather than copying rate limits into an article and treating them as permanent facts.
The numbers in this article are accurate against the documentation checked while researching it, but API limits should always be verified again before launching a new project.
That’s especially important for production applications.
What I would put into a real project
For a small project, my basic API checklist would look like this:
1. Read the documentation
Not just the “Getting Started” page.
I want:
- limits,
- authentication,
- errors,
- pricing,
- licensing,
- and terms.
2. Test the failure case
Don’t only test:
200 OK.
Test:
401.
403.
404.
429.
And whatever server-side error responses are relevant.
3. Add caching where appropriate
If data doesn’t need to be live every second, don’t request it every second.
4. Keep credentials out of the frontend
Use a backend or secure server-side mechanism where required.
5. Monitor usage
If the provider gives me usage headers or a dashboard, I use them.
6. Have a fallback
If the API disappears for ten minutes, what does my application show?
A blank screen?
Or a useful fallback message?
That’s a very different user experience.
My “free API” hierarchy
If I’m choosing an API for a project, I think about it in three levels.
Level 1: Perfect for learning
These APIs let me learn HTTP requests, JSON, authentication and error handling without worrying too much about production infrastructure.
Dog API is a good example.
Level 2: Good for prototypes and small applications
This is where APIs like Open-Meteo and NASA become particularly interesting.
They provide genuinely useful data with documented limits.
Level 3: Production dependency
This is where I become much more cautious.
A production dependency deserves:
- documented limits,
- predictable behaviour,
- monitoring,
- error handling,
- licensing clarity,
- and a plan for what happens if the service changes.
The fact that an API has a free tier doesn’t remove those responsibilities.
What I would actually choose
If I were building a small collection of projects today, my choices would depend on the job.
Weather
Open-Meteo would be one of my first options for a non-commercial project because it doesn’t require an API key for the free API and has extensive documentation.
Developer data
GitHub’s REST API is an obvious choice when the data belongs to GitHub and the documented limits fit the application.
Space/science projects
NASA APIs are difficult to ignore when the required data is available there.
Weather with a commercial application
I’d investigate OpenWeather’s commercial options rather than assuming a free plan is appropriate for a monetized product.
Learning API development
I’d happily use something simple such as the Dog API to practice requests and JSON handling.
The important thing is that I’m choosing based on the project rather than choosing an API because a blog called it “the best free API.”
The real cost of a free API
This is the conclusion I keep coming back to.
An API can have a price of:
$0.00
and still have a cost.
The cost may be:
- request limits,
- engineering time,
- maintenance,
- attribution,
- vendor dependency,
- migration risk,
- or the work required to handle failures.
That doesn’t make free APIs bad.
Quite the opposite.
Free APIs are one of the best ways to build, experiment and learn.
But I want to know what “free” actually means before I build something important around one.
My pre-launch API checklist
Before I put an API-powered feature into a live project, I would ask:
- Is the API currently maintained?
- What exactly is the free limit?
- Is the limit per minute, hour, day or month?
- Does authentication change the limit?
- Is commercial use allowed?
- Is attribution required?
- What happens at 429?
- Can I cache the response?
- Where will the API key live?
- What happens if the API is unavailable?
- How will I monitor usage?
- What is my fallback plan?
That checklist is more valuable to me than a list of fifty API names.
Because finding an API is easy.
Building something that survives real usage is the harder part.
Final thought
The best free API isn’t necessarily the one with the biggest quota.
It is the one whose data, limits, licensing and reliability match the job I am trying to do.
That’s why I don’t get too excited when I see a headline saying:
“100% FREE API — NO LIMITS!”
I immediately want to read the documentation.
How many requests?
For whom?
For what type of use?
Under which licence?
What happens when traffic grows?
Those questions aren’t exciting.
But they’re exactly the questions that separate a fun prototype from a project I can confidently keep running.
And that’s how I think about free APIs now:
Use the free tier when it genuinely fits.
Respect the limits.
Cache what doesn’t need to be live.
Protect the credentials.
Read the licence.
And when the project becomes big enough that the free tier no longer fits, that’s not a failure.
It simply means the project has outgrown the free tier.