Beyond Successful API Calls: Managing Timeouts, Retries, and Service Failures

External APIs are an essential part of modern application development. Whether it's processing payments, authenticating users, or retrieving data from third-party services, applications depend on these integrations to function properly.

But what happens when an API suddenly stops responding?

A request might take several seconds longer than expected, return an HTTP 500 error, or fail because of a temporary network interruption. If the application continues waiting or repeatedly sends requests, the problem can affect other services and consume valuable resources.

Developers use several resilience patterns to prevent these situations from affecting the entire application.

Timeouts: Controlling How Long Requests Wait

Every external API request should have a defined timeout. Without one, slow responses can keep connections occupied and eventually affect application performance.

For example, Python's requests library allows developers to configure connection and read timeouts:

response = requests.get(
    "https://api.example.com/data",
    timeout=(3, 5)
)

Here, the application allows three seconds to establish a connection and five seconds to receive response data.

Retries and Exponential Backoff

Temporary network failures and HTTP 503 responses may recover without manual intervention. Retrying selected requests can help handle these situations.

However, immediately repeating failed requests can increase pressure on an already struggling service.

This is where exponential backoff becomes useful. Instead of retrying continuously, the application gradually increases the delay between attempts.

A simple sequence could look like this:

• First retry: 1 second

• Second retry: 2 seconds

• Third retry: 4 seconds

Adding random jitter helps prevent multiple clients from retrying simultaneously.

Another important consideration is idempotency. When payment or order requests are repeated, idempotency keys help prevent the same business operation from being processed more than once.

Circuit Breakers and Graceful Degradation

What if an external service continues failing despite multiple attempts?

A circuit breaker helps control repeated requests using three states: Closed, Open, and Half-Open. Depending on the service's health, it either allows requests, blocks them temporarily, or permits limited requests to test recovery.

Applications can also use graceful degradation. For instance, if a recommendation API becomes unavailable, an e-commerce platform can hide recommendations while keeping product pages and checkout functional.

Monitoring API Failures

Handling failures also requires proper observability. Developers can monitor API latency, p95/p99 response times, timeout frequency, retry success rates, circuit breaker transitions, and fallback execution.

These metrics provide visibility into how external dependencies behave under real production conditions.

Read the full article for a closer look at how these techniques work in practice.

What Happens When an API Call Fails? A Practical Guide