swift_small_white Created with Sketch.


Custom batch - batch

You may want to perform multiple operations with one API call to reduce latency.

If you have one index per user, you may want to perform a batch operations across several indices. We expose a method to perform this type of batch:

let operations: [JSONObject] = [
    "action": "addObject",
    "indexName": "index1",
    "body": [
      "firstname": "Jimmie",
      "lastname": "Barninger"
    "action": "addObject",
    "indexName": "index2",
    "body": [
      "firstname": "Warren",
      "lastname": "Speach"
client.batch(operations: operations) {
  (content, error) in
  // Handle response

The attribute action can have these values:

  • addObject
  • updateObject
  • partialUpdateObject
  • partialUpdateObjectNoCreate
  • deleteObject

Backup / Export an index - browse

The search method cannot return more than 1,000 results. If you need to retrieve all the content of your index (for backup, SEO purposes or for running a script on it), you should use the browse method instead. This method lets you retrieve objects beyond the 1,000 limit.

This method is optimized for speed. To make it fast, distinct, typo-tolerance, word proximity, geo distance and number of matched words are disabled. Results are still returned ranked by attributes and custom ranking.

Response Format

  "hits": [
      "firstname": "Jimmie",
      "lastname": "Barninger",
      "objectID": "433"
  "processingTimeMS": 7,
  "query": "",
  "params": "filters=level%3D20",
  • cursor (string, optional): A cursor to retrieve the next chunk of data. If absent, it means that the end of the index has been reached.
  • query (string): Query text used to filter the results.
  • params (string, URL-encoded): Search parameters used to filter the results.
  • processingTimeMS (integer): Time that the server took to process the request, in milliseconds. Note: This does not include network time.

The following fields are provided for convenience purposes, and only when the browse is not filtered:

  • nbHits (integer): Number of objects in the index.
  • page (integer): Index of the current page (zero-based).
  • hitsPerPage (integer): Maximum number of hits returned per page.
  • nbPages (integer): Number of pages corresponding to the number of hits. Basically, ceil(nbHits / hitsPerPage).


Using the low-level methods:

index.browse(query: Query(), completionHandler: { (content, error) in
  if error != nil {
  // Handle content [...]
  // If there is more content...
  if let cursor = content!["cursor"] as? String {
      index.browse(from: cursor, completionHandler: { (content, error) in
          // Handle more content [...]

Using the browse helper:

let iterator = BrowseIterator(index: index, query: Query()) { (iterator, content, error) in
  // Handle the content/error [...]
  // You may cancel the iteration with:

Retry logic

Algolia’s architecture is heavily redundant, to provide optimal reliability. Every application is hosted on at least three different servers. 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:

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

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.

Configuring timeouts

Network & DNS resolution can be slow. That is why we have pre-configured timeouts. We do not advise to change them, but it could make sense to change them in some special cases:

// Time-out for search queries:
client.searchTimeout = 5.0 // in seconds
// Time-out for other requests:
client.timeout = 10.0 // in seconds