diff --git a/output/openapi/elasticsearch-openapi.json b/output/openapi/elasticsearch-openapi.json
index 6fcafa063f..90ab9893f6 100644
--- a/output/openapi/elasticsearch-openapi.json
+++ b/output/openapi/elasticsearch-openapi.json
@@ -3661,7 +3661,7 @@
           "cluster"
         ],
         "summary": "Get the cluster health status",
-        "description": "You can also use the API to get the health status of only specified data streams and indices.\nFor data streams, the API retrieves the health status of the stream’s backing indices.\n\nThe cluster health status is: green, yellow or red.\nOn the shard level, a red status indicates that the specific shard is not allocated in the cluster. Yellow means that the primary shard is allocated but replicas are not. Green means that all shards are allocated.\nThe index level status is controlled by the worst shard status.\n\nOne of the main benefits of the API is the ability to wait until the cluster reaches a certain high water-mark health level.\nThe cluster status is controlled by the worst index status.",
+        "description": "You can also use the API to get the health status of only specified data streams and indices.\nFor data streams, the API retrieves the health status of the stream’s backing indices.\n\nThe cluster health status is: green, yellow or red.\nOn the shard level, a red status indicates that the specific shard is not allocated in the cluster. Yellow means that the primary shard is allocated but replicas are not. Green means that all shards are allocated.\nThe index level status is controlled by the worst shard status.\n\nOne of the main benefits of the API is the ability to wait until the cluster reaches a certain high watermark health level.\nThe cluster status is controlled by the worst index status.",
         "operationId": "cluster-health",
         "parameters": [
           {
@@ -3712,7 +3712,7 @@
           "cluster"
         ],
         "summary": "Get the cluster health status",
-        "description": "You can also use the API to get the health status of only specified data streams and indices.\nFor data streams, the API retrieves the health status of the stream’s backing indices.\n\nThe cluster health status is: green, yellow or red.\nOn the shard level, a red status indicates that the specific shard is not allocated in the cluster. Yellow means that the primary shard is allocated but replicas are not. Green means that all shards are allocated.\nThe index level status is controlled by the worst shard status.\n\nOne of the main benefits of the API is the ability to wait until the cluster reaches a certain high water-mark health level.\nThe cluster status is controlled by the worst index status.",
+        "description": "You can also use the API to get the health status of only specified data streams and indices.\nFor data streams, the API retrieves the health status of the stream’s backing indices.\n\nThe cluster health status is: green, yellow or red.\nOn the shard level, a red status indicates that the specific shard is not allocated in the cluster. Yellow means that the primary shard is allocated but replicas are not. Green means that all shards are allocated.\nThe index level status is controlled by the worst shard status.\n\nOne of the main benefits of the API is the ability to wait until the cluster reaches a certain high watermark health level.\nThe cluster status is controlled by the worst index status.",
         "operationId": "cluster-health-1",
         "parameters": [
           {
@@ -3906,13 +3906,13 @@
           "cluster"
         ],
         "summary": "Reroute the cluster",
-        "description": "Manually change the allocation of individual shards in the cluster.\nFor example, a shard can be moved from one node to another explicitly, an allocation can be cancelled, and an unassigned shard can be explicitly allocated to a specific node.\n\nIt is important to note that after processing any reroute commands Elasticsearch will perform rebalancing as normal (respecting the values of settings such as `cluster.routing.rebalance.enable`) in order to remain in a balanced state.\nFor example, if the requested allocation includes moving a shard from node1 to node2 then this may cause a shard to be moved from node2 back to node1 to even things out.\n\nThe cluster can be set to disable allocations using the `cluster.routing.allocation.enable` setting.\nIf allocations are disabled then the only allocations that will be performed are explicit ones given using the reroute command, and consequent allocations due to rebalancing.\n\nThe cluster will attempt to allocate a shard a maximum of `index.allocation.max_retries` times in a row (defaults to `5`), before giving up and leaving the shard unallocated.\nThis scenario can be caused by structural problems such as having an analyzer which refers to a stopwords file which doesn’t exist on all nodes.\n\nOnce the problem has been corrected, allocation can be manually retried by calling the reroute API with the `?retry_failed` URI query parameter, which will attempt a single retry round for these shards.",
+        "description": "Manually change the allocation of individual shards in the cluster.\nFor example, a shard can be moved from one node to another explicitly, an allocation can be canceled, and an unassigned shard can be explicitly allocated to a specific node.\n\nIt is important to note that after processing any reroute commands Elasticsearch will perform rebalancing as normal (respecting the values of settings such as `cluster.routing.rebalance.enable`) in order to remain in a balanced state.\nFor example, if the requested allocation includes moving a shard from node1 to node2 then this may cause a shard to be moved from node2 back to node1 to even things out.\n\nThe cluster can be set to disable allocations using the `cluster.routing.allocation.enable` setting.\nIf allocations are disabled then the only allocations that will be performed are explicit ones given using the reroute command, and consequent allocations due to rebalancing.\n\nThe cluster will attempt to allocate a shard a maximum of `index.allocation.max_retries` times in a row (defaults to `5`), before giving up and leaving the shard unallocated.\nThis scenario can be caused by structural problems such as having an analyzer which refers to a stopwords file which doesn’t exist on all nodes.\n\nOnce the problem has been corrected, allocation can be manually retried by calling the reroute API with the `?retry_failed` URI query parameter, which will attempt a single retry round for these shards.",
         "operationId": "cluster-reroute",
         "parameters": [
           {
             "in": "query",
             "name": "dry_run",
-            "description": "If true, then the request simulates the operation.\nIt will calculate the result of applying the commands to the current cluster state and return the resulting cluster state after the commands (and re-balancing) has been applied; it will not actually perform the requested changes.",
+            "description": "If true, then the request simulates the operation.\nIt will calculate the result of applying the commands to the current cluster state and return the resulting cluster state after the commands (and rebalancing) have been applied; it will not actually perform the requested changes.",
             "deprecated": false,
             "schema": {
               "type": "boolean"
@@ -4027,7 +4027,7 @@
           "cluster"
         ],
         "summary": "Get the cluster state",
-        "description": "Get comprehensive information about the state of the cluster.\n\nThe cluster state is an internal data structure which keeps track of a variety of information needed by every node, including:the identity and attributes of the other nodes in the cluster; cluster-wide settings; index metadata, including the mapping and settings for each index; the location and status of every shard copy in the cluster.\n\nThe elected master node ensures that every node in the cluster has a copy of the same cluster state.\nThis API lets you retrieve a representation of this internal state for debugging or diagnostic purposes.\nYou may need to consult the Elasticsearch source code to determine the precise meaning of the response.\n\nBy default the API will route requests to the elected master node since this node is the authoritative source of cluster states.\nYou can also retrieve the cluster state held on the node handling the API request by adding the `?local=true` query parameter.\n\nElasticsearch may need to expend significant effort to compute a response to this API in larger clusters, and the response may comprise a very large quantity of data.\nIf you use this API repeatedly, your cluster may become unstable.\n\nWARNING: The response is a representation of an internal data structure.\nIts format is not subject to the same compatibility guarantees as other more stable APIs and may change from version to version.\nDo not query this API using external monitoring tools.\nInstead, obtain the information you require using other more stable cluster APIs.",
+        "description": "Get comprehensive information about the state of the cluster.\n\nThe cluster state is an internal data structure which keeps track of a variety of information needed by every node, including the identity and attributes of the other nodes in the cluster; cluster-wide settings; index metadata, including the mapping and settings for each index; the location and status of every shard copy in the cluster.\n\nThe elected master node ensures that every node in the cluster has a copy of the same cluster state.\nThis API lets you retrieve a representation of this internal state for debugging or diagnostic purposes.\nYou may need to consult the Elasticsearch source code to determine the precise meaning of the response.\n\nBy default the API will route requests to the elected master node since this node is the authoritative source of cluster states.\nYou can also retrieve the cluster state held on the node handling the API request by adding the `?local=true` query parameter.\n\nElasticsearch may need to expend significant effort to compute a response to this API in larger clusters, and the response may comprise a very large quantity of data.\nIf you use this API repeatedly, your cluster may become unstable.\n\nWARNING: The response is a representation of an internal data structure.\nIts format is not subject to the same compatibility guarantees as other more stable APIs and may change from version to version.\nDo not query this API using external monitoring tools.\nInstead, obtain the information you require using other more stable cluster APIs.",
         "operationId": "cluster-state",
         "parameters": [
           {
@@ -4069,7 +4069,7 @@
           "cluster"
         ],
         "summary": "Get the cluster state",
-        "description": "Get comprehensive information about the state of the cluster.\n\nThe cluster state is an internal data structure which keeps track of a variety of information needed by every node, including:the identity and attributes of the other nodes in the cluster; cluster-wide settings; index metadata, including the mapping and settings for each index; the location and status of every shard copy in the cluster.\n\nThe elected master node ensures that every node in the cluster has a copy of the same cluster state.\nThis API lets you retrieve a representation of this internal state for debugging or diagnostic purposes.\nYou may need to consult the Elasticsearch source code to determine the precise meaning of the response.\n\nBy default the API will route requests to the elected master node since this node is the authoritative source of cluster states.\nYou can also retrieve the cluster state held on the node handling the API request by adding the `?local=true` query parameter.\n\nElasticsearch may need to expend significant effort to compute a response to this API in larger clusters, and the response may comprise a very large quantity of data.\nIf you use this API repeatedly, your cluster may become unstable.\n\nWARNING: The response is a representation of an internal data structure.\nIts format is not subject to the same compatibility guarantees as other more stable APIs and may change from version to version.\nDo not query this API using external monitoring tools.\nInstead, obtain the information you require using other more stable cluster APIs.",
+        "description": "Get comprehensive information about the state of the cluster.\n\nThe cluster state is an internal data structure which keeps track of a variety of information needed by every node, including the identity and attributes of the other nodes in the cluster; cluster-wide settings; index metadata, including the mapping and settings for each index; the location and status of every shard copy in the cluster.\n\nThe elected master node ensures that every node in the cluster has a copy of the same cluster state.\nThis API lets you retrieve a representation of this internal state for debugging or diagnostic purposes.\nYou may need to consult the Elasticsearch source code to determine the precise meaning of the response.\n\nBy default the API will route requests to the elected master node since this node is the authoritative source of cluster states.\nYou can also retrieve the cluster state held on the node handling the API request by adding the `?local=true` query parameter.\n\nElasticsearch may need to expend significant effort to compute a response to this API in larger clusters, and the response may comprise a very large quantity of data.\nIf you use this API repeatedly, your cluster may become unstable.\n\nWARNING: The response is a representation of an internal data structure.\nIts format is not subject to the same compatibility guarantees as other more stable APIs and may change from version to version.\nDo not query this API using external monitoring tools.\nInstead, obtain the information you require using other more stable cluster APIs.",
         "operationId": "cluster-state-1",
         "parameters": [
           {
@@ -4114,7 +4114,7 @@
           "cluster"
         ],
         "summary": "Get the cluster state",
-        "description": "Get comprehensive information about the state of the cluster.\n\nThe cluster state is an internal data structure which keeps track of a variety of information needed by every node, including:the identity and attributes of the other nodes in the cluster; cluster-wide settings; index metadata, including the mapping and settings for each index; the location and status of every shard copy in the cluster.\n\nThe elected master node ensures that every node in the cluster has a copy of the same cluster state.\nThis API lets you retrieve a representation of this internal state for debugging or diagnostic purposes.\nYou may need to consult the Elasticsearch source code to determine the precise meaning of the response.\n\nBy default the API will route requests to the elected master node since this node is the authoritative source of cluster states.\nYou can also retrieve the cluster state held on the node handling the API request by adding the `?local=true` query parameter.\n\nElasticsearch may need to expend significant effort to compute a response to this API in larger clusters, and the response may comprise a very large quantity of data.\nIf you use this API repeatedly, your cluster may become unstable.\n\nWARNING: The response is a representation of an internal data structure.\nIts format is not subject to the same compatibility guarantees as other more stable APIs and may change from version to version.\nDo not query this API using external monitoring tools.\nInstead, obtain the information you require using other more stable cluster APIs.",
+        "description": "Get comprehensive information about the state of the cluster.\n\nThe cluster state is an internal data structure which keeps track of a variety of information needed by every node, including the identity and attributes of the other nodes in the cluster; cluster-wide settings; index metadata, including the mapping and settings for each index; the location and status of every shard copy in the cluster.\n\nThe elected master node ensures that every node in the cluster has a copy of the same cluster state.\nThis API lets you retrieve a representation of this internal state for debugging or diagnostic purposes.\nYou may need to consult the Elasticsearch source code to determine the precise meaning of the response.\n\nBy default the API will route requests to the elected master node since this node is the authoritative source of cluster states.\nYou can also retrieve the cluster state held on the node handling the API request by adding the `?local=true` query parameter.\n\nElasticsearch may need to expend significant effort to compute a response to this API in larger clusters, and the response may comprise a very large quantity of data.\nIf you use this API repeatedly, your cluster may become unstable.\n\nWARNING: The response is a representation of an internal data structure.\nIts format is not subject to the same compatibility guarantees as other more stable APIs and may change from version to version.\nDo not query this API using external monitoring tools.\nInstead, obtain the information you require using other more stable cluster APIs.",
         "operationId": "cluster-state-2",
         "parameters": [
           {
@@ -9374,7 +9374,7 @@
           "health_report"
         ],
         "summary": "Get the cluster health",
-        "description": "Get a report with the health status of an Elasticsearch cluster.\nThe report contains a list of indicators that compose Elasticsearch functionality.\n\nEach indicator has a health status of: green, unknown, yellow or red.\nThe indicator will provide an explanation and metadata describing the reason for its current health status.\n\nThe cluster’s status is controlled by the worst indicator status.\n\nIn the event that an indicator’s status is non-green, a list of impacts may be present in the indicator result which detail the functionalities that are negatively affected by the health issue.\nEach impact carries with it a severity level, an area of the system that is affected, and a simple description of the impact on the system.\n\nSome health indicators can determine the root cause of a health problem and prescribe a set of steps that can be performed in order to improve the health of the system.\nThe root cause and remediation steps are encapsulated in a diagnosis.\nA diagnosis contains a cause detailing a root cause analysis, an action containing a brief description of the steps to take to fix the problem, the list of affected resources (if applicable), and a detailed step-by-step troubleshooting guide to fix the diagnosed problem.\n\nNOTE: The health indicators perform root cause analysis of non-green health statuses. This can be computationally expensive when called frequently.\nWhen setting up automated polling of the API for health status set verbose to false to disable the more expensive analysis logic.",
+        "description": "Get a report with the health status of an Elasticsearch cluster.\nThe report contains a list of indicators that compose Elasticsearch functionality.\n\nEach indicator has a health status of: green, unknown, yellow or red.\nThe indicator will provide an explanation and metadata describing the reason for its current health status.\n\nThe cluster’s status is controlled by the worst indicator status.\n\nIn the event that an indicator’s status is non-green, a list of impacts may be present in the indicator result which detail the functionalities that are negatively affected by the health issue.\nEach impact carries with it a severity level, an area of the system that is affected, and a simple description of the impact on the system.\n\nSome health indicators can determine the root cause of a health problem and prescribe a set of steps that can be performed in order to improve the health of the system.\nThe root cause and remediation steps are encapsulated in a diagnosis.\nA diagnosis contains a cause detailing a root cause analysis, an action containing a brief description of the steps to take to fix the problem, the list of affected resources (if applicable), and a detailed step-by-step troubleshooting guide to fix the diagnosed problem.\n\nNOTE: The health indicators perform root cause analysis of non-green health statuses. This can be computationally expensive when called frequently.\nWhen setting up automated polling of the API for health status, set verbose to false to disable the more expensive analysis logic.",
         "operationId": "health-report",
         "parameters": [
           {
@@ -9401,7 +9401,7 @@
           "health_report"
         ],
         "summary": "Get the cluster health",
-        "description": "Get a report with the health status of an Elasticsearch cluster.\nThe report contains a list of indicators that compose Elasticsearch functionality.\n\nEach indicator has a health status of: green, unknown, yellow or red.\nThe indicator will provide an explanation and metadata describing the reason for its current health status.\n\nThe cluster’s status is controlled by the worst indicator status.\n\nIn the event that an indicator’s status is non-green, a list of impacts may be present in the indicator result which detail the functionalities that are negatively affected by the health issue.\nEach impact carries with it a severity level, an area of the system that is affected, and a simple description of the impact on the system.\n\nSome health indicators can determine the root cause of a health problem and prescribe a set of steps that can be performed in order to improve the health of the system.\nThe root cause and remediation steps are encapsulated in a diagnosis.\nA diagnosis contains a cause detailing a root cause analysis, an action containing a brief description of the steps to take to fix the problem, the list of affected resources (if applicable), and a detailed step-by-step troubleshooting guide to fix the diagnosed problem.\n\nNOTE: The health indicators perform root cause analysis of non-green health statuses. This can be computationally expensive when called frequently.\nWhen setting up automated polling of the API for health status set verbose to false to disable the more expensive analysis logic.",
+        "description": "Get a report with the health status of an Elasticsearch cluster.\nThe report contains a list of indicators that compose Elasticsearch functionality.\n\nEach indicator has a health status of: green, unknown, yellow or red.\nThe indicator will provide an explanation and metadata describing the reason for its current health status.\n\nThe cluster’s status is controlled by the worst indicator status.\n\nIn the event that an indicator’s status is non-green, a list of impacts may be present in the indicator result which detail the functionalities that are negatively affected by the health issue.\nEach impact carries with it a severity level, an area of the system that is affected, and a simple description of the impact on the system.\n\nSome health indicators can determine the root cause of a health problem and prescribe a set of steps that can be performed in order to improve the health of the system.\nThe root cause and remediation steps are encapsulated in a diagnosis.\nA diagnosis contains a cause detailing a root cause analysis, an action containing a brief description of the steps to take to fix the problem, the list of affected resources (if applicable), and a detailed step-by-step troubleshooting guide to fix the diagnosed problem.\n\nNOTE: The health indicators perform root cause analysis of non-green health statuses. This can be computationally expensive when called frequently.\nWhen setting up automated polling of the API for health status, set verbose to false to disable the more expensive analysis logic.",
         "operationId": "health-report-1",
         "parameters": [
           {
diff --git a/output/schema/schema.json b/output/schema/schema.json
index a0f0abd329..c9e74c01de 100644
--- a/output/schema/schema.json
+++ b/output/schema/schema.json
@@ -2487,7 +2487,7 @@
           "stability": "stable"
         }
       },
-      "description": "Get the cluster health status.\nYou can also use the API to get the health status of only specified data streams and indices.\nFor data streams, the API retrieves the health status of the stream’s backing indices.\n\nThe cluster health status is: green, yellow or red.\nOn the shard level, a red status indicates that the specific shard is not allocated in the cluster. Yellow means that the primary shard is allocated but replicas are not. Green means that all shards are allocated.\nThe index level status is controlled by the worst shard status.\n\nOne of the main benefits of the API is the ability to wait until the cluster reaches a certain high water-mark health level.\nThe cluster status is controlled by the worst index status.",
+      "description": "Get the cluster health status.\nYou can also use the API to get the health status of only specified data streams and indices.\nFor data streams, the API retrieves the health status of the stream’s backing indices.\n\nThe cluster health status is: green, yellow or red.\nOn the shard level, a red status indicates that the specific shard is not allocated in the cluster. Yellow means that the primary shard is allocated but replicas are not. Green means that all shards are allocated.\nThe index level status is controlled by the worst shard status.\n\nOne of the main benefits of the API is the ability to wait until the cluster reaches a certain high watermark health level.\nThe cluster status is controlled by the worst index status.",
       "docId": "cluster-health",
       "docTag": "cluster",
       "docUrl": "https://www.elastic.co/guide/en/elasticsearch/reference/{branch}/cluster-health.html",
@@ -2762,7 +2762,7 @@
           "stability": "stable"
         }
       },
-      "description": "Reroute the cluster.\nManually change the allocation of individual shards in the cluster.\nFor example, a shard can be moved from one node to another explicitly, an allocation can be cancelled, and an unassigned shard can be explicitly allocated to a specific node.\n\nIt is important to note that after processing any reroute commands Elasticsearch will perform rebalancing as normal (respecting the values of settings such as `cluster.routing.rebalance.enable`) in order to remain in a balanced state.\nFor example, if the requested allocation includes moving a shard from node1 to node2 then this may cause a shard to be moved from node2 back to node1 to even things out.\n\nThe cluster can be set to disable allocations using the `cluster.routing.allocation.enable` setting.\nIf allocations are disabled then the only allocations that will be performed are explicit ones given using the reroute command, and consequent allocations due to rebalancing.\n\nThe cluster will attempt to allocate a shard a maximum of `index.allocation.max_retries` times in a row (defaults to `5`), before giving up and leaving the shard unallocated.\nThis scenario can be caused by structural problems such as having an analyzer which refers to a stopwords file which doesn’t exist on all nodes.\n\nOnce the problem has been corrected, allocation can be manually retried by calling the reroute API with the `?retry_failed` URI query parameter, which will attempt a single retry round for these shards.",
+      "description": "Reroute the cluster.\nManually change the allocation of individual shards in the cluster.\nFor example, a shard can be moved from one node to another explicitly, an allocation can be canceled, and an unassigned shard can be explicitly allocated to a specific node.\n\nIt is important to note that after processing any reroute commands Elasticsearch will perform rebalancing as normal (respecting the values of settings such as `cluster.routing.rebalance.enable`) in order to remain in a balanced state.\nFor example, if the requested allocation includes moving a shard from node1 to node2 then this may cause a shard to be moved from node2 back to node1 to even things out.\n\nThe cluster can be set to disable allocations using the `cluster.routing.allocation.enable` setting.\nIf allocations are disabled then the only allocations that will be performed are explicit ones given using the reroute command, and consequent allocations due to rebalancing.\n\nThe cluster will attempt to allocate a shard a maximum of `index.allocation.max_retries` times in a row (defaults to `5`), before giving up and leaving the shard unallocated.\nThis scenario can be caused by structural problems such as having an analyzer which refers to a stopwords file which doesn’t exist on all nodes.\n\nOnce the problem has been corrected, allocation can be manually retried by calling the reroute API with the `?retry_failed` URI query parameter, which will attempt a single retry round for these shards.",
       "docId": "cluster-reroute",
       "docUrl": "https://www.elastic.co/guide/en/elasticsearch/reference/{branch}/cluster-reroute.html",
       "name": "cluster.reroute",
@@ -2801,7 +2801,7 @@
           "stability": "stable"
         }
       },
-      "description": "Get the cluster state.\nGet comprehensive information about the state of the cluster.\n\nThe cluster state is an internal data structure which keeps track of a variety of information needed by every node, including:the identity and attributes of the other nodes in the cluster; cluster-wide settings; index metadata, including the mapping and settings for each index; the location and status of every shard copy in the cluster.\n\nThe elected master node ensures that every node in the cluster has a copy of the same cluster state.\nThis API lets you retrieve a representation of this internal state for debugging or diagnostic purposes.\nYou may need to consult the Elasticsearch source code to determine the precise meaning of the response.\n\nBy default the API will route requests to the elected master node since this node is the authoritative source of cluster states.\nYou can also retrieve the cluster state held on the node handling the API request by adding the `?local=true` query parameter.\n\nElasticsearch may need to expend significant effort to compute a response to this API in larger clusters, and the response may comprise a very large quantity of data.\nIf you use this API repeatedly, your cluster may become unstable.\n\nWARNING: The response is a representation of an internal data structure.\nIts format is not subject to the same compatibility guarantees as other more stable APIs and may change from version to version.\nDo not query this API using external monitoring tools.\nInstead, obtain the information you require using other more stable cluster APIs.",
+      "description": "Get the cluster state.\nGet comprehensive information about the state of the cluster.\n\nThe cluster state is an internal data structure which keeps track of a variety of information needed by every node, including the identity and attributes of the other nodes in the cluster; cluster-wide settings; index metadata, including the mapping and settings for each index; the location and status of every shard copy in the cluster.\n\nThe elected master node ensures that every node in the cluster has a copy of the same cluster state.\nThis API lets you retrieve a representation of this internal state for debugging or diagnostic purposes.\nYou may need to consult the Elasticsearch source code to determine the precise meaning of the response.\n\nBy default the API will route requests to the elected master node since this node is the authoritative source of cluster states.\nYou can also retrieve the cluster state held on the node handling the API request by adding the `?local=true` query parameter.\n\nElasticsearch may need to expend significant effort to compute a response to this API in larger clusters, and the response may comprise a very large quantity of data.\nIf you use this API repeatedly, your cluster may become unstable.\n\nWARNING: The response is a representation of an internal data structure.\nIts format is not subject to the same compatibility guarantees as other more stable APIs and may change from version to version.\nDo not query this API using external monitoring tools.\nInstead, obtain the information you require using other more stable cluster APIs.",
       "docId": "cluster-state",
       "docUrl": "https://www.elastic.co/guide/en/elasticsearch/reference/{branch}/cluster-state.html",
       "name": "cluster.state",
@@ -5494,7 +5494,7 @@
           "stability": "stable"
         }
       },
-      "description": "Get the cluster health.\nGet a report with the health status of an Elasticsearch cluster.\nThe report contains a list of indicators that compose Elasticsearch functionality.\n\nEach indicator has a health status of: green, unknown, yellow or red.\nThe indicator will provide an explanation and metadata describing the reason for its current health status.\n\nThe cluster’s status is controlled by the worst indicator status.\n\nIn the event that an indicator’s status is non-green, a list of impacts may be present in the indicator result which detail the functionalities that are negatively affected by the health issue.\nEach impact carries with it a severity level, an area of the system that is affected, and a simple description of the impact on the system.\n\nSome health indicators can determine the root cause of a health problem and prescribe a set of steps that can be performed in order to improve the health of the system.\nThe root cause and remediation steps are encapsulated in a diagnosis.\nA diagnosis contains a cause detailing a root cause analysis, an action containing a brief description of the steps to take to fix the problem, the list of affected resources (if applicable), and a detailed step-by-step troubleshooting guide to fix the diagnosed problem.\n\nNOTE: The health indicators perform root cause analysis of non-green health statuses. This can be computationally expensive when called frequently.\nWhen setting up automated polling of the API for health status set verbose to false to disable the more expensive analysis logic.",
+      "description": "Get the cluster health.\nGet a report with the health status of an Elasticsearch cluster.\nThe report contains a list of indicators that compose Elasticsearch functionality.\n\nEach indicator has a health status of: green, unknown, yellow or red.\nThe indicator will provide an explanation and metadata describing the reason for its current health status.\n\nThe cluster’s status is controlled by the worst indicator status.\n\nIn the event that an indicator’s status is non-green, a list of impacts may be present in the indicator result which detail the functionalities that are negatively affected by the health issue.\nEach impact carries with it a severity level, an area of the system that is affected, and a simple description of the impact on the system.\n\nSome health indicators can determine the root cause of a health problem and prescribe a set of steps that can be performed in order to improve the health of the system.\nThe root cause and remediation steps are encapsulated in a diagnosis.\nA diagnosis contains a cause detailing a root cause analysis, an action containing a brief description of the steps to take to fix the problem, the list of affected resources (if applicable), and a detailed step-by-step troubleshooting guide to fix the diagnosed problem.\n\nNOTE: The health indicators perform root cause analysis of non-green health statuses. This can be computationally expensive when called frequently.\nWhen setting up automated polling of the API for health status, set verbose to false to disable the more expensive analysis logic.",
       "docUrl": "https://www.elastic.co/guide/en/elasticsearch/reference/current/health-api.html",
       "name": "health_report",
       "request": {
@@ -26196,7 +26196,7 @@
       "body": {
         "kind": "no_body"
       },
-      "description": "Get the cluster health.\nGet a report with the health status of an Elasticsearch cluster.\nThe report contains a list of indicators that compose Elasticsearch functionality.\n\nEach indicator has a health status of: green, unknown, yellow or red.\nThe indicator will provide an explanation and metadata describing the reason for its current health status.\n\nThe cluster’s status is controlled by the worst indicator status.\n\nIn the event that an indicator’s status is non-green, a list of impacts may be present in the indicator result which detail the functionalities that are negatively affected by the health issue.\nEach impact carries with it a severity level, an area of the system that is affected, and a simple description of the impact on the system.\n\nSome health indicators can determine the root cause of a health problem and prescribe a set of steps that can be performed in order to improve the health of the system.\nThe root cause and remediation steps are encapsulated in a diagnosis.\nA diagnosis contains a cause detailing a root cause analysis, an action containing a brief description of the steps to take to fix the problem, the list of affected resources (if applicable), and a detailed step-by-step troubleshooting guide to fix the diagnosed problem.\n\nNOTE: The health indicators perform root cause analysis of non-green health statuses. This can be computationally expensive when called frequently.\nWhen setting up automated polling of the API for health status set verbose to false to disable the more expensive analysis logic.",
+      "description": "Get the cluster health.\nGet a report with the health status of an Elasticsearch cluster.\nThe report contains a list of indicators that compose Elasticsearch functionality.\n\nEach indicator has a health status of: green, unknown, yellow or red.\nThe indicator will provide an explanation and metadata describing the reason for its current health status.\n\nThe cluster’s status is controlled by the worst indicator status.\n\nIn the event that an indicator’s status is non-green, a list of impacts may be present in the indicator result which detail the functionalities that are negatively affected by the health issue.\nEach impact carries with it a severity level, an area of the system that is affected, and a simple description of the impact on the system.\n\nSome health indicators can determine the root cause of a health problem and prescribe a set of steps that can be performed in order to improve the health of the system.\nThe root cause and remediation steps are encapsulated in a diagnosis.\nA diagnosis contains a cause detailing a root cause analysis, an action containing a brief description of the steps to take to fix the problem, the list of affected resources (if applicable), and a detailed step-by-step troubleshooting guide to fix the diagnosed problem.\n\nNOTE: The health indicators perform root cause analysis of non-green health statuses. This can be computationally expensive when called frequently.\nWhen setting up automated polling of the API for health status, set verbose to false to disable the more expensive analysis logic.",
       "inherits": {
         "type": {
           "name": "RequestBase",
@@ -107489,7 +107489,7 @@
       "body": {
         "kind": "no_body"
       },
-      "description": "Get the cluster health status.\nYou can also use the API to get the health status of only specified data streams and indices.\nFor data streams, the API retrieves the health status of the stream’s backing indices.\n\nThe cluster health status is: green, yellow or red.\nOn the shard level, a red status indicates that the specific shard is not allocated in the cluster. Yellow means that the primary shard is allocated but replicas are not. Green means that all shards are allocated.\nThe index level status is controlled by the worst shard status.\n\nOne of the main benefits of the API is the ability to wait until the cluster reaches a certain high water-mark health level.\nThe cluster status is controlled by the worst index status.",
+      "description": "Get the cluster health status.\nYou can also use the API to get the health status of only specified data streams and indices.\nFor data streams, the API retrieves the health status of the stream’s backing indices.\n\nThe cluster health status is: green, yellow or red.\nOn the shard level, a red status indicates that the specific shard is not allocated in the cluster. Yellow means that the primary shard is allocated but replicas are not. Green means that all shards are allocated.\nThe index level status is controlled by the worst shard status.\n\nOne of the main benefits of the API is the ability to wait until the cluster reaches a certain high watermark health level.\nThe cluster status is controlled by the worst index status.",
       "inherits": {
         "type": {
           "name": "RequestBase",
@@ -109007,7 +109007,7 @@
           }
         ]
       },
-      "description": "Reroute the cluster.\nManually change the allocation of individual shards in the cluster.\nFor example, a shard can be moved from one node to another explicitly, an allocation can be cancelled, and an unassigned shard can be explicitly allocated to a specific node.\n\nIt is important to note that after processing any reroute commands Elasticsearch will perform rebalancing as normal (respecting the values of settings such as `cluster.routing.rebalance.enable`) in order to remain in a balanced state.\nFor example, if the requested allocation includes moving a shard from node1 to node2 then this may cause a shard to be moved from node2 back to node1 to even things out.\n\nThe cluster can be set to disable allocations using the `cluster.routing.allocation.enable` setting.\nIf allocations are disabled then the only allocations that will be performed are explicit ones given using the reroute command, and consequent allocations due to rebalancing.\n\nThe cluster will attempt to allocate a shard a maximum of `index.allocation.max_retries` times in a row (defaults to `5`), before giving up and leaving the shard unallocated.\nThis scenario can be caused by structural problems such as having an analyzer which refers to a stopwords file which doesn’t exist on all nodes.\n\nOnce the problem has been corrected, allocation can be manually retried by calling the reroute API with the `?retry_failed` URI query parameter, which will attempt a single retry round for these shards.",
+      "description": "Reroute the cluster.\nManually change the allocation of individual shards in the cluster.\nFor example, a shard can be moved from one node to another explicitly, an allocation can be canceled, and an unassigned shard can be explicitly allocated to a specific node.\n\nIt is important to note that after processing any reroute commands Elasticsearch will perform rebalancing as normal (respecting the values of settings such as `cluster.routing.rebalance.enable`) in order to remain in a balanced state.\nFor example, if the requested allocation includes moving a shard from node1 to node2 then this may cause a shard to be moved from node2 back to node1 to even things out.\n\nThe cluster can be set to disable allocations using the `cluster.routing.allocation.enable` setting.\nIf allocations are disabled then the only allocations that will be performed are explicit ones given using the reroute command, and consequent allocations due to rebalancing.\n\nThe cluster will attempt to allocate a shard a maximum of `index.allocation.max_retries` times in a row (defaults to `5`), before giving up and leaving the shard unallocated.\nThis scenario can be caused by structural problems such as having an analyzer which refers to a stopwords file which doesn’t exist on all nodes.\n\nOnce the problem has been corrected, allocation can be manually retried by calling the reroute API with the `?retry_failed` URI query parameter, which will attempt a single retry round for these shards.",
       "inherits": {
         "type": {
           "name": "RequestBase",
@@ -109021,7 +109021,7 @@
       "path": [],
       "query": [
         {
-          "description": "If true, then the request simulates the operation.\nIt will calculate the result of applying the commands to the current cluster state and return the resulting cluster state after the commands (and re-balancing) has been applied; it will not actually perform the requested changes.",
+          "description": "If true, then the request simulates the operation.\nIt will calculate the result of applying the commands to the current cluster state and return the resulting cluster state after the commands (and rebalancing) have been applied; it will not actually perform the requested changes.",
           "name": "dry_run",
           "required": false,
           "serverDefault": false,
@@ -109320,7 +109320,7 @@
       "body": {
         "kind": "no_body"
       },
-      "description": "Get the cluster state.\nGet comprehensive information about the state of the cluster.\n\nThe cluster state is an internal data structure which keeps track of a variety of information needed by every node, including:the identity and attributes of the other nodes in the cluster; cluster-wide settings; index metadata, including the mapping and settings for each index; the location and status of every shard copy in the cluster.\n\nThe elected master node ensures that every node in the cluster has a copy of the same cluster state.\nThis API lets you retrieve a representation of this internal state for debugging or diagnostic purposes.\nYou may need to consult the Elasticsearch source code to determine the precise meaning of the response.\n\nBy default the API will route requests to the elected master node since this node is the authoritative source of cluster states.\nYou can also retrieve the cluster state held on the node handling the API request by adding the `?local=true` query parameter.\n\nElasticsearch may need to expend significant effort to compute a response to this API in larger clusters, and the response may comprise a very large quantity of data.\nIf you use this API repeatedly, your cluster may become unstable.\n\nWARNING: The response is a representation of an internal data structure.\nIts format is not subject to the same compatibility guarantees as other more stable APIs and may change from version to version.\nDo not query this API using external monitoring tools.\nInstead, obtain the information you require using other more stable cluster APIs.",
+      "description": "Get the cluster state.\nGet comprehensive information about the state of the cluster.\n\nThe cluster state is an internal data structure which keeps track of a variety of information needed by every node, including the identity and attributes of the other nodes in the cluster; cluster-wide settings; index metadata, including the mapping and settings for each index; the location and status of every shard copy in the cluster.\n\nThe elected master node ensures that every node in the cluster has a copy of the same cluster state.\nThis API lets you retrieve a representation of this internal state for debugging or diagnostic purposes.\nYou may need to consult the Elasticsearch source code to determine the precise meaning of the response.\n\nBy default the API will route requests to the elected master node since this node is the authoritative source of cluster states.\nYou can also retrieve the cluster state held on the node handling the API request by adding the `?local=true` query parameter.\n\nElasticsearch may need to expend significant effort to compute a response to this API in larger clusters, and the response may comprise a very large quantity of data.\nIf you use this API repeatedly, your cluster may become unstable.\n\nWARNING: The response is a representation of an internal data structure.\nIts format is not subject to the same compatibility guarantees as other more stable APIs and may change from version to version.\nDo not query this API using external monitoring tools.\nInstead, obtain the information you require using other more stable cluster APIs.",
       "inherits": {
         "type": {
           "name": "RequestBase",