"Incorrect HTTP method for uri" when PUTting _index_template

I am trying to create an index template. Following the examples in getting-started-index-lifecycle-management and indices-templates I'm trying with a PUT request that looks like:


with body:

	"index_patterns": [
	"data_stream": {
		"timestamp_field": "tsField"
	"template": {
		"mappings": {
			"dynamic": true,
			"date_detection": true,
			"dynamic_date_formats": [
			"numeric_detection": false,
			"_source": {
				"enabled": false,
				"includes": [],
				"excludes": []
			"_routing": {
				"required": false
			"meta": {},
			"properties": {
				"someId": {
					"type": "keyword",
					"ignore_above": 256,
					"norms": false
				"some_metric": {
					"type": "float"
				"some_boolean": {
					"type": "byte"
				"tsField": {
					"type": "date",
					"format": "epoch_millis"
		"settings": {
			"number_of_shards": 1,
			"number_of_replicas": 1,
			"index.lifecycle.name": "retention-1-week"

but I get the following error:

  "error": "Incorrect HTTP method for uri [/_index_template/name-of-index-template] and method [PUT], allowed: [POST]",
  "status": 405

Would you know what's wrong with how I structured my request?

Thanks in advance.

1 Like

There is no such end point. Just remove the "_index" part and try again, e.g.

PUT http://localhost:9200/_template/your_template_name

You may also want to review that index_patterns value, in my experience it's usually better to have a trailing wildcard matching the indices you want to create with that particular template rather than have a wildcard in the middle of the pattern. This is particularly important if you want to create some sort of template hierarchy in your cluster - perhaps a general template with common fields and then more specialized templates for special fields or shard settings.

You can apply several index templates in a hierarchical fashion when creating one index, you do so by defining the template order and a stricter index_patterns for the higher orders. It's a bit like inheritance for index templates :slight_smile: For an example of this, see Good practice for index templates in ES.

Good luck!

Thank you!

Ah, I see what the problem was. I just noticed a banner at the top of the 2 pages I linked:

You are looking at preliminary documentation for a future release. Not what you want? See the current release documentation.

Apparently the default for the documentation pages is to show information from the future (version 8.0, not out yet, while the current one - which I am using - is 7.7). That's a little confusing, I struggle to understand why that's the case.

Anyway, now I discovered that in the present there is still no distinction between index templates (whose endpoint will be _index_template) and component templates (endpoint _component_template). Moreover, there is no concept and optimization for data streams (sending my request with the data_stream field results in a "unknown key [data_stream] in the template " error (but I won't in version 8.0).

Regarding the pattern structure and template inheritance: thank you for the valuable information. It's not something I have a use for at the moment (I just have a few indices, and the pattern format that I have is just mimicking the names of kafka topics that elasticsearch is ingesting, and they are very specific, all with the same fields/properties, and only distinguished by the name in the middle). But I will keep the possibility in mind!

Thank you.

1 Like

Actually, I have a question on patterns.

Reading the 7.7 version of "Automate rollover with ILM" (my first link), I noticed that it's possible to specify an "index.lifecycle.rollover_alias" field under "settings" in the template.

The example uses a pattern for the index with a wildcard in the end, so that it can match all indices of the form datastream-<number> (with <number> that increments automatically on rollover).

In my case I would need to be general (use wildcards) both in the middle and at the end of the index name.

Imagine my indices are of the form project_name.city.responsibility. For example project_name is ml for Machine Learning and responsibility is eval for Evaluation (real-time stream of performance metrics on some ML predictions, for a given city). The ml and eval part are fixed, while the city can change (I have multiple cities, and all the eval streams for them have the same structure, hence my need for using a pattern of the form ml.*.eval).

I also need rollover on all of them, though. Therefore, if I understood the way to "impose a retention window" in elasticsearch, I should activate automatic rollover on my indices, plus some ILM policy with deletion for old data (I would have indices like ml.paris.eval-0003, and after X days I would have ml.paris.eval-0004, while ml.paris.eval-0003 is moved to deletion). Finally, I would need an alias over them, so that I can refer to whatever is the current rolled-over index without specifying the numeric part at the end (I can always use ml.paris.eval in place of ml.paris.eval-<most-recent-number>).

I hope my scenario is clear. Basically I need to be generic both in the middle of indices' names (variability over city) and at the end of them (for matching automatically rolled-over indices).

So now my question is: is there a way to specify a "generic alias" in "index.lifecycle.rollover_alias"?

I would like to have in my template:

"index_patterns": ["ml.*.eval-*"]

and then:

"index.lifecycle.rollover_alias": "ml.*.eval"

but this is not possible.

Do I have to create a different template for every city? (All templates would be identical, except for the index name and the alias, which would contain the city "hardcoded" inside, and I would use the pattern there only for the rollover & alias functionality)

Or is this a use case for template inheritance that you were advocating for? (A template to match generic cities and a template to match the final numeric part that comes from rollover and impose aliases? I'm not sure how would I mix them in this case. Perhaps you can help here).

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.