Advanced methods
List of methods
| Get logs |
Get the logs of the latest search and indexing operations. |
| Configuring timeouts |
Change the pre-configured timeouts. |
| Set extra header |
Send an extra HTTP header to Algolia for use with later queries. |
| Wait for operations |
Wait for a task to complete before executing the next line of code, to synchronize index updates. |
| Custom request |
Perform a custom request |
It’s recommended to use the Kotlin API client, which is better suited for Android development.
We released a new version of the JavaScript API client in public beta. Read the beta documentation for more information.
We released a new version of the PHP API client in public beta. Read the beta documentation for more information.
We released a new version of the Java API client in public beta. Read the beta documentation for more information.
Retry logic
To provide reliability, Algolia’s architecture is redundant. Every application is hosted on at least three different servers (clusters).
As a developer, you don’t need to worry about these details, the API clients handle them for you:
- Leverage the dynamic distributed search network to perform automatic load balancing between servers.
- The retry logic switches the targeted server whenever it detects that one of them is down or unreachable. A given request won’t fail unless all servers are down or unreachable at the same time.
Application-level errors, for example, invalid queries are still reported without retry.
Error handling
Requests can fail for two main reasons:
- Network issues: the server couldn’t be reached, or didn’t answer within the timeout.
- Application error: the server rejected the request.
For application errors, the API client reports:
- message: an error message indicating the cause of the error
- status: an HTTP status code indicating the type of error
For example:
1
2
3
4
{
"message":"Invalid Application ID",
"status":404
}
