Advanced methods API client methods
This is documentation for v3 of the PHP API clients, which is not the latest version. To see the documentation for the latest version, see PHP v4.
This is documentation for v2 of the Ruby API clients, which is not the latest version. To see the documentation for the latest version, see Ruby v3.
This is documentation for v4 of the JavaScript API clients, which is not the latest version. To see the documentation for the latest version, see JavaScript v5.
This is documentation for v3 of the Python API clients, which is not the latest version. To see the documentation for the latest version, see Python v4.
This is documentation for v8 of the Swift API clients, which is not the latest version. To see the documentation for the latest version, see Swift v9.
This is documentation for v2 of the Kotlin API clients, which is not the latest version. To see the documentation for the latest version, see Kotlin v3.
This is documentation for v6 of the C# API clients, which is not the latest version. To see the documentation for the latest version, see C# v7.
This is documentation for v3 of the Java API clients, which is not the latest version. To see the documentation for the latest version, see Java v4.
This is documentation for v3 of the Go API clients, which is not the latest version. To see the documentation for the latest version, see Go v4.
This is documentation for v1 of the Scala API clients, which is not the latest version. To see the documentation for the latest version, see Scala v2.
| 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 to ensure synchronized index updates. |
| Custom request |
Perform a custom request |
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:
- Use 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 such as 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
}
