Table of contents

Imagine this: you wrote a client that makes requests to a website, and everything works. Then suddenly errors start piling up, workers hang, and the server replies with the mysterious code 429. Sound familiar? Then this guide is for you. We'll break down how to build an HTTP client that doesn't panic at the first problem, but behaves politely and resiliently.

Introduction: why 429 is not an error, but a signal

Many developers see code 429 and think: something broke. In reality, the server is telling you something very specific: you're sending too many requests, slow down. It's not a permanent refusal or a block. It's a request to ease up. And if you listen correctly, your client will become reliable.

What the reader will get in the end

By the end of this tutorial, you'll have a working HTTP client that can do several important things. It correctly handles code 429 and respects the Retry-After header. It uses exponential backoff with jitter so it doesn't create a storm of retries. It limits concurrency so it doesn't overwhelm the target server. And it never hangs thanks to proper timeouts.

You'll get ready-to-use code snippets in three languages: Python (using the httpx library and urllib3 Retry), Node.js, and Go. Each snippet you can plug into your own project and adapt to your needs.

Who this guide is for

This guide is aimed at beginner developers who already know how to make simple HTTP requests but haven't yet dealt with production load. However, it also includes advanced blocks: circuit breaker, metrics, graceful degradation. If you're writing a scraper, an integration with a third-party API, or a service that talks to external resources, this material will save you many sleepless nights.

What you need to know beforehand

You just need to understand what an HTTP request and HTTP response are. It's helpful to know status codes (e.g., 200 is success, 404 is not found). Basic familiarity with at least one language (Python, JavaScript, or Go) will come in handy. No deep networking knowledge required – everything is explained in simple terms.

How much time it will take

Reading and understanding the theory: about 40 minutes. Building a basic client step by step: roughly one hour. Full implementation with all protections, metrics, and tests: about three hours. Don't rush: it's better to slowly understand each step than to quickly copy code you don't understand.

Tip: Read this guide with your code editor open. Try out examples on a test endpoint, not on a live production service.

Prerequisites

Before writing code, let's set up the working environment. This will take a little time but save confusion later.

Needed tools

  • A language and its environment: Python 3.11 or newer, or Node.js 20 or newer, or Go 1.22 or newer.
  • A code editor – any will do, e.g., VS Code.
  • A terminal to run scripts.
  • Internet access to a test HTTP service that can return different response codes.

What to install for Python

  1. Check the Python version in the terminal: type python --version and press Enter.
  2. Create a virtual environment with python -m venv venv.
  3. Activate it: on Windows with venv\Scripts\activate, on macOS and Linux with source venv/bin/activate.
  4. Install libraries with pip install httpx urllib3 requests.

What to install for Node.js

  1. Check the version with node --version.
  2. Create a project folder and enter it.
  3. Initialize the project with npm init -y.
  4. As of Node.js 20, the built-in fetch is available without installation, so no extra packages are needed for a basic client.

What to install for Go

  1. Check the version with go version.
  2. Create a folder and initialize a module with go mod init myclient.
  3. The standard library net/http is sufficient; external packages are optional.

Backups and safety

⚠️ Warning: Never test a new client directly on an important production service. First, use a test endpoint or a local dummy server that you control. Otherwise, aggressive retries could harm another service and lead to your block.

If you're modifying an existing project, make a copy of the file or create a separate branch in your version control system. That way you can always revert changes.

✅ Check: You've installed the chosen language, created a project, and verified that a test script runs without errors. Now we can move on to theory.

Basic concepts in simple terms

To build a client confidently, you need to understand a few key terms. Let's break them down without complex jargon.

What codes 403, 407, 429, and 503 mean

These four codes are easily confused, but they behave differently and require different treatment.

  • Code 429 Too Many Requests – the server says you've exceeded the request limit. This is temporary. You need to slow down and retry later.
  • Code 403 Forbidden – access is denied. This is often not about speed but about permissions: wrong key, lack of authorization, region restriction. Retrying the request unchanged is usually useless.
  • Code 503 Service Unavailable – the server is temporarily overloaded or under maintenance. Like 429, it's temporary, and retrying later can help.
  • Code 407 Proxy Authentication Required – and here's an important nuance. This code comes not from the target site, but from the proxy server. It means the proxy requires authentication and you haven't provided it, or provided it incorrectly.

⚠️ Warning: Code 407 cannot be fixed by IP rotation or backoff. It's a configuration error in your client – specifically, wrong proxy credentials. Check your login, password, and connection string format. No amount of retries will help until you fix the authentication.

Difference between 429 and 403

Remember a simple rule. 429 is about quantity: you're doing it too often. 403 is about permission: you're not allowed at all. With 429, a retry after a pause solves the problem. With 403, a retry without changing conditions won't help – you need to change the key, headers, or approach.

Headers: Retry-After and X-RateLimit

Polite servers hint at when you can come back. The Retry-After header tells you how many seconds to wait before retrying. Sometimes it's a number of seconds, sometimes a specific date. Your client must respect this header: if the server says wait 10 seconds, retrying after 1 second will only make things worse.

The X-RateLimit family of headers tells you the limits: how many requests you're allowed, how many remain, and when the counter resets. For example, X-RateLimit-Remaining shows the remaining count. If it's near zero, you should slow down in advance, without waiting for a 429.

How limits work: token bucket and sliding window

Servers count your requests in two common ways.

Token bucket works like this. Imagine a bucket into which tokens drip at a fixed rate. Each request takes one token. If there are no tokens, the request is rejected with code 429. This scheme allows short bursts: if you've been quiet for a while, the bucket fills up, and you can send a batch of requests at once.

Sliding window counts the number of requests in the last interval, e.g., the last minute. As soon as you exceed the limit in that window, you get a 429. Bursts are punished more harshly here.

Why concurrency is also a limit

Many forget: the limit isn't only on frequency, but also on the number of simultaneous connections. If you open 500 parallel requests, the server may see it as an attack, even if the total number per minute is small. Concurrency must be limited just as strictly as frequency.

Tip: Before building a client, learn the limits of the target service from its documentation. Knowing exact numbers saves you guesswork and unnecessary 429s.

✅ Check: You understand the difference between 429, 403, 407, and 503, know about Retry-After, and have an idea of how the server counts your requests. Great, let's move to practice.

Step 1: Setting up timeouts correctly

Goal: Ensure no request can hang forever and block a worker.

Why a client without timeouts is dangerous

A client without timeouts is a ticking time bomb. If the server stops responding, your request will wait indefinitely. One hanging request holds one worker. Ten hanging requests – your entire pool of workers is occupied, new tasks aren't processed, the service is effectively down. Timeout is your first line of defense.

Four types of timeouts

A proper client distinguishes several timeouts, rather than setting one generic timeout for everything.

  1. Connect timeout – how long to wait to establish a connection to the server. If the server is unreachable, you'll find out quickly.
  2. Read timeout – how long to wait for data after sending the request. Protects against a server that accepted the request but stays silent.
  3. Write timeout – how long to wait for sending the request body. Relevant for large uploads.
  4. Total timeout – the maximum time for the entire request, including all phases.

What values to start with

There are no universal numbers, but there are reasonable starting values. For connect, take 3-5 seconds: connections are usually established quickly. For read, take 10-30 seconds depending on how fast the service delivers data. Set the total timeout to cover the longest reasonable request, e.g., 30-60 seconds.

⚠️ Warning: Never set huge timeouts like 300 seconds for all requests. That masks problems and creates a queue of hanging operations. Better to fail fast and retry than to wait uselessly for a long time.

Step-by-step configuration

  1. Determine how long a successful request to your service usually takes. Measure it a few times.
  2. Set the read timeout to roughly double the average response time.
  3. Set the connect timeout to 3-5 seconds.
  4. Set the total timeout as the sum of reasonable phases plus a small margin.
  5. Run a test request and verify it completes, not hangs.

Tip: If your service sometimes sends large files and sometimes small responses, create different timeout profiles for different request types. One size does not fit all.

Expected result: When hitting a deliberately slow or unreachable address, your client aborts the attempt within the set time with a clear timeout error, rather than hanging forever.

✅ Check: Send a request to an address that doesn't respond (e.g., a non-existent port). The client should return a timeout error approximately within the set time. If it hangs longer, the timeout is not configured correctly.

Step 2: Building retries with exponential backoff and jitter

Goal: Teach the client to retry requests intelligently, without harming itself or the server.

What can be retried: idempotency

Before retrying a request, ask yourself: is it safe to execute it twice? This property is called idempotency. A request is idempotent if repeating it yields the same result and causes no side effects.

  • GET, HEAD, PUT, DELETE are typically idempotent. Retrying them is safe.
  • POST is typically not idempotent. A retry may create a duplicate order, a second payment, a duplicate record.

⚠️ Warning: Never blindly retry POST requests. Resending a non-idempotent request can lead to double billing or duplicate data. If you need to retry POST, use an idempotency key (Idempotency-Key) that the server recognizes and won't execute the operation twice.

How many times to retry

Infinite retries are evil. A reasonable limit is 3 to 5 attempts. If after five attempts the request didn't succeed, the problem is more serious than a temporary glitch and needs to be logged and handled separately.

What is exponential backoff

Backoff is the pause between retries. Exponential means the pause grows multiplicatively with each attempt. For example: first pause 1 second, second 2 seconds, third 4, fourth 8. The formula is simple: base delay multiplied by two to the power of the attempt number.

Why exactly this? If the server is overloaded, short frequent retries will only finish it off. Growing pauses give the server time to recover.

Why without jitter you get a retry storm

Imagine a thousand clients all get a 429 at the same time. They all wait exactly 1 second, then exactly 2, then exactly 4. And they all retry at the same moment. This creates a synchronous storm: the server receives another thousand requests at once and sends 429 again. The problem loops and never resolves.

The solution is jitter – a random addition to the pause. Instead of exactly 2 seconds, one client waits 1.7, another 2.3, another 1.9. Retries are spread out over time, and the server unloads smoothly.

How to respect Retry-After

If the server sends the Retry-After header, it overrides your backoff formula. The rule is simple: take the maximum of your calculated pause and the Retry-After value. Never retry earlier than the server asked. That's a gross violation of politeness that will lead to more 429s.

Step-by-step implementation of retry logic

  1. Check if the request is idempotent. If not and no idempotency key is present – do not retry.
  2. Check the response code. Retry only on 429, 503, and network errors (timeout, connection reset).
  3. Increment the attempt counter. If it exceeds the limit – stop and return an error.
  4. Calculate the base pause using exponential growth.
  5. Add random jitter to the pause.
  6. If Retry-After is present, take the larger of the two values.
  7. Wait the calculated time and retry the request.

Tip: Cap the maximum pause, e.g., 30 or 60 seconds. Otherwise, by the fifth attempt, the backoff may grow to unreasonably large values, and the user will wait too long.

Expected result: On 429, the client pauses, retries the request, and the pauses between retries grow and vary slightly from attempt to attempt.

✅ Check: Set up a test server to return 429 several times in a row, then 200. Your client should successfully get the final response, and you'll see growing pauses with variation in the logs.

Step 3: Limiting concurrency

Goal: Prevent the client from overwhelming the server with a flood of simultaneous requests.

What is a semaphore in simple terms

A semaphore is a counter of permits. Imagine a coat check with a limited number of hooks. While a hook is free, you hang your coat. If all are taken, you wait until someone frees one. A semaphore allows a limited number of tasks to run concurrently, and queues the rest.

Task queue

All requests to be made are placed in a queue. Workers pick up tasks from the queue as they become free. This gives you full control over the pace: as many workers as the max concurrency.

Per-host limit

An important point: the limit should be per host, not global. If you work with multiple services, a global limit for everything isn't optimal. One slow host shouldn't block requests to another. Set a per-domain limit.

Connection pool and keep-alive

Each new TCP connection costs: handshake, secure channel setup. Keep-alive allows reusing a connection for multiple requests in a row. This saves time and server resources. A connection pool keeps open connections ready. Configure the pool size to match your concurrency limit.

⚠️ Warning: Don't confuse connection pool size with concurrency limit. The pool can be slightly larger than the limit for headroom, but if the pool is huge and the limit is small, you're holding unnecessary open connections. Keep them in reasonable balance.

Step-by-step concurrency configuration

  1. Determine a safe number of simultaneous requests per host. Start small, e.g., 5-10.
  2. Create a semaphore with that many permits.
  3. Before each request, acquire a permit.
  4. After the request completes (successfully or not), always release the permit.
  5. Configure a connection pool with keep-alive around the same order of values.
  6. Gradually increase the limit, monitoring the rate of 429s. Once it rises, you've found the ceiling.

Tip: Release the semaphore permit in a finally block or its equivalent. Otherwise, on error, the permit won't be returned, the counter leaks, and eventually the client stops dead.

Expected result: No matter how many tasks you put in the queue, the number of simultaneous requests to the host does not exceed the set limit.

✅ Check: Queue 100 tasks with a limit of 5. In logs or connection monitoring, you should see no more than 5 active requests at any time.

Step 4: Responding specifically to code 429

Goal: Build a correct response to the overload signal and understand when IP rotation is appropriate.

Three actions on 429

When a 429 arrives, you have three tools, and they should be used together.

  1. Slow down – reduce the overall request pace, not just pause for one request. This is key: 429 is a signal that your overall tempo is too high.
  2. Change IP – if you're using IP rotation, switching addresses may help when the limit is tied to a specific address. But it's not a silver bullet.
  3. Defer the task – return the request to the queue with a delay, to execute later when limits recover.

⚠️ Warning: Changing IP does not replace politeness. If the limit is on an account or key, no rotation will help – you'll still hit 429. Don't turn rotation into a way to bypass rules: respect service limits and Retry-After regardless.

Response code action matrix

Keep this simple decision table handy. Here's what to do with each code.

  • 200-299 Success – process the response, release resources, take the next task.
  • 429 Too Many Requests – slow down tempo, respect Retry-After, retry with backoff, defer task or change IP if needed.
  • 503 Service Unavailable – retry with backoff, respect Retry-After, but don't change IP: the problem is server-side.
  • 403 Forbidden – don't blindly retry. Check authorization, headers, permissions. Log for analysis.
  • 407 Proxy Authentication Required – fix proxy credentials. Don't retry or rotate until configuration is fixed.
  • 400, 404, 422 client errors – don't retry. These are errors in your request; retrying won't change anything.
  • 500, 502, 504 server errors – cautiously retry with backoff a small number of times.
  • Network errors and timeouts – retry with backoff if the request is idempotent.

Step-by-step implementation of 429 response

  1. On receiving 429, immediately stop increasing the pace.
  2. Read the Retry-After header if present.
  3. Calculate the pause as the maximum of backoff and Retry-After.
  4. If the limit is likely IP-bound and you have rotation, change the address before retry.
  5. If attempts are exhausted, defer the task back to the queue with a large delay.
  6. Reduce the overall concurrency limit temporarily to give the server a breather.

Tip: Maintain a separate counter for the proportion of 429s in the last minute. If it rises, automatically slow down before the situation becomes critical. This is called adaptive throttling.

Expected result: On a series of 429s, the client smoothly reduces its pace, respects Retry-After, and eventually completes requests successfully without creating a storm.

✅ Check: Simulate a burst of 429s on a test server. The client should reduce its activity, not accelerate retries. The share of successful responses after the pause should recover.

Step 5: Adding a circuit breaker and graceful degradation

Goal: Give the client a fuse that protects both you and the server during prolonged problems.

What is a circuit breaker

Think of a circuit breaker like one in your electrical panel. If errors keep flowing, it opens the circuit: it stops passing requests to the troublesome service for a while. This protects the server from being hammered and your client from wasting resources.

Three states of the breaker

  • Closed – normal operation, requests pass through. The client counts errors.
  • Open – too many errors, requests are immediately blocked without reaching the server. Held for a set duration.
  • Half-open – trial mode. The client lets a few requests through to check if the service has recovered. If yes, it switches back to closed; if not, back to open.

Graceful degradation instead of total shutdown

When a service is unavailable, you don't have to crash everything. Graceful degradation is the ability to work worse but continue working. Examples: serve data from cache instead of fresh, show a reduced result, postpone non-essential tasks, return a sensible fallback instead of an error.

Tip: Always think about what to show the user or system when an external service is down. A fallback with a meaningful message is better than a hang or stack trace.

Step-by-step circuit breaker configuration

  1. Set an error threshold that opens the breaker, e.g., 50% failure rate over a window of 20 requests.
  2. Set the time the breaker stays open, e.g., 30 seconds.
  3. Count successes and failures in a sliding window.
  4. When the threshold is exceeded, switch the breaker to open.
  5. After the time expires, switch to half-open and let through a few trial requests.
  6. Based on the results, return to closed or reopen.

⚠️ Warning: Don't confuse a circuit breaker with retries. Retries repeat a single request, while the breaker manages the entire flow to the service. Together they are powerful, but they must be configured coherently so the breaker doesn't open too early due to normal isolated failures.

Expected result: During prolonged service unavailability, the client stops pummeling it with requests, quickly returns a fallback, and periodically checks for recovery.

✅ Check: Make a test server unavailable. After a series of failures, the client should stop sending requests (open), and after the server recovers, it should return to normal operation via half-open.

Verifying the result: which metrics to track

Resilience can't be assessed by gut feeling. You need numbers. Here are key metrics that show whether the client has become more reliable.

Key indicators

  • Success rate – percentage of requests that complete with a 2xx code. The higher the better. Aim for a consistently high value even under load.
  • p95 latency – the time within which 95% of requests complete. This metric is fairer than the average because it shows how the majority feels, not just the lucky ones.
  • Proportion of 429s – percentage of responses with code 429. If high, you're sending too aggressively. Aim to minimize it.
  • Retries per request – shows how hard it is to achieve success. An increase indicates problems.
  • Circuit breaker openings count – frequent openings signal service instability or overly aggressive settings.

Readiness checklist

  1. Timeouts are set for all phases, no request hangs forever.
  2. Retries work only for idempotent requests and safe status codes.
  3. Backoff grows exponentially and includes jitter.
  4. Retry-After is always respected.
  5. Concurrency is limited per host via a semaphore.
  6. Connection pool with keep-alive is configured in line with the limit.
  7. Response to 429 reduces the pace, not increases retries.
  8. Response code action matrix is implemented.
  9. Circuit breaker protects against prolonged failures.
  10. Metrics are collected and available for analysis.

How to tell the client is more resilient

Compare metrics before and after improvements under the same load. A resilient client shows a high success rate, low 429 rate, stable p95, and no hanging workers. Even when the server misbehaves, your service keeps working without cascading failures.

✅ Check: Run a load test on a test endpoint. If under load the success rate stays high and there are no hangs – congratulations, the client is resilient.

Common mistakes and their solutions

Let's look at typical pitfalls almost everyone hits.

Mistake 1: Retries increase load

Problem: The server is overloaded, and your aggressive retries finish it off. Cause: Retries without backoff and without reducing the overall pace. Solution: Add exponential backoff with jitter, limit the number of attempts, and reduce overall concurrency as errors increase.

Mistake 2: Retrying non-idempotent requests

Problem: Duplicate orders, double charges, duplicate records. Cause: Blindly retrying POST requests. Solution: Only retry idempotent methods. For POST, use an idempotency key that the server recognizes and won't execute the operation twice.

Mistake 3: Treating 429 with endless IP rotation

Problem: You keep changing IPs, but 429 doesn't go away. Cause: The limit is tied to a key or account, not the IP, or you're simply sending too much total traffic. Solution: Slow down and respect Retry-After. IP rotation is just one tool, not a substitute for politeness.

Mistake 4: Synchronous retry storm

Problem: All clients retry at the same moment, the server falls again. Cause: Backoff without jitter. Solution: Add a random component to each pause.

Mistake 5: Hanging workers

Problem: The service gradually stops processing tasks. Cause: No timeouts, requests hang forever. Solution: Set connect, read, and total timeouts on all requests.

Mistake 6: Semaphore permit leak

Problem: Over time, the client stops making requests. Cause: Semaphore permits aren't released on error. Solution: Release permits in a finally block so it always happens.

Mistake 7: Wrong response to 407

Problem: The client endlessly retries and rotates IPs but keeps getting 407. Cause: Code 407 comes from the proxy and means proxy authentication error, not a service problem. Solution: Check and fix the proxy credentials. Retries are useless here.

Ready-made code snippets

Below are descriptions of approaches for three stacks. Adapt to your project.

Python with httpx

Create an httpx client with explicit timeouts via a Timeout object, specifying connect and read separately. Set pool limits via httpx Limits, specifying max connections per host. Wrap the call in a retry loop: on 429 and 503, read Retry-After, calculate pause as max of exponential backoff with jitter and Retry-After value, then sleep via asyncio sleep. Limit concurrency with asyncio Semaphore, releasing it in a finally block. Retry only idempotent methods, cap attempts at five.

Python with urllib3 Retry

The urllib3 library offers a built-in mechanism. Create a Retry object with parameters: total sets number of attempts, backoff_factor enables exponential pauses, status_forcelist lists codes to retry, e.g., 429, 500, 502, 503, 504. The parameter respect_retry_after_header enables honoring Retry-After. Pass this Retry to a PoolManager or to a requests adapter via HTTPAdapter. This is the fastest way to get basic resilience without writing a loop manually.

Node.js

Use the built-in fetch with AbortController for timeouts: create a controller, set a setTimeout to abort, pass signal to fetch. Wrap the call in a function with a retry loop. Check response.status: on 429 and 503, read the Retry-After header via response.headers.get, calculate a pause with jitter, wait via a promise with setTimeout. For concurrency limiting, use a simple promise semaphore or a popular throttling library. Keep the number of concurrent promises under control via a queue.

Go

In Go, configure an http Client with a Timeout field for total timeout and set up a Transport with MaxIdleConnsPerHost and IdleConnTimeout for pool and keep-alive. For connect timeout, use DialContext with a net Dialer. Implement a retry loop: on 429 and 503, read the Retry-After header, calculate pause via time Duration with exponential growth and random jitter, wait via time Sleep or select with context. Limit concurrency with a buffered channel as a semaphore: write to the channel before the request, read from it in defer after.

Tip: In any language, externalize settings (timeouts, retry count, concurrency limit) into configuration, don't hardcode them. That way you can adjust behavior per service without rewriting code.

Additional features and optimization

Once the basic client works, you can make it even smarter.

Adaptive rate limiting

Instead of a fixed limit, make it dynamic. Read X-RateLimit-Remaining headers and slow down preemptively when the remaining count is low. This avoids 429s before they happen.

Task priorities

Not all requests are equal. Implement a priority queue: important tasks run first, non-essential ones are deferred first during degradation.

Caching

For idempotent GET requests, add a cache with a short TTL. This reduces server load and your share of 429s without any tricks.

Observability

Add structured logging and metrics. Log every retry, every circuit breaker open, every long pause. This helps you quickly find bottlenecks during incident analysis.

Tip: Start with a simple client and add advanced features as real needs arise. Premature complexity is as harmful as its absence.

FAQ: Frequently asked questions

Should I always respect Retry-After, even if it's large?

Yes. If Retry-After is too long for your scenario, it's better to defer the task or return a degraded response than to retry early. Ignoring Retry-After almost always leads to more 429s.

Can I retry POST requests?

Only cautiously. If the operation is not idempotent, a retry may create a duplicate. Use an idempotency key so the server itself protects you from double execution.

What number of concurrent requests should I start with?

Start small, e.g., 5-10 per host, then increase while monitoring the 429 rate and p95. Once 429s rise, you've found the ceiling.

How does 429 differ from 503 in practice?

429 is about your pace: you're sending too often. 503 is about the server: it itself is overloaded or under maintenance. On 429, slow down and possibly change IP. On 503, changing IP doesn't help; just retry later.

Why does my client sometimes get 407?

Code 407 comes from the proxy and means proxy authentication failed. Check your proxy login and password. IP rotation and backoff won't help – it's a configuration error.

How many retry attempts is normal?

Typically three to five. More rarely makes sense: if five attempts didn't help, the problem is more serious than a temporary glitch.

Why do I need jitter if backoff already grows?

Without jitter, many clients retry at the same moments and create a synchronous storm. Random variation spreads retries over time and unloads the server smoothly.

When should I open the circuit breaker?

When the error rate in a sliding window exceeds a set threshold, e.g., half of the requests. This protects both the server and your client from wasting resources.

Does changing IP help with 429?

Sometimes, if the limit is tied to the IP. But if the limit is on a key or account, changing IP is useless. Changing IP doesn't replace slowing down and respecting Retry-After.

What should I show the user when the service is down?

A clear fallback, cached data, or a reduced result. That's better than a hang or a technical error on the screen.

Conclusion

You've come a long way. Let's recap what you built. You configured timeouts for all phases so no request hangs forever. You added smart retries with exponential backoff and jitter, which only repeat safe requests and respect Retry-After. You limited concurrency with a semaphore and set up a connection pool with keep-alive. You built a proper response to 429 and created an action matrix for status codes. Finally, you added a circuit breaker and graceful degradation.

The main idea of this whole guide is simple. 429 is not an error, it's a conversation. The server tells you to slow down, and a polite client listens. Resilience comes not from aggression, but from knowing when to ease up.

What to do next

Collect metrics under real load and look at success rates and 429 proportions. Gradually adjust limits per service. Add adaptive rate limiting based on X-RateLimit headers. Implement caching for idempotent requests.

Where to go from here

Explore the topic of IP address pools and their health separately – that's a large adjacent area we intentionally didn't touch here. Dive into observability: traces, dashboards, alerts. And definitely read the documentation of the services you work with: exact limits are always better than guesses.

You did great. Now you have a client that doesn't panic but behaves resiliently and politely. This is the foundation for building reliable integrations. Good luck with your projects.