I built three small apps in 2025 that use only free-tier APIs (HTTP endpoints that other services expose for programmatic access). One handles lead routing for a friend’s consulting business, one does nightly market data aggregation for a non-profit I help with, and one runs my own home automation hub. Total annual cost: $0. Total time spent fighting rate limits (the per-service cap on how many requests you can make in a given window, reset every minute or month) and finding replacements when a “free” tier turned into a “free trial ending in 30 days” tier: more than I expected. This post is what I learned, which APIs actually stayed free, and the four I will not touch again.
What I was actually building
The three apps are not impressive individually. The lead-routing app is a webhook receiver (a small program that sits at a URL and receives structured data the moment something happens elsewhere) plus a Postgres table and a Slack notification. The market data app is a scheduled task that pulls a few hundred rows per day from a couple of public data sources, normalizes them, and writes the result to a CSV in an S3-compatible bucket (cloud object storage with the same API as Amazon’s S3, usable with cheaper or self-hosted alternatives). The home automation app is a Python service that polls a weather API and adjusts a few smart switches.
Between the three apps, I touch 14 different free APIs. Eleven are still free as of February 2026. Three changed pricing. Two changed in a way that hurt, one changed in a way I am still deciding whether I like. The point of this article is the eleven that stayed free and the three that did not, because the gap between “has a free tier” and “free tier you can actually build on” is bigger than the marketing pages suggest.
The eleven that stayed free
I am grouping these by category so the table is short. The list below is what survived 12+ months of real use, not what looked good in a “Top 10 free APIs” roundup.
- GitHub REST API (personal access token). 5,000 requests per hour for public repos, 500 for private ones. I use it for issue triage and release-note drafts.
- Open-Meteo for weather. No API key required, no rate limit I have ever hit, no email signup. Returns the same data WeatherAPI charges $9 per month for. This is the one I tell everyone about first.
- CoinGecko for crypto prices. Free tier is 30 calls per minute; the public endpoint does not need a key. I cross-check the data against a paid feed a friend runs, and the numbers match to 4 decimal places.
- ExchangeRate.host for FX. Same shape as CoinGecko. No key for the public endpoint, daily updates for most currencies.
- Nominatim (OpenStreetMap) for geocoding. Free for low-volume use, generous rate limit (1 request per second), and the data quality is good enough for “where is the closest coffee shop” type queries.
- JSONPlaceholder. Not for production, but the cleanest fake REST backend for prototypes. I have used it in three demo projects this year and it has not changed once.
- OpenAI’s $5 free credit for new accounts (3-month window). Replaced the older fine-tuning free tier. Fine for testing prompts before paying.
- Google Custom Search JSON API. 100 queries per day free, requires a key. I use it to monitor mentions of a few keywords for the non-profit’s media tracking.
- ipapi.co for IP geolocation. 1,000 lookups per day free, no key. I use it in the lead-routing app to reject submissions from outside the US.
- Plaid (sandbox only). Free forever for the sandbox environment, no real bank data. I would not touch their paid tier for a hobby project, but the sandbox is a real product to build against.
- Resend for transactional email. 3,000 emails per month free, 100 per day, and the API is the cleanest one in this list. I use it for the lead-routing app’s “we received your form” emails.
If I had to pick two to keep and give up the rest, it would be Open-Meteo and Resend. Both are the kind of tool you forget is there because they just work.
The three that did not stay free
These are the ones that cost me a chunk of time last year. I am naming them because the pricing change was not announced loudly and a few of my developer friends got caught by the same thing.
- OpenAI’s
text-davinci-003was free during the beta, then deprecated. The replacement (gpt-3.5-turbo) is cheap but not free. Hobby-app builders got a soft redirect to a paid model and a 90-day grace period that was easy to miss. - Google Cloud Vision’s “free 1,000 images per month” became “free 1,000 images per month, but the second 1,000 bills you” without changing the marketing page. The page still says “1,000 free.” The new sentence is “1,000 free, then metered,” two paragraphs down.
- A small sentiment-analysis API that asked for an email to “stay updated” then sent me a 30-day free trial of the Pro plan, which auto-renewed at $49 per month. I caught it on day 14 and cancelled. I do not name this one because I do not want to call out a small company for what is a common pattern, but the shape of the trap is worth describing: free trial, auto-renew, no email reminder.
I do not have a clean rule for the third case beyond “always read the cancellation flow before signing up for a free trial of anything.” The first two are more interesting. The OpenAI deprecation was the right call: the model was old, the replacement is better, and the grace period was generous. The Google Cloud Vision change was less defensible. The pricing page should have said “1,000 free, then $1.50 per 1,000” or whatever the rate is, in the same paragraph as the free number.
The four I will not touch again
This is the list I wish I had at the start of 2025. Every one of these has a “free” tier on the marketing page that I tried to use and could not.
- Any API whose free tier requires a credit card on file. I tried three of these. All three were fine until they were not, and the failure mode was a $200 surprise invoice from a service I had not used in 8 months. The free tier with a credit card is a paid tier in disguise.
- Any API whose free tier expires after 90 days. A “free for 3 months” tier is a free trial, not a free tier. The marketing page should be honest about this.
- Any API whose “free” tier excludes the data I actually need. Some mapping APIs are “free” but the geocoding accuracy is too coarse for addresses outside the US. Some weather APIs are “free” but only the current-conditions endpoint is free, the historical endpoint is metered.
- Any API whose documentation is auto-generated and not curated. I tried one whose swagger (a machine-readable description of an API’s endpoints, auto-generated from the code) was 6 months out of date and whose “Getting Started” page referenced endpoints that no longer existed. I spent a Saturday on it and gave up.
These four are not a list of bad companies. Most of them have good products. They are a list of “free tier shapes” that I now refuse to start with, because the time cost of finding out the shape does not match your needs is bigger than the time cost of just picking a paid tier with a known rate.
Trade-offs
The free-tier approach is not free in time. I spent roughly two weekends per app debugging rate limits and writing small adapters when an API changed. That is real time, and it is the cost nobody talks about. In our case, the apps are small and the time was bounded; the non-profit market data app is the worst, because I am the only maintainer and a rate-limit spike at 2 AM means the data file is stale by morning.
Money is not really a cost. I spent $0 on API calls in 2025 and $14 on a domain name for the home automation app. The hosting (a $5/month VPS, virtual private server) is a separate line item and is not a free-tier story.
Features are the real cost. The free tiers I rely on do not include the things I would use if I were paying: historical lookups beyond 30 days, higher rate limits, priority support, SLAs (Service Level Agreements, a contract promising a certain uptime percentage and response time, usually 99.9% or better). For a hobby project, none of this matters. For a small business, some of it does.
The upside is also real. I have three apps that work, that I run on my own VPS, and that I can move to a different provider in a weekend. I cannot do that with the SaaS (Software as a Service, software you rent instead of install) equivalents, which would lock me into a vendor’s roadmap, pricing changes, and feature deprecations. The free-tier approach is “free in vendor lock-in” as much as “free in money,” and it is the reason I keep building this way.
If you are building a hobby project and you have time to debug rate limits, the free-tier approach is a clear win. If you are building a business, calculate the cost of the engineer-time spent on free-tier workarounds; it is often cheaper to pay for the paid tier and move on. If you are somewhere in between, start with free and migrate to paid when the rate limit becomes a problem you can measure, not when the marketing page first mentions it.
Bottom line
The “free” in free-tier API almost always means “free for low-volume, non-commercial use, with the option to pay later.” That is a real and useful thing, and the eleven services on my working list prove it can be done. The trap is the gap between “has a free tier” and “free tier you can build a real product on,” which the marketing page does not always surface clearly. Read the cancellation flow, read the rate limit docs, and read the section about what happens after the first 1,000 requests. The apps I built on free tiers work because the services earned that trust over 12+ months, and the ones I am dropping did not.