Multi-search Template

Introduced 1.0

The Multi-search Template API runs multiple search template requests in a single API request.

Path and HTTP methods

The Multi-search Template API uses the following paths:

  1. GET /_msearch/template
  2. POST /_msearch/template
  3. GET /{index}/_msearch/template
  4. POST /{index}/_msearch/template

Request body

The multi-search template request body follows this pattern, similar to the Multi-search API pattern:

  1. Metadata\n
  2. Query\n
  3. Metadata\n
  4. Query\n
  • Metadata lines include options, such as which indexes to search and the type of search.
  • Query lines use query DSL.

Like the bulk operation, the JSON doesn’t need to be minified—spaces are fine—but it does need to be on a single line. OpenSearch uses newline characters to parse multi-search requests and requires that the request body end with a newline character.

URL parameters and metadata options

All multi-search template URL parameters are optional. Some can also be applied per search as part of each metadata line.

ParameterTypeDescriptionSupported in metadata
allow_no_indicesBooleanSpecifies whether to ignore wildcards that don’t match any indexes. Default is true.Yes
cancel_after_time_intervalTimeThe interval of time after which the search request will be canceled. Supported at both parent and child request levels. The order of precedence is child-level parameter, parent-level parameter, and cluster setting. Default is -1.Yes
css_minimize_roundtripsBooleanSpecifies whether OpenSearch should try to minimize the number of network round trips between the coordinating node and remote clusters (only applicable to cross-cluster search requests). Default is true.No
expand_wildcardsEnumExpands wildcard expressions to concrete indexes. Combine multiple values with commas. Supported values are all, open, closed, hidden, and none. Default is open.Yes
ignore_unavailableBooleanIf an index or shard from the index list doesn’t exist, then this setting specifies whether to ignore the missing index or shard rather than fail the query. Default is false.Yes
max_concurrent_searchesIntegerThe maximum number of concurrent searches. The default depends on your node count and search thread pool size. Higher values can improve performance, but there may be a risk of overloading the cluster.No
max_concurrent_shard_requestsIntegerThe maximum number of concurrent shard requests that each search executes per node. Default is 5. Higher values can improve performance, but there may be a risk of overloading the cluster.No
pre_filter_shard_sizeIntegerDefault is 128.No
rest_total_hits_as_intStringSpecifies whether the hits.total property is returned as an integer (true) or an object (false). Default is false.No
search_typeStringAffects the relevance score. Valid options are query_then_fetch and dfs_query_then_fetch. query_then_fetch scores documents using term and document frequencies for a single shard (faster, less accurate), whereas dfs_query_then_fetch uses term and document frequencies across all shards (slower, more accurate). Default is query_then_fetch.Yes
typed_keysBooleanSpecifies whether to prefix aggregation names with their internal types in the response. Default is false.No

Metadata-only options

Some options can’t be applied as URL parameters to the entire request. Instead, you can apply them per search as part of each metadata line. All are optional.

OptionTypeDescription
indexString, string arrayIf you don’t specify an index or multiple indexes as part of the URL (or want to override the URL value for an individual search), you can include it under this option. Examples include “logs-*” and [“my-store”, “sample_data_ecommerce”].
preferenceStringSpecifies the nodes or shards on which you want to perform the search. This setting can be useful for testing, but in most situations, the default behavior provides the best search latencies. Options include _local, _only_local, _prefer_nodes, _only_nodes, and _shards. These last three options accept a list of nodes or shards. Examples include “_only_nodes:data-node1,data-node2” and “_shards:0,1.
request_cacheBooleanSpecifies whether to cache results, which can improve latency for repeated searches. Default is to use the index.requests.cache.enable setting for the index (which defaults to true for new indexes).
routingStringComma-separated custom routing values, for example, “routing”: “value1,value2,value3”.

Example

The following example msearch/template API request runs queries against a single index using multiple templates named line_search_template and play_search_template:

Request

  1. GET _msearch/template
  2. {"index":"shakespeare"}
  3. {"id":"line_search_template","params":{"text_entry":"All the world's a stage","limit":false,"size":2}}
  4. {"index":"shakespeare"}
  5. {"id":"play_search_template","params":{"play_name":"Henry IV"}}

copy

Response

OpenSearch returns an array with the results of each search in the same order as in the multi-search template request:

  1. {
  2. "took": 5,
  3. "responses": [
  4. {
  5. "took": 5,
  6. "timed_out": false,
  7. "_shards": {
  8. "total": 1,
  9. "successful": 1,
  10. "skipped": 0,
  11. "failed": 0
  12. },
  13. "hits": {
  14. "total": {
  15. "value": 0,
  16. "relation": "eq"
  17. },
  18. "max_score": null,
  19. "hits": []
  20. }
  21. },
  22. {
  23. "took": 3,
  24. "timed_out": false,
  25. "_shards": {
  26. "total": 1,
  27. "successful": 1,
  28. "skipped": 0,
  29. "failed": 0
  30. },
  31. "hits": {
  32. "total": {
  33. "value": 0,
  34. "relation": "eq"
  35. },
  36. "max_score": null,
  37. "hits": []
  38. }
  39. }
  40. ]
  41. }