Jump to content

New API quota dashboard?


Recommended Posts

Hello

 

Using some of the apps that take advantage of the new api there seems to be some significant changes.  One appears to be that the quota for cache downloads is per cacher instead of per cacher per api partner. (I don't know what is the case for the other limits.) So one app can impact the performance of others by consuming all of the resources. 

 

From a user perspective, the resources consumed are pretty opaque.  I have no idea how much of the quota the website partners consume or a what time of day to schedule around them. GSAK uses the API to tell me how many are consumed but not by which api partner. My smartphone apps also don"t tell me how much of the API they are using to generate the great maps.

 

It would be nice to have some insight into what is going on. This would let me not use particularly greedy apps on road trips when the maps on my smartphone are more important. (It is frustrating having a map stop populating on a roadtrip.)If a website partner is particularly greedy that subscription might get terminated. Right now can i get a list of partners authorized on my account?

 

Are there any tools to let me see which apps are consuming my quotas and limits? 

 

Thanks

Link to comment
6 minutes ago, sloth96 said:

Are there any tools to let me see which apps are consuming my quotas and limits? 

YOU are the tool. It's you who triggers an API download (done by an app). None of the apps are doing it on its own.

And yes: the API limits are obviously per Groundspeak Member, not per app.

Your authorized apps could be found there:

Your authorizations (click here)

 

Hans

 

Edited by HHL
Link to comment
1 hour ago, HHL said:

YOU are the tool. It's you who triggers an API download (done by an app). None of the apps are doing it on its own.

And yes: the API limits are obviously per Groundspeak Member, not per app.

Most of this is wrong. Many of the apps are doing this on their own.
API limits are per member, per app.

Edited by thomfre
No markdown support in the forums...
Link to comment
32 minutes ago, thomfre said:

Most of this is wrong. Many of the apps are doing this on their own.
API limits are per member, per app.

A quick test a couple of weeks ago with two apps showed that doing a refresh in one dropped the balance in the other.  This is for the new api.

 

I became sensitized to it when the map feature in the mobile app would not fill in.  I checked the api balance and there were none left.

Link to comment
4 minutes ago, sloth96 said:

A quick test a couple of weeks ago with two apps showed that doing a refresh in one dropped the balance in the other.  This is for the new api.

 

I became sensitized to it when the map feature in the mobile app would not fill in.  I checked the api balance and there were none left.

Yes, it looks like I'm wrong as well :(

Link to comment

So using a mobile app to do mapping I believe i went through the quota in under 30 minutes. How much do you pan around a map?

 

Looking at the 60 calls per minute and 50 caches per call an app can go through the full quota of 16000 in a little over 5 minutes. Then all your other partner apps cant download another cache for a day.

 

I am not making an assessment on the right or wrong behavior. I am meerly noting it has changed with the new api and i would like a tool to manage it.

  • Upvote 1
Link to comment
1 minute ago, HHL said:

The old API behaviour was a bug. Only people that want harvesting and scraping GS's database might be angry. I'm not.

How do you know it was a bug?

 

It's not that hard to download thousands of caches, and that did not use to break apps with the old API. Now it will.

Link to comment
9 minutes ago, thomfre said:

How do you know it was a bug?

 

1% of users are wasting 99% of bandwith.

 

16000 quota is larger than I expected. It could be arranged to 10 calls per minute cumulating to maximum 16000. This way you can always use the API but harvest only limited amount of data.

Link to comment
2 minutes ago, arisoft said:

Maybe the idea is that data harvesting apps should check the balance themself before starting to harvest more.

How is that stopping a user from using GSAK to download 16 000 caches before he/she go outside to play with one of the partner apps?

Link to comment
Just now, thomfre said:
3 minutes ago, arisoft said:

Maybe the idea is that data harvesting apps should check the balance themself before starting to harvest more.

How is that stopping a user from using GSAK to download 16 000 caches before he/she go outside to play with one of the partner apps?

 

Do you mean that GSAK do not have setting for the minimum balance? If it is the case then you may ask to add this important feature to GSAK as soon as possible.

Until then, use GSAK harvester only after you have done the daily outdoors Geocaching.

Link to comment
9 minutes ago, BlackRose67 said:

[...]

 

GSAK has a dialog to check your API balance for each day.

Yes, and there is also a macro function for checking the current balance:

GcBalance(sType) : Number

 

Hans

Edited by HHL
Link to comment

I think the key part of this discussion is what the original post was about... can there be a dashboard summary of API usage by partner? That's the only way to really tell which app or website is consuming the quota. Allowing a user to monitor this puts them in control and avoid partner apps using more than they want.

  • Upvote 1
Link to comment
13 minutes ago, SpiritGuide said:

I think the key part of this discussion is what the original post was about... can there be a dashboard summary of API usage by partner? That's the only way to really tell which app or website is consuming the quota. Allowing a user to monitor this puts them in control and avoid partner apps using more than they want.

I fully support that idea!

 

But I don't think any API app use more than they have to (why should they?), the issue here is that you now have a shared pool where you used to have separate pools. This will affect users that use multiple API apps.

Link to comment

This seems oh so silly to me. How many caches does one really need to get in a 24  hour period? More than 26,000? Previously, for premium members, the limits were 6000 full cache details and 10,000 lite cache details. Evidently that was per app, though I suspect that wasn't the original intent by Geocaching HQ. Now, the full details quota has been updated from 6000 to 16,000, though for all apps. That's a big increase, 167%.

Link to comment
8 hours ago, sloth96 said:

So using a mobile app to do mapping I believe i went through the quota in under 30 minutes. How much do you pan around a map?

So don't putz around for 30 minutes with the map on your mobile. :laughing:

 

I will say, that for mapping, the lite cache option should be used. That's essentially why it was added. Lite-cache gets no description, full cache does. I don't know what your mobile app is doing, but perhaps you ought to complain to it's producer on its inefficient use of your cache quota.

Link to comment
9 hours ago, thomfre said:

Most of this is wrong. Many of the apps are doing this on their own.
API limits are per member, per app.

Apps aren't doing it, "on their own", unless they are not following the API partner agreement. Apps should only be using the API for a user if the user allows them too and in the manner authorized. The user is able to revoke an app's authorization any time. I'll also suggest that it is a user's responsibility to understand what authorizing an app entails.

Link to comment
2 minutes ago, Corfman Clan said:

Apps aren't doing it, "on their own", unless they are not following the API partner agreement. Apps should only be using the API for a user if the user allows them too and in the manner authorized. The user is able to revoke an app's authorization any time. I'll also suggest that it is a user's responsibility to understand what authorizing an app entails.

All of that is true, but some apps will fetch data in the background, without the exact API call being initiated by the user (like indicated in the post I quoted).

I went back and had a look, and I see plenty of evidence for the 6000 per app limit being intended. The new quota might be a huge increase for some, like the people using only one app. But for people using 3+ apps, it's not an increase at all.

Link to comment
1 hour ago, thomfre said:

All of that is true, but some apps will fetch data in the background, without the exact API call being initiated by the user (like indicated in the post I quoted).

 

And instead of fixing the leaking App you prefer to have more API calls?

  • Upvote 1
Link to comment
7 minutes ago, arisoft said:

 

And instead of fixing the leaking App you prefer to have more API calls?

Leaking app? There is a lot of nice API apps out there, and they have been working perfectly fine until now.

 

What most of you seem to forget is that people have gotten used to apps not affecting each other. I can't speak for the world, but it's common here in Norway to use the available quota to fetch caches in GSAK.  People have done that for a long time, and how should they know that they have to stop now? If they don't, they can't use any other app.

 

The issue isn't a single partner app (not sure where you get the data harvesting apps from, do they even exist anymore?) - it's users being used to doing something that will soon break their workflow.

 

It doesn't matter to them that some random dude on the forum think they shouldn't need to download that many caches. And why should it?

 

The increased limit is nice. But separate limits was a lot nicer.

Link to comment

Wow, it really seems like most people here simply have to comment on things that they don't understand.

At least some got the point. The issue at hand is NOT data harvesting and is NOT a broken app. Like thomfre wrote, many of us are used to have GSAK update their local database on a regular basis often using up the quota. Now this will affect my caching trip that day using ANY partner app. That can not be good and will cause some bad feedback for innocent partners.

 

I think HQ should rather revert to the lower per app/user quote that was in place in the past! Many cacher don't even know what that whole API talk is about. The average housewife cacher (no offence) will NOT understand that because they used tool A or website B on their computer that suddenly app C on their phone will not work anymore for the next 24h.

 

Yes, the technically versed might get it but the average user does not even know what the 'API' is....

 

They use and app and it works! Now one app/tool/website can and will impact ALL partner apps.

 

In one word: BAD 

  • Upvote 3
Link to comment
6 hours ago, thomfre said:

What most of you seem to forget is that people have gotten used to apps not affecting each other. I can't speak for the world, but it's common here in Norway to use the available quota to fetch caches in GSAK.  People have done that for a long time, and how should they know that they have to stop now? If they don't, they can't use any other app. 

 

They will find this quite fast when they notice that run out of quota is not the best option for them. As I told earlier, you should adjust your App to consume the amount you want. GSAK has tools needed for this. If your App is using the balance without your consent it leaks and it should be fixed.

 

The overall situation is better than earlier. Earlier you could find only 6000 caches per day. Now you can find 16000 caches per day which is a huge improvement. The only requirement  is that you have propertly working tools which do not waste your balance.

 

I admit that showing statistics could be a nice addition, but as you stated, you already know how you balance is wasted. For debugging you can use a counter build in the application itself.

Link to comment
4 minutes ago, arisoft said:

I admit that showing statistics could be a nice addition, but as you stated, you already know how you balance is wasted. For debugging you can use a counter build in the application itself.

+ 1

There are people out in the wild that simply use their brain for debugging. ?

Edited by HHL
  • Upvote 1
Link to comment
6 hours ago, june17 said:

Yes, the technically versed might get it but the average user does not even know what the 'API' is....

 

Nor they know what GSAK is. But GSAK knows what the balance is and can adopt the situation. The end result is better than before.

  • Upvote 1
Link to comment
4 hours ago, arisoft said:

The overall situation is better than earlier. Earlier you could find only 6000 caches per day. Now you can find 16000 caches per day which is a huge improvement. The only requirement  is that you have propertly working tools which do not waste your balance.

 

It's not the "finding" of caches per day, but the downloading of cache data per day. Updating offline lists, trip planning, locating lonely caches, or pulling in caches on live maps is not finding. The newer apps allow better offline list management with updates which can benefit the user (not leaking), but may not fall under the original HQ intent with how quotas were meant.

  • Helpful 1
Link to comment
2 hours ago, SpiritGuide said:

It's not the "finding" of caches per day, but the downloading of cache data per day.

 

If you can't find 16000 cacher per day, how many cache descriptions you can read per day? In practice, what you can do with those 16000 caches in general?

 

3 hours ago, SpiritGuide said:

Updating offline lists, trip planning, locating lonely caches, or pulling in caches on live maps is not finding.

 

I would call this data harvesting. Are you keeping a copy of cache database and you are using all available bandwith to keep it updated? You can download almost 6 million caches per year. Do you really need all this data for Geocaching?

 

  • Upvote 1
Link to comment

Viewing the live map on PGC uses quota pr cache displayed, downloading a bookmark list to cachly uses quota, yes small tings, but not harvesting.

GSAK as you keep coming back to isn't the solution for everyone....

Some of us looks at various maps, and uses other API partners to make plans, and not just for today, but months ahead in time....

viewing maps, adding caches to other api partners... everything eats quota....

Those of you who only use GSAK have gained a whole lot more daily quota, but while GSAK is great for keeping a "harvested" DB of caches in your country/region and submitting logs from the GPSr, it's crap for almost everything else when compared to what's out there...

We actually had more daily quota before when it was 6000 whitout harvesting, but for planning....

And the OP of this tread didn't ask for more API calls, but for geocaching.com to list on https://www.geocaching.com/account/settings/authorizations or similar, what each partner consumes... (this is data Groundspeak already collects, how else do they know what to take away from the quota...)

Link to comment
11 minutes ago, cghove said:

downloading a bookmark list to cachly uses quota

Downloading a Bookmark List does not consume API quota when you PQ the BM beforehand and then load the zipped PQ via the NewApi.

Seems that Cachly is not that smart, right?

 

Hans

Link to comment
5 minutes ago, HHL said:

Downloading a Bookmark List does not consume API quota when you PQ the BM beforehand and then load the zipped PQ via the NewApi.

Seems that Cachly is not that smart, right?

 

Hans

It seem's that not everyone uses GSAK in their geocaching life, If you PQ it beforehand, you'll lose certain information and sort order.. ;)

Link to comment
2 hours ago, HHL said:

Downloading a Bookmark List does not consume API quota when you PQ the BM beforehand and then load the zipped PQ via the NewApi.

Seems that Cachly is not that smart, right?

 

Hans

But then you're not using the bookmark list, you're using the pocket query. At any rate, this statement seems rather specious.

  • Upvote 1
Link to comment
2 hours ago, cghove said:

...And the OP of this tread didn't ask for more API calls, but for geocaching.com to list on https://www.geocaching.com/account/settings/authorizations or similar, what each partner consumes... (this is data Groundspeak already collects, how else do they know what to take away from the quota...)

Actually we don't know if these data are collected with the new API. Obviously it was known with the previous API since the quota was per app, but now the quota isn't per app so the data very well may not be known.

Link to comment
11 minutes ago, Corfman Clan said:

But then you're not using the bookmark list, you're using the pocket query.

Yes. I get the BM data and the download counts against the 10 PQ limit per day. But the API quota is not touched. Nothing specious with that.

 

Hans

Link to comment
3 minutes ago, HHL said:

Yes. I get the BM data and the download counts against the 10 PQ limit per day. But the API quota is not touched. Nothing specious with that.

 

Hans

I think comparing apples to oranges (bookmark lists to pocket queries), which is what you're doing, is specious. I don't mean this as discounting doing what you suggest to get more cache data per day.

Edited by Corfman Clan
Link to comment
4 hours ago, HHL said:

Downloading a Bookmark List does not consume API quota when you PQ the BM beforehand and then load the zipped PQ via the NewApi.

Seems that Cachly is not that smart, right?

 

Hans

 

I think Cachly is pretty smart. A list downloaded via zipped PQ may not have all the data needed for full details and logs used to identify possible FTFs, DNFs, lonely caches or the logs the user would like to see. And after a list is downloaded there may be added caches or waypoints the user doesn't want to overwrite if downloading the PQ again. Refreshing the PQ list to get more needed data will consume API quota. 

Link to comment

I have good news for everyone (well maybe not everyone but most of you). I was concerned about this as well and had brought it up with HQ.

They were kind enough to discuss this topic and agreed to revert this change to how it was with the old API: limits are per user AND per app, just like before.

Not sure when it will be changed over on their end but it WILL happen.... ?

 

I am happy and I am sure my users will appreciate this change as well (as will many others ?).

 

Happy caching!

  • Helpful 1
Link to comment
43 minutes ago, arisoft said:

 

But the ones who had problems with this new feature are not happy at all if the 16000 limit is downgraded back to 6000. :)

 

I don't mind :)

I appreciate the 16k limit, but the per app limit is much more important. So if this change leads to the limit being 6k per app again, I'm perfectly fine with that!

Link to comment

When HQ responded to me they did NOT mention a reduction in quota! No promises but my understanding is 16k per app per user.... Of course it could be reduced but a separation by app is very important. I personally had issues with the new limitation and I am very happy even with 6k! At least I KNOW that I have 6k in the app I want to use even after playing in GSAK or other apps.

Anyways, some people simply can't be happy for others it seems...

  • Upvote 2
Link to comment

Actually, I understand why HQ would have limits per user and not per app. It seems the whole purpose of a quota is to keep some users from consuming too much server resources. If they can switch apps just to bypass reaching a limit reached on one, then it doesn't do what a quota is intended for. 

  • Upvote 1
  • Helpful 1
Link to comment
On 3/21/2019 at 1:57 PM, support@gcdroid.com said:

I have good news for everyone (well maybe not everyone but most of you). I was concerned about this as well and had brought it up with HQ.

They were kind enough to discuss this topic and agreed to revert this change to how it was with the old API: limits are per user AND per app, just like before.

Not sure when it will be changed over on their end but it WILL happen.... ?

 

I am happy and I am sure my users will appreciate this change as well (as will many others ?).

 

Happy caching!

This appears to have happened. The point of a dashboard is gone for me.

 

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...