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. |
It’s recommended to use the Kotlin API client, which is better suited for Android development.
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 DSN 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:
- Network issues: the server could not be reached, or did not answer within the timeout.
- 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:
1
2
3
4
{
"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.
