Advanced

List of methods

Get logs

Get the logs of the latest search and indexing operations.

Configuring timeouts

Override the pre-configured timeouts.

Set extra header

Sends an extra http header to Algolia, for all subsequent queries.

Wait for operations

Wait for a task to complete before executing the next line of code, to synchronize index updates.

Retry logic

Algolia’s architecture is heavily redundant, to provide optimal reliability. Every application is hosted on at least three different servers (called clusters). As a developer, however, you don’t need to worry about those details. The API Client handles them for you:

  • It leverages our dynamic DNS to perform automatic load balancing between servers.
  • Its retry logic switches the targeted server whenever it detects that one of them is down or unreachable. Therefore, a given request will not fail unless all servers are down or unreachable at the same time.

Application-level errors (e.g. invalid query) are still reported without retry.

Error handling

Requests can fail for two main reasons:

  1. Network issues: the server could not be reached, or did not answer within the timeout.
  2. Application error: the server rejected the request.

In the latter case, the error reported by the API client contains:

  • message: an error message indicating the cause of the error
  • status: an HTTP status code indicating the type of error

Here’s an example:

{
  "message":"Invalid Application ID",
  "status":404
}

The error message is purely informational and intended for the developer. You should never rely on its content programmatically, as it may change without notice.