A free API can be suitable for a practice project and unsuitable for the same project after it gains advertising or paying customers. Before building a weather widget, separate four questions: can you access the endpoint, may you use the data for your purpose, how much traffic is allowed and what happens when the service is unavailable?
Use the API directory as a starting point, then open the provider's current documentation. A directory entry is a dated research note. It cannot guarantee continuing availability, unchanged terms or permission for every business model.
Write down the intended use
Describe the widget in one sentence: a fictional personal project shows tomorrow's weather for a manually selected city. Then describe its possible next version: an advertising-supported travel site uses the same data. Those uses may fall under different provider terms even when the code makes identical requests.
Open-Meteo provides a useful concrete example. Its terms page, checked for this guide on November 7, 2026, restricts its Free API service to non-commercial use and identifies advertising-supported sites as commercial examples. Its data licensing and service-access conditions are separate details to read together. Do not conclude that a permissive data license makes every hosted endpoint free for commercial access.
For your candidate provider, record the exact terms URL, the check date and the decision relevant to your project. Also check attribution, redistribution and retention requirements. If the use is ambiguous, ask the provider or choose a service whose published conditions clearly cover it. A missing prohibition in a directory description is insufficient evidence.
Estimate requests from behavior
Imagine a test widget with 20 page loads, each requesting current conditions and a forecast once. That design makes 40 requests before refreshes or retries. This is arithmetic for the fictional design, not an estimate of your traffic or a provider allowance. Recalculate when you add location search, automatic polling or several cities.
Rate limits can depend on an account, token, IP address or endpoint. GitHub's REST rate-limit documentation, for example, distinguishes authentication methods and describes additional restrictions for some endpoints. Treat its rules as GitHub-specific. Another provider can count requests differently.
Check whether the service documents response headers showing remaining capacity, retry timing or caching instructions. Use a bounded retry policy and respect the documented delay. A loop that immediately repeats a throttled request can make recovery harder. Consider caching only when the terms and the freshness needs of your feature allow it.
Check how the browser will reach it
An endpoint opening in a browser tab does not prove that frontend JavaScript can read it from your site's origin. MDN's CORS guide explains how server response headers govern cross-origin access. Some requests also require a preflight. Test the actual request method and headers your application needs.
Do not disable browser security to make a demo appear functional. A backend integration may be appropriate when it is permitted by the provider and needed for authorization, caching or credentials. It must remain a controlled integration, not an unrestricted proxy that lets visitors fetch arbitrary URLs.
Separate public client identifiers from secret credentials. A browser-delivered key can be inspected by visitors. Keep privileged or paid API secrets on a server, apply the provider's supported restrictions and authorize your own callers. The absence of a key does not imply unlimited access or permission to collect every available field.
Plan for a blank result
Your weather widget needs distinct states for loading, no matching city, stale data and a failed request. Show when displayed information was updated if freshness affects its meaning. Avoid presenting a cached value as current simply because a network request failed.
Practise response categories in the HTTP workbench. Its lesson routes and 401, 429 and 500 scenarios are simulated, with no real weather provider connection. They can help you choose interface messages; they cannot prove that a selected API supports CORS, meets a quota or permits your intended use.
- Choose one directory provider and open its official documentation and terms.
- Write the allowed use, authentication requirement and traffic-counting rule, with source links.
- Calculate requests for one typical page visit and one retry.
- Describe what the widget displays when the provider throttles it.
- Set a review point before adding advertising, subscriptions or a new data use.
The expected result is a short decision record you can revisit before the project changes. If you cannot identify a permission or an operational limit, leave that field unresolved and investigate it before depending on the service.