How do you deal with free but limited number of API calls to services (eg weather APIs)?



I’ve seen this page where a few people created a weather app in {N}:

Most of the public API’s - like weather - usually have a free tier that limits the number of API calls per day and/or per minute. Usually they are 500 per day, but some goes up to 1000 or so.

So when you write an app that uses such free API service(s), how do you deal with these free but limited number of allowed API calls? After all, say, 1000 people download your app and they all start adding weather locations and start refreshing an pulling data. Your 500 (or even 1000) calls per day will be over in a second and the API key will be blocked or suspended, etc. All of a sudden now your app is unusable.

I have a hard time imagining that the developer pays the usage for the API key out of his/her pocket just so other users can use the free app. (Unless you are a major corporation and have other revenue means to cover the expense, etc.)

I checked some of those apps (link above) and none of them seem to put restrictions on the number of calls. Eg, checking that you only download data, say, once per hour. But even if you do, it’s easy to get over the free limit, depending on the number of people who might use your app.

Are you, or would you, be concerned that your app stops working due to a block to our API key Especially if you sell your app for a few bucks, you need to make sure your app is working. So you can’t use the limited but free API calls. In which case are you paying for your own data that others will use? What if they use too much data? Are you keep paying more? That doesn’t seem to add up to me.

So if you wrote such an app that uses limited but free number of API calls to a service, I would be curious to know what is the general “practice” in such cases?



If I was trying to cheat the system I would do one of the following:

  1. Build a micro-service (backend-service) that pings the “free/limited” API and caches the results for 24 hours.
  2. Cache the results local to the user’s device for 24 hours using couchbase, sqlite, app-settings, etc.
  3. Rotate API keys when I receive back an invalid status code for reaching their API limit (this is probably what a lot of them are doing that have very specific (non-cacheable) data like weather for specific zip codes.


Interesting thoughts, thanks!

Caching is always a must, since weather for most locations doesn’t change every 5 minutes, so updating every 1-2 hours would be acceptable. Not sure about the 24 hour caching though, since at midnight the data would/could still show that it’s “Sunny” :slight_smile:

However, rotating API keys might be interesting if they also attach IP addresses to keys. In that case they would know immediately if multiple keys were registered from the same IP and can block all keys effectively. But this is just theory of course.