Skip to main content
Perplexica’s API uses standard HTTP status codes to indicate the success or failure of requests. This guide covers the error codes you may encounter and how to handle them effectively.

HTTP status codes

The API uses the following HTTP status codes:

Error response format

When an error occurs, the API returns a JSON object with error details:
For validation errors, the response may include additional details:

400 Bad Request errors

Missing required fields

Returned when required parameters are missing from the request:
Common causes:
  • Missing sources array in request body
  • Missing query string in request body
  • Empty query string
Example fix:

Validation errors

Returned when request parameters fail validation:
Common validation errors:
  • chatModel.providerId - Chat model provider id must be provided
  • chatModel.key - Chat model key must be provided
  • embeddingModel.providerId - Embedding model provider id must be provided
  • embeddingModel.key - Embedding model key must be provided
  • optimizationMode - Must be one of: speed, balanced, quality
  • messageId - Message ID is required (for /api/chat endpoint)
  • chatId - Chat ID is required (for /api/chat endpoint)

Missing provider fields

Returned when creating a provider without required fields:
This occurs when type, name, or config are missing from a provider creation request.

500 Internal Server errors

General server error

Returned when an unexpected error occurs during processing:
Common causes:
  • Model loading failure
  • Database connection issues
  • Search processing errors

Endpoint-specific errors

Different endpoints may return more specific error messages:

Streaming errors

When using streaming mode, errors are sent as part of the stream:
After an error message, the stream will close. Your client should handle this message type:
When an error occurs in a streaming response, the connection will be closed immediately after sending the error message. Always implement proper error handling in your stream consumer.

Best practices

Validate before sending

Validate your request data before sending it to the API:

Handle errors gracefully

Implement proper error handling in your application:

Retry logic

Implement retry logic for transient errors:
Always implement exponential backoff when retrying failed requests to avoid overwhelming the server.

Get provider information

To avoid provider-related errors, always fetch available providers before making search requests:
See the Search API documentation for more details on the /api/providers endpoint.