What can cause API exhaustion 429 too many requests?

 A timeout API usually means an API call that stops waiting for a response after a specified amount of time.

For example:

Your app → API request → Server
                    ↓
              waits 10 seconds
                    ↓
             no response
                    ↓
              TIMEOUT

Simple example

Suppose your application calls:

GET /api/users

and you set a 5-second timeout.

• Server responds in 2 seconds → ✅ success

• Server responds in 4 seconds → ✅ success

• Server takes 8 seconds → ❌ timeout

A timeout prevents your application from waiting forever.

Common types of API timeouts

• Connection timeout — how long to wait to establish a connection.

• Read/response timeout — how long to wait for the server to return data.

• Request timeout — maximum total time allowed for the API request.

• Idle timeout — disconnects a connection after being inactive for a period.

For example, in Python:

import requests

response = requests.get(
    "https://example.com/api/users",
    timeout=10
)

Here, the request will wait up to 10 seconds before raising a timeout error.

If you're asking which HTTP status code is used for API rate limiting, it's:

429 Too Many Requests

It means the client has sent too many requests in a given period.

Example:

HTTP/1.1 429 Too Many Requests
Retry-After: 60

Retry-After: 60 means the client should wait 60 seconds before trying again.

Don't confuse these:

Situation	Status code
Rate limit exceeded	429
Request/server took too long	408 or 504, depending on the situation
Server error	500
Service temporarily unavailable	503

For rate-limited APIs, 429 is the standard status code.

Sure. Here’s a practical example using Azure API Management (APIM).

Scenario: Rate limit exhaustion

Assume you want to allow each client:

• 100 requests per minute

• If they exceed the limit → return HTTP 429 Too Many Requests

APIM policy example

<policies>
    <inbound>
        <base />

        <rate-limit-by-key 
            calls="100"
            renewal-period="60"
            counter-key="@(context.Subscription.Id)" />
    </inbound>

    <backend>
        <base />
    </backend>

    <outbound>
        <base />
    </outbound>

    <on-error>
        <base />
    </on-error>
</policies>

What happens?

Suppose a client sends requests like this:

12:00:00 → Request 1    ✅ 200
12:00:05 → Request 25   ✅ 200
12:00:20 → Request 75   ✅ 200
12:00:40 → Request 100  ✅ 200
12:00:45 → Request 101  ❌ 429 Too Many Requests

The client has exhausted its rate limit.

The API response would typically be:

HTTP/1.1 429 Too Many Requests

After the 60-second renewal period, the client can make requests again.

---

Example APIM settings

1. Rate limit

Limit requests over a time period:

<rate-limit-by-key 
    calls="100"
    renewal-period="60"
    counter-key="@(context.Subscription.Id)" />

Setting	Meaning
calls="100"	Maximum 100 requests
renewal-period="60"	Limit resets every 60 seconds
counter-key	Identifies which client/user is being limited

---

2. Quota limit

A quota limits requests over a longer period.

For example, 10,000 requests per month:

<quota-by-key
    calls="10000"
    renewal-period="2592000"
    counter-key="@(context.Subscription.Id)" />

Example:

Client usage: 9,999 requests  → ✅
Client usage: 10,000 requests → ✅
Client usage: 10,001 requests → ❌ 429 Too Many Requests

The client must wait until the quota renewal period resets.

---

Combined APIM policy

You can apply both a short-term rate limit and a long-term quota:

<policies>
    <inbound>
        <base />

        <!-- Maximum 100 requests per minute -->
        <rate-limit-by-key
            calls="100"
            renewal-period="60"
            counter-key="@(context.Subscription.Id)" />

        <!-- Maximum 10,000 requests per month -->
        <quota-by-key
            calls="10000"
            renewal-period="2592000"
            counter-key="@(context.Subscription.Id)" />

    </inbound>

    <backend>
        <base />
    </backend>

    <outbound>
        <base />
    </outbound>

    <on-error>
        <base />
    </on-error>
</policies>

In short

Rate limit
100 requests/minute
        ↓
Exceeded?
        ↓
HTTP 429 Too Many Requests
        ↓
Wait for renewal period
        ↓
Requests allowed again