Skip to main content

Overview

The Perplexity SDKs provide robust error handling with specific exception types for different error scenarios. This guide covers how to catch and handle common API errors gracefully.

Common Error Types

The SDKs provide specific exception types for different error scenarios. All of them inherit from PerplexityError:
  • APIConnectionError - Network connection issues. APITimeoutError (Python) or APIConnectionTimeoutError (TypeScript) is raised when a request times out
  • APIStatusError (Python) or APIError (TypeScript) - Base class for HTTP status errors (4xx, 5xx)
  • BadRequestError - 400, invalid request parameters
  • AuthenticationError - 401, invalid API key or authentication issues
  • PermissionDeniedError - 403
  • NotFoundError - 404
  • ConflictError - 409
  • UnprocessableEntityError - 422
  • RateLimitError - 429, rate limit exceeded
  • InternalServerError - 500 and above
  • APIResponseValidationError (Python only) - The response did not match the expected schema
In TypeScript, check error types with instanceof against the classes exported from the package, such as Perplexity.RateLimitError.

Basic Error Handling

Handle common API errors with try-catch blocks:
Common HTTP status codes: 400 (Bad Request), 401 (Authentication), 403 (Permission Denied), 404 (Not Found), 429 (Rate Limit), 500+ (Server Error).

Advanced Error Handling

Exponential Backoff for Rate Limits

The SDKs already retry connection errors, 408, 409, 429, and 5xx responses twice by default, waiting for the Retry-After interval when the server sends one (see Configuration). The Python SDK only follows Retry-After values of 60 seconds or less and uses its own backoff for longer values; the TypeScript SDK follows any value. For custom retry logic, wait at least the Retry-After interval that a 429 response carries, and fall back to exponential backoff with jitter when the header is missing:

Error Context and Debugging

Extract detailed error information for debugging:

Error Recovery Strategies

Graceful Degradation

Implement fallback mechanisms when API calls fail:

Best Practices

1

Always handle rate limits

Rate limiting is common with API usage. Always implement retry logic that waits for the Retry-After interval, with exponential backoff as a fallback.
Don’t implement aggressive retry loops without delays - this can worsen rate limiting.
2

Log errors for monitoring

Include proper logging to track error patterns and API health.
3

Set appropriate timeouts

Configure timeouts to prevent hanging requests.
4

Handle authentication errors

Check for invalid API keys and provide helpful error messages.

Configuration

Configure timeouts and retries

Best Practices

Environment variables and rate limiting