Almost every automation that stalls stalls on data. The logic is fine, the trigger fires, and then something needs a postcode lookup, an exchange rate, a company record or a weather forecast, and there is no obvious place to get it.
There are thousands of free APIs that solve exactly this. The problem is that free is doing an enormous amount of work in that sentence.
The five things free can mean
Two APIs can both be listed as free and behave completely differently the moment a client depends on one.
- Genuinely open. No key, no signup, call it and it responds. Rare, usually public-interest data, and the most likely to disappear without warning.
- Free with a key. The common case. You register, you get a key, you are rate limited. Fine for most client work.
- Free tier of a paid product. Permanent but deliberately small, and priced so growth pushes you onto a plan. Fine if you know that going in.
- Free trial. Free for thirty days, then it stops. This is the one that breaks a client automation a month after you hand it over.
- Free for non-commercial use only. Works perfectly in testing and is a licence breach the moment you bill a client for the workflow using it.
The five checks before you build
- 01Authentication. Does it need a key? If yes, register now rather than later, because approval is sometimes manual and can take days.
- 02Rate limit. Find the number of requests per minute, day or month. Then estimate what your automation will actually use at the client's real volume, not your test volume.
- 03Permanence. Search the pricing page for the word trial. If the free tier expires, treat the API as paid from the start and price it into the work.
- 04Commercial use. Read the terms for the phrase non-commercial. Free for personal projects is not free for client work, and this is the most commonly missed condition of the five.
- 05CORS. Only matters if you are calling from a browser, but if CORS is unsupported the call fails no matter how correct your key is, and you will need a server or proxy in between.
Build as if it will disappear
Free APIs vanish. They get acquired, rate limited, moved behind a paywall or simply abandoned. This is not a reason to avoid them, it is a reason to build so it is survivable.
- Put the endpoint and the key in configuration, never hardcoded across several nodes. Swapping providers should be one change, not a search through a workflow.
- Handle the failure explicitly. Decide what the automation does when the API returns nothing, and make sure someone is told. Silence is the worst outcome.
- Cache anything that does not change often. Exchange rates hourly, company records daily. This keeps you inside rate limits and reduces how much a provider's outage matters.
- Know your second choice before you need it. Note an alternative provider in the workflow description so the person fixing it at speed is not also researching.
What to tell the client
If a client's automation depends on a free API, say so plainly, in writing, when you hand it over. Name the provider, name the limit, and state what happens if it changes.
This is not a weakness in the work. It is the difference between a supplier problem and your problem when the provider changes their terms. Agencies that skip this conversation end up absorbing the cost of a decision they never made.
The short version
Free APIs are genuinely useful and worth building on. Check the key, the limit, the permanence, the commercial terms and CORS. Build so the provider can be swapped. Tell the client what they are depending on.
Do that and a free API is a sensible engineering decision. Skip it and you have built a client's process on something you never read the terms of.
