function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion

G_GEO_TOO_MANY_QUERIES and Google Maps API keys

I'm in the process of packaging some code that includes callouts to Google Maps for geocoding. The code works just fine in my development org, but since the package could be installed on any Salesforce instance, I can't always use a Google Maps API key that's based on my development org's instance. Fortunately, in Google Map in Visualforce Page, I found that I can use a key based on this URL:


This seems to work, except now I get G_GEO_TOO_MANY_QUERIES.


Is Google's "too many queries" limit based on all requests coming from That would make sense from Google's perspective, but from the perspective of a single org on a single Salesforce instance, it doesn't seem fair that every other instance's org's requests should count against my limit?


Is there any way to create a Google Maps API key that's specific to my own org (or an org my package is installed in), so that only requests made from my org count against my limit.


For reference, see my post from late 2008:




I'm also having this issue. Specifically on the na1 server. There must be quite a few of us on that one trying to make these calls, as the limit is quite high. I think the limit is IP based, so a single server would accumulate our collective calls :( Trying to figure out a way around this, I think a client side call might be the only solution.



Ron WildRon Wild

Well, that kind takes the fun out of it ... esp. since it's only going to get less and less functional as more developers figure out how to use it.


I though Salesforce and Google were buddies.  No special deals for friends in the cloud?



Ronak PatelRonak Patel

there is limit for that .

10 callouts from one request call

so any page or controller u can use upto 10 queries only.


That's true, but it's not the issue I was having. My issue wasn't the number of callouts per transaction. My code was doing only one call per transaction.


It's been a couple of years since I had this problem, and I haven't re-tried it recently. It could be that the problem has been resolved in one way or another -- I don't know.