# How to bypass rate limiter when using an API key?

**URL:** <https://meta.discourse.org/t/how-to-bypass-rate-limiter-when-using-an-api-key/25990>\
**Category:** Self-hosting\
**Created:** [March 5, 2015, 12:01am UTC](https://meta.discourse.org/t/how-to-bypass-rate-limiter-when-using-an-api-key/25990 "2015-03-05T00:01:14Z")\
**Posts on this page:** 1\
**Showing post:** 14

<div class="post-metadata">

**Author:** ![DeanMarkTaylor](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/deanmarktaylor/32/102462_2.png) [@DeanMarkTaylor](https://meta.discourse.org/u/DeanMarkTaylor)\
**Post date:** [September 18, 2017, 5:06pm UTC](https://meta.discourse.org/t/how-to-bypass-rate-limiter-when-using-an-api-key/25990/14 "2017-09-18T17:06:54Z")

</div>

> [@riking](#):
>
> have a model of the rate limits in your client and force it to sleep if you are about to violate them!

All HTTP clients should really use “Truncated Exponential Backoff” or something similar:

> [Exponential Backoff](http://en.wikipedia.org/wiki/Exponential_backoff) is an algorithm that retries requests to the server based on certain status codes in the server response. The retries exponentially increase the waiting time up to a certain threshold. The idea is that if the server is down temporarily, it is not overwhelmed with requests hitting at the same time when it comes back up.

It’s quite common to find an open source implementation in all of Google’s API libraries.

Some example implementations listed here for Google Storage calls:

> **[Retry strategy  |  Cloud Storage  |  Google Cloud Documentation](https://docs.cloud.google.com/storage/docs/retry-strategy)**

---

_[View the full topic](https://meta.discourse.org/t/how-to-bypass-rate-limiter-when-using-an-api-key/25990)._