@elastic/schemas 0.4.4 → 0.4.5

package/lib/cjs/es/json/security.put_role_mapping.request.json

@@ -1 +1 @@
-{ "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "security.put_role_mapping", "type": "object", "properties": { "enabled": { "type": "boolean", "description": "Mappings that have `enabled` set to `false` are ignored when role mapping is performed.", "x-found-in": "body" }, "metadata": { "$ref": "./_types.json#/$defs/_types__Metadata", "description": "Additional metadata that helps define which roles are assigned to each user.\nWithin the metadata object, keys beginning with `_` are reserved for system usage.", "x-found-in": "body" }, "roles": { "type": "array", "items": { "type": "string" }, "description": "A list of role names that are granted to the users that match the role mapping rules.\nExactly one of `roles` or `role_templates` must be specified.", "x-found-in": "body" }, "role_templates": { "type": "array", "items": { "$ref": "./security._types.json#/$defs/security._types__RoleTemplate" }, "description": "A list of Mustache templates that will be evaluated to determine the roles names that should granted to the users that match the role mapping rules.\nExactly one of `roles` or `role_templates` must be specified.", "x-found-in": "body" }, "rules": { "$ref": "./security._types.json#/$defs/security._types__RoleMappingRule", "description": "The rules that determine which users should be matched by the mapping.\nA rule is a logical condition that is expressed by using a JSON DSL.", "x-found-in": "body" }, "run_as": { "type": "array", "items": { "type": "string" }, "x-found-in": "body" }, "refresh": { "$ref": "./_types.json#/$defs/_types__Refresh", "description": "If `true` (the default) then refresh the affected shards to make this operation visible to search, if `wait_for` then wait for a refresh to make this operation visible to search, if `false` then do nothing with refreshes.", "x-found-in": "query" }, "name": { "type": "string", "description": "The distinct name that identifies the role mapping.\nThe name is used solely as an identifier to facilitate interaction via the API; it does not affect the behavior of the mapping in any way.", "x-found-in": "path" } }, "required": ["name"], "description": "Create or update role mappings.\n\nRole mappings define which roles are assigned to each user.\nEach mapping has rules that identify users and a list of roles that are granted to those users.\nThe role mapping APIs are generally the preferred way to manage role mappings rather than using role mapping files. The create or update role mappings API cannot update role mappings that are defined in role mapping files.\n\nNOTE: This API does not create roles. Rather, it maps users to existing roles.\nRoles can be created by using the create or update roles API or roles files.\n\n**Role templates**\n\nThe most common use for role mappings is to create a mapping from a known value on the user to a fixed role name.\nFor example, all users in the `cn=admin,dc=example,dc=com` LDAP group should be given the superuser role in Elasticsearch.\nThe `roles` field is used for this purpose.\n\nFor more complex needs, it is possible to use Mustache templates to dynamically determine the names of the roles that should be granted to the user.\nThe `role_templates` field is used for this purpose.\n\nNOTE: To use role templates successfully, the relevant scripting feature must be enabled.\nOtherwise, all attempts to create a role mapping with role templates fail.\n\nAll of the user fields that are available in the role mapping rules are also available in the role templates.\nThus it is possible to assign a user to a role that reflects their username, their groups, or the name of the realm to which they authenticated.\n\nBy default a template is evaluated to produce a single string that is the name of the role which should be assigned to the user.\nIf the format of the template is set to \"json\" then the template is expected to produce a JSON string or an array of JSON strings for the role names." }
+{ "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "security.put_role_mapping", "type": "object", "properties": { "refresh": { "$ref": "./_types.json#/$defs/_types__Refresh", "description": "If `true` (the default) then refresh the affected shards to make this operation visible to search, if `wait_for` then wait for a refresh to make this operation visible to search, if `false` then do nothing with refreshes.", "x-found-in": "query" }, "enabled": { "type": "boolean", "description": "Mappings that have `enabled` set to `false` are ignored when role mapping is performed.", "x-found-in": "body" }, "metadata": { "$ref": "./_types.json#/$defs/_types__Metadata", "description": "Additional metadata that helps define which roles are assigned to each user.\nWithin the metadata object, keys beginning with `_` are reserved for system usage.", "x-found-in": "body" }, "roles": { "type": "array", "items": { "type": "string" }, "description": "A list of role names that are granted to the users that match the role mapping rules.\nExactly one of `roles` or `role_templates` must be specified.", "x-found-in": "body" }, "role_templates": { "type": "array", "items": { "$ref": "./security._types.json#/$defs/security._types__RoleTemplate" }, "description": "A list of Mustache templates that will be evaluated to determine the roles names that should granted to the users that match the role mapping rules.\nExactly one of `roles` or `role_templates` must be specified.", "x-found-in": "body" }, "rules": { "$ref": "./security._types.json#/$defs/security._types__RoleMappingRule", "description": "The rules that determine which users should be matched by the mapping.\nA rule is a logical condition that is expressed by using a JSON DSL.", "x-found-in": "body" }, "run_as": { "type": "array", "items": { "type": "string" }, "x-found-in": "body" }, "name": { "type": "string", "description": "The distinct name that identifies the role mapping.\nThe name is used solely as an identifier to facilitate interaction via the API; it does not affect the behavior of the mapping in any way.", "x-found-in": "path" } }, "required": ["name"], "description": "Create or update role mappings.\n\nRole mappings define which roles are assigned to each user.\nEach mapping has rules that identify users and a list of roles that are granted to those users.\nThe role mapping APIs are generally the preferred way to manage role mappings rather than using role mapping files. The create or update role mappings API cannot update role mappings that are defined in role mapping files.\n\nNOTE: This API does not create roles. Rather, it maps users to existing roles.\nRoles can be created by using the create or update roles API or roles files.\n\n**Role templates**\n\nThe most common use for role mappings is to create a mapping from a known value on the user to a fixed role name.\nFor example, all users in the `cn=admin,dc=example,dc=com` LDAP group should be given the superuser role in Elasticsearch.\nThe `roles` field is used for this purpose.\n\nFor more complex needs, it is possible to use Mustache templates to dynamically determine the names of the roles that should be granted to the user.\nThe `role_templates` field is used for this purpose.\n\nNOTE: To use role templates successfully, the relevant scripting feature must be enabled.\nOtherwise, all attempts to create a role mapping with role templates fail.\n\nAll of the user fields that are available in the role mapping rules are also available in the role templates.\nThus it is possible to assign a user to a role that reflects their username, their groups, or the name of the realm to which they authenticated.\n\nBy default a template is evaluated to produce a single string that is the name of the role which should be assigned to the user.\nIf the format of the template is set to \"json\" then the template is expected to produce a JSON string or an array of JSON strings for the role names." }

package/lib/cjs/es/json/security.put_user.request.json

@@ -1 +1 @@
-{ "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "security.put_user", "type": "object", "properties": { "username": { "type": "string", "description": "An identifier for the user.\n\nNOTE: Usernames must be at least 1 and no more than 507 characters.\nThey can contain alphanumeric characters (a-z, A-Z, 0-9), spaces, punctuation, and printable symbols in the Basic Latin (ASCII) block.\nLeading or trailing whitespace is not allowed.", "x-found-in": "path" }, "email": { "oneOf": [{ "type": "string" }, { "type": "null" }], "description": "The email of the user.", "x-found-in": "body" }, "full_name": { "oneOf": [{ "type": "string" }, { "type": "null" }], "description": "The full name of the user.", "x-found-in": "body" }, "metadata": { "$ref": "./_types.json#/$defs/_types__Metadata", "description": "Arbitrary metadata that you want to associate with the user.", "x-found-in": "body" }, "password": { "type": "string", "description": "The user's password.\nPasswords must be at least 6 characters long.\nWhen adding a user, one of `password` or `password_hash` is required.\nWhen updating an existing user, the password is optional, so that other fields on the user (such as their roles) may be updated without modifying the user's password", "x-found-in": "body" }, "password_hash": { "type": "string", "description": "A hash of the user's password.\nThis must be produced using the same hashing algorithm as has been configured for password storage.\nFor more details, see the explanation of the `xpack.security.authc.password_hashing.algorithm` setting in the user cache and password hash algorithm documentation.\nUsing this parameter allows the client to pre-hash the password for performance and/or confidentiality reasons.\nThe `password` parameter and the `password_hash` parameter cannot be used in the same request.", "x-found-in": "body" }, "roles": { "type": "array", "items": { "type": "string" }, "description": "A set of roles the user has.\nThe roles determine the user's access permissions.\nTo create a user without any roles, specify an empty list (`[]`).", "x-found-in": "body" }, "enabled": { "type": "boolean", "description": "Specifies whether the user is enabled.", "x-found-in": "body" }, "refresh": { "$ref": "./_types.json#/$defs/_types__Refresh", "description": "Valid values are `true`, `false`, and `wait_for`.\nThese values have the same meaning as in the index API, but the default value for this API is true.", "x-found-in": "query" } }, "required": ["username"], "description": "Create or update users.\n\nAdd and update users in the native realm.\nA password is required for adding a new user but is optional when updating an existing user.\nTo change a user's password without updating any other fields, use the change password API." }
+{ "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "security.put_user", "type": "object", "properties": { "refresh": { "$ref": "./_types.json#/$defs/_types__Refresh", "description": "Valid values are `true`, `false`, and `wait_for`.\nThese values have the same meaning as in the index API, but the default value for this API is true.", "x-found-in": "query" }, "username": { "type": "string", "description": "An identifier for the user.\n\nNOTE: Usernames must be at least 1 and no more than 507 characters.\nThey can contain alphanumeric characters (a-z, A-Z, 0-9), spaces, punctuation, and printable symbols in the Basic Latin (ASCII) block.\nLeading or trailing whitespace is not allowed.", "x-found-in": "path" }, "email": { "anyOf": [{ "type": "string" }, { "type": "null" }], "description": "The email of the user.", "x-found-in": "body" }, "full_name": { "anyOf": [{ "type": "string" }, { "type": "null" }], "description": "The full name of the user.", "x-found-in": "body" }, "metadata": { "$ref": "./_types.json#/$defs/_types__Metadata", "description": "Arbitrary metadata that you want to associate with the user.", "x-found-in": "body" }, "password": { "type": "string", "description": "The user's password.\nPasswords must be at least 6 characters long.\nWhen adding a user, one of `password` or `password_hash` is required.\nWhen updating an existing user, the password is optional, so that other fields on the user (such as their roles) may be updated without modifying the user's password", "x-found-in": "body" }, "password_hash": { "type": "string", "description": "A hash of the user's password.\nThis must be produced using the same hashing algorithm as has been configured for password storage.\nFor more details, see the explanation of the `xpack.security.authc.password_hashing.algorithm` setting in the user cache and password hash algorithm documentation.\nUsing this parameter allows the client to pre-hash the password for performance and/or confidentiality reasons.\nThe `password` parameter and the `password_hash` parameter cannot be used in the same request.", "x-found-in": "body" }, "roles": { "type": "array", "items": { "type": "string" }, "description": "A set of roles the user has.\nThe roles determine the user's access permissions.\nTo create a user without any roles, specify an empty list (`[]`).", "x-found-in": "body" }, "enabled": { "type": "boolean", "description": "Specifies whether the user is enabled.", "x-found-in": "body" } }, "required": ["username"], "description": "Create or update users.\n\nAdd and update users in the native realm.\nA password is required for adding a new user but is optional when updating an existing user.\nTo change a user's password without updating any other fields, use the change password API." }

package/lib/cjs/es/json/security.query_api_keys.request.json

@@ -1 +1 @@
-{ "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "security.query_api_keys", "type": "object", "properties": { "aggregations": { "type": "object", "additionalProperties": { "$ref": "./security.query_api_keys.json#/$defs/security.query_api_keys__ApiKeyAggregationContainer" }, "description": "Any aggregations to run over the corpus of returned API keys.\nAggregations and queries work together. Aggregations are computed only on the API keys that match the query.\nThis supports only a subset of aggregation types, namely: `terms`, `range`, `date_range`, `missing`,\n`cardinality`, `value_count`, `composite`, `filter`, and `filters`.\nAdditionally, aggregations only run over the same subset of fields that query works with.", "x-found-in": "body" }, "query": { "$ref": "./security.query_api_keys.json#/$defs/security.query_api_keys__ApiKeyQueryContainer", "description": "A query to filter which API keys to return.\nIf the query parameter is missing, it is equivalent to a `match_all` query.\nThe query supports a subset of query types, including `match_all`, `bool`, `term`, `terms`, `match`,\n`ids`, `prefix`, `wildcard`, `exists`, `range`, and `simple_query_string`.\nYou can query the following public information associated with an API key: `id`, `type`, `name`,\n`creation`, `expiration`, `invalidated`, `invalidation`, `username`, `realm`, and `metadata`.\n\nNOTE: The queryable string values associated with API keys are internally mapped as keywords.\nConsequently, if no `analyzer` parameter is specified for a `match` query, then the provided match query string is interpreted as a single keyword value.\nSuch a match query is hence equivalent to a `term` query.", "x-found-in": "body" }, "from": { "type": "number", "description": "The starting document offset.\nIt must not be negative.\nBy default, you cannot page through more than 10,000 hits using the `from` and `size` parameters.\nTo page through more hits, use the `search_after` parameter.", "x-found-in": "body" }, "sort": { "$ref": "./_types.json#/$defs/_types__Sort", "description": "The sort definition.\nOther than `id`, all public fields of an API key are eligible for sorting.\nIn addition, sort can also be applied to the `_doc` field to sort by index order.", "x-found-in": "body" }, "size": { "type": "number", "description": "The number of hits to return.\nIt must not be negative.\nThe `size` parameter can be set to `0`, in which case no API key matches are returned, only the aggregation results.\nBy default, you cannot page through more than 10,000 hits using the `from` and `size` parameters.\nTo page through more hits, use the `search_after` parameter.", "x-found-in": "body" }, "search_after": { "$ref": "./_types.json#/$defs/_types__SortResults", "description": "The search after definition.", "x-found-in": "body" }, "with_limited_by": { "type": "boolean", "description": "Return the snapshot of the owner user's role descriptors associated with the API key.\nAn API key's actual permission is the intersection of its assigned role descriptors and the owner user's role descriptors (effectively limited by it).\nAn API key cannot retrieve any API key’s limited-by role descriptors (including itself) unless it has `manage_api_key` or higher privileges.", "x-found-in": "query" }, "with_profile_uid": { "type": "boolean", "description": "Determines whether to also retrieve the profile UID for the API key owner principal.\nIf it exists, the profile UID is returned under the `profile_uid` response field for each API key.", "x-found-in": "query" }, "typed_keys": { "type": "boolean", "description": "Determines whether aggregation names are prefixed by their respective types in the response.", "x-found-in": "query" } }, "description": "Find API keys with a query.\n\nGet a paginated list of API keys and their information.\nYou can optionally filter the results with a query.\n\nTo use this API, you must have at least the `manage_own_api_key` or the `read_security` cluster privileges.\nIf you have only the `manage_own_api_key` privilege, this API returns only the API keys that you own.\nIf you have the `read_security`, `manage_api_key`, or greater privileges (including `manage_security`), this API returns all API keys regardless of ownership.\nRefer to the linked documentation for examples of how to find API keys:" }
+{ "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "security.query_api_keys", "type": "object", "properties": { "with_limited_by": { "type": "boolean", "description": "Return the snapshot of the owner user's role descriptors associated with the API key.\nAn API key's actual permission is the intersection of its assigned role descriptors and the owner user's role descriptors (effectively limited by it).\nAn API key cannot retrieve any API key’s limited-by role descriptors (including itself) unless it has `manage_api_key` or higher privileges.", "x-found-in": "query" }, "with_profile_uid": { "type": "boolean", "description": "Determines whether to also retrieve the profile UID for the API key owner principal.\nIf it exists, the profile UID is returned under the `profile_uid` response field for each API key.", "x-found-in": "query" }, "typed_keys": { "type": "boolean", "description": "Determines whether aggregation names are prefixed by their respective types in the response.", "x-found-in": "query" }, "aggregations": { "type": "object", "additionalProperties": { "$ref": "./security.query_api_keys.json#/$defs/security.query_api_keys__ApiKeyAggregationContainer" }, "description": "Any aggregations to run over the corpus of returned API keys.\nAggregations and queries work together. Aggregations are computed only on the API keys that match the query.\nThis supports only a subset of aggregation types, namely: `terms`, `range`, `date_range`, `missing`,\n`cardinality`, `value_count`, `composite`, `filter`, and `filters`.\nAdditionally, aggregations only run over the same subset of fields that query works with.", "x-found-in": "body" }, "query": { "$ref": "./security.query_api_keys.json#/$defs/security.query_api_keys__ApiKeyQueryContainer", "description": "A query to filter which API keys to return.\nIf the query parameter is missing, it is equivalent to a `match_all` query.\nThe query supports a subset of query types, including `match_all`, `bool`, `term`, `terms`, `match`,\n`ids`, `prefix`, `wildcard`, `exists`, `range`, and `simple_query_string`.\nYou can query the following public information associated with an API key: `id`, `type`, `name`,\n`creation`, `expiration`, `invalidated`, `invalidation`, `username`, `realm`, and `metadata`.\n\nNOTE: The queryable string values associated with API keys are internally mapped as keywords.\nConsequently, if no `analyzer` parameter is specified for a `match` query, then the provided match query string is interpreted as a single keyword value.\nSuch a match query is hence equivalent to a `term` query.", "x-found-in": "body" }, "from": { "type": "number", "description": "The starting document offset.\nIt must not be negative.\nBy default, you cannot page through more than 10,000 hits using the `from` and `size` parameters.\nTo page through more hits, use the `search_after` parameter.", "x-found-in": "body" }, "sort": { "$ref": "./_types.json#/$defs/_types__Sort", "description": "The sort definition.\nOther than `id`, all public fields of an API key are eligible for sorting.\nIn addition, sort can also be applied to the `_doc` field to sort by index order.", "x-found-in": "body" }, "size": { "type": "number", "description": "The number of hits to return.\nIt must not be negative.\nThe `size` parameter can be set to `0`, in which case no API key matches are returned, only the aggregation results.\nBy default, you cannot page through more than 10,000 hits using the `from` and `size` parameters.\nTo page through more hits, use the `search_after` parameter.", "x-found-in": "body" }, "search_after": { "$ref": "./_types.json#/$defs/_types__SortResults", "description": "The search after definition.", "x-found-in": "body" } }, "description": "Find API keys with a query.\n\nGet a paginated list of API keys and their information.\nYou can optionally filter the results with a query.\n\nTo use this API, you must have at least the `manage_own_api_key` or the `read_security` cluster privileges.\nIf you have only the `manage_own_api_key` privilege, this API returns only the API keys that you own.\nIf you have the `read_security`, `manage_api_key`, or greater privileges (including `manage_security`), this API returns all API keys regardless of ownership.\nRefer to the linked documentation for examples of how to find API keys:" }

package/lib/cjs/es/json/security.query_user.request.json

@@ -1 +1 @@
-{ "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "security.query_user", "type": "object", "properties": { "query": { "$ref": "./security.query_user.json#/$defs/security.query_user__UserQueryContainer", "description": "A query to filter which users to return.\nIf the query parameter is missing, it is equivalent to a `match_all` query.\nThe query supports a subset of query types, including `match_all`, `bool`, `term`, `terms`, `match`,\n`ids`, `prefix`, `wildcard`, `exists`, `range`, and `simple_query_string`.\nYou can query the following information associated with user: `username`, `roles`, `enabled`, `full_name`, and `email`.", "x-found-in": "body" }, "from": { "type": "number", "description": "The starting document offset.\nIt must not be negative.\nBy default, you cannot page through more than 10,000 hits using the `from` and `size` parameters.\nTo page through more hits, use the `search_after` parameter.", "x-found-in": "body" }, "sort": { "$ref": "./_types.json#/$defs/_types__Sort", "description": "The sort definition.\nFields eligible for sorting are: `username`, `roles`, `enabled`.\nIn addition, sort can also be applied to the `_doc` field to sort by index order.", "x-found-in": "body" }, "size": { "type": "number", "description": "The number of hits to return.\nIt must not be negative.\nBy default, you cannot page through more than 10,000 hits using the `from` and `size` parameters.\nTo page through more hits, use the `search_after` parameter.", "x-found-in": "body" }, "search_after": { "$ref": "./_types.json#/$defs/_types__SortResults", "description": "The search after definition", "x-found-in": "body" }, "with_profile_uid": { "type": "boolean", "description": "Determines whether to retrieve the user profile UID, if it exists, for the users.", "x-found-in": "query" } }, "description": "Find users with a query.\n\nGet information for users in a paginated manner.\nYou can optionally filter the results with a query.\n\nNOTE: As opposed to the get user API, built-in users are excluded from the result.\nThis API is only for native users." }
+{ "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "security.query_user", "type": "object", "properties": { "with_profile_uid": { "type": "boolean", "description": "Determines whether to retrieve the user profile UID, if it exists, for the users.", "x-found-in": "query" }, "query": { "$ref": "./security.query_user.json#/$defs/security.query_user__UserQueryContainer", "description": "A query to filter which users to return.\nIf the query parameter is missing, it is equivalent to a `match_all` query.\nThe query supports a subset of query types, including `match_all`, `bool`, `term`, `terms`, `match`,\n`ids`, `prefix`, `wildcard`, `exists`, `range`, and `simple_query_string`.\nYou can query the following information associated with user: `username`, `roles`, `enabled`, `full_name`, and `email`.", "x-found-in": "body" }, "from": { "type": "number", "description": "The starting document offset.\nIt must not be negative.\nBy default, you cannot page through more than 10,000 hits using the `from` and `size` parameters.\nTo page through more hits, use the `search_after` parameter.", "x-found-in": "body" }, "sort": { "$ref": "./_types.json#/$defs/_types__Sort", "description": "The sort definition.\nFields eligible for sorting are: `username`, `roles`, `enabled`.\nIn addition, sort can also be applied to the `_doc` field to sort by index order.", "x-found-in": "body" }, "size": { "type": "number", "description": "The number of hits to return.\nIt must not be negative.\nBy default, you cannot page through more than 10,000 hits using the `from` and `size` parameters.\nTo page through more hits, use the `search_after` parameter.", "x-found-in": "body" }, "search_after": { "$ref": "./_types.json#/$defs/_types__SortResults", "description": "The search after definition", "x-found-in": "body" } }, "description": "Find users with a query.\n\nGet information for users in a paginated manner.\nYou can optionally filter the results with a query.\n\nNOTE: As opposed to the get user API, built-in users are excluded from the result.\nThis API is only for native users." }

package/lib/cjs/es/json/security.suggest_user_profiles.request.json

@@ -1 +1 @@
-{ "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "security.suggest_user_profiles", "type": "object", "properties": { "name": { "type": "string", "description": "A query string used to match name-related fields in user profile documents.\nName-related fields are the user's `username`, `full_name`, and `email`.", "x-found-in": "body" }, "size": { "type": "number", "description": "The number of profiles to return.", "x-found-in": "body" }, "data": { "oneOf": [{ "type": "string" }, { "type": "array", "items": { "type": "string" } }], "description": "A comma-separated list of filters for the `data` field of the profile document.\nTo return all content use `data=*`.\nTo return a subset of content, use `data=<key>` to retrieve content nested under the specified `<key>`.\nBy default, the API returns no `data` content.\nIt is an error to specify `data` as both the query parameter and the request body field.", "x-found-in": "query" }, "hint": { "$ref": "./security.suggest_user_profiles.json#/$defs/security.suggest_user_profiles__Hint", "description": "Extra search criteria to improve relevance of the suggestion result.\nProfiles matching the spcified hint are ranked higher in the response.\nProfiles not matching the hint aren't excluded from the response as long as the profile matches the `name` field query.", "x-found-in": "body" } }, "description": "Suggest a user profile.\n\nGet suggestions for user profiles that match specified search criteria.\n\nNOTE: The user profile feature is designed only for use by Kibana and Elastic's Observability, Enterprise Search, and Elastic Security solutions.\nIndividual users and external applications should not call this API directly.\nElastic reserves the right to change or remove this feature in future releases without prior notice." }
+{ "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "security.suggest_user_profiles", "type": "object", "properties": { "data": { "anyOf": [{ "type": "string" }, { "type": "array", "items": { "type": "string" } }], "description": "A comma-separated list of filters for the `data` field of the profile document.\nTo return all content use `data=*`.\nTo return a subset of content, use `data=<key>` to retrieve content nested under the specified `<key>`.\nBy default, the API returns no `data` content.\nIt is an error to specify `data` as both the query parameter and the request body field.", "x-found-in": "body" }, "name": { "type": "string", "description": "A query string used to match name-related fields in user profile documents.\nName-related fields are the user's `username`, `full_name`, and `email`.", "x-found-in": "body" }, "size": { "type": "number", "description": "The number of profiles to return.", "x-found-in": "body" }, "hint": { "$ref": "./security.suggest_user_profiles.json#/$defs/security.suggest_user_profiles__Hint", "description": "Extra search criteria to improve relevance of the suggestion result.\nProfiles matching the spcified hint are ranked higher in the response.\nProfiles not matching the hint aren't excluded from the response as long as the profile matches the `name` field query.", "x-found-in": "body" } }, "description": "Suggest a user profile.\n\nGet suggestions for user profiles that match specified search criteria.\n\nNOTE: The user profile feature is designed only for use by Kibana and Elastic's Observability, Enterprise Search, and Elastic Security solutions.\nIndividual users and external applications should not call this API directly.\nElastic reserves the right to change or remove this feature in future releases without prior notice." }

package/lib/cjs/es/json/security.update_settings.request.json

@@ -1 +1 @@
-{ "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "security.update_settings", "type": "object", "properties": { "security": { "$ref": "./security._types.json#/$defs/security._types__SecuritySettings", "description": "Settings for the index used for most security configuration, including native realm users and roles configured with the API.", "x-found-in": "body" }, "security-profile": { "$ref": "./security._types.json#/$defs/security._types__SecuritySettings", "description": "Settings for the index used to store profile information.", "x-found-in": "body" }, "security-tokens": { "$ref": "./security._types.json#/$defs/security._types__SecuritySettings", "description": "Settings for the index used to store tokens.", "x-found-in": "body" }, "master_timeout": { "$ref": "./_types.json#/$defs/_types__Duration", "description": "The period to wait for a connection to the master node.\nIf no response is received before the timeout expires, the request fails and returns an error.", "x-found-in": "query" }, "timeout": { "$ref": "./_types.json#/$defs/_types__Duration", "description": "The period to wait for a response.\nIf no response is received before the timeout expires, the request fails and returns an error.", "x-found-in": "query" } }, "description": "Update security index settings.\n\nUpdate the user-configurable settings for the security internal index (`.security` and associated indices). Only a subset of settings are allowed to be modified. This includes `index.auto_expand_replicas` and `index.number_of_replicas`.\n\nNOTE: If `index.auto_expand_replicas` is set, `index.number_of_replicas` will be ignored during updates.\n\nIf a specific index is not in use on the system and settings are provided for it, the request will be rejected.\nThis API does not yet support configuring the settings for indices before they are in use." }
+{ "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "security.update_settings", "type": "object", "properties": { "master_timeout": { "$ref": "./_types.json#/$defs/_types__Duration", "description": "The period to wait for a connection to the master node.\nIf no response is received before the timeout expires, the request fails and returns an error.", "x-found-in": "query" }, "timeout": { "$ref": "./_types.json#/$defs/_types__Duration", "description": "The period to wait for a response.\nIf no response is received before the timeout expires, the request fails and returns an error.", "x-found-in": "query" }, "security": { "$ref": "./security._types.json#/$defs/security._types__SecuritySettings", "description": "Settings for the index used for most security configuration, including native realm users and roles configured with the API.", "x-found-in": "body" }, "security-profile": { "$ref": "./security._types.json#/$defs/security._types__SecuritySettings", "description": "Settings for the index used to store profile information.", "x-found-in": "body" }, "security-tokens": { "$ref": "./security._types.json#/$defs/security._types__SecuritySettings", "description": "Settings for the index used to store tokens.", "x-found-in": "body" } }, "description": "Update security index settings.\n\nUpdate the user-configurable settings for the security internal index (`.security` and associated indices). Only a subset of settings are allowed to be modified. This includes `index.auto_expand_replicas` and `index.number_of_replicas`.\n\nNOTE: If `index.auto_expand_replicas` is set, `index.number_of_replicas` will be ignored during updates.\n\nIf a specific index is not in use on the system and settings are provided for it, the request will be rejected.\nThis API does not yet support configuring the settings for indices before they are in use." }

package/lib/cjs/es/json/security.update_user_profile_data.request.json

@@ -1 +1 @@
-{ "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "security.update_user_profile_data", "type": "object", "properties": { "labels": { "type": "object", "additionalProperties": {}, "description": "Searchable data that you want to associate with the user profile.\nThis field supports a nested data structure.\nWithin the labels object, top-level keys cannot begin with an underscore (`_`) or contain a period (`.`).", "x-found-in": "body" }, "data": { "type": "object", "additionalProperties": {}, "description": "Non-searchable data that you want to associate with the user profile.\nThis field supports a nested data structure.\nWithin the `data` object, top-level keys cannot begin with an underscore (`_`) or contain a period (`.`).\nThe data object is not searchable, but can be retrieved with the get user profile API.", "x-found-in": "body" }, "if_seq_no": { "type": "number", "description": "Only perform the operation if the document has this sequence number.", "x-found-in": "query" }, "if_primary_term": { "type": "number", "description": "Only perform the operation if the document has this primary term.", "x-found-in": "query" }, "refresh": { "$ref": "./_types.json#/$defs/_types__Refresh", "description": "If 'true', Elasticsearch refreshes the affected shards to make this operation\nvisible to search.\nIf 'wait_for', it waits for a refresh to make this operation visible to search.\nIf 'false', nothing is done with refreshes.", "x-found-in": "query" }, "uid": { "type": "string", "description": "A unique identifier for the user profile.", "x-found-in": "path" } }, "required": ["uid"], "description": "Update user profile data.\n\nUpdate specific data for the user profile that is associated with a unique ID.\n\nNOTE: The user profile feature is designed only for use by Kibana and Elastic's Observability, Enterprise Search, and Elastic Security solutions.\nIndividual users and external applications should not call this API directly.\nElastic reserves the right to change or remove this feature in future releases without prior notice.\n\nTo use this API, you must have one of the following privileges:\n\n* The `manage_user_profile` cluster privilege.\n* The `update_profile_data` global privilege for the namespaces that are referenced in the request.\n\nThis API updates the `labels` and `data` fields of an existing user profile document with JSON objects.\nNew keys and their values are added to the profile document and conflicting keys are replaced by data that's included in the request.\n\nFor both labels and data, content is namespaced by the top-level fields.\nThe `update_profile_data` global privilege grants privileges for updating only the allowed namespaces." }
+{ "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "security.update_user_profile_data", "type": "object", "properties": { "if_seq_no": { "type": "number", "description": "Only perform the operation if the document has this sequence number.", "x-found-in": "query" }, "if_primary_term": { "type": "number", "description": "Only perform the operation if the document has this primary term.", "x-found-in": "query" }, "refresh": { "$ref": "./_types.json#/$defs/_types__Refresh", "description": "If 'true', Elasticsearch refreshes the affected shards to make this operation\nvisible to search.\nIf 'wait_for', it waits for a refresh to make this operation visible to search.\nIf 'false', nothing is done with refreshes.", "x-found-in": "query" }, "labels": { "type": "object", "additionalProperties": {}, "description": "Searchable data that you want to associate with the user profile.\nThis field supports a nested data structure.\nWithin the labels object, top-level keys cannot begin with an underscore (`_`) or contain a period (`.`).", "x-found-in": "body" }, "data": { "type": "object", "additionalProperties": {}, "description": "Non-searchable data that you want to associate with the user profile.\nThis field supports a nested data structure.\nWithin the `data` object, top-level keys cannot begin with an underscore (`_`) or contain a period (`.`).\nThe data object is not searchable, but can be retrieved with the get user profile API.", "x-found-in": "body" }, "uid": { "type": "string", "description": "A unique identifier for the user profile.", "x-found-in": "path" } }, "required": ["uid"], "description": "Update user profile data.\n\nUpdate specific data for the user profile that is associated with a unique ID.\n\nNOTE: The user profile feature is designed only for use by Kibana and Elastic's Observability, Enterprise Search, and Elastic Security solutions.\nIndividual users and external applications should not call this API directly.\nElastic reserves the right to change or remove this feature in future releases without prior notice.\n\nTo use this API, you must have one of the following privileges:\n\n* The `manage_user_profile` cluster privilege.\n* The `update_profile_data` global privilege for the namespaces that are referenced in the request.\n\nThis API updates the `labels` and `data` fields of an existing user profile document with JSON objects.\nNew keys and their values are added to the profile document and conflicting keys are replaced by data that's included in the request.\n\nFor both labels and data, content is namespaced by the top-level fields.\nThe `update_profile_data` global privilege grants privileges for updating only the allowed namespaces." }

package/lib/cjs/es/json/simulate.ingest.request.json

@@ -1 +1 @@
-{ "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "simulate.ingest", "type": "object", "properties": { "docs": { "type": "array", "items": { "$ref": "./ingest._types.json#/$defs/ingest._types__Document" }, "description": "Sample documents to test in the pipeline.", "x-found-in": "body" }, "component_template_substitutions": { "type": "object", "additionalProperties": { "$ref": "./cluster._types.json#/$defs/cluster._types__ComponentTemplateNode" }, "description": "A map of component template names to substitute component template definition objects.", "x-found-in": "body" }, "index_template_substitutions": { "type": "object", "additionalProperties": { "$ref": "./indices._types.json#/$defs/indices._types__IndexTemplate" }, "description": "A map of index template names to substitute index template definition objects.", "x-found-in": "body" }, "mapping_addition": { "$ref": "./_types.mapping.json#/$defs/_types.mapping__TypeMapping", "x-found-in": "body" }, "pipeline_substitutions": { "type": "object", "additionalProperties": { "$ref": "./ingest._types.json#/$defs/ingest._types__Pipeline" }, "description": "Pipelines to test.\nIf you don’t specify the `pipeline` request path parameter, this parameter is required.\nIf you specify both this and the request path parameter, the API only uses the request path parameter.", "x-found-in": "body" }, "pipeline": { "type": "string", "description": "The pipeline to use as the default pipeline.\nThis value can be used to override the default pipeline of the index.", "x-found-in": "query" }, "merge_type": { "$ref": "./simulate.ingest.json#/$defs/simulate.ingest__MergeType", "description": "The mapping merge type if mapping overrides are being provided in mapping_addition.\nThe allowed values are one of index or template.\nThe index option merges mappings the way they would be merged into an existing index.\nThe template option merges mappings the way they would be merged into a template.", "x-found-in": "query" }, "index": { "type": "string", "description": "The index to simulate ingesting into.\nThis value can be overridden by specifying an index on each document.\nIf you specify this parameter in the request path, it is used for any documents that do not explicitly specify an index argument.", "x-found-in": "path" } }, "required": ["docs"], "description": "Simulate data ingestion.\n\nRun ingest pipelines against a set of provided documents, optionally with substitute pipeline definitions, to simulate ingesting data into an index.\n\nThis API is meant to be used for troubleshooting or pipeline development, as it does not actually index any data into Elasticsearch.\n\nThe API runs the default and final pipeline for that index against a set of documents provided in the body of the request.\nIf a pipeline contains a reroute processor, it follows that reroute processor to the new index, running that index's pipelines as well the same way that a non-simulated ingest would.\nNo data is indexed into Elasticsearch.\nInstead, the transformed document is returned, along with the list of pipelines that have been run and the name of the index where the document would have been indexed if this were not a simulation.\nThe transformed document is validated against the mappings that would apply to this index, and any validation error is reported in the result.\n\nThis API differs from the simulate pipeline API in that you specify a single pipeline for that API, and it runs only that one pipeline.\nThe simulate pipeline API is more useful for developing a single pipeline, while the simulate ingest API is more useful for troubleshooting the interaction of the various pipelines that get applied when ingesting into an index.\n\nBy default, the pipeline definitions that are currently in the system are used.\nHowever, you can supply substitute pipeline definitions in the body of the request.\nThese will be used in place of the pipeline definitions that are already in the system. This can be used to replace existing pipeline definitions or to create new ones. The pipeline substitutions are used only within this request." }
+{ "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "simulate.ingest", "type": "object", "properties": { "pipeline": { "type": "string", "description": "The pipeline to use as the default pipeline.\nThis value can be used to override the default pipeline of the index.", "x-found-in": "query" }, "merge_type": { "$ref": "./simulate.ingest.json#/$defs/simulate.ingest__MergeType", "description": "The mapping merge type if mapping overrides are being provided in mapping_addition.\nThe allowed values are one of index or template.\nThe index option merges mappings the way they would be merged into an existing index.\nThe template option merges mappings the way they would be merged into a template.", "x-found-in": "query" }, "docs": { "type": "array", "items": { "$ref": "./ingest._types.json#/$defs/ingest._types__Document" }, "description": "Sample documents to test in the pipeline.", "x-found-in": "body" }, "component_template_substitutions": { "type": "object", "additionalProperties": { "$ref": "./cluster._types.json#/$defs/cluster._types__ComponentTemplateNode" }, "description": "A map of component template names to substitute component template definition objects.", "x-found-in": "body" }, "index_template_substitutions": { "type": "object", "additionalProperties": { "$ref": "./indices._types.json#/$defs/indices._types__IndexTemplate" }, "description": "A map of index template names to substitute index template definition objects.", "x-found-in": "body" }, "mapping_addition": { "$ref": "./_types.mapping.json#/$defs/_types.mapping__TypeMapping", "x-found-in": "body" }, "pipeline_substitutions": { "type": "object", "additionalProperties": { "$ref": "./ingest._types.json#/$defs/ingest._types__Pipeline" }, "description": "Pipelines to test.\nIf you don’t specify the `pipeline` request path parameter, this parameter is required.\nIf you specify both this and the request path parameter, the API only uses the request path parameter.", "x-found-in": "body" }, "index": { "type": "string", "description": "The index to simulate ingesting into.\nThis value can be overridden by specifying an index on each document.\nIf you specify this parameter in the request path, it is used for any documents that do not explicitly specify an index argument.", "x-found-in": "path" } }, "required": ["docs"], "description": "Simulate data ingestion.\n\nRun ingest pipelines against a set of provided documents, optionally with substitute pipeline definitions, to simulate ingesting data into an index.\n\nThis API is meant to be used for troubleshooting or pipeline development, as it does not actually index any data into Elasticsearch.\n\nThe API runs the default and final pipeline for that index against a set of documents provided in the body of the request.\nIf a pipeline contains a reroute processor, it follows that reroute processor to the new index, running that index's pipelines as well the same way that a non-simulated ingest would.\nNo data is indexed into Elasticsearch.\nInstead, the transformed document is returned, along with the list of pipelines that have been run and the name of the index where the document would have been indexed if this were not a simulation.\nThe transformed document is validated against the mappings that would apply to this index, and any validation error is reported in the result.\n\nThis API differs from the simulate pipeline API in that you specify a single pipeline for that API, and it runs only that one pipeline.\nThe simulate pipeline API is more useful for developing a single pipeline, while the simulate ingest API is more useful for troubleshooting the interaction of the various pipelines that get applied when ingesting into an index.\n\nBy default, the pipeline definitions that are currently in the system are used.\nHowever, you can supply substitute pipeline definitions in the body of the request.\nThese will be used in place of the pipeline definitions that are already in the system. This can be used to replace existing pipeline definitions or to create new ones. The pipeline substitutions are used only within this request." }

package/lib/cjs/es/json/slm.put_lifecycle.request.json

@@ -1 +1 @@
-{ "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "slm.put_lifecycle", "type": "object", "properties": { "config": { "$ref": "./slm._types.json#/$defs/slm._types__Configuration", "description": "Configuration for each snapshot created by the policy.", "x-found-in": "body" }, "name": { "type": "string", "description": "Name automatically assigned to each snapshot created by the policy. Date math is supported. To prevent conflicting snapshot names, a UUID is automatically appended to each snapshot name.", "x-found-in": "body" }, "repository": { "type": "string", "description": "Repository used to store snapshots created by this policy. This repository must exist prior to the policy’s creation. You can create a repository using the snapshot repository API.", "x-found-in": "body" }, "retention": { "$ref": "./slm._types.json#/$defs/slm._types__Retention", "description": "Retention rules used to retain and delete snapshots created by the policy.", "x-found-in": "body" }, "schedule": { "type": "string", "description": "Periodic or absolute schedule at which the policy creates snapshots. SLM applies schedule changes immediately.", "x-found-in": "body" }, "master_timeout": { "$ref": "./_types.json#/$defs/_types__Duration", "description": "The period to wait for a connection to the master node.\nIf no response is received before the timeout expires, the request fails and returns an error.\nTo indicate that the request should never timeout, set it to `-1`.", "x-found-in": "query" }, "timeout": { "$ref": "./_types.json#/$defs/_types__Duration", "description": "The period to wait for a response.\nIf no response is received before the timeout expires, the request fails and returns an error.\nTo indicate that the request should never timeout, set it to `-1`.", "x-found-in": "query" }, "policy_id": { "type": "string", "description": "The identifier for the snapshot lifecycle policy you want to create or update.", "x-found-in": "path" } }, "required": ["policy_id"], "description": "Create or update a policy.\n\nCreate or update a snapshot lifecycle policy.\nIf the policy already exists, this request increments the policy version.\nOnly the latest version of a policy is stored." }
+{ "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "slm.put_lifecycle", "type": "object", "properties": { "master_timeout": { "$ref": "./_types.json#/$defs/_types__Duration", "description": "The period to wait for a connection to the master node.\nIf no response is received before the timeout expires, the request fails and returns an error.\nTo indicate that the request should never timeout, set it to `-1`.", "x-found-in": "query" }, "timeout": { "$ref": "./_types.json#/$defs/_types__Duration", "description": "The period to wait for a response.\nIf no response is received before the timeout expires, the request fails and returns an error.\nTo indicate that the request should never timeout, set it to `-1`.", "x-found-in": "query" }, "config": { "$ref": "./slm._types.json#/$defs/slm._types__Configuration", "description": "Configuration for each snapshot created by the policy.", "x-found-in": "body" }, "name": { "type": "string", "description": "Name automatically assigned to each snapshot created by the policy. Date math is supported. To prevent conflicting snapshot names, a UUID is automatically appended to each snapshot name.", "x-found-in": "body" }, "repository": { "type": "string", "description": "Repository used to store snapshots created by this policy. This repository must exist prior to the policy’s creation. You can create a repository using the snapshot repository API.", "x-found-in": "body" }, "retention": { "$ref": "./slm._types.json#/$defs/slm._types__Retention", "description": "Retention rules used to retain and delete snapshots created by the policy.", "x-found-in": "body" }, "schedule": { "type": "string", "description": "Periodic or absolute schedule at which the policy creates snapshots. SLM applies schedule changes immediately.", "x-found-in": "body" }, "policy_id": { "type": "string", "description": "The identifier for the snapshot lifecycle policy you want to create or update.", "x-found-in": "path" } }, "required": ["policy_id"], "description": "Create or update a policy.\n\nCreate or update a snapshot lifecycle policy.\nIf the policy already exists, this request increments the policy version.\nOnly the latest version of a policy is stored." }

package/lib/cjs/es/json/snapshot.clone.request.json

@@ -1 +1 @@
-{ "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "snapshot.clone", "type": "object", "properties": { "indices": { "type": "string", "description": "A comma-separated list of indices to include in the snapshot.\nMulti-target syntax is supported.", "x-found-in": "body" }, "master_timeout": { "$ref": "./_types.json#/$defs/_types__Duration", "description": "The period to wait for the master node.\nIf the master node is not available before the timeout expires, the request fails and returns an error.\nTo indicate that the request should never timeout, set it to `-1`.", "x-found-in": "query" }, "repository": { "type": "string", "description": "The name of the snapshot repository that both source and target snapshot belong to.", "x-found-in": "path" }, "snapshot": { "type": "string", "description": "The source snapshot name.", "x-found-in": "path" }, "target_snapshot": { "type": "string", "description": "The target snapshot name.", "x-found-in": "path" } }, "required": ["repository", "snapshot", "target_snapshot", "indices"], "description": "Clone a snapshot.\n\nClone part of all of a snapshot into another snapshot in the same repository." }
+{ "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "snapshot.clone", "type": "object", "properties": { "master_timeout": { "$ref": "./_types.json#/$defs/_types__Duration", "description": "The period to wait for the master node.\nIf the master node is not available before the timeout expires, the request fails and returns an error.\nTo indicate that the request should never timeout, set it to `-1`.", "x-found-in": "query" }, "indices": { "type": "string", "description": "A comma-separated list of indices to include in the snapshot.\nMulti-target syntax is supported.", "x-found-in": "body" }, "repository": { "type": "string", "description": "The name of the snapshot repository that both source and target snapshot belong to.", "x-found-in": "path" }, "snapshot": { "type": "string", "description": "The source snapshot name.", "x-found-in": "path" }, "target_snapshot": { "type": "string", "description": "The target snapshot name.", "x-found-in": "path" } }, "required": ["repository", "snapshot", "target_snapshot", "indices"], "description": "Clone a snapshot.\n\nClone part of all of a snapshot into another snapshot in the same repository." }

package/lib/cjs/es/json/snapshot.create.request.json

@@ -1 +1 @@
-{ "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "snapshot.create", "type": "object", "properties": { "expand_wildcards": { "$ref": "./_types.json#/$defs/_types__ExpandWildcards", "description": "Determines how wildcard patterns in the `indices` parameter match data streams and indices.\nIt supports comma-separated values such as `open,hidden`.", "x-found-in": "body" }, "feature_states": { "type": "array", "items": { "type": "string" }, "description": "The feature states to include in the snapshot.\nEach feature state includes one or more system indices containing related data.\nYou can view a list of eligible features using the get features API.\n\nIf `include_global_state` is `true`, all current feature states are included by default.\nIf `include_global_state` is `false`, no feature states are included by default.\n\nNote that specifying an empty array will result in the default behavior.\nTo exclude all feature states, regardless of the `include_global_state` value, specify an array with only the value `none` (`[\"none\"]`).", "x-found-in": "body" }, "ignore_unavailable": { "type": "boolean", "description": "If `true`, the request ignores data streams and indices in `indices` that are missing or closed.\nIf `false`, the request returns an error for any data stream or index that is missing or closed.", "x-found-in": "body" }, "include_global_state": { "type": "boolean", "description": "If `true`, the current cluster state is included in the snapshot.\nThe cluster state includes persistent cluster settings, composable index templates, legacy index templates, ingest pipelines, and ILM policies.\nIt also includes data stored in system indices, such as Watches and task records (configurable via `feature_states`).", "x-found-in": "body" }, "indices": { "$ref": "./_types.json#/$defs/_types__Indices", "description": "A comma-separated list of data streams and indices to include in the snapshot.\nIt supports a multi-target syntax.\nThe default is an empty array (`[]`), which includes all regular data streams and regular indices.\nTo exclude all data streams and indices, use `-*`.\n\nYou can't use this parameter to include or exclude system indices or system data streams from a snapshot.\nUse `feature_states` instead.", "x-found-in": "body" }, "metadata": { "$ref": "./_types.json#/$defs/_types__Metadata", "description": "Arbitrary metadata to the snapshot, such as a record of who took the snapshot, why it was taken, or any other useful data.\nIt can have any contents but it must be less than 1024 bytes.\nThis information is not automatically generated by Elasticsearch.", "x-found-in": "body" }, "partial": { "type": "boolean", "description": "If `true`, allows the snapshot to proceed even if some of the target shards are unavailable.\nIn this case, the resulting snapshot will not contain snapshots of the unavailable target shards, and will report its state as `PARTIAL`.\nAdditionally, if `true`, allows index metadata operations such as deletions while the snapshot is in progress.\nThis is almost always preferable to failing the snapshot completely when a single shard is unavailable, and blocking index metadata operations.\n\nIf `false`, the entire restore operation will fail if one or more indices included in the snapshot do not have all primary shards available, and index metadata operations such as deletions will be forbidden until the snapshot completes.", "x-found-in": "body" }, "master_timeout": { "$ref": "./_types.json#/$defs/_types__Duration", "description": "The period to wait for a connection to the master node.\nIf no response is received before the timeout expires, the request fails and returns an error.", "x-found-in": "query" }, "wait_for_completion": { "type": "boolean", "description": "If `true`, the request returns a response when the snapshot is complete.\nIf `false`, the request returns a response when the snapshot initializes.", "x-found-in": "query" }, "repository": { "type": "string", "description": "The name of the repository for the snapshot.", "x-found-in": "path" }, "snapshot": { "type": "string", "description": "The name of the snapshot.\nIt supportes date math.\nIt must be unique in the repository.", "x-found-in": "path" } }, "required": ["repository", "snapshot"], "description": "Create a snapshot.\n\nTake a snapshot of a cluster or of data streams and indices." }
+{ "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "snapshot.create", "type": "object", "properties": { "master_timeout": { "$ref": "./_types.json#/$defs/_types__Duration", "description": "The period to wait for a connection to the master node.\nIf no response is received before the timeout expires, the request fails and returns an error.", "x-found-in": "query" }, "wait_for_completion": { "type": "boolean", "description": "If `true`, the request returns a response when the snapshot is complete.\nIf `false`, the request returns a response when the snapshot initializes.", "x-found-in": "query" }, "expand_wildcards": { "$ref": "./_types.json#/$defs/_types__ExpandWildcards", "description": "Determines how wildcard patterns in the `indices` parameter match data streams and indices.\nIt supports comma-separated values such as `open,hidden`.", "x-found-in": "body" }, "feature_states": { "type": "array", "items": { "type": "string" }, "description": "The feature states to include in the snapshot.\nEach feature state includes one or more system indices containing related data.\nYou can view a list of eligible features using the get features API.\n\nIf `include_global_state` is `true`, all current feature states are included by default.\nIf `include_global_state` is `false`, no feature states are included by default.\n\nNote that specifying an empty array will result in the default behavior.\nTo exclude all feature states, regardless of the `include_global_state` value, specify an array with only the value `none` (`[\"none\"]`).", "x-found-in": "body" }, "ignore_unavailable": { "type": "boolean", "description": "If `true`, the request ignores data streams and indices in `indices` that are missing or closed.\nIf `false`, the request returns an error for any data stream or index that is missing or closed.", "x-found-in": "body" }, "include_global_state": { "type": "boolean", "description": "If `true`, the current cluster state is included in the snapshot.\nThe cluster state includes persistent cluster settings, composable index templates, legacy index templates, ingest pipelines, and ILM policies.\nIt also includes data stored in system indices, such as Watches and task records (configurable via `feature_states`).", "x-found-in": "body" }, "indices": { "$ref": "./_types.json#/$defs/_types__Indices", "description": "A comma-separated list of data streams and indices to include in the snapshot.\nIt supports a multi-target syntax.\nThe default is an empty array (`[]`), which includes all regular data streams and regular indices.\nTo exclude all data streams and indices, use `-*`.\n\nYou can't use this parameter to include or exclude system indices or system data streams from a snapshot.\nUse `feature_states` instead.", "x-found-in": "body" }, "metadata": { "$ref": "./_types.json#/$defs/_types__Metadata", "description": "Arbitrary metadata to the snapshot, such as a record of who took the snapshot, why it was taken, or any other useful data.\nIt can have any contents but it must be less than 1024 bytes.\nThis information is not automatically generated by Elasticsearch.", "x-found-in": "body" }, "partial": { "type": "boolean", "description": "If `true`, allows the snapshot to proceed even if some of the target shards are unavailable.\nIn this case, the resulting snapshot will not contain snapshots of the unavailable target shards, and will report its state as `PARTIAL`.\nAdditionally, if `true`, allows index metadata operations such as deletions while the snapshot is in progress.\nThis is almost always preferable to failing the snapshot completely when a single shard is unavailable, and blocking index metadata operations.\n\nIf `false`, the entire restore operation will fail if one or more indices included in the snapshot do not have all primary shards available, and index metadata operations such as deletions will be forbidden until the snapshot completes.", "x-found-in": "body" }, "repository": { "type": "string", "description": "The name of the repository for the snapshot.", "x-found-in": "path" }, "snapshot": { "type": "string", "description": "The name of the snapshot.\nIt supportes date math.\nIt must be unique in the repository.", "x-found-in": "path" } }, "required": ["repository", "snapshot"], "description": "Create a snapshot.\n\nTake a snapshot of a cluster or of data streams and indices." }

package/lib/cjs/es/json/snapshot.get.request.json

@@ -1 +1 @@
-{ "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "snapshot.get", "type": "object", "properties": { "after": { "type": "string", "description": "An offset identifier to start pagination from as returned by the next field in the response body.", "x-found-in": "query" }, "from_sort_value": { "type": "string", "description": "The value of the current sort column at which to start retrieval.\nIt can be a string `snapshot-` or a repository name when sorting by snapshot or repository name.\nIt can be a millisecond time value or a number when sorting by `index-` or shard count.", "x-found-in": "query" }, "ignore_unavailable": { "type": "boolean", "description": "If `false`, the request returns an error for any snapshots that are unavailable.", "x-found-in": "query" }, "index_details": { "type": "boolean", "description": "If `true`, the response includes additional information about each index in the snapshot comprising the number of shards in the index, the total size of the index in bytes, and the maximum number of segments per shard in the index.\nThe default is `false`, meaning that this information is omitted.", "x-found-in": "query" }, "index_names": { "type": "boolean", "description": "If `true`, the response includes the name of each index in each snapshot.", "x-found-in": "query" }, "include_repository": { "type": "boolean", "description": "If `true`, the response includes the repository name in each snapshot.", "x-found-in": "query" }, "master_timeout": { "$ref": "./_types.json#/$defs/_types__Duration", "description": "The period to wait for a connection to the master node.\nIf no response is received before the timeout expires, the request fails and returns an error.", "x-found-in": "query" }, "order": { "$ref": "./_types.json#/$defs/_types__SortOrder", "description": "The sort order.\nValid values are `asc` for ascending and `desc` for descending order.\nThe default behavior is ascending order.", "x-found-in": "query" }, "offset": { "type": "number", "description": "Numeric offset to start pagination from based on the snapshots matching this request. Using a non-zero value for this parameter is mutually exclusive with using the after parameter. Defaults to 0.", "x-found-in": "query" }, "size": { "type": "number", "description": "The maximum number of snapshots to return.\nThe default is -1, which means to return all that match the request without limit.", "x-found-in": "query" }, "slm_policy_filter": { "type": "string", "description": "Filter snapshots by a comma-separated list of snapshot lifecycle management (SLM) policy names that snapshots belong to.\n\nYou can use wildcards (`*`) and combinations of wildcards followed by exclude patterns starting with `-`.\nFor example, the pattern `*,-policy-a-\\*` will return all snapshots except for those that were created by an SLM policy with a name starting with `policy-a-`.\nNote that the wildcard pattern `*` matches all snapshots created by an SLM policy but not those snapshots that were not created by an SLM policy.\nTo include snapshots that were not created by an SLM policy, you can use the special pattern `_none` that will match all snapshots without an SLM policy.", "x-found-in": "query" }, "sort": { "$ref": "./snapshot._types.json#/$defs/snapshot._types__SnapshotSort", "description": "The sort order for the result.\nThe default behavior is sorting by snapshot start time stamp.", "x-found-in": "query" }, "state": { "oneOf": [{ "$ref": "./snapshot._types.json#/$defs/snapshot._types__SnapshotState" }, { "type": "array", "items": { "$ref": "./snapshot._types.json#/$defs/snapshot._types__SnapshotState" } }], "description": "Only return snapshots with a state found in the given comma-separated list of snapshot states.\nThe default is all snapshot states.", "x-found-in": "query" }, "verbose": { "type": "boolean", "description": "If `true`, returns additional information about each snapshot such as the version of Elasticsearch which took the snapshot, the start and end times of the snapshot, and the number of shards snapshotted.\n\nNOTE: The parameters `size`, `order`, `after`, `from_sort_value`, `offset`, `slm_policy_filter`, and `sort` are not supported when you set `verbose=false` and the sort order for requests with `verbose=false` is undefined.", "x-found-in": "query" }, "repository": { "type": "string", "description": "A comma-separated list of snapshot repository names used to limit the request.\nWildcard (`*`) expressions are supported.", "x-found-in": "path" }, "snapshot": { "$ref": "./_types.json#/$defs/_types__Names", "description": "A comma-separated list of snapshot names to retrieve\nWildcards (`*`) are supported.\n\n* To get information about all snapshots in a registered repository, use a wildcard (`*`) or `_all`.\n* To get information about any snapshots that are currently running, use `_current`.", "x-found-in": "path" } }, "required": ["repository", "snapshot"], "description": "Get snapshot information.\n\nNOTE: The `after` parameter and `next` field enable you to iterate through snapshots with some consistency guarantees regarding concurrent creation or deletion of snapshots.\nIt is guaranteed that any snapshot that exists at the beginning of the iteration and is not concurrently deleted will be seen during the iteration.\nSnapshots concurrently created may be seen during an iteration." }
+{ "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "snapshot.get", "type": "object", "properties": { "after": { "type": "string", "description": "An offset identifier to start pagination from as returned by the next field in the response body.", "x-found-in": "query" }, "from_sort_value": { "type": "string", "description": "The value of the current sort column at which to start retrieval.\nIt can be a string `snapshot-` or a repository name when sorting by snapshot or repository name.\nIt can be a millisecond time value or a number when sorting by `index-` or shard count.", "x-found-in": "query" }, "ignore_unavailable": { "type": "boolean", "description": "If `false`, the request returns an error for any snapshots that are unavailable.", "x-found-in": "query" }, "index_details": { "type": "boolean", "description": "If `true`, the response includes additional information about each index in the snapshot comprising the number of shards in the index, the total size of the index in bytes, and the maximum number of segments per shard in the index.\nThe default is `false`, meaning that this information is omitted.", "x-found-in": "query" }, "index_names": { "type": "boolean", "description": "If `true`, the response includes the name of each index in each snapshot.", "x-found-in": "query" }, "include_repository": { "type": "boolean", "description": "If `true`, the response includes the repository name in each snapshot.", "x-found-in": "query" }, "master_timeout": { "$ref": "./_types.json#/$defs/_types__Duration", "description": "The period to wait for a connection to the master node.\nIf no response is received before the timeout expires, the request fails and returns an error.", "x-found-in": "query" }, "order": { "$ref": "./_types.json#/$defs/_types__SortOrder", "description": "The sort order.\nValid values are `asc` for ascending and `desc` for descending order.\nThe default behavior is ascending order.", "x-found-in": "query" }, "offset": { "type": "number", "description": "Numeric offset to start pagination from based on the snapshots matching this request. Using a non-zero value for this parameter is mutually exclusive with using the after parameter. Defaults to 0.", "x-found-in": "query" }, "size": { "type": "number", "description": "The maximum number of snapshots to return.\nThe default is -1, which means to return all that match the request without limit.", "x-found-in": "query" }, "slm_policy_filter": { "type": "string", "description": "Filter snapshots by a comma-separated list of snapshot lifecycle management (SLM) policy names that snapshots belong to.\n\nYou can use wildcards (`*`) and combinations of wildcards followed by exclude patterns starting with `-`.\nFor example, the pattern `*,-policy-a-\\*` will return all snapshots except for those that were created by an SLM policy with a name starting with `policy-a-`.\nNote that the wildcard pattern `*` matches all snapshots created by an SLM policy but not those snapshots that were not created by an SLM policy.\nTo include snapshots that were not created by an SLM policy, you can use the special pattern `_none` that will match all snapshots without an SLM policy.", "x-found-in": "query" }, "sort": { "$ref": "./snapshot._types.json#/$defs/snapshot._types__SnapshotSort", "description": "The sort order for the result.\nThe default behavior is sorting by snapshot start time stamp.", "x-found-in": "query" }, "state": { "anyOf": [{ "$ref": "./snapshot._types.json#/$defs/snapshot._types__SnapshotState" }, { "type": "array", "items": { "$ref": "./snapshot._types.json#/$defs/snapshot._types__SnapshotState" } }], "description": "Only return snapshots with a state found in the given comma-separated list of snapshot states.\nThe default is all snapshot states.", "x-found-in": "query" }, "verbose": { "type": "boolean", "description": "If `true`, returns additional information about each snapshot such as the version of Elasticsearch which took the snapshot, the start and end times of the snapshot, and the number of shards snapshotted.\n\nNOTE: The parameters `size`, `order`, `after`, `from_sort_value`, `offset`, `slm_policy_filter`, and `sort` are not supported when you set `verbose=false` and the sort order for requests with `verbose=false` is undefined.", "x-found-in": "query" }, "repository": { "type": "string", "description": "A comma-separated list of snapshot repository names used to limit the request.\nWildcard (`*`) expressions are supported.", "x-found-in": "path" }, "snapshot": { "$ref": "./_types.json#/$defs/_types__Names", "description": "A comma-separated list of snapshot names to retrieve\nWildcards (`*`) are supported.\n\n* To get information about all snapshots in a registered repository, use a wildcard (`*`) or `_all`.\n* To get information about any snapshots that are currently running, use `_current`.", "x-found-in": "path" } }, "required": ["repository", "snapshot"], "description": "Get snapshot information.\n\nNOTE: The `after` parameter and `next` field enable you to iterate through snapshots with some consistency guarantees regarding concurrent creation or deletion of snapshots.\nIt is guaranteed that any snapshot that exists at the beginning of the iteration and is not concurrently deleted will be seen during the iteration.\nSnapshots concurrently created may be seen during an iteration." }

package/lib/cjs/es/json/snapshot.restore.request.json

@@ -1 +1 @@
-{ "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "snapshot.restore", "type": "object", "properties": { "feature_states": { "type": "array", "items": { "type": "string" }, "description": "The feature states to restore.\nIf `include_global_state` is `true`, the request restores all feature states in the snapshot by default.\nIf `include_global_state` is `false`, the request restores no feature states by default.\nNote that specifying an empty array will result in the default behavior.\nTo restore no feature states, regardless of the `include_global_state` value, specify an array containing only the value `none` (`[\"none\"]`).", "x-found-in": "body" }, "ignore_index_settings": { "type": "array", "items": { "type": "string" }, "description": "The index settings to not restore from the snapshot.\nYou can't use this option to ignore `index.number_of_shards`.\n\nFor data streams, this option applies only to restored backing indices.\nNew backing indices are configured using the data stream's matching index template.", "x-found-in": "body" }, "ignore_unavailable": { "type": "boolean", "description": "If `true`, the request ignores any index or data stream in indices that's missing from the snapshot.\nIf `false`, the request returns an error for any missing index or data stream.", "x-found-in": "body" }, "include_aliases": { "type": "boolean", "description": "If `true`, the request restores aliases for any restored data streams and indices.\nIf `false`, the request doesn’t restore aliases.", "x-found-in": "body" }, "include_global_state": { "type": "boolean", "description": "If `true`, restore the cluster state. The cluster state includes:\n\n* Persistent cluster settings\n* Index templates\n* Legacy index templates\n* Ingest pipelines\n* Index lifecycle management (ILM) policies\n* Stored scripts\n* For snapshots taken after 7.12.0, feature states\n\nIf `include_global_state` is `true`, the restore operation merges the legacy index templates in your cluster with the templates contained in the snapshot, replacing any existing ones whose name matches one in the snapshot.\nIt completely removes all persistent settings, non-legacy index templates, ingest pipelines, and ILM lifecycle policies that exist in your cluster and replaces them with the corresponding items from the snapshot.\n\nUse the `feature_states` parameter to configure how feature states are restored.\n\nIf `include_global_state` is `true` and a snapshot was created without a global state then the restore request will fail.", "x-found-in": "body" }, "index_settings": { "$ref": "./indices._types.json#/$defs/indices._types__IndexSettings", "description": "Index settings to add or change in restored indices, including backing indices.\nYou can't use this option to change `index.number_of_shards`.\n\nFor data streams, this option applies only to restored backing indices.\nNew backing indices are configured using the data stream's matching index template.", "x-found-in": "body" }, "indices": { "$ref": "./_types.json#/$defs/_types__Indices", "description": "A comma-separated list of indices and data streams to restore.\nIt supports a multi-target syntax.\nThe default behavior is all regular indices and regular data streams in the snapshot.\n\nYou can't use this parameter to restore system indices or system data streams.\nUse `feature_states` instead.", "x-found-in": "body" }, "partial": { "type": "boolean", "description": "If `false`, the entire restore operation will fail if one or more indices included in the snapshot do not have all primary shards available.\n\nIf true, it allows restoring a partial snapshot of indices with unavailable shards.\nOnly shards that were successfully included in the snapshot will be restored.\nAll missing shards will be recreated as empty.", "x-found-in": "body" }, "rename_pattern": { "type": "string", "description": "A rename pattern to apply to restored data streams and indices.\nData streams and indices matching the rename pattern will be renamed according to `rename_replacement`.\n\nThe rename pattern is applied as defined by the regular expression that supports referencing the original text, according to the `appendReplacement` logic.", "x-found-in": "body" }, "rename_replacement": { "type": "string", "description": "The rename replacement string that is used with the `rename_pattern`.", "x-found-in": "body" }, "master_timeout": { "$ref": "./_types.json#/$defs/_types__Duration", "description": "The period to wait for the master node.\nIf the master node is not available before the timeout expires, the request fails and returns an error.\nTo indicate that the request should never timeout, set it to `-1`.", "x-found-in": "query" }, "wait_for_completion": { "type": "boolean", "description": "If `true`, the request returns a response when the restore operation completes.\nThe operation is complete when it finishes all attempts to recover primary shards for restored indices.\nThis applies even if one or more of the recovery attempts fail.\n\nIf `false`, the request returns a response when the restore operation initializes.", "x-found-in": "query" }, "repository": { "type": "string", "description": "The name of the repository to restore a snapshot from.", "x-found-in": "path" }, "snapshot": { "type": "string", "description": "The name of the snapshot to restore.", "x-found-in": "path" } }, "required": ["repository", "snapshot"], "description": "Restore a snapshot.\n\nRestore a snapshot of a cluster or data streams and indices.\n\nYou can restore a snapshot only to a running cluster with an elected master node.\nThe snapshot repository must be registered and available to the cluster.\nThe snapshot and cluster versions must be compatible.\n\nTo restore a snapshot, the cluster's global metadata must be writable. Ensure there are't any cluster blocks that prevent writes. The restore operation ignores index blocks.\n\nBefore you restore a data stream, ensure the cluster contains a matching index template with data streams enabled. To check, use the index management feature in Kibana or the get index template API:\n\n```\nGET _index_template/*?filter_path=index_templates.name,index_templates.index_template.index_patterns,index_templates.index_template.data_stream\n```\n\nIf no such template exists, you can create one or restore a cluster state that contains one. Without a matching index template, a data stream can't roll over or create backing indices.\n\nIf your snapshot contains data from App Search or Workplace Search, you must restore the Enterprise Search encryption key before you restore the snapshot." }
+{ "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "snapshot.restore", "type": "object", "properties": { "master_timeout": { "$ref": "./_types.json#/$defs/_types__Duration", "description": "The period to wait for the master node.\nIf the master node is not available before the timeout expires, the request fails and returns an error.\nTo indicate that the request should never timeout, set it to `-1`.", "x-found-in": "query" }, "wait_for_completion": { "type": "boolean", "description": "If `true`, the request returns a response when the restore operation completes.\nThe operation is complete when it finishes all attempts to recover primary shards for restored indices.\nThis applies even if one or more of the recovery attempts fail.\n\nIf `false`, the request returns a response when the restore operation initializes.", "x-found-in": "query" }, "feature_states": { "type": "array", "items": { "type": "string" }, "description": "The feature states to restore.\nIf `include_global_state` is `true`, the request restores all feature states in the snapshot by default.\nIf `include_global_state` is `false`, the request restores no feature states by default.\nNote that specifying an empty array will result in the default behavior.\nTo restore no feature states, regardless of the `include_global_state` value, specify an array containing only the value `none` (`[\"none\"]`).", "x-found-in": "body" }, "ignore_index_settings": { "type": "array", "items": { "type": "string" }, "description": "The index settings to not restore from the snapshot.\nYou can't use this option to ignore `index.number_of_shards`.\n\nFor data streams, this option applies only to restored backing indices.\nNew backing indices are configured using the data stream's matching index template.", "x-found-in": "body" }, "ignore_unavailable": { "type": "boolean", "description": "If `true`, the request ignores any index or data stream in indices that's missing from the snapshot.\nIf `false`, the request returns an error for any missing index or data stream.", "x-found-in": "body" }, "include_aliases": { "type": "boolean", "description": "If `true`, the request restores aliases for any restored data streams and indices.\nIf `false`, the request doesn’t restore aliases.", "x-found-in": "body" }, "include_global_state": { "type": "boolean", "description": "If `true`, restore the cluster state. The cluster state includes:\n\n* Persistent cluster settings\n* Index templates\n* Legacy index templates\n* Ingest pipelines\n* Index lifecycle management (ILM) policies\n* Stored scripts\n* For snapshots taken after 7.12.0, feature states\n\nIf `include_global_state` is `true`, the restore operation merges the legacy index templates in your cluster with the templates contained in the snapshot, replacing any existing ones whose name matches one in the snapshot.\nIt completely removes all persistent settings, non-legacy index templates, ingest pipelines, and ILM lifecycle policies that exist in your cluster and replaces them with the corresponding items from the snapshot.\n\nUse the `feature_states` parameter to configure how feature states are restored.\n\nIf `include_global_state` is `true` and a snapshot was created without a global state then the restore request will fail.", "x-found-in": "body" }, "index_settings": { "$ref": "./indices._types.json#/$defs/indices._types__IndexSettings", "description": "Index settings to add or change in restored indices, including backing indices.\nYou can't use this option to change `index.number_of_shards`.\n\nFor data streams, this option applies only to restored backing indices.\nNew backing indices are configured using the data stream's matching index template.", "x-found-in": "body" }, "indices": { "$ref": "./_types.json#/$defs/_types__Indices", "description": "A comma-separated list of indices and data streams to restore.\nIt supports a multi-target syntax.\nThe default behavior is all regular indices and regular data streams in the snapshot.\n\nYou can't use this parameter to restore system indices or system data streams.\nUse `feature_states` instead.", "x-found-in": "body" }, "partial": { "type": "boolean", "description": "If `false`, the entire restore operation will fail if one or more indices included in the snapshot do not have all primary shards available.\n\nIf true, it allows restoring a partial snapshot of indices with unavailable shards.\nOnly shards that were successfully included in the snapshot will be restored.\nAll missing shards will be recreated as empty.", "x-found-in": "body" }, "rename_pattern": { "type": "string", "description": "A rename pattern to apply to restored data streams and indices.\nData streams and indices matching the rename pattern will be renamed according to `rename_replacement`.\n\nThe rename pattern is applied as defined by the regular expression that supports referencing the original text, according to the `appendReplacement` logic.", "x-found-in": "body" }, "rename_replacement": { "type": "string", "description": "The rename replacement string that is used with the `rename_pattern`.", "x-found-in": "body" }, "repository": { "type": "string", "description": "The name of the repository to restore a snapshot from.", "x-found-in": "path" }, "snapshot": { "type": "string", "description": "The name of the snapshot to restore.", "x-found-in": "path" } }, "required": ["repository", "snapshot"], "description": "Restore a snapshot.\n\nRestore a snapshot of a cluster or data streams and indices.\n\nYou can restore a snapshot only to a running cluster with an elected master node.\nThe snapshot repository must be registered and available to the cluster.\nThe snapshot and cluster versions must be compatible.\n\nTo restore a snapshot, the cluster's global metadata must be writable. Ensure there are't any cluster blocks that prevent writes. The restore operation ignores index blocks.\n\nBefore you restore a data stream, ensure the cluster contains a matching index template with data streams enabled. To check, use the index management feature in Kibana or the get index template API:\n\n```\nGET _index_template/*?filter_path=index_templates.name,index_templates.index_template.index_patterns,index_templates.index_template.data_stream\n```\n\nIf no such template exists, you can create one or restore a cluster state that contains one. Without a matching index template, a data stream can't roll over or create backing indices.\n\nIf your snapshot contains data from App Search or Workplace Search, you must restore the Enterprise Search encryption key before you restore the snapshot." }

package/lib/cjs/es/json/sql.query.request.json

@@ -1 +1 @@
-{ "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "sql.query", "type": "object", "properties": { "allow_partial_search_results": { "type": "boolean", "description": "If `true`, the response has partial results when there are shard request timeouts or shard failures.\nIf `false`, the API returns an error with no partial results.", "x-found-in": "body" }, "catalog": { "type": "string", "description": "The default catalog (cluster) for queries.\nIf unspecified, the queries execute on the data in the local cluster only.", "x-found-in": "body" }, "columnar": { "type": "boolean", "description": "If `true`, the results are in a columnar fashion: one row represents all the values of a certain column from the current page of results.\nThe API supports this parameter only for CBOR, JSON, SMILE, and YAML responses.", "x-found-in": "body" }, "cursor": { "type": "string", "description": "The cursor used to retrieve a set of paginated results.\nIf you specify a cursor, the API only uses the `columnar` and `time_zone` request body parameters.\nIt ignores other request body parameters.", "x-found-in": "body" }, "fetch_size": { "type": "number", "description": "The maximum number of rows (or entries) to return in one response.", "x-found-in": "body" }, "field_multi_value_leniency": { "type": "boolean", "description": "If `false`, the API returns an exception when encountering multiple values for a field.\nIf `true`, the API is lenient and returns the first value from the array with no guarantee of consistent results.", "x-found-in": "body" }, "filter": { "$ref": "./_types.query_dsl.json#/$defs/_types.query_dsl__QueryContainer", "description": "The Elasticsearch query DSL for additional filtering.", "x-found-in": "body" }, "index_using_frozen": { "type": "boolean", "description": "If `true`, the search can run on frozen indices.", "x-found-in": "body" }, "keep_alive": { "$ref": "./_types.json#/$defs/_types__Duration", "description": "The retention period for an async or saved synchronous search.", "x-found-in": "body" }, "keep_on_completion": { "type": "boolean", "description": "If `true`, Elasticsearch stores synchronous searches if you also specify the `wait_for_completion_timeout` parameter.\nIf `false`, Elasticsearch only stores async searches that don't finish before the `wait_for_completion_timeout`.", "x-found-in": "body" }, "page_timeout": { "$ref": "./_types.json#/$defs/_types__Duration", "description": "The minimum retention period for the scroll cursor.\nAfter this time period, a pagination request might fail because the scroll cursor is no longer available.\nSubsequent scroll requests prolong the lifetime of the scroll cursor by the duration of `page_timeout` in the scroll request.", "x-found-in": "body" }, "params": { "type": "array", "items": {}, "description": "The values for parameters in the query.", "x-found-in": "body" }, "query": { "type": "string", "description": "The SQL query to run.", "x-found-in": "body" }, "request_timeout": { "$ref": "./_types.json#/$defs/_types__Duration", "description": "The timeout before the request fails.", "x-found-in": "body" }, "runtime_mappings": { "$ref": "./_types.mapping.json#/$defs/_types.mapping__RuntimeFields", "description": "One or more runtime fields for the search request.\nThese fields take precedence over mapped fields with the same name.", "x-found-in": "body" }, "time_zone": { "type": "string", "description": "The ISO-8601 time zone ID for the search.", "x-found-in": "body" }, "wait_for_completion_timeout": { "$ref": "./_types.json#/$defs/_types__Duration", "description": "The period to wait for complete results.\nIt defaults to no timeout, meaning the request waits for complete search results.\nIf the search doesn't finish within this period, the search becomes async.\n\nTo save a synchronous search, you must specify this parameter and the `keep_on_completion` parameter.", "x-found-in": "body" }, "format": { "$ref": "./sql.query.json#/$defs/sql.query__SqlFormat", "description": "The format for the response.\nYou can also specify a format using the `Accept` HTTP header.\nIf you specify both this parameter and the `Accept` HTTP header, this parameter takes precedence.", "x-found-in": "query" } }, "description": "Get SQL search results.\n\nRun an SQL request." }
+{ "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "sql.query", "type": "object", "properties": { "format": { "$ref": "./sql.query.json#/$defs/sql.query__SqlFormat", "description": "The format for the response.\nYou can also specify a format using the `Accept` HTTP header.\nIf you specify both this parameter and the `Accept` HTTP header, this parameter takes precedence.", "x-found-in": "query" }, "allow_partial_search_results": { "type": "boolean", "description": "If `true`, the response has partial results when there are shard request timeouts or shard failures.\nIf `false`, the API returns an error with no partial results.", "x-found-in": "body" }, "catalog": { "type": "string", "description": "The default catalog (cluster) for queries.\nIf unspecified, the queries execute on the data in the local cluster only.", "x-found-in": "body" }, "columnar": { "type": "boolean", "description": "If `true`, the results are in a columnar fashion: one row represents all the values of a certain column from the current page of results.\nThe API supports this parameter only for CBOR, JSON, SMILE, and YAML responses.", "x-found-in": "body" }, "cursor": { "type": "string", "description": "The cursor used to retrieve a set of paginated results.\nIf you specify a cursor, the API only uses the `columnar` and `time_zone` request body parameters.\nIt ignores other request body parameters.", "x-found-in": "body" }, "fetch_size": { "type": "number", "description": "The maximum number of rows (or entries) to return in one response.", "x-found-in": "body" }, "field_multi_value_leniency": { "type": "boolean", "description": "If `false`, the API returns an exception when encountering multiple values for a field.\nIf `true`, the API is lenient and returns the first value from the array with no guarantee of consistent results.", "x-found-in": "body" }, "filter": { "$ref": "./_types.query_dsl.json#/$defs/_types.query_dsl__QueryContainer", "description": "The Elasticsearch query DSL for additional filtering.", "x-found-in": "body" }, "index_using_frozen": { "type": "boolean", "description": "If `true`, the search can run on frozen indices.", "x-found-in": "body" }, "keep_alive": { "$ref": "./_types.json#/$defs/_types__Duration", "description": "The retention period for an async or saved synchronous search.", "x-found-in": "body" }, "keep_on_completion": { "type": "boolean", "description": "If `true`, Elasticsearch stores synchronous searches if you also specify the `wait_for_completion_timeout` parameter.\nIf `false`, Elasticsearch only stores async searches that don't finish before the `wait_for_completion_timeout`.", "x-found-in": "body" }, "page_timeout": { "$ref": "./_types.json#/$defs/_types__Duration", "description": "The minimum retention period for the scroll cursor.\nAfter this time period, a pagination request might fail because the scroll cursor is no longer available.\nSubsequent scroll requests prolong the lifetime of the scroll cursor by the duration of `page_timeout` in the scroll request.", "x-found-in": "body" }, "params": { "type": "array", "items": {}, "description": "The values for parameters in the query.", "x-found-in": "body" }, "query": { "type": "string", "description": "The SQL query to run.", "x-found-in": "body" }, "request_timeout": { "$ref": "./_types.json#/$defs/_types__Duration", "description": "The timeout before the request fails.", "x-found-in": "body" }, "runtime_mappings": { "$ref": "./_types.mapping.json#/$defs/_types.mapping__RuntimeFields", "description": "One or more runtime fields for the search request.\nThese fields take precedence over mapped fields with the same name.", "x-found-in": "body" }, "time_zone": { "type": "string", "description": "The ISO-8601 time zone ID for the search.", "x-found-in": "body" }, "wait_for_completion_timeout": { "$ref": "./_types.json#/$defs/_types__Duration", "description": "The period to wait for complete results.\nIt defaults to no timeout, meaning the request waits for complete search results.\nIf the search doesn't finish within this period, the search becomes async.\n\nTo save a synchronous search, you must specify this parameter and the `keep_on_completion` parameter.", "x-found-in": "body" } }, "description": "Get SQL search results.\n\nRun an SQL request." }

package/lib/cjs/es/json/synonyms.put_synonym.request.json

@@ -1 +1 @@
-{ "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "synonyms.put_synonym", "type": "object", "properties": { "synonyms_set": { "oneOf": [{ "$ref": "./synonyms._types.json#/$defs/synonyms._types__SynonymRule" }, { "type": "array", "items": { "$ref": "./synonyms._types.json#/$defs/synonyms._types__SynonymRule" } }], "description": "The synonym rules definitions for the synonyms set.", "x-found-in": "body" }, "refresh": { "type": "boolean", "description": "If `true`, the request will refresh the analyzers with the new synonyms set and wait for the new synonyms to be available before returning.\nIf `false`, analyzers will not be reloaded with the new synonym set", "x-found-in": "query" }, "append": { "type": "boolean", "description": "If `true`, the provided synonym rules are appended to the existing set, with matching IDs overwriting existing rules.\nIf `false`, the entire synonyms set is replaced with the new synonym rules definitions.", "x-found-in": "query" }, "id": { "type": "string", "description": "The ID of the synonyms set to be created or updated.", "x-found-in": "path" } }, "required": ["id", "synonyms_set"], "description": "Create or update a synonym set.\n\nSynonym sets are limited to a maximum of 100,000 synonym rules per set by default.\nThis limit is configurable using the `synonyms.max_synonym_rules` cluster setting.\n\nWhen an existing synonyms set is updated, the search analyzers that use the synonyms set are reloaded automatically for all indices.\nThis is equivalent to invoking the reload search analyzers API for all indices that use the synonyms set.\n\nFor practical examples of how to create or update a synonyms set, refer to the External documentation." }
+{ "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "synonyms.put_synonym", "type": "object", "properties": { "refresh": { "type": "boolean", "description": "If `true`, the request will refresh the analyzers with the new synonyms set and wait for the new synonyms to be available before returning.\nIf `false`, analyzers will not be reloaded with the new synonym set", "x-found-in": "query" }, "append": { "type": "boolean", "description": "If `true`, the provided synonym rules are appended to the existing set, with matching IDs overwriting existing rules.\nIf `false`, the entire synonyms set is replaced with the new synonym rules definitions.", "x-found-in": "query" }, "synonyms_set": { "anyOf": [{ "$ref": "./synonyms._types.json#/$defs/synonyms._types__SynonymRule" }, { "type": "array", "items": { "$ref": "./synonyms._types.json#/$defs/synonyms._types__SynonymRule" } }], "description": "The synonym rules definitions for the synonyms set.", "x-found-in": "body" }, "id": { "type": "string", "description": "The ID of the synonyms set to be created or updated.", "x-found-in": "path" } }, "required": ["id", "synonyms_set"], "description": "Create or update a synonym set.\n\nSynonym sets are limited to a maximum of 100,000 synonym rules per set by default.\nThis limit is configurable using the `synonyms.max_synonym_rules` cluster setting.\n\nWhen an existing synonyms set is updated, the search analyzers that use the synonyms set are reloaded automatically for all indices.\nThis is equivalent to invoking the reload search analyzers API for all indices that use the synonyms set.\n\nFor practical examples of how to create or update a synonyms set, refer to the External documentation." }

package/lib/cjs/es/json/synonyms.put_synonym_rule.request.json

@@ -1 +1 @@
-{ "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "synonyms.put_synonym_rule", "type": "object", "properties": { "synonyms": { "type": "string", "description": "The synonym rule information definition, which must be in Solr format.", "x-found-in": "body" }, "refresh": { "type": "boolean", "description": "If `true`, the request will refresh the analyzers with the new synonym rule and wait for the new synonyms to be available before returning.\nIf `false`, analyzers will not be reloaded with the new synonym rule", "x-found-in": "query" }, "set_id": { "type": "string", "description": "The ID of the synonym set.", "x-found-in": "path" }, "rule_id": { "type": "string", "description": "The ID of the synonym rule to be updated or created.", "x-found-in": "path" } }, "required": ["set_id", "rule_id", "synonyms"], "description": "Create or update a synonym rule.\n\nCreate or update a synonym rule in a synonym set.\n\nIf any of the synonym rules included is invalid, the API returns an error.\n\nWhen you update a synonym rule, all analyzers using the synonyms set will be reloaded automatically to reflect the new rule." }
+{ "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "synonyms.put_synonym_rule", "type": "object", "properties": { "refresh": { "type": "boolean", "description": "If `true`, the request will refresh the analyzers with the new synonym rule and wait for the new synonyms to be available before returning.\nIf `false`, analyzers will not be reloaded with the new synonym rule", "x-found-in": "query" }, "synonyms": { "type": "string", "description": "The synonym rule information definition, which must be in Solr format.", "x-found-in": "body" }, "set_id": { "type": "string", "description": "The ID of the synonym set.", "x-found-in": "path" }, "rule_id": { "type": "string", "description": "The ID of the synonym rule to be updated or created.", "x-found-in": "path" } }, "required": ["set_id", "rule_id", "synonyms"], "description": "Create or update a synonym rule.\n\nCreate or update a synonym rule in a synonym set.\n\nIf any of the synonym rules included is invalid, the API returns an error.\n\nWhen you update a synonym rule, all analyzers using the synonyms set will be reloaded automatically to reflect the new rule." }

package/lib/cjs/es/json/tasks.cancel.request.json

@@ -1 +1 @@
-{ "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "tasks.cancel", "type": "object", "properties": { "actions": { "oneOf": [{ "type": "string" }, { "type": "array", "items": { "type": "string" } }], "description": "A comma-separated list or wildcard expression of actions that is used to limit the request.", "x-found-in": "query" }, "nodes": { "type": "array", "items": { "type": "string" }, "description": "A comma-separated list of node IDs or names that is used to limit the request.", "x-found-in": "query" }, "parent_task_id": { "type": "string", "description": "A parent task ID that is used to limit the tasks.", "x-found-in": "query" }, "wait_for_completion": { "type": "boolean", "description": "If true, the request blocks until all found tasks are complete.", "x-found-in": "query" }, "task_id": { "type": "string", "description": "The task identifier.", "x-found-in": "path" } }, "description": "Cancel a task.\n\nWARNING: The task management API is new and should still be considered a beta feature.\nThe API may change in ways that are not backwards compatible.\n\nA task may continue to run for some time after it has been cancelled because it may not be able to safely stop its current activity straight away.\nIt is also possible that Elasticsearch must complete its work on other tasks before it can process the cancellation.\nThe get task information API will continue to list these cancelled tasks until they complete.\nThe cancelled flag in the response indicates that the cancellation command has been processed and the task will stop as soon as possible.\n\nTo troubleshoot why a cancelled task does not complete promptly, use the get task information API with the `?detailed` parameter to identify the other tasks the system is running.\nYou can also use the node hot threads API to obtain detailed information about the work the system is doing instead of completing the cancelled task.\n\nFor relocatable tasks, this API transparently follows the task across graceful shutdown relocations,\nso callers can keep using the original task ID. The returned task reports its `original_task_id` and `original_start_time_in_millis`\nif it is continuing work from an earlier task." }
+{ "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "tasks.cancel", "type": "object", "properties": { "actions": { "anyOf": [{ "type": "string" }, { "type": "array", "items": { "type": "string" } }], "description": "A comma-separated list or wildcard expression of actions that is used to limit the request.", "x-found-in": "query" }, "nodes": { "type": "array", "items": { "type": "string" }, "description": "A comma-separated list of node IDs or names that is used to limit the request.", "x-found-in": "query" }, "parent_task_id": { "type": "string", "description": "A parent task ID that is used to limit the tasks.", "x-found-in": "query" }, "wait_for_completion": { "type": "boolean", "description": "If true, the request blocks until all found tasks are complete.", "x-found-in": "query" }, "task_id": { "type": "string", "description": "The task identifier.", "x-found-in": "path" } }, "description": "Cancel a task.\n\nWARNING: The task management API is new and should still be considered a beta feature.\nThe API may change in ways that are not backwards compatible.\n\nA task may continue to run for some time after it has been cancelled because it may not be able to safely stop its current activity straight away.\nIt is also possible that Elasticsearch must complete its work on other tasks before it can process the cancellation.\nThe get task information API will continue to list these cancelled tasks until they complete.\nThe cancelled flag in the response indicates that the cancellation command has been processed and the task will stop as soon as possible.\n\nTo troubleshoot why a cancelled task does not complete promptly, use the get task information API with the `?detailed` parameter to identify the other tasks the system is running.\nYou can also use the node hot threads API to obtain detailed information about the work the system is doing instead of completing the cancelled task.\n\nFor relocatable tasks, this API transparently follows the task across graceful shutdown relocations,\nso callers can keep using the original task ID. The returned task reports its `original_task_id` and `original_start_time_in_millis`\nif it is continuing work from an earlier task." }

package/lib/cjs/es/json/tasks.list.request.json

@@ -1 +1 @@
-{ "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "tasks.list", "type": "object", "properties": { "actions": { "oneOf": [{ "type": "string" }, { "type": "array", "items": { "type": "string" } }], "description": "A comma-separated list or wildcard expression of actions used to limit the request.\nFor example, you can use `cluser:*` to retrieve all cluster-related tasks.", "x-found-in": "query" }, "detailed": { "type": "boolean", "description": "If `true`, the response includes detailed information about the running tasks.\nThis information is useful to distinguish tasks from each other but is more costly to run.", "x-found-in": "query" }, "group_by": { "$ref": "./tasks._types.json#/$defs/tasks._types__GroupBy", "description": "A key that is used to group tasks in the response.\nThe task lists can be grouped either by nodes or by parent tasks.", "x-found-in": "query" }, "nodes": { "$ref": "./_types.json#/$defs/_types__NodeIds", "description": "A comma-separated list of node IDs or names that is used to limit the returned information.", "x-found-in": "query" }, "parent_task_id": { "type": "string", "description": "A parent task identifier that is used to limit returned information.\nTo return all tasks, omit this parameter or use a value of `-1`.\nIf the parent task is not found, the API does not return a 404 response code.", "x-found-in": "query" }, "timeout": { "$ref": "./_types.json#/$defs/_types__Duration", "description": "The period to wait for each node to respond.\nIf a node does not respond before its timeout expires, the response does not include its information.\nHowever, timed out nodes are included in the `node_failures` property.", "x-found-in": "query" }, "wait_for_completion": { "type": "boolean", "description": "If `true`, the request blocks until the operation is complete.", "x-found-in": "query" } }, "description": "Get all tasks.\n\nGet information about the tasks currently running on one or more nodes in the cluster.\n\nWARNING: The task management API is new and should still be considered a beta feature.\nThe API may change in ways that are not backwards compatible.\n\nFor relocatable tasks, this API transparently follows the task across graceful shutdown relocations,\nso callers can keep using the original task ID. The returned task reports its `original_task_id` and `original_start_time_in_millis`\nif it is continuing work from an earlier task.\n\n**Identifying running tasks**\n\nThe `X-Opaque-Id header`, when provided on the HTTP request header, is going to be returned as a header in the response as well as in the headers field for in the task information.\nThis enables you to track certain calls or associate certain tasks with the client that started them.\nFor example:\n\n```\ncurl -i -H \"X-Opaque-Id: 123456\" \"http://localhost:9200/_tasks?group_by=parents\"\n```\n\nThe API returns the following result:\n\n```\nHTTP/1.1 200 OK\nX-Opaque-Id: 123456\ncontent-type: application/json; charset=UTF-8\ncontent-length: 831\n\n{\n  \"tasks\" : {\n    \"u5lcZHqcQhu-rUoFaqDphA:45\" : {\n      \"node\" : \"u5lcZHqcQhu-rUoFaqDphA\",\n      \"id\" : 45,\n      \"type\" : \"transport\",\n      \"action\" : \"cluster:monitor/tasks/lists\",\n      \"start_time_in_millis\" : 1513823752749,\n      \"running_time_in_nanos\" : 293139,\n      \"cancellable\" : false,\n      \"headers\" : {\n        \"X-Opaque-Id\" : \"123456\"\n      },\n      \"children\" : [\n        {\n          \"node\" : \"u5lcZHqcQhu-rUoFaqDphA\",\n          \"id\" : 46,\n          \"type\" : \"direct\",\n          \"action\" : \"cluster:monitor/tasks/lists[n]\",\n          \"start_time_in_millis\" : 1513823752750,\n          \"running_time_in_nanos\" : 92133,\n          \"cancellable\" : false,\n          \"parent_task_id\" : \"u5lcZHqcQhu-rUoFaqDphA:45\",\n          \"headers\" : {\n            \"X-Opaque-Id\" : \"123456\"\n          }\n        }\n      ]\n    }\n  }\n }\n```\nIn this example, `X-Opaque-Id: 123456` is the ID as a part of the response header.\nThe `X-Opaque-Id` in the task `headers` is the ID for the task that was initiated by the REST request.\nThe `X-Opaque-Id` in the children `headers` is the child task of the task that was initiated by the REST request." }
+{ "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "tasks.list", "type": "object", "properties": { "actions": { "anyOf": [{ "type": "string" }, { "type": "array", "items": { "type": "string" } }], "description": "A comma-separated list or wildcard expression of actions used to limit the request.\nFor example, you can use `cluser:*` to retrieve all cluster-related tasks.", "x-found-in": "query" }, "detailed": { "type": "boolean", "description": "If `true`, the response includes detailed information about the running tasks.\nThis information is useful to distinguish tasks from each other but is more costly to run.", "x-found-in": "query" }, "group_by": { "$ref": "./tasks._types.json#/$defs/tasks._types__GroupBy", "description": "A key that is used to group tasks in the response.\nThe task lists can be grouped either by nodes or by parent tasks.", "x-found-in": "query" }, "nodes": { "$ref": "./_types.json#/$defs/_types__NodeIds", "description": "A comma-separated list of node IDs or names that is used to limit the returned information.", "x-found-in": "query" }, "parent_task_id": { "type": "string", "description": "A parent task identifier that is used to limit returned information.\nTo return all tasks, omit this parameter or use a value of `-1`.\nIf the parent task is not found, the API does not return a 404 response code.", "x-found-in": "query" }, "timeout": { "$ref": "./_types.json#/$defs/_types__Duration", "description": "The period to wait for each node to respond.\nIf a node does not respond before its timeout expires, the response does not include its information.\nHowever, timed out nodes are included in the `node_failures` property.", "x-found-in": "query" }, "wait_for_completion": { "type": "boolean", "description": "If `true`, the request blocks until the operation is complete.", "x-found-in": "query" } }, "description": "Get all tasks.\n\nGet information about the tasks currently running on one or more nodes in the cluster.\n\nWARNING: The task management API is new and should still be considered a beta feature.\nThe API may change in ways that are not backwards compatible.\n\nFor relocatable tasks, this API transparently follows the task across graceful shutdown relocations,\nso callers can keep using the original task ID. The returned task reports its `original_task_id` and `original_start_time_in_millis`\nif it is continuing work from an earlier task.\n\n**Identifying running tasks**\n\nThe `X-Opaque-Id header`, when provided on the HTTP request header, is going to be returned as a header in the response as well as in the headers field for in the task information.\nThis enables you to track certain calls or associate certain tasks with the client that started them.\nFor example:\n\n```\ncurl -i -H \"X-Opaque-Id: 123456\" \"http://localhost:9200/_tasks?group_by=parents\"\n```\n\nThe API returns the following result:\n\n```\nHTTP/1.1 200 OK\nX-Opaque-Id: 123456\ncontent-type: application/json; charset=UTF-8\ncontent-length: 831\n\n{\n  \"tasks\" : {\n    \"u5lcZHqcQhu-rUoFaqDphA:45\" : {\n      \"node\" : \"u5lcZHqcQhu-rUoFaqDphA\",\n      \"id\" : 45,\n      \"type\" : \"transport\",\n      \"action\" : \"cluster:monitor/tasks/lists\",\n      \"start_time_in_millis\" : 1513823752749,\n      \"running_time_in_nanos\" : 293139,\n      \"cancellable\" : false,\n      \"headers\" : {\n        \"X-Opaque-Id\" : \"123456\"\n      },\n      \"children\" : [\n        {\n          \"node\" : \"u5lcZHqcQhu-rUoFaqDphA\",\n          \"id\" : 46,\n          \"type\" : \"direct\",\n          \"action\" : \"cluster:monitor/tasks/lists[n]\",\n          \"start_time_in_millis\" : 1513823752750,\n          \"running_time_in_nanos\" : 92133,\n          \"cancellable\" : false,\n          \"parent_task_id\" : \"u5lcZHqcQhu-rUoFaqDphA:45\",\n          \"headers\" : {\n            \"X-Opaque-Id\" : \"123456\"\n          }\n        }\n      ]\n    }\n  }\n }\n```\nIn this example, `X-Opaque-Id: 123456` is the ID as a part of the response header.\nThe `X-Opaque-Id` in the task `headers` is the ID for the task that was initiated by the REST request.\nThe `X-Opaque-Id` in the children `headers` is the child task of the task that was initiated by the REST request." }

package/lib/cjs/es/json/termvectors.request.json

@@ -1 +1 @@
-{ "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "termvectors", "type": "object", "properties": { "doc": { "description": "An artificial document (a document not present in the index) for which you want to retrieve term vectors.", "x-found-in": "body" }, "filter": { "$ref": "./_global.termvectors.json#/$defs/_global.termvectors__Filter", "description": "Filter terms based on their tf-idf scores.\nThis could be useful in order find out a good characteristic vector of a document.\nThis feature works in a similar manner to the second phase of the More Like This Query.", "x-found-in": "body" }, "per_field_analyzer": { "type": "object", "additionalProperties": { "type": "string" }, "description": "Override the default per-field analyzer.\nThis is useful in order to generate term vectors in any fashion, especially when using artificial documents.\nWhen providing an analyzer for a field that already stores term vectors, the term vectors will be regenerated.", "x-found-in": "body" }, "fields": { "$ref": "./_types.json#/$defs/_types__Fields", "description": "A comma-separated list or wildcard expressions of fields to include in the statistics.\nIt is used as the default list unless a specific field list is provided in the `completion_fields` or `fielddata_fields` parameters.", "x-found-in": "query" }, "field_statistics": { "type": "boolean", "description": "If `true`, the response includes:\n\n* The document count (how many documents contain this field).\n* The sum of document frequencies (the sum of document frequencies for all terms in this field).\n* The sum of total term frequencies (the sum of total term frequencies of each term in this field).", "x-found-in": "query" }, "offsets": { "type": "boolean", "description": "If `true`, the response includes term offsets.", "x-found-in": "query" }, "payloads": { "type": "boolean", "description": "If `true`, the response includes term payloads.", "x-found-in": "query" }, "positions": { "type": "boolean", "description": "If `true`, the response includes term positions.", "x-found-in": "query" }, "term_statistics": { "type": "boolean", "description": "If `true`, the response includes:\n\n* The total term frequency (how often a term occurs in all documents).\n* The document frequency (the number of documents containing the current term).\n\nBy default these values are not returned since term statistics can have a serious performance impact.", "x-found-in": "query" }, "routing": { "$ref": "./_types.json#/$defs/_types__Routing", "description": "A custom value that is used to route operations to a specific shard.\nNot allowed when `index.slice.enabled` is `true` for the target index; use `_slice` instead.", "x-found-in": "query" }, "version": { "type": "number", "description": "If `true`, returns the document version as part of a hit.", "x-found-in": "query" }, "version_type": { "$ref": "./_types.json#/$defs/_types__VersionType", "description": "The version type.", "x-found-in": "query" }, "preference": { "type": "string", "description": "The node or shard the operation should be performed on.\nIt is random by default.", "x-found-in": "query" }, "realtime": { "type": "boolean", "description": "If true, the request is real-time as opposed to near-real-time.", "x-found-in": "query" }, "index": { "type": "string", "description": "The name of the index that contains the document.", "x-found-in": "path" }, "id": { "type": "string", "description": "A unique identifier for the document.", "x-found-in": "path" } }, "required": ["index"], "description": "Get term vector information.\n\nGet information and statistics about terms in the fields of a particular document.\n\nYou can retrieve term vectors for documents stored in the index or for artificial documents passed in the body of the request.\nYou can specify the fields you are interested in through the `fields` parameter or by adding the fields to the request body.\nFor example:\n\n```\nGET /my-index-000001/_termvectors/1?fields=message\n```\n\nFields can be specified using wildcards, similar to the multi match query.\n\nTerm vectors are real-time by default, not near real-time.\nThis can be changed by setting `realtime` parameter to `false`.\n\nYou can request three types of values: _term information_, _term statistics_, and _field statistics_.\nBy default, all term information and field statistics are returned for all fields but term statistics are excluded.\n\n**Term information**\n\n* term frequency in the field (always returned)\n* term positions (`positions: true`)\n* start and end offsets (`offsets: true`)\n* term payloads (`payloads: true`), as base64 encoded bytes\n\nIf the requested information wasn't stored in the index, it will be computed on the fly if possible.\nAdditionally, term vectors could be computed for documents not even existing in the index, but instead provided by the user.\n\n> warn\n> Start and end offsets assume UTF-16 encoding is being used. If you want to use these offsets in order to get the original text that produced this token, you should make sure that the string you are taking a sub-string of is also encoded using UTF-16.\n\n**Behaviour**\n\nThe term and field statistics are not accurate.\nDeleted documents are not taken into account.\nThe information is only retrieved for the shard the requested document resides in.\nThe term and field statistics are therefore only useful as relative measures whereas the absolute numbers have no meaning in this context.\nBy default, when requesting term vectors of artificial documents, a shard to get the statistics from is randomly selected.\nUse `routing` only to hit a particular shard.\nRefer to the linked documentation for detailed examples of how to use this API." }
+{ "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "termvectors", "type": "object", "properties": { "fields": { "type": "array", "items": { "type": "string", "description": "Path to field or array of paths. Some API's support wildcards in the path to select multiple fields." }, "description": "A list of fields to include in the statistics.\nIt is used as the default list unless a specific field list is provided in the `completion_fields` or `fielddata_fields` parameters.", "x-found-in": "body" }, "field_statistics": { "type": "boolean", "description": "If `true`, the response includes:\n\n* The document count (how many documents contain this field).\n* The sum of document frequencies (the sum of document frequencies for all terms in this field).\n* The sum of total term frequencies (the sum of total term frequencies of each term in this field).", "x-found-in": "body" }, "offsets": { "type": "boolean", "description": "If `true`, the response includes term offsets.", "x-found-in": "body" }, "payloads": { "type": "boolean", "description": "If `true`, the response includes term payloads.", "x-found-in": "body" }, "positions": { "type": "boolean", "description": "If `true`, the response includes term positions.", "x-found-in": "body" }, "preference": { "type": "string", "description": "The node or shard the operation should be performed on.\nIt is random by default.", "x-found-in": "query" }, "realtime": { "type": "boolean", "description": "If true, the request is real-time as opposed to near-real-time.", "x-found-in": "query" }, "routing": { "$ref": "./_types.json#/$defs/_types__Routing", "description": "A custom value that is used to route operations to a specific shard.", "x-found-in": "body" }, "term_statistics": { "type": "boolean", "description": "If `true`, the response includes:\n\n* The total term frequency (how often a term occurs in all documents).\n* The document frequency (the number of documents containing the current term).\n\nBy default these values are not returned since term statistics can have a serious performance impact.", "x-found-in": "body" }, "version": { "type": "number", "description": "If `true`, returns the document version as part of a hit.", "x-found-in": "body" }, "version_type": { "$ref": "./_types.json#/$defs/_types__VersionType", "description": "The version type.", "x-found-in": "body" }, "doc": { "description": "An artificial document (a document not present in the index) for which you want to retrieve term vectors.", "x-found-in": "body" }, "filter": { "$ref": "./_global.termvectors.json#/$defs/_global.termvectors__Filter", "description": "Filter terms based on their tf-idf scores.\nThis could be useful in order find out a good characteristic vector of a document.\nThis feature works in a similar manner to the second phase of the More Like This Query.", "x-found-in": "body" }, "per_field_analyzer": { "type": "object", "additionalProperties": { "type": "string" }, "description": "Override the default per-field analyzer.\nThis is useful in order to generate term vectors in any fashion, especially when using artificial documents.\nWhen providing an analyzer for a field that already stores term vectors, the term vectors will be regenerated.", "x-found-in": "body" }, "index": { "type": "string", "description": "The name of the index that contains the document.", "x-found-in": "path" }, "id": { "type": "string", "description": "A unique identifier for the document.", "x-found-in": "path" } }, "required": ["index"], "description": "Get term vector information.\n\nGet information and statistics about terms in the fields of a particular document.\n\nYou can retrieve term vectors for documents stored in the index or for artificial documents passed in the body of the request.\nYou can specify the fields you are interested in through the `fields` parameter or by adding the fields to the request body.\nFor example:\n\n```\nGET /my-index-000001/_termvectors/1?fields=message\n```\n\nFields can be specified using wildcards, similar to the multi match query.\n\nTerm vectors are real-time by default, not near real-time.\nThis can be changed by setting `realtime` parameter to `false`.\n\nYou can request three types of values: _term information_, _term statistics_, and _field statistics_.\nBy default, all term information and field statistics are returned for all fields but term statistics are excluded.\n\n**Term information**\n\n* term frequency in the field (always returned)\n* term positions (`positions: true`)\n* start and end offsets (`offsets: true`)\n* term payloads (`payloads: true`), as base64 encoded bytes\n\nIf the requested information wasn't stored in the index, it will be computed on the fly if possible.\nAdditionally, term vectors could be computed for documents not even existing in the index, but instead provided by the user.\n\n> warn\n> Start and end offsets assume UTF-16 encoding is being used. If you want to use these offsets in order to get the original text that produced this token, you should make sure that the string you are taking a sub-string of is also encoded using UTF-16.\n\n**Behaviour**\n\nThe term and field statistics are not accurate.\nDeleted documents are not taken into account.\nThe information is only retrieved for the shard the requested document resides in.\nThe term and field statistics are therefore only useful as relative measures whereas the absolute numbers have no meaning in this context.\nBy default, when requesting term vectors of artificial documents, a shard to get the statistics from is randomly selected.\nUse `routing` only to hit a particular shard.\nRefer to the linked documentation for detailed examples of how to use this API." }

package/lib/cjs/es/json/text_structure.find_field_structure.request.json

@@ -1 +1 @@
-{ "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "text_structure.find_field_structure", "type": "object", "properties": { "column_names": { "oneOf": [{ "type": "string" }, { "type": "array", "items": { "type": "string" } }], "description": "If `format` is set to `delimited`, you can specify the column names in a comma-separated list.\nIf this parameter is not specified, the structure finder uses the column names from the header row of the text.\nIf the text does not have a header row, columns are named \"column1\", \"column2\", \"column3\", for example.", "x-found-in": "query" }, "delimiter": { "type": "string", "description": "If you have set `format` to `delimited`, you can specify the character used to delimit the values in each row.\nOnly a single character is supported; the delimiter cannot have multiple characters.\nBy default, the API considers the following possibilities: comma, tab, semi-colon, and pipe (`|`).\nIn this default scenario, all rows must have the same number of fields for the delimited format to be detected.\nIf you specify a delimiter, up to 10% of the rows can have a different number of columns than the first row.", "x-found-in": "query" }, "documents_to_sample": { "type": "number", "description": "The number of documents to include in the structural analysis.\nThe minimum value is 2.", "x-found-in": "query" }, "ecs_compatibility": { "$ref": "./text_structure._types.json#/$defs/text_structure._types__EcsCompatibilityType", "description": "The mode of compatibility with ECS compliant Grok patterns.\nUse this parameter to specify whether to use ECS Grok patterns instead of legacy ones when the structure finder creates a Grok pattern.\nThis setting primarily has an impact when a whole message Grok pattern such as `%{CATALINALOG}` matches the input.\nIf the structure finder identifies a common structure but has no idea of the meaning then generic field names such as `path`, `ipaddress`, `field1`, and `field2` are used in the `grok_pattern` output.\nThe intention in that situation is that a user who knows the meanings will rename the fields before using them.", "x-found-in": "query" }, "explain": { "type": "boolean", "description": "If `true`, the response includes a field named `explanation`, which is an array of strings that indicate how the structure finder produced its result.", "x-found-in": "query" }, "field": { "type": "string", "description": "The field that should be analyzed.", "x-found-in": "query" }, "format": { "$ref": "./text_structure._types.json#/$defs/text_structure._types__FormatType", "description": "The high level structure of the text.\nBy default, the API chooses the format.\nIn this default scenario, all rows must have the same number of fields for a delimited format to be detected.\nIf the format is set to delimited and the delimiter is not set, however, the API tolerates up to 5% of rows that have a different number of columns than the first row.", "x-found-in": "query" }, "grok_pattern": { "type": "string", "description": "If the format is `semi_structured_text`, you can specify a Grok pattern that is used to extract fields from every message in the text.\nThe name of the timestamp field in the Grok pattern must match what is specified in the `timestamp_field` parameter.\nIf that parameter is not specified, the name of the timestamp field in the Grok pattern must match \"timestamp\".\nIf `grok_pattern` is not specified, the structure finder creates a Grok pattern.", "x-found-in": "query" }, "index": { "type": "string", "description": "The name of the index that contains the analyzed field.", "x-found-in": "query" }, "quote": { "type": "string", "description": "If the format is `delimited`, you can specify the character used to quote the values in each row if they contain newlines or the delimiter character.\nOnly a single character is supported.\nIf this parameter is not specified, the default value is a double quote (`\"`).\nIf your delimited text format does not use quoting, a workaround is to set this argument to a character that does not appear anywhere in the sample.", "x-found-in": "query" }, "should_trim_fields": { "type": "boolean", "description": "If the format is `delimited`, you can specify whether values between delimiters should have whitespace trimmed from them.\nIf this parameter is not specified and the delimiter is pipe (`|`), the default value is true.\nOtherwise, the default value is `false`.", "x-found-in": "query" }, "should_parse_recursively": { "type": "boolean", "description": "If the format is `ndjson`, you can specify whether to parse nested JSON objects recursively.\nThe nested objects are parsed to a maximum depth equal to the default value of the `index.mapping.depth.limit` setting.\nAnything beyond that depth is parsed as an `object` type field.\nFor formats other than `ndjson`, this parameter is ignored.", "x-found-in": "query" }, "timeout": { "$ref": "./_types.json#/$defs/_types__Duration", "description": "The maximum amount of time that the structure analysis can take.\nIf the analysis is still running when the timeout expires, it will be stopped.", "x-found-in": "query" }, "timestamp_field": { "type": "string", "description": "The name of the field that contains the primary timestamp of each record in the text.\nIn particular, if the text was ingested into an index, this is the field that would be used to populate the `@timestamp` field.\n\nIf the format is `semi_structured_text`, this field must match the name of the appropriate extraction in the `grok_pattern`.\nTherefore, for semi-structured text, it is best not to specify this parameter unless `grok_pattern` is also specified.\n\nFor structured text, if you specify this parameter, the field must exist within the text.\n\nIf this parameter is not specified, the structure finder makes a decision about which field (if any) is the primary timestamp field.\nFor structured text, it is not compulsory to have a timestamp in the text.", "x-found-in": "query" }, "timestamp_format": { "type": "string", "description": "The Java time format of the timestamp field in the text.\nOnly a subset of Java time format letter groups are supported:\n\n* `a`\n* `d`\n* `dd`\n* `EEE`\n* `EEEE`\n* `H`\n* `HH`\n* `h`\n* `M`\n* `MM`\n* `MMM`\n* `MMMM`\n* `mm`\n* `ss`\n* `XX`\n* `XXX`\n* `yy`\n* `yyyy`\n* `zzz`\n\nAdditionally `S` letter groups (fractional seconds) of length one to nine are supported providing they occur after `ss` and are separated from the `ss` by a period (`.`), comma (`,`), or colon (`:`).\nSpacing and punctuation is also permitted with the exception a question mark (`?`), newline, and carriage return, together with literal text enclosed in single quotes.\nFor example, `MM/dd HH.mm.ss,SSSSSS 'in' yyyy` is a valid override format.\n\nOne valuable use case for this parameter is when the format is semi-structured text, there are multiple timestamp formats in the text, and you know which format corresponds to the primary timestamp, but you do not want to specify the full `grok_pattern`.\nAnother is when the timestamp format is one that the structure finder does not consider by default.\n\nIf this parameter is not specified, the structure finder chooses the best format from a built-in set.\n\nIf the special value `null` is specified, the structure finder will not look for a primary timestamp in the text.\nWhen the format is semi-structured text, this will result in the structure finder treating the text as single-line messages.", "x-found-in": "query" } }, "required": ["field", "index"], "description": "Find the structure of a text field.\n\nFind the structure of a text field in an Elasticsearch index.\n\nThis API provides a starting point for extracting further information from log messages already ingested into Elasticsearch.\nFor example, if you have ingested data into a very simple index that has just `@timestamp` and message fields, you can use this API to see what common structure exists in the message field.\n\nThe response from the API contains:\n\n* Sample messages.\n* Statistics that reveal the most common values for all fields detected within the text and basic numeric statistics for numeric fields.\n* Information about the structure of the text, which is useful when you write ingest configurations to index it or similarly formatted text.\n* Appropriate mappings for an Elasticsearch index, which you could use to ingest the text.\n\nAll this information can be calculated by the structure finder with no guidance.\nHowever, you can optionally override some of the decisions about the text structure by specifying one or more query parameters.\n\nIf the structure finder produces unexpected results, specify the `explain` query parameter and an explanation will appear in the response.\nIt helps determine why the returned structure was chosen." }
+{ "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "text_structure.find_field_structure", "type": "object", "properties": { "column_names": { "anyOf": [{ "type": "string" }, { "type": "array", "items": { "type": "string" } }], "description": "If `format` is set to `delimited`, you can specify the column names in a comma-separated list.\nIf this parameter is not specified, the structure finder uses the column names from the header row of the text.\nIf the text does not have a header row, columns are named \"column1\", \"column2\", \"column3\", for example.", "x-found-in": "query" }, "delimiter": { "type": "string", "description": "If you have set `format` to `delimited`, you can specify the character used to delimit the values in each row.\nOnly a single character is supported; the delimiter cannot have multiple characters.\nBy default, the API considers the following possibilities: comma, tab, semi-colon, and pipe (`|`).\nIn this default scenario, all rows must have the same number of fields for the delimited format to be detected.\nIf you specify a delimiter, up to 10% of the rows can have a different number of columns than the first row.", "x-found-in": "query" }, "documents_to_sample": { "type": "number", "description": "The number of documents to include in the structural analysis.\nThe minimum value is 2.", "x-found-in": "query" }, "ecs_compatibility": { "$ref": "./text_structure._types.json#/$defs/text_structure._types__EcsCompatibilityType", "description": "The mode of compatibility with ECS compliant Grok patterns.\nUse this parameter to specify whether to use ECS Grok patterns instead of legacy ones when the structure finder creates a Grok pattern.\nThis setting primarily has an impact when a whole message Grok pattern such as `%{CATALINALOG}` matches the input.\nIf the structure finder identifies a common structure but has no idea of the meaning then generic field names such as `path`, `ipaddress`, `field1`, and `field2` are used in the `grok_pattern` output.\nThe intention in that situation is that a user who knows the meanings will rename the fields before using them.", "x-found-in": "query" }, "explain": { "type": "boolean", "description": "If `true`, the response includes a field named `explanation`, which is an array of strings that indicate how the structure finder produced its result.", "x-found-in": "query" }, "field": { "type": "string", "description": "The field that should be analyzed.", "x-found-in": "query" }, "format": { "$ref": "./text_structure._types.json#/$defs/text_structure._types__FormatType", "description": "The high level structure of the text.\nBy default, the API chooses the format.\nIn this default scenario, all rows must have the same number of fields for a delimited format to be detected.\nIf the format is set to delimited and the delimiter is not set, however, the API tolerates up to 5% of rows that have a different number of columns than the first row.", "x-found-in": "query" }, "grok_pattern": { "type": "string", "description": "If the format is `semi_structured_text`, you can specify a Grok pattern that is used to extract fields from every message in the text.\nThe name of the timestamp field in the Grok pattern must match what is specified in the `timestamp_field` parameter.\nIf that parameter is not specified, the name of the timestamp field in the Grok pattern must match \"timestamp\".\nIf `grok_pattern` is not specified, the structure finder creates a Grok pattern.", "x-found-in": "query" }, "index": { "type": "string", "description": "The name of the index that contains the analyzed field.", "x-found-in": "query" }, "quote": { "type": "string", "description": "If the format is `delimited`, you can specify the character used to quote the values in each row if they contain newlines or the delimiter character.\nOnly a single character is supported.\nIf this parameter is not specified, the default value is a double quote (`\"`).\nIf your delimited text format does not use quoting, a workaround is to set this argument to a character that does not appear anywhere in the sample.", "x-found-in": "query" }, "should_trim_fields": { "type": "boolean", "description": "If the format is `delimited`, you can specify whether values between delimiters should have whitespace trimmed from them.\nIf this parameter is not specified and the delimiter is pipe (`|`), the default value is true.\nOtherwise, the default value is `false`.", "x-found-in": "query" }, "should_parse_recursively": { "type": "boolean", "description": "If the format is `ndjson`, you can specify whether to parse nested JSON objects recursively.\nThe nested objects are parsed to a maximum depth equal to the default value of the `index.mapping.depth.limit` setting.\nAnything beyond that depth is parsed as an `object` type field.\nFor formats other than `ndjson`, this parameter is ignored.", "x-found-in": "query" }, "timeout": { "$ref": "./_types.json#/$defs/_types__Duration", "description": "The maximum amount of time that the structure analysis can take.\nIf the analysis is still running when the timeout expires, it will be stopped.", "x-found-in": "query" }, "timestamp_field": { "type": "string", "description": "The name of the field that contains the primary timestamp of each record in the text.\nIn particular, if the text was ingested into an index, this is the field that would be used to populate the `@timestamp` field.\n\nIf the format is `semi_structured_text`, this field must match the name of the appropriate extraction in the `grok_pattern`.\nTherefore, for semi-structured text, it is best not to specify this parameter unless `grok_pattern` is also specified.\n\nFor structured text, if you specify this parameter, the field must exist within the text.\n\nIf this parameter is not specified, the structure finder makes a decision about which field (if any) is the primary timestamp field.\nFor structured text, it is not compulsory to have a timestamp in the text.", "x-found-in": "query" }, "timestamp_format": { "type": "string", "description": "The Java time format of the timestamp field in the text.\nOnly a subset of Java time format letter groups are supported:\n\n* `a`\n* `d`\n* `dd`\n* `EEE`\n* `EEEE`\n* `H`\n* `HH`\n* `h`\n* `M`\n* `MM`\n* `MMM`\n* `MMMM`\n* `mm`\n* `ss`\n* `XX`\n* `XXX`\n* `yy`\n* `yyyy`\n* `zzz`\n\nAdditionally `S` letter groups (fractional seconds) of length one to nine are supported providing they occur after `ss` and are separated from the `ss` by a period (`.`), comma (`,`), or colon (`:`).\nSpacing and punctuation is also permitted with the exception a question mark (`?`), newline, and carriage return, together with literal text enclosed in single quotes.\nFor example, `MM/dd HH.mm.ss,SSSSSS 'in' yyyy` is a valid override format.\n\nOne valuable use case for this parameter is when the format is semi-structured text, there are multiple timestamp formats in the text, and you know which format corresponds to the primary timestamp, but you do not want to specify the full `grok_pattern`.\nAnother is when the timestamp format is one that the structure finder does not consider by default.\n\nIf this parameter is not specified, the structure finder chooses the best format from a built-in set.\n\nIf the special value `null` is specified, the structure finder will not look for a primary timestamp in the text.\nWhen the format is semi-structured text, this will result in the structure finder treating the text as single-line messages.", "x-found-in": "query" } }, "required": ["field", "index"], "description": "Find the structure of a text field.\n\nFind the structure of a text field in an Elasticsearch index.\n\nThis API provides a starting point for extracting further information from log messages already ingested into Elasticsearch.\nFor example, if you have ingested data into a very simple index that has just `@timestamp` and message fields, you can use this API to see what common structure exists in the message field.\n\nThe response from the API contains:\n\n* Sample messages.\n* Statistics that reveal the most common values for all fields detected within the text and basic numeric statistics for numeric fields.\n* Information about the structure of the text, which is useful when you write ingest configurations to index it or similarly formatted text.\n* Appropriate mappings for an Elasticsearch index, which you could use to ingest the text.\n\nAll this information can be calculated by the structure finder with no guidance.\nHowever, you can optionally override some of the decisions about the text structure by specifying one or more query parameters.\n\nIf the structure finder produces unexpected results, specify the `explain` query parameter and an explanation will appear in the response.\nIt helps determine why the returned structure was chosen." }

package/lib/cjs/es/json/text_structure.find_message_structure.request.json

@@ -1 +1 @@
-{ "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "text_structure.find_message_structure", "type": "object", "properties": { "messages": { "type": "array", "items": { "type": "string" }, "description": "The list of messages you want to analyze.", "x-found-in": "body" }, "column_names": { "oneOf": [{ "type": "string" }, { "type": "array", "items": { "type": "string" } }], "description": "If the format is `delimited`, you can specify the column names in a comma-separated list.\nIf this parameter is not specified, the structure finder uses the column names from the header row of the text.\nIf the text does not have a header role, columns are named \"column1\", \"column2\", \"column3\", for example.", "x-found-in": "query" }, "delimiter": { "type": "string", "description": "If you the format is `delimited`, you can specify the character used to delimit the values in each row.\nOnly a single character is supported; the delimiter cannot have multiple characters.\nBy default, the API considers the following possibilities: comma, tab, semi-colon, and pipe (`|`).\nIn this default scenario, all rows must have the same number of fields for the delimited format to be detected.\nIf you specify a delimiter, up to 10% of the rows can have a different number of columns than the first row.", "x-found-in": "query" }, "ecs_compatibility": { "$ref": "./text_structure._types.json#/$defs/text_structure._types__EcsCompatibilityType", "description": "The mode of compatibility with ECS compliant Grok patterns.\nUse this parameter to specify whether to use ECS Grok patterns instead of legacy ones when the structure finder creates a Grok pattern.\nThis setting primarily has an impact when a whole message Grok pattern such as `%{CATALINALOG}` matches the input.\nIf the structure finder identifies a common structure but has no idea of meaning then generic field names such as `path`, `ipaddress`, `field1`, and `field2` are used in the `grok_pattern` output, with the intention that a user who knows the meanings rename these fields before using it.", "x-found-in": "query" }, "explain": { "type": "boolean", "description": "If this parameter is set to true, the response includes a field named `explanation`, which is an array of strings that indicate how the structure finder produced its result.", "x-found-in": "query" }, "format": { "$ref": "./text_structure._types.json#/$defs/text_structure._types__FormatType", "description": "The high level structure of the text.\nBy default, the API chooses the format.\nIn this default scenario, all rows must have the same number of fields for a delimited format to be detected.\nIf the format is `delimited` and the delimiter is not set, however, the API tolerates up to 5% of rows that have a different number of columns than the first row.", "x-found-in": "query" }, "grok_pattern": { "type": "string", "description": "If the format is `semi_structured_text`, you can specify a Grok pattern that is used to extract fields from every message in the text.\nThe name of the timestamp field in the Grok pattern must match what is specified in the `timestamp_field` parameter.\nIf that parameter is not specified, the name of the timestamp field in the Grok pattern must match \"timestamp\".\nIf `grok_pattern` is not specified, the structure finder creates a Grok pattern.", "x-found-in": "query" }, "quote": { "type": "string", "description": "If the format is `delimited`, you can specify the character used to quote the values in each row if they contain newlines or the delimiter character.\nOnly a single character is supported.\nIf this parameter is not specified, the default value is a double quote (`\"`).\nIf your delimited text format does not use quoting, a workaround is to set this argument to a character that does not appear anywhere in the sample.", "x-found-in": "query" }, "should_trim_fields": { "type": "boolean", "description": "If the format is `delimited`, you can specify whether values between delimiters should have whitespace trimmed from them.\nIf this parameter is not specified and the delimiter is pipe (`|`), the default value is true.\nOtherwise, the default value is `false`.", "x-found-in": "query" }, "should_parse_recursively": { "type": "boolean", "description": "If the format is `ndjson`, you can specify whether to parse nested JSON objects recursively.\nThe nested objects are parsed to a maximum depth equal to the default value of the `index.mapping.depth.limit` setting.\nAnything beyond that depth is parsed as an `object` type field.\nFor formats other than `ndjson`, this parameter is ignored.", "x-found-in": "query" }, "timeout": { "$ref": "./_types.json#/$defs/_types__Duration", "description": "The maximum amount of time that the structure analysis can take.\nIf the analysis is still running when the timeout expires, it will be stopped.", "x-found-in": "query" }, "timestamp_field": { "type": "string", "description": "The name of the field that contains the primary timestamp of each record in the text.\nIn particular, if the text was ingested into an index, this is the field that would be used to populate the `@timestamp` field.\n\nIf the format is `semi_structured_text`, this field must match the name of the appropriate extraction in the `grok_pattern`.\nTherefore, for semi-structured text, it is best not to specify this parameter unless `grok_pattern` is also specified.\n\nFor structured text, if you specify this parameter, the field must exist within the text.\n\nIf this parameter is not specified, the structure finder makes a decision about which field (if any) is the primary timestamp field.\nFor structured text, it is not compulsory to have a timestamp in the text.", "x-found-in": "query" }, "timestamp_format": { "type": "string", "description": "The Java time format of the timestamp field in the text.\nOnly a subset of Java time format letter groups are supported:\n\n* `a`\n* `d`\n* `dd`\n* `EEE`\n* `EEEE`\n* `H`\n* `HH`\n* `h`\n* `M`\n* `MM`\n* `MMM`\n* `MMMM`\n* `mm`\n* `ss`\n* `XX`\n* `XXX`\n* `yy`\n* `yyyy`\n* `zzz`\n\nAdditionally `S` letter groups (fractional seconds) of length one to nine are supported providing they occur after `ss` and are separated from the `ss` by a period (`.`), comma (`,`), or colon (`:`).\nSpacing and punctuation is also permitted with the exception a question mark (`?`), newline, and carriage return, together with literal text enclosed in single quotes.\nFor example, `MM/dd HH.mm.ss,SSSSSS 'in' yyyy` is a valid override format.\n\nOne valuable use case for this parameter is when the format is semi-structured text, there are multiple timestamp formats in the text, and you know which format corresponds to the primary timestamp, but you do not want to specify the full `grok_pattern`.\nAnother is when the timestamp format is one that the structure finder does not consider by default.\n\nIf this parameter is not specified, the structure finder chooses the best format from a built-in set.\n\nIf the special value `null` is specified, the structure finder will not look for a primary timestamp in the text.\nWhen the format is semi-structured text, this will result in the structure finder treating the text as single-line messages.", "x-found-in": "query" } }, "required": ["messages"], "description": "Find the structure of text messages.\n\nFind the structure of a list of text messages.\nThe messages must contain data that is suitable to be ingested into Elasticsearch.\n\nThis API provides a starting point for ingesting data into Elasticsearch in a format that is suitable for subsequent use with other Elastic Stack functionality.\nUse this API rather than the find text structure API if your input text has already been split up into separate messages by some other process.\n\nThe response from the API contains:\n\n* Sample messages.\n* Statistics that reveal the most common values for all fields detected within the text and basic numeric statistics for numeric fields.\n* Information about the structure of the text, which is useful when you write ingest configurations to index it or similarly formatted text.\nAppropriate mappings for an Elasticsearch index, which you could use to ingest the text.\n\nAll this information can be calculated by the structure finder with no guidance.\nHowever, you can optionally override some of the decisions about the text structure by specifying one or more query parameters.\n\nIf the structure finder produces unexpected results, specify the `explain` query parameter and an explanation will appear in the response.\nIt helps determine why the returned structure was chosen." }
+{ "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "text_structure.find_message_structure", "type": "object", "properties": { "column_names": { "anyOf": [{ "type": "string" }, { "type": "array", "items": { "type": "string" } }], "description": "If the format is `delimited`, you can specify the column names in a comma-separated list.\nIf this parameter is not specified, the structure finder uses the column names from the header row of the text.\nIf the text does not have a header role, columns are named \"column1\", \"column2\", \"column3\", for example.", "x-found-in": "query" }, "delimiter": { "type": "string", "description": "If you the format is `delimited`, you can specify the character used to delimit the values in each row.\nOnly a single character is supported; the delimiter cannot have multiple characters.\nBy default, the API considers the following possibilities: comma, tab, semi-colon, and pipe (`|`).\nIn this default scenario, all rows must have the same number of fields for the delimited format to be detected.\nIf you specify a delimiter, up to 10% of the rows can have a different number of columns than the first row.", "x-found-in": "query" }, "ecs_compatibility": { "$ref": "./text_structure._types.json#/$defs/text_structure._types__EcsCompatibilityType", "description": "The mode of compatibility with ECS compliant Grok patterns.\nUse this parameter to specify whether to use ECS Grok patterns instead of legacy ones when the structure finder creates a Grok pattern.\nThis setting primarily has an impact when a whole message Grok pattern such as `%{CATALINALOG}` matches the input.\nIf the structure finder identifies a common structure but has no idea of meaning then generic field names such as `path`, `ipaddress`, `field1`, and `field2` are used in the `grok_pattern` output, with the intention that a user who knows the meanings rename these fields before using it.", "x-found-in": "query" }, "explain": { "type": "boolean", "description": "If this parameter is set to true, the response includes a field named `explanation`, which is an array of strings that indicate how the structure finder produced its result.", "x-found-in": "query" }, "format": { "$ref": "./text_structure._types.json#/$defs/text_structure._types__FormatType", "description": "The high level structure of the text.\nBy default, the API chooses the format.\nIn this default scenario, all rows must have the same number of fields for a delimited format to be detected.\nIf the format is `delimited` and the delimiter is not set, however, the API tolerates up to 5% of rows that have a different number of columns than the first row.", "x-found-in": "query" }, "grok_pattern": { "type": "string", "description": "If the format is `semi_structured_text`, you can specify a Grok pattern that is used to extract fields from every message in the text.\nThe name of the timestamp field in the Grok pattern must match what is specified in the `timestamp_field` parameter.\nIf that parameter is not specified, the name of the timestamp field in the Grok pattern must match \"timestamp\".\nIf `grok_pattern` is not specified, the structure finder creates a Grok pattern.", "x-found-in": "query" }, "quote": { "type": "string", "description": "If the format is `delimited`, you can specify the character used to quote the values in each row if they contain newlines or the delimiter character.\nOnly a single character is supported.\nIf this parameter is not specified, the default value is a double quote (`\"`).\nIf your delimited text format does not use quoting, a workaround is to set this argument to a character that does not appear anywhere in the sample.", "x-found-in": "query" }, "should_trim_fields": { "type": "boolean", "description": "If the format is `delimited`, you can specify whether values between delimiters should have whitespace trimmed from them.\nIf this parameter is not specified and the delimiter is pipe (`|`), the default value is true.\nOtherwise, the default value is `false`.", "x-found-in": "query" }, "should_parse_recursively": { "type": "boolean", "description": "If the format is `ndjson`, you can specify whether to parse nested JSON objects recursively.\nThe nested objects are parsed to a maximum depth equal to the default value of the `index.mapping.depth.limit` setting.\nAnything beyond that depth is parsed as an `object` type field.\nFor formats other than `ndjson`, this parameter is ignored.", "x-found-in": "query" }, "timeout": { "$ref": "./_types.json#/$defs/_types__Duration", "description": "The maximum amount of time that the structure analysis can take.\nIf the analysis is still running when the timeout expires, it will be stopped.", "x-found-in": "query" }, "timestamp_field": { "type": "string", "description": "The name of the field that contains the primary timestamp of each record in the text.\nIn particular, if the text was ingested into an index, this is the field that would be used to populate the `@timestamp` field.\n\nIf the format is `semi_structured_text`, this field must match the name of the appropriate extraction in the `grok_pattern`.\nTherefore, for semi-structured text, it is best not to specify this parameter unless `grok_pattern` is also specified.\n\nFor structured text, if you specify this parameter, the field must exist within the text.\n\nIf this parameter is not specified, the structure finder makes a decision about which field (if any) is the primary timestamp field.\nFor structured text, it is not compulsory to have a timestamp in the text.", "x-found-in": "query" }, "timestamp_format": { "type": "string", "description": "The Java time format of the timestamp field in the text.\nOnly a subset of Java time format letter groups are supported:\n\n* `a`\n* `d`\n* `dd`\n* `EEE`\n* `EEEE`\n* `H`\n* `HH`\n* `h`\n* `M`\n* `MM`\n* `MMM`\n* `MMMM`\n* `mm`\n* `ss`\n* `XX`\n* `XXX`\n* `yy`\n* `yyyy`\n* `zzz`\n\nAdditionally `S` letter groups (fractional seconds) of length one to nine are supported providing they occur after `ss` and are separated from the `ss` by a period (`.`), comma (`,`), or colon (`:`).\nSpacing and punctuation is also permitted with the exception a question mark (`?`), newline, and carriage return, together with literal text enclosed in single quotes.\nFor example, `MM/dd HH.mm.ss,SSSSSS 'in' yyyy` is a valid override format.\n\nOne valuable use case for this parameter is when the format is semi-structured text, there are multiple timestamp formats in the text, and you know which format corresponds to the primary timestamp, but you do not want to specify the full `grok_pattern`.\nAnother is when the timestamp format is one that the structure finder does not consider by default.\n\nIf this parameter is not specified, the structure finder chooses the best format from a built-in set.\n\nIf the special value `null` is specified, the structure finder will not look for a primary timestamp in the text.\nWhen the format is semi-structured text, this will result in the structure finder treating the text as single-line messages.", "x-found-in": "query" }, "messages": { "type": "array", "items": { "type": "string" }, "description": "The list of messages you want to analyze.", "x-found-in": "body" } }, "required": ["messages"], "description": "Find the structure of text messages.\n\nFind the structure of a list of text messages.\nThe messages must contain data that is suitable to be ingested into Elasticsearch.\n\nThis API provides a starting point for ingesting data into Elasticsearch in a format that is suitable for subsequent use with other Elastic Stack functionality.\nUse this API rather than the find text structure API if your input text has already been split up into separate messages by some other process.\n\nThe response from the API contains:\n\n* Sample messages.\n* Statistics that reveal the most common values for all fields detected within the text and basic numeric statistics for numeric fields.\n* Information about the structure of the text, which is useful when you write ingest configurations to index it or similarly formatted text.\nAppropriate mappings for an Elasticsearch index, which you could use to ingest the text.\n\nAll this information can be calculated by the structure finder with no guidance.\nHowever, you can optionally override some of the decisions about the text structure by specifying one or more query parameters.\n\nIf the structure finder produces unexpected results, specify the `explain` query parameter and an explanation will appear in the response.\nIt helps determine why the returned structure was chosen." }