diff --git a/output/openapi/elasticsearch-openapi.json b/output/openapi/elasticsearch-openapi.json
index 281504ab63..686d8ca3ef 100644
--- a/output/openapi/elasticsearch-openapi.json
+++ b/output/openapi/elasticsearch-openapi.json
@@ -38754,6 +38754,122 @@
         "x-state": "Added in 7.12.0"
       }
     },
+    "/_snapshot/{repository}/_verify_integrity": {
+      "post": {
+        "tags": [
+          "snapshot"
+        ],
+        "summary": "Verify the repository integrity",
+        "description": "Verify the integrity of the contents of a snapshot repository.\n\nThis API enables you to perform a comprehensive check of the contents of a repository, looking for any anomalies in its data or metadata which might prevent you from restoring snapshots from the repository or which might cause future snapshot create or delete operations to fail.\n\nIf you suspect the integrity of the contents of one of your snapshot repositories, cease all write activity to this repository immediately, set its `read_only` option to `true`, and use this API to verify its integrity.\nUntil you do so:\n\n* It may not be possible to restore some snapshots from this repository.\n* Searchable snapshots may report errors when searched or may have unassigned shards.\n* Taking snapshots into this repository may fail or may appear to succeed but have created a snapshot which cannot be restored.\n* Deleting snapshots from this repository may fail or may appear to succeed but leave the underlying data on disk.\n* Continuing to write to the repository while it is in an invalid state may causing additional damage to its contents.\n\nIf the API finds any problems with the integrity of the contents of your repository, Elasticsearch will not be able to repair the damage.\nThe only way to bring the repository back into a fully working state after its contents have been damaged is by restoring its contents from a repository backup which was taken before the damage occurred.\nYou must also identify what caused the damage and take action to prevent it from happening again.\n\nIf you cannot restore a repository backup, register a new repository and use this for all future snapshot operations.\nIn some cases it may be possible to recover some of the contents of a damaged repository, either by restoring as many of its snapshots as needed and taking new snapshots of the restored data, or by using the reindex API to copy data from any searchable snapshots mounted from the damaged repository.\n\nAvoid all operations which write to the repository while the verify repository integrity API is running.\nIf something changes the repository contents while an integrity verification is running then Elasticsearch may incorrectly report having detected some anomalies in its contents due to the concurrent writes.\nIt may also incorrectly fail to report some anomalies that the concurrent writes prevented it from detecting.\n\nNOTE: This API is intended for exploratory use by humans. You should expect the request parameters and the response format to vary in future versions.\n\nNOTE: This API may not work correctly in a mixed-version cluster.\n\nThe default values for the parameters of this API are designed to limit the impact of the integrity verification on other activities in your cluster.\nFor instance, by default it will only use at most half of the `snapshot_meta` threads to verify the integrity of each snapshot, allowing other snapshot operations to use the other half of this thread pool.\nIf you modify these parameters to speed up the verification process, you risk disrupting other snapshot-related operations in your cluster.\nFor large repositories, consider setting up a separate single-node Elasticsearch cluster just for running the integrity verification API.\n\nThe response exposes implementation details of the analysis which may change from version to version.\nThe response body format is therefore not considered stable and may be different in newer versions.",
+        "operationId": "snapshot-repository-verify-integrity",
+        "parameters": [
+          {
+            "in": "path",
+            "name": "repository",
+            "description": "The name of the snapshot repository.",
+            "required": true,
+            "deprecated": false,
+            "schema": {
+              "$ref": "#/components/schemas/_types.Names"
+            },
+            "style": "simple"
+          },
+          {
+            "in": "query",
+            "name": "blob_thread_pool_concurrency",
+            "description": "If `verify_blob_contents` is `true`, this parameter specifies how many blobs to verify at once.",
+            "deprecated": false,
+            "schema": {
+              "type": "number"
+            },
+            "style": "form"
+          },
+          {
+            "in": "query",
+            "name": "index_snapshot_verification_concurrency",
+            "description": "The maximum number of index snapshots to verify concurrently within each index verification.",
+            "deprecated": false,
+            "schema": {
+              "type": "number"
+            },
+            "style": "form"
+          },
+          {
+            "in": "query",
+            "name": "index_verification_concurrency",
+            "description": "The number of indices to verify concurrently.\nThe default behavior is to use the entire `snapshot_meta` thread pool.",
+            "deprecated": false,
+            "schema": {
+              "type": "number"
+            },
+            "style": "form"
+          },
+          {
+            "in": "query",
+            "name": "max_bytes_per_sec",
+            "description": "If `verify_blob_contents` is `true`, this parameter specifies the maximum amount of data that Elasticsearch will read from the repository every second.",
+            "deprecated": false,
+            "schema": {
+              "type": "string"
+            },
+            "style": "form"
+          },
+          {
+            "in": "query",
+            "name": "max_failed_shard_snapshots",
+            "description": "The number of shard snapshot failures to track during integrity verification, in order to avoid excessive resource usage.\nIf your repository contains more than this number of shard snapshot failures, the verification will fail.",
+            "deprecated": false,
+            "schema": {
+              "type": "number"
+            },
+            "style": "form"
+          },
+          {
+            "in": "query",
+            "name": "meta_thread_pool_concurrency",
+            "description": "The maximum number of snapshot metadata operations to run concurrently.\nThe default behavior is to use at most half of the `snapshot_meta` thread pool at once.",
+            "deprecated": false,
+            "schema": {
+              "type": "number"
+            },
+            "style": "form"
+          },
+          {
+            "in": "query",
+            "name": "snapshot_verification_concurrency",
+            "description": "The number of snapshots to verify concurrently.\nThe default behavior is to use at most half of the `snapshot_meta` thread pool at once.",
+            "deprecated": false,
+            "schema": {
+              "type": "number"
+            },
+            "style": "form"
+          },
+          {
+            "in": "query",
+            "name": "verify_blob_contents",
+            "description": "Indicates whether to verify the checksum of every data blob in the repository.\nIf this feature is enabled, Elasticsearch will read the entire repository contents, which may be extremely slow and expensive.",
+            "deprecated": false,
+            "schema": {
+              "type": "boolean"
+            },
+            "style": "form"
+          }
+        ],
+        "responses": {
+          "200": {
+            "description": "",
+            "content": {
+              "application/json": {
+                "schema": {
+                  "type": "object"
+                }
+              }
+            }
+          }
+        },
+        "x-state": "Technical preview"
+      }
+    },
     "/_snapshot/{repository}/{snapshot}/_restore": {
       "post": {
         "tags": [
diff --git a/output/schema/schema.json b/output/schema/schema.json
index d756e8ae0a..7fe3ea66a5 100644
--- a/output/schema/schema.json
+++ b/output/schema/schema.json
@@ -21197,7 +21197,7 @@
         "stack": {
           "since": "8.16.0",
           "stability": "experimental",
-          "visibility": "private"
+          "visibility": "public"
         }
       },
       "description": "Verify the repository integrity.\nVerify the integrity of the contents of a snapshot repository.\n\nThis API enables you to perform a comprehensive check of the contents of a repository, looking for any anomalies in its data or metadata which might prevent you from restoring snapshots from the repository or which might cause future snapshot create or delete operations to fail.\n\nIf you suspect the integrity of the contents of one of your snapshot repositories, cease all write activity to this repository immediately, set its `read_only` option to `true`, and use this API to verify its integrity.\nUntil you do so:\n\n* It may not be possible to restore some snapshots from this repository.\n* Searchable snapshots may report errors when searched or may have unassigned shards.\n* Taking snapshots into this repository may fail or may appear to succeed but have created a snapshot which cannot be restored.\n* Deleting snapshots from this repository may fail or may appear to succeed but leave the underlying data on disk.\n* Continuing to write to the repository while it is in an invalid state may causing additional damage to its contents.\n\nIf the API finds any problems with the integrity of the contents of your repository, Elasticsearch will not be able to repair the damage.\nThe only way to bring the repository back into a fully working state after its contents have been damaged is by restoring its contents from a repository backup which was taken before the damage occurred.\nYou must also identify what caused the damage and take action to prevent it from happening again.\n\nIf you cannot restore a repository backup, register a new repository and use this for all future snapshot operations.\nIn some cases it may be possible to recover some of the contents of a damaged repository, either by restoring as many of its snapshots as needed and taking new snapshots of the restored data, or by using the reindex API to copy data from any searchable snapshots mounted from the damaged repository.\n\nAvoid all operations which write to the repository while the verify repository integrity API is running.\nIf something changes the repository contents while an integrity verification is running then Elasticsearch may incorrectly report having detected some anomalies in its contents due to the concurrent writes.\nIt may also incorrectly fail to report some anomalies that the concurrent writes prevented it from detecting.\n\nNOTE: This API is intended for exploratory use by humans. You should expect the request parameters and the response format to vary in future versions.\n\nNOTE: This API may not work correctly in a mixed-version cluster.\n\nThe default values for the parameters of this API are designed to limit the impact of the integrity verification on other activities in your cluster.\nFor instance, by default it will only use at most half of the `snapshot_meta` threads to verify the integrity of each snapshot, allowing other snapshot operations to use the other half of this thread pool.\nIf you modify these parameters to speed up the verification process, you risk disrupting other snapshot-related operations in your cluster.\nFor large repositories, consider setting up a separate single-node Elasticsearch cluster just for running the integrity verification API.\n\nThe response exposes implementation details of the analysis which may change from version to version.\nThe response body format is therefore not considered stable and may be different in newer versions.",
diff --git a/specification/snapshot/repository_verify_integrity/SnapshotRepositoryVerifyIntegrityRequest.ts b/specification/snapshot/repository_verify_integrity/SnapshotRepositoryVerifyIntegrityRequest.ts
index 88d648e7cc..5e3eef9233 100644
--- a/specification/snapshot/repository_verify_integrity/SnapshotRepositoryVerifyIntegrityRequest.ts
+++ b/specification/snapshot/repository_verify_integrity/SnapshotRepositoryVerifyIntegrityRequest.ts
@@ -59,7 +59,7 @@ import { integer } from '@_types/Numeric'
  * The response exposes implementation details of the analysis which may change from version to version.
  * The response body format is therefore not considered stable and may be different in newer versions.
  * @rest_spec_name snapshot.repository_verify_integrity
- * @availability stack since=8.16.0 stability=experimental visibility=private
+ * @availability stack since=8.16.0 stability=experimental visibility=public
  * @cluster_privileges manage
  * @doc_id snapshot-repo-verify-integrity
  */