New Rate Limits for the Geocoding & Places API Effective July 1, 2025
Here's my feedback for the topic:
Though the throughput of geocodings increases from an average speed of "2'000 geocodings/ minute" to "6'000/minute" (derived by 100/sec) this info might require your attention because of this:
- Burst traffic within a second: If your application sends, for example, 150 requests in under a second, this would now violate the 100 requests/second limit. Previously, such a burst was allowed as long as it stayed under 2000/min. After the change you'll likely receive 429 Too Many Requests or similar errors.
- Reduced burst flexibility: Under the old limit, you could send short bursts of several hundred requests quickly and then pause. With the new per-second cap, this is no longer possible — the system expects strict adherence every second.
- More precise client-side rate limiting needed: You'll now need a throttling mechanism that ensures no more than 100 requests per second, consistently.
- Implement a leaky bucket or token bucket algorithm to smooth out request rates.
- If using multi-threaded or multi-process request generation, make sure to coordinate globally to stay within the shared rate limit.
- Log and monitor request failures (especially HTTP 429s) with timestamps to spot rate spikes.
- Consider to use batch geocoding
- Consider to use multiple ApiKeys as the rate limits apply "per ApiKey“
Bernd
