How should I handle 429: Rate Limit responses?

The best strategy for handling 429s is a retry + exponential backoff strategy.

Deepgram defines rate limits for every project based on the number of concurrent (active) requests. Deepgram does not define rate limits per-minute or per-hour; rate limits are only applied based on the number of requests that are actively processing for a given project.

When your application receives a 429: Too Many Requests response, Deepgram recommends retrying the request. Based on your product needs, the maximum number of retries and the time between retries can be set for optimal product experience.

Deepgram recommends using an exponential backoff strategy for retrying requests, but a simple fixed-time retry strategy will work for a demo/proof-of-concept.

Below is pseudocode for a simple fixed-time retry strategy:

def make_request_to_deepgram_and_retry():
    retry_time = 3  # seconds
    maximum_number_of_retries = 10
    for i in range(maximum_number_of_retries):
        try:
            return make_request_to_deepgram()
        catch (429 error):
            time.sleep(retry_time)
            continue
    return None

Implementing an exponential backoff strategy is only slightly more complicated:

def make_request_to_deepgram_and_retry():
    retry_time = 0.5  # start with a 0.5 second retry time
    maximum_number_of_retries = 10
    maximum_retry_time = 30
    for i in range(maximum_number_of_retries):
        try:
            return make_request_to_deepgram()
        catch (429 error):
            time.sleep(retry_time)
            retry_time = retry_time * 2  # exponential backoff
            if retry_time > maximum_retry_time:
                retry_time = maximum_retry_time
            continue
    return None

Different products will require different values for maximum_number_of_retries and maximum_retry_time.

• If your product operates in a time-sensitive, you may want to set a low value for the retry time and only retry 3-5 times, then trigger fallback logic if the transcript is not returned.

• On the other hand, if it's more important that your product receives a transcript no matter how long it takes, you may want to set a medium value for the retry time and retry continuously until a transcript is returned.