Registrar API Rate Limits: Retries and Backoff with Jitter

When your platform registers domains through a registrar API, two problems can bite you: rate limiting and duplicate registrations. Rate limits are the caps registrars put on how many requests you can send in a given period. Duplicates happen when a retry after a timeout creates a second registration. Both are avoidable with the right client-side logic.

What are registrar API rate limits and why do they matter?

Registrar APIs enforce rate limits to protect their infrastructure. These limits are usually expressed as requests per second, minute, or hour, and may be applied per IP address, per API key, or per account. When you exceed a limit, the API typically responds with HTTP 429 (Too Many Requests) and may include a Retry-After header indicating how long to wait. Ignoring these limits leads to failed operations and can get your API access suspended.

Rate limits matter because domain registration is time-sensitive and often part of a larger workflow (e.g., a customer checkout). If your system hammers the API and gets throttled, registrations fail, customers get frustrated, and you may end up with inconsistent state between your platform and the registrar.

How do you implement client-side rate limiting?

Client-side rate limiting means controlling the pace of your requests before they hit the API. The simplest approach is a token bucket or leaky bucket algorithm. For example, if the registrar allows 10 requests per second, you can use a token bucket that refills at 10 tokens per second and holds at most 10 tokens. Each request consumes a token; if none are available, you wait.

Implement this with a queue and a worker that processes requests at the allowed rate. In distributed systems, use a shared store like Redis to coordinate rate limiting across multiple instances. Always respect the Retry-After header when you receive a 429 response; it's the registrar telling you exactly how long to back off.

What is exponential backoff with jitter and how does it prevent throttling?

Exponential backoff is a retry strategy where you wait longer after each failure: first wait 1 second, then 2, then 4, and so on, up to a maximum. Jitter adds randomness to the wait time to prevent multiple clients from retrying simultaneously (the thundering herd problem). Without jitter, synchronized retries can cause new spikes that trigger more rate limiting.

A common formula is: delay = min(cap, base * 2^attempt) * random(0.5, 1.5). For example, with base=1s and cap=32s, the delays might be 1s, 2s, 4s, 8s, 16s, 32s, each multiplied by a random factor between 0.5 and 1.5. This spreads out retries and gives the API time to recover.

Use exponential backoff with jitter for retrying after transient errors (5xx, 429, network timeouts). Do not retry on client errors (4xx other than 429) because they indicate a problem with the request itself.

How do you avoid duplicate domain registrations when retrying?

Duplicate registrations occur when a request succeeds on the registrar's side but your system doesn't receive the response (e.g., due to a timeout) and retries. To prevent this, use idempotency keys. An idempotency key is a unique identifier (like a UUID) that you generate for each registration attempt and include in the request header. The registrar uses this key to detect and ignore duplicate requests.

Not all registrar APIs support idempotency keys. If yours doesn't, you need a different strategy: before retrying, check the domain's status via a separate API call (e.g., query the domain info endpoint). If the domain is already registered to you, treat the operation as successful. Also, design your system to record the intent to register before making the call, and use a state machine to track progress (e.g., pending, registered, failed). This way, you can reconcile state after a failure.

Additionally, ensure that your retry logic is idempotent at the application level: if a registration is already in progress for a domain, don't start another one. Use a lock or a database transaction to enforce this.

What does a robust retry policy look like?

A robust retry policy combines rate limiting, exponential backoff with jitter, and idempotency. Here are the key components:

• Retry on specific errors: Only retry on 429, 5xx, and network errors. Do not retry on 4xx client errors.
• Maximum retries: Set a limit (e.g., 5 retries) to avoid infinite loops.
• Maximum delay: Cap the backoff delay (e.g., 32 seconds) to keep total latency reasonable.
• Jitter: Add randomness to each delay to avoid synchronized retries.
• Idempotency: Use idempotency keys or pre-check state to avoid duplicates.
• Logging and monitoring: Log all retries and failures so you can diagnose issues and adjust limits.

Implement this as a reusable HTTP client wrapper or middleware that all registrar calls go through. This centralizes the logic and makes it easy to update.

How can Teculiar help?

Teculiar is a platform for hosting, domain, and VPS resellers to build, sell, and automate their offerings, including domain provisioning with built-in retry and rate-limiting logic. To see how it fits your stack, visit our pricing page.

What to do next

• Review your registrar's API documentation for rate limits and idempotency support.
• Implement a rate limiter and retry logic with exponential backoff and jitter in your API client.
• Add idempotency keys or pre-check logic to prevent duplicate registrations.
• Monitor and log retries to fine-tune your settings over time.

Start by auditing your current domain registration flow to identify where throttling and duplicates occur, then apply these patterns incrementally.