Create or update index template API

You can use C-style /* */ block comments in index templates. You can include comments anywhere in the request body, except before the opening curly bracket.

You can include index aliases in an index template.

PUT _index_template/template_1
{
  "index_patterns" : ["te*"],
  "template": {
    "settings" : {
        "number_of_shards" : 1
    },
    "aliases" : {
        "alias1" : {},
        "alias2" : {
            "filter" : {
                "term" : {"user.id" : "kimchy" }
            },
            "routing" : "shard-1"
        },
        "{index}-alias" : {} 
    }
  }
}

If multiple index templates match the name of a new index or data stream, the template with the highest priority is used. For example:

PUT /_index_template/template_1
{
  "index_patterns" : ["t*"],
  "priority" : 0,
  "template": {
    "settings" : {
      "number_of_shards" : 1,
      "number_of_replicas": 0
    },
    "mappings" : {
      "_source" : { "enabled" : false }
    }
  }
}

PUT /_index_template/template_2
{
  "index_patterns" : ["te*"],
  "priority" : 1,
  "template": {
    "settings" : {
      "number_of_shards" : 2
    },
    "mappings" : {
      "_source" : { "enabled" : true }
    }
  }
}

For indices that start with te*, _source will enabled, and the index will have two primary shards and one replica, because only template_2 will be applied.

You can use the version parameter to add a version number to an index template. External systems can use these version numbers to simplify template management.

The version parameter is optional and not automatically generated or used by Elasticsearch.

To unset a version, replace the template without specifying one.

PUT /_index_template/template_1
{
  "index_patterns" : ["foo", "bar"],
  "priority" : 0,
  "template": {
    "settings" : {
        "number_of_shards" : 1
    }
  },
  "version": 123
}

To check the version, you can use the get index template API.

You can use the _meta parameter to add arbitrary metadata to an index template. This user-defined object is stored in the cluster state, so keeping it short is preferrable.

The _meta parameter is optional and not automatically generated or used by Elasticsearch.

To unset _meta, replace the template without specifying one.

PUT /_index_template/template_1
{
  "index_patterns": ["foo", "bar"],
  "template": {
    "settings" : {
        "number_of_shards" : 3
    }
  },
  "_meta": {
    "description": "set number of shards to three",
    "serialization": {
      "class": "MyIndexTemplate",
      "id": 17
    }
  }
}

To check the _meta, you can use the get index template API.

To use an index template for a data stream, the template must include an empty data_stream object. Data stream templates are only used for a stream’s backing indices, they are not applied to regular indices. See Create an index template.

PUT /_index_template/template_1
{
  "index_patterns": ["logs-*"],
  "data_stream": { }
}

When multiple component templates are specified in the composed_of field for an index template, they are merged in the order specified, meaning that later component templates override earlier component templates. Any mappings, settings, or aliases from the parent index template are merged in next. Finally, any configuration on the index request itself is merged.

In this example, the order of the two component templates changes the number of shards for an index:

PUT /_component_template/template_with_2_shards
{
  "template": {
    "settings": {
      "index.number_of_shards": 2
    }
  }
}

PUT /_component_template/template_with_3_shards
{
  "template": {
    "settings": {
      "index.number_of_shards": 3
    }
  }
}

PUT /_index_template/template_1
{
  "index_patterns": ["t*"],
  "composed_of": ["template_with_2_shards", "template_with_3_shards"]
}

In this case, an index matching t* will have three primary shards. If the order of composed templates were reversed, the index would have two primary shards.

Mapping definitions are merged recursively, which means that later mapping components can introduce new field mappings and update the mapping configuration. If a field mapping is already contained in an earlier component, its definition will be completely overwritten by the later one.

This recursive merging strategy applies not only to field mappings, but also root options like dynamic_templates and meta. If an earlier component contains a dynamic_templates block, then by default new dynamic_templates entries are appended onto the end. If an entry already exists with the same key, then it is overwritten by the new definition.