@subkamran: First, yes, we can email all users with an API key. We were hoping to have our new API changes out already, and doing a release about it including notes, features and new documentation that I've been working on. Unfortunately we're pushing out other significant tech changes, that must go first, before we release this, and got held back. Sorry.
Next, I am happy to help out with your strategy, as a web and app developer myself. A good idea for apps is to take advantage of native local storage on api requests. So for iOS for example, you can use Core Data or SQLLite to cache the data returned for a specific api request. On the web, taking advantage of database, nosql solution (redis, cassandra, or whatever) would be cool. What we usually do is, save a key based on the request filled with the data, so like, if the user requests: /api?param1¶m2¶m3 we store the key as myLocalDataStore::param1:param2:param3 = $dataReturned.
However, that's just a suggestion. With the new version we won't have limits, and we'll be using queueing to take advantage of heavy loads (which we kind of do now, just not optimally). We can talk about increasing your limit so you can populate your data. I'm doing it for a couple of other app developers as well. We can set a timeframe to do this. Currently we need to get our new tech stack stuff out on live before we do, but I expect to be free to help out on this issue next week.
Log in to comment