Retry and rate-limit patterns for marketplace APIs

Marketplace APIs impose call limits and, sooner or later, return transient errors. A reliable integration does not suffer them: it handles them with established retry and rate-limiting patterns. Let's look at the main ones.

Classify errors

Not every error should be retried. The first rule is to classify them:

Type	Example	Action
Transient	429, 503, timeout	Retry with backoff
Permanent	400, 422 (invalid data)	Do not retry, fix it
Authentication	401	Refresh token, then retry

Exponential backoff with jitter

Retrying immediately makes things worse. The correct pattern is exponential backoff (1s, 2s, 4s, 8s…) with random jitter to prevent many clients from retrying in sync. Always honour the Retry-After header when the API provides it.

Respect limits: token bucket

To avoid exceeding limits in the first place, use a client-side rate limiter, typically a token bucket: tokens refill at a constant rate and each call consumes one. When tokens run out, calls wait. With multiple workers, the limiter must be shared (e.g. via a central store) to respect a global budget.

Circuit breaker

If an API is clearly struggling, continuing to call it is harmful. The circuit breaker "opens" after an error threshold, temporarily blocks calls and then gradually tries to close again. It protects both the provider and your own pipeline.

Idempotency: the safety net

Retry and idempotency go together. If an operation is retried, it must be repeatable without creating duplicates: idempotent keys, existence checks, upserts. Without idempotency, retries become a source of errors rather than a solution.

Putting it together

In practice calls go through a chain: rate limiter (stay within budget) → circuit breaker (don't hammer a broken service) → retry with backoff (absorb transients) → idempotency (make the retry safe). On Azure these patterns live in the workers and combine with queues and dead-letter for definitive failures.

Common mistakes

• retrying every error, even permanent ones;
• immediate retries with no backoff or jitter;
• ignoring Retry-After and declared limits;
• retries without idempotency, which create duplicates.

Conclusion

Backoff with jitter, token bucket, circuit breaker and idempotency are the four pillars of resilience towards rate-limited APIs. Applied together, they turn unavoidable errors into managed events, keeping the pipeline stable even under pressure.