Skip to main content

Retries and Timeouts

The Spotify SDK includes built-in retry logic with exponential backoff and jitter to handle transient errors, rate limits, and network issues automatically.

Overview

The SDK automatically retries requests that fail due to:
  • Connection errors - Network connectivity issues
  • Timeout exceptions - Requests that exceed the timeout limit
  • Rate limit responses (429) - Respects the Retry-After header from Spotify
  • Server errors (5xx) - Temporary Spotify server issues
Client errors (4xx) like NotFoundError, BadRequestError, and AuthenticationError are not retried automatically, as they typically indicate an issue with the request that won’t be resolved by retrying.

Default Retry Configuration

Both SpotifyClient and AsyncSpotifyClient use these default retry settings: These values are defined in the AsyncBaseClient class (src/spotify_sdk/_async/_base_client.py:28-32):

Configuring Max Retries

You can customize the maximum number of retries when initializing the client:

Exponential Backoff with Jitter

The SDK uses exponential backoff with jitter to avoid overwhelming the API and prevent thundering herd problems.

How It Works

The backoff calculation is implemented in _calculate_backoff() (src/spotify_sdk/_async/_base_client.py:221-228):

Example Backoff Times

Here’s what actual backoff times might look like with jitter:
Jitter helps distribute retry attempts over time, reducing the likelihood of multiple clients retrying simultaneously and causing another spike in traffic.

Rate Limit Handling

When Spotify returns a 429 (rate limit) response, the SDK respects the Retry-After header provided by the API.

Rate Limit Retry Logic

The retry logic for rate limits (src/spotify_sdk/_async/_base_client.py:146-154):
The SDK will:
  1. Use the Retry-After value from the response header if available
  2. Fall back to exponential backoff if no Retry-After header is present
  3. Retry the request after waiting
  4. Raise RateLimitError if all retries are exhausted

Handling Rate Limits in Your Code

Timeout Configuration

The SDK allows you to configure request timeouts at the client level and per-request.

Client-Level Timeout

Set a default timeout for all requests:

Per-Request Timeout

The underlying request() method supports per-request timeout overrides (src/spotify_sdk/_async/_base_client.py:90-110):
Timeout exceptions are automatically retried up to max_retries times. If you’re experiencing consistent timeouts, consider increasing the timeout value rather than just increasing retries.

Retry Flow Diagram

Here’s how the retry logic works:

Which Errors Trigger Retries

Retried Automatically

These errors are automatically retried:

Not Retried

These errors are not retried automatically:

Implementation Details

The retry logic is implemented in the request() method of AsyncBaseClient (src/spotify_sdk/_async/_base_client.py:122-163):

Best Practices

For production applications, the default max_retries=3 is usually sufficient. For batch processing or less time-sensitive operations, you might increase this:
If you’re on a slow network or making requests that return large responses, increase the timeout:
While retries happen automatically, you may want to log when they occur for monitoring:
When all retries are exhausted, the SDK raises an exception. Handle this in your application: