@tapis/tapis-typescript-sk 0.0.2 → 0.0.3

package/dist/apis/VaultApi.d.ts

@@ -1,8 +1,8 @@
 /**
  * Tapis Security API
- * The Tapis Security API provides access to the Tapis Security Kernel authorization and secrets facilities.
+ * The Tapis Security API provides for management of Security Kernel (SK) role-based authorization and secrets resources.
  *
- * The version of the OpenAPI document: 0.1
+ * The version of the OpenAPI document: 1.8.2
  * Contact: cicsupport@tacc.utexas.edu
  *
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -10,12 +10,11 @@
  * Do not edit the class manually.
  */
 import * as runtime from '../runtime';
-import { ReqValidateServicePwd, ReqVersions, ReqWriteSecret, RespAuthorized, RespBasic, RespSecret, RespSecretList, RespSecretMeta, RespSecretVersionMetadata, RespVersions } from '../models';
+import type { ReqValidatePwd, ReqVersions, ReqWriteSecret, RespAuthorized, RespBasic, RespSecret, RespSecretList, RespSecretMeta, RespSecretVersionMetadata, RespVersions } from '../models/index';
 export interface DeleteSecretRequest {
     secretType: string;
     secretName: string;
     reqVersions: ReqVersions;
-    pretty?: boolean;
     sysid?: string;
     sysuser?: string;
     keytype?: string;
@@ -27,7 +26,6 @@ export interface DestroySecretRequest {
     secretType: string;
     secretName: string;
     reqVersions: ReqVersions;
-    pretty?: boolean;
     sysid?: string;
     sysuser?: string;
     keytype?: string;
@@ -40,7 +38,6 @@ export interface DestroySecretMetaRequest {
     secretName: string;
     tenant?: string;
     user?: string;
-    pretty?: boolean;
     sysid?: string;
     sysuser?: string;
     keytype?: string;
@@ -52,7 +49,6 @@ export interface ListSecretMetaRequest {
     secretType: string;
     tenant?: string;
     user?: string;
-    pretty?: boolean;
     sysid?: string;
     sysuser?: string;
     keytype?: string;
@@ -66,7 +62,6 @@ export interface ReadSecretRequest {
     tenant?: string;
     user?: string;
     version?: number;
-    pretty?: boolean;
     sysid?: string;
     sysuser?: string;
     keytype?: string;
@@ -79,7 +74,6 @@ export interface ReadSecretMetaRequest {
     secretName: string;
     tenant?: string;
     user?: string;
-    pretty?: boolean;
     sysid?: string;
     sysuser?: string;
     keytype?: string;
@@ -91,7 +85,6 @@ export interface UndeleteSecretRequest {
     secretType: string;
     secretName: string;
     reqVersions: ReqVersions;
-    pretty?: boolean;
     sysid?: string;
     sysuser?: string;
     keytype?: string;
@@ -101,14 +94,16 @@ export interface UndeleteSecretRequest {
 }
 export interface ValidateServicePasswordRequest {
     secretName: string;
-    reqValidateServicePwd: ReqValidateServicePwd;
-    pretty?: boolean;
+    reqValidatePwd: ReqValidatePwd;
+}
+export interface ValidateSiteAdminPasswordRequest {
+    secretName: string;
+    reqValidatePwd: ReqValidatePwd;
 }
 export interface WriteSecretRequest {
     secretType: string;
     secretName: string;
     reqWriteSecret: ReqWriteSecret;
-    pretty?: boolean;
     sysid?: string;
     sysuser?: string;
     keytype?: string;
@@ -121,75 +116,83 @@ export interface WriteSecretRequest {
  */
 export declare class VaultApi extends runtime.BaseAPI {
     /**
-     * Soft delete one or more versions of a secret. Each version can be deleted individually or as part of a group specified in the input array. Deletion can be reversed using the *secret/undelete/{secretName}* endpoint, which make this a _soft_ deletion operation.  The input versions array is interpreted as follows:     * [-] - empty = delete all versions    * [0] - zero = delete only the latest version    * [1, 3, ...] - list = delete the specified versions  A valid tenant and user must also be specified in the body.  ### Naming Secrets Secrets can be arranged hierarchically by using the \"+\" characters in the *secretName*.  These characters will be converted to slashes upon receipt, allowing secrets to be arranged in folders.  A secret is assigned a path name constructed from the *secretType* and *secretName* path parameters and, optionally, from query parameters determined by the *secretType*. Each *secretType* determines a specific transformation from the url path to a path in the vault.  The *secretType* may require certain query parameters to be present on the request in order to construct the vault path.  See the next section for details.  ### Secret Types The list below documents each *secretType* and their applicable query parameters. Highlighted parameter names indicate required parameters. When present, default values are listed first and also highlighted.    - **system**     - *sysid*: the unique system id     - *sysuser*: the accessing user (except when keytype=cert)     - keytype: *sshkey* | password | accesskey | cert   - **dbcred**     - *dbhost*:  the DBMS hostname, IP address or alias     - *dbname*:  the database name or alias     - *dbservice*: service name   - **jwtsigning** - *no query parameters*   - **user** - *no query parameters*   - **service** - *no query parameters* ### Authorization Requestors are authorized based on the secret type specified in the URL path.  The following authorizations are enforced:  - system: limited to the systems service - dbcred: any service - jwtsigning: limited to the tokens service - user: any user - service: any service
+     * Soft delete one or more versions of a secret. Each version can be deleted individually or as part of a group specified in the input array. Deletion can be reversed using the *secret/undelete/{secretName}* endpoint, which make this a _soft_ deletion operation.  The input versions array is interpreted as follows:     * [-] - empty = delete all versions    * [0] - zero = delete only the latest version    * [1, 3, ...] - list = delete the specified versions  A valid tenant and user must also be specified in the body.  ### Naming Secrets Secrets can be arranged hierarchically by using the \"+\" characters in the *secretName*. These characters will be converted to slashes upon receipt, allowing secrets to be arranged in folders.  A secret is assigned a path name constructed from the *secretType* and *secretName* path parameters and, optionally, from query parameters determined by the *secretType*. Each *secretType* determines a specific transformation from the url path to a path in the vault. The *secretType* may require certain query parameters to be present on the request in order to construct the vault path. See the next section for details.  ### Secret Types The list below documents each *secretType* and their applicable query parameters. Highlighted parameter names indicate required parameters. When present, default values are listed first and also highlighted.    - **system**     - *sysid*: the unique system id     - *sysuser*: the accessing user (except when keytype=cert)     - keytype: *sshkey* | password | accesskey | token | tmskey | cert   - **dbcred**     - *dbhost*:  the DBMS hostname, IP address or alias     - *dbname*:  the database name or alias     - *dbservice*: service name   - **jwtsigning** - *no query parameters*   - **user** - *no query parameters*   - **service** - *no query parameters*  ### Authorization Requestors are authorized based on the secret type specified in the URL path. The following authorizations are enforced:  - system: limited to the systems service - dbcred: any service - jwtsigning: limited to the tokens service - user: any user - service: any service
+     */
+    deleteSecretRaw(requestParameters: DeleteSecretRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<RespVersions>>;
+    /**
+     * Soft delete one or more versions of a secret. Each version can be deleted individually or as part of a group specified in the input array. Deletion can be reversed using the *secret/undelete/{secretName}* endpoint, which make this a _soft_ deletion operation.  The input versions array is interpreted as follows:     * [-] - empty = delete all versions    * [0] - zero = delete only the latest version    * [1, 3, ...] - list = delete the specified versions  A valid tenant and user must also be specified in the body.  ### Naming Secrets Secrets can be arranged hierarchically by using the \"+\" characters in the *secretName*. These characters will be converted to slashes upon receipt, allowing secrets to be arranged in folders.  A secret is assigned a path name constructed from the *secretType* and *secretName* path parameters and, optionally, from query parameters determined by the *secretType*. Each *secretType* determines a specific transformation from the url path to a path in the vault. The *secretType* may require certain query parameters to be present on the request in order to construct the vault path. See the next section for details.  ### Secret Types The list below documents each *secretType* and their applicable query parameters. Highlighted parameter names indicate required parameters. When present, default values are listed first and also highlighted.    - **system**     - *sysid*: the unique system id     - *sysuser*: the accessing user (except when keytype=cert)     - keytype: *sshkey* | password | accesskey | token | tmskey | cert   - **dbcred**     - *dbhost*:  the DBMS hostname, IP address or alias     - *dbname*:  the database name or alias     - *dbservice*: service name   - **jwtsigning** - *no query parameters*   - **user** - *no query parameters*   - **service** - *no query parameters*  ### Authorization Requestors are authorized based on the secret type specified in the URL path. The following authorizations are enforced:  - system: limited to the systems service - dbcred: any service - jwtsigning: limited to the tokens service - user: any user - service: any service
+     */
+    deleteSecret(requestParameters: DeleteSecretRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<RespVersions>;
+    /**
+     * Destroy one or more versions of a secret. Destroy implements a hard delete which delete that cannot be undone. It does not, however, remove any metadata associated with the secret.  The input versions array is interpreted as follows:     * [-] - empty = destroy all versions    * [0] - zero = destroy only the latest version    * [1, 3, ...] - list = destroy the specified versions  A valid tenant and user must be specified in the body.  ### Naming Secrets Secrets can be arranged hierarchically by using the \"+\" characters in the *secretName*. These characters will be converted to slashes upon receipt, allowing secrets to be arranged in folders.  A secret is assigned a path name constructed from the *secretType* and *secretName* path parameters and, optionally, from query parameters determined by the *secretType*. Each *secretType* determines a specific transformation from the url path to a path in the vault. The *secretType* may require certain query parameters to be present on the request in order to construct the vault path. See the next section for details.  ### Secret Types The list below documents each *secretType* and their applicable query parameters. Highlighted parameter names indicate required parameters. When present, default values are listed first and also highlighted.    - **system**     - *sysid*: the unique system id     - *sysuser*: the accessing user (except when keytype=cert)     - keytype: *sshkey* | password | accesskey | token | tmskey | cert   - **dbcred**     - *dbhost*:  the DBMS hostname, IP address or alias     - *dbname*:  the database name or alias     - *dbservice*: service name   - **jwtsigning** - *no query parameters*   - **user** - *no query parameters*   - **service** - *no query parameters*  ### Authorization Requestors are authorized based on the secret type specified in the URL path. The following authorizations are enforced:  - system: limited to the systems service - dbcred: any service - jwtsigning: limited to the tokens service - user: any user - service: any service
      */
-    deleteSecretRaw(requestParameters: DeleteSecretRequest, initOverrides?: RequestInit): Promise<runtime.ApiResponse<RespVersions>>;
+    destroySecretRaw(requestParameters: DestroySecretRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<RespVersions>>;
     /**
-     * Soft delete one or more versions of a secret. Each version can be deleted individually or as part of a group specified in the input array. Deletion can be reversed using the *secret/undelete/{secretName}* endpoint, which make this a _soft_ deletion operation.  The input versions array is interpreted as follows:     * [-] - empty = delete all versions    * [0] - zero = delete only the latest version    * [1, 3, ...] - list = delete the specified versions  A valid tenant and user must also be specified in the body.  ### Naming Secrets Secrets can be arranged hierarchically by using the \"+\" characters in the *secretName*.  These characters will be converted to slashes upon receipt, allowing secrets to be arranged in folders.  A secret is assigned a path name constructed from the *secretType* and *secretName* path parameters and, optionally, from query parameters determined by the *secretType*. Each *secretType* determines a specific transformation from the url path to a path in the vault.  The *secretType* may require certain query parameters to be present on the request in order to construct the vault path.  See the next section for details.  ### Secret Types The list below documents each *secretType* and their applicable query parameters. Highlighted parameter names indicate required parameters. When present, default values are listed first and also highlighted.    - **system**     - *sysid*: the unique system id     - *sysuser*: the accessing user (except when keytype=cert)     - keytype: *sshkey* | password | accesskey | cert   - **dbcred**     - *dbhost*:  the DBMS hostname, IP address or alias     - *dbname*:  the database name or alias     - *dbservice*: service name   - **jwtsigning** - *no query parameters*   - **user** - *no query parameters*   - **service** - *no query parameters* ### Authorization Requestors are authorized based on the secret type specified in the URL path.  The following authorizations are enforced:  - system: limited to the systems service - dbcred: any service - jwtsigning: limited to the tokens service - user: any user - service: any service
+     * Destroy one or more versions of a secret. Destroy implements a hard delete which delete that cannot be undone. It does not, however, remove any metadata associated with the secret.  The input versions array is interpreted as follows:     * [-] - empty = destroy all versions    * [0] - zero = destroy only the latest version    * [1, 3, ...] - list = destroy the specified versions  A valid tenant and user must be specified in the body.  ### Naming Secrets Secrets can be arranged hierarchically by using the \"+\" characters in the *secretName*. These characters will be converted to slashes upon receipt, allowing secrets to be arranged in folders.  A secret is assigned a path name constructed from the *secretType* and *secretName* path parameters and, optionally, from query parameters determined by the *secretType*. Each *secretType* determines a specific transformation from the url path to a path in the vault. The *secretType* may require certain query parameters to be present on the request in order to construct the vault path. See the next section for details.  ### Secret Types The list below documents each *secretType* and their applicable query parameters. Highlighted parameter names indicate required parameters. When present, default values are listed first and also highlighted.    - **system**     - *sysid*: the unique system id     - *sysuser*: the accessing user (except when keytype=cert)     - keytype: *sshkey* | password | accesskey | token | tmskey | cert   - **dbcred**     - *dbhost*:  the DBMS hostname, IP address or alias     - *dbname*:  the database name or alias     - *dbservice*: service name   - **jwtsigning** - *no query parameters*   - **user** - *no query parameters*   - **service** - *no query parameters*  ### Authorization Requestors are authorized based on the secret type specified in the URL path. The following authorizations are enforced:  - system: limited to the systems service - dbcred: any service - jwtsigning: limited to the tokens service - user: any user - service: any service
      */
-    deleteSecret(requestParameters: DeleteSecretRequest, initOverrides?: RequestInit): Promise<RespVersions>;
+    destroySecret(requestParameters: DestroySecretRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<RespVersions>;
     /**
-     * Destroy one or more versions of a secret. Destroy implements a hard delete which delete that cannot be undone. It does not, however, remove any metadata associated with the secret.  The input versions array is interpreted as follows:     * [-] - empty = destroy all versions    * [0] - zero = destroy only the latest version    * [1, 3, ...] - list = destroy the specified versions  A valid tenant and user must be specified in the body.  ### Naming Secrets Secrets can be arranged hierarchically by using the \"+\" characters in the *secretName*.  These characters will be converted to slashes upon receipt, allowing secrets to be arranged in folders.  A secret is assigned a path name constructed from the *secretType* and *secretName* path parameters and, optionally, from query parameters determined by the *secretType*. Each *secretType* determines a specific transformation from the url path to a path in the vault.  The *secretType* may require certain query parameters to be present on the request in order to construct the vault path.  See the next section for details.  ### Secret Types The list below documents each *secretType* and their applicable query parameters. Highlighted parameter names indicate required parameters. When present, default values are listed first and also highlighted.    - **system**     - *sysid*: the unique system id     - *sysuser*: the accessing user (except when keytype=cert)     - keytype: *sshkey* | password | accesskey | cert   - **dbcred**     - *dbhost*:  the DBMS hostname, IP address or alias     - *dbname*:  the database name or alias     - *dbservice*: service name   - **jwtsigning** - *no query parameters*   - **user** - *no query parameters*   - **service** - *no query parameters* ### Authorization Requestors are authorized based on the secret type specified in the URL path.  The following authorizations are enforced:  - system: limited to the systems service - dbcred: any service - jwtsigning: limited to the tokens service - user: any user - service: any service
+     * Erase all traces of a secret: its key, all versions of its value and all its metadata. Specifying a folder erases all secrets in that folder.  A valid tenant and user must be specified as query parameters.  ### Naming Secrets Secrets can be arranged hierarchically by using the \"+\" characters in the *secretName*. These characters will be converted to slashes upon receipt, allowing secrets to be arranged in folders.  A secret is assigned a path name constructed from the *secretType* and *secretName* path parameters and, optionally, from query parameters determined by the *secretType*. Each *secretType* determines a specific transformation from the url path to a path in the vault. The *secretType* may require certain query parameters to be present on the request in order to construct the vault path. See the next section for details.  ### Secret Types The list below documents each *secretType* and their applicable query parameters. Highlighted parameter names indicate required parameters. When present, default values are listed first and also highlighted.    - **system**     - *sysid*: the unique system id     - *sysuser*: the accessing user (except when keytype=cert)     - keytype: *sshkey* | password | accesskey | token | tmskey | cert   - **dbcred**     - *dbhost*:  the DBMS hostname, IP address or alias     - *dbname*:  the database name or alias     - *dbservice*: service name   - **jwtsigning** - *no query parameters*   - **user** - *no query parameters*   - **service** - *no query parameters*  ### Authorization Requestors are authorized based on the secret type specified in the URL path. The following authorizations are enforced:  - system: limited to the systems service - dbcred: any service - jwtsigning: limited to the tokens service - user: any user - service: any service
      */
-    destroySecretRaw(requestParameters: DestroySecretRequest, initOverrides?: RequestInit): Promise<runtime.ApiResponse<RespVersions>>;
+    destroySecretMetaRaw(requestParameters: DestroySecretMetaRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<RespBasic>>;
     /**
-     * Destroy one or more versions of a secret. Destroy implements a hard delete which delete that cannot be undone. It does not, however, remove any metadata associated with the secret.  The input versions array is interpreted as follows:     * [-] - empty = destroy all versions    * [0] - zero = destroy only the latest version    * [1, 3, ...] - list = destroy the specified versions  A valid tenant and user must be specified in the body.  ### Naming Secrets Secrets can be arranged hierarchically by using the \"+\" characters in the *secretName*.  These characters will be converted to slashes upon receipt, allowing secrets to be arranged in folders.  A secret is assigned a path name constructed from the *secretType* and *secretName* path parameters and, optionally, from query parameters determined by the *secretType*. Each *secretType* determines a specific transformation from the url path to a path in the vault.  The *secretType* may require certain query parameters to be present on the request in order to construct the vault path.  See the next section for details.  ### Secret Types The list below documents each *secretType* and their applicable query parameters. Highlighted parameter names indicate required parameters. When present, default values are listed first and also highlighted.    - **system**     - *sysid*: the unique system id     - *sysuser*: the accessing user (except when keytype=cert)     - keytype: *sshkey* | password | accesskey | cert   - **dbcred**     - *dbhost*:  the DBMS hostname, IP address or alias     - *dbname*:  the database name or alias     - *dbservice*: service name   - **jwtsigning** - *no query parameters*   - **user** - *no query parameters*   - **service** - *no query parameters* ### Authorization Requestors are authorized based on the secret type specified in the URL path.  The following authorizations are enforced:  - system: limited to the systems service - dbcred: any service - jwtsigning: limited to the tokens service - user: any user - service: any service
+     * Erase all traces of a secret: its key, all versions of its value and all its metadata. Specifying a folder erases all secrets in that folder.  A valid tenant and user must be specified as query parameters.  ### Naming Secrets Secrets can be arranged hierarchically by using the \"+\" characters in the *secretName*. These characters will be converted to slashes upon receipt, allowing secrets to be arranged in folders.  A secret is assigned a path name constructed from the *secretType* and *secretName* path parameters and, optionally, from query parameters determined by the *secretType*. Each *secretType* determines a specific transformation from the url path to a path in the vault. The *secretType* may require certain query parameters to be present on the request in order to construct the vault path. See the next section for details.  ### Secret Types The list below documents each *secretType* and their applicable query parameters. Highlighted parameter names indicate required parameters. When present, default values are listed first and also highlighted.    - **system**     - *sysid*: the unique system id     - *sysuser*: the accessing user (except when keytype=cert)     - keytype: *sshkey* | password | accesskey | token | tmskey | cert   - **dbcred**     - *dbhost*:  the DBMS hostname, IP address or alias     - *dbname*:  the database name or alias     - *dbservice*: service name   - **jwtsigning** - *no query parameters*   - **user** - *no query parameters*   - **service** - *no query parameters*  ### Authorization Requestors are authorized based on the secret type specified in the URL path. The following authorizations are enforced:  - system: limited to the systems service - dbcred: any service - jwtsigning: limited to the tokens service - user: any user - service: any service
      */
-    destroySecret(requestParameters: DestroySecretRequest, initOverrides?: RequestInit): Promise<RespVersions>;
+    destroySecretMeta(requestParameters: DestroySecretMetaRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<RespBasic>;
     /**
-     * Erase all traces of a secret: its key, all versions of its value and all its metadata. Specifying a folder erases all secrets in that folder.  A valid tenant and user must be specified as query parameters.  ### Naming Secrets Secrets can be arranged hierarchically by using the \"+\" characters in the *secretName*.  These characters will be converted to slashes upon receipt, allowing secrets to be arranged in folders.  A secret is assigned a path name constructed from the *secretType* and *secretName* path parameters and, optionally, from query parameters determined by the *secretType*. Each *secretType* determines a specific transformation from the url path to a path in the vault.  The *secretType* may require certain query parameters to be present on the request in order to construct the vault path.  See the next section for details.  ### Secret Types The list below documents each *secretType* and their applicable query parameters. Highlighted parameter names indicate required parameters. When present, default values are listed first and also highlighted.    - **system**     - *sysid*: the unique system id     - *sysuser*: the accessing user (except when keytype=cert)     - keytype: *sshkey* | password | accesskey | cert   - **dbcred**     - *dbhost*:  the DBMS hostname, IP address or alias     - *dbname*:  the database name or alias     - *dbservice*: service name   - **jwtsigning** - *no query parameters*   - **user** - *no query parameters*   - **service** - *no query parameters* ### Authorization Requestors are authorized based on the secret type specified in the URL path.  The following authorizations are enforced:  - system: limited to the systems service - dbcred: any service - jwtsigning: limited to the tokens service - user: any user - service: any service
+     * List the secret names at the specified path. The path must represent a folder, not an actual secret name. If the path does not have a trailing slash one will be inserted. Secret names should not encode private information.  A valid tenant and user must be specified as query parameters.  ### Naming Secrets Secrets can be arranged hierarchically by using the \"+\" characters in the secret name. These characters will be converted to slashes upon receipt, allowing secrets to be arranged in folders.  A secret is assigned a path name constructed from the *secretType* path parameter and, optionally, from query parameters determined by the *secretType*. Each *secretType* determines a specific transformation from the url path to a path in the vault. The *secretType* may require certain query parameters to be present on the request in order to construct the vault path. See the next section for details.  ### Secret Types The list below documents each *secretType* and their applicable query parameters. Highlighted parameter names indicate required parameters. When present, default values are listed first and also highlighted.    - **system**     - *sysid*: the unique system id     - *sysuser*: the accessing user (except when keytype=cert)     - keytype: *sshkey* | password | accesskey | token | tmskey | cert   - **dbcred**     - *dbhost*:  the DBMS hostname, IP address or alias     - *dbname*:  the database name or alias     - *dbservice*: service name   - **jwtsigning** - *no query parameters*   - **user** - *no query parameters*   - **service** - *no query parameters*  ### Authorization Requestors are authorized based on the secret type specified in the URL path. The following authorizations are enforced:  - system: limited to the systems service - dbcred: any service - jwtsigning: limited to the tokens service - user: any user - service: any service
      */
-    destroySecretMetaRaw(requestParameters: DestroySecretMetaRequest, initOverrides?: RequestInit): Promise<runtime.ApiResponse<RespBasic>>;
+    listSecretMetaRaw(requestParameters: ListSecretMetaRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<RespSecretList>>;
     /**
-     * Erase all traces of a secret: its key, all versions of its value and all its metadata. Specifying a folder erases all secrets in that folder.  A valid tenant and user must be specified as query parameters.  ### Naming Secrets Secrets can be arranged hierarchically by using the \"+\" characters in the *secretName*.  These characters will be converted to slashes upon receipt, allowing secrets to be arranged in folders.  A secret is assigned a path name constructed from the *secretType* and *secretName* path parameters and, optionally, from query parameters determined by the *secretType*. Each *secretType* determines a specific transformation from the url path to a path in the vault.  The *secretType* may require certain query parameters to be present on the request in order to construct the vault path.  See the next section for details.  ### Secret Types The list below documents each *secretType* and their applicable query parameters. Highlighted parameter names indicate required parameters. When present, default values are listed first and also highlighted.    - **system**     - *sysid*: the unique system id     - *sysuser*: the accessing user (except when keytype=cert)     - keytype: *sshkey* | password | accesskey | cert   - **dbcred**     - *dbhost*:  the DBMS hostname, IP address or alias     - *dbname*:  the database name or alias     - *dbservice*: service name   - **jwtsigning** - *no query parameters*   - **user** - *no query parameters*   - **service** - *no query parameters* ### Authorization Requestors are authorized based on the secret type specified in the URL path.  The following authorizations are enforced:  - system: limited to the systems service - dbcred: any service - jwtsigning: limited to the tokens service - user: any user - service: any service
+     * List the secret names at the specified path. The path must represent a folder, not an actual secret name. If the path does not have a trailing slash one will be inserted. Secret names should not encode private information.  A valid tenant and user must be specified as query parameters.  ### Naming Secrets Secrets can be arranged hierarchically by using the \"+\" characters in the secret name. These characters will be converted to slashes upon receipt, allowing secrets to be arranged in folders.  A secret is assigned a path name constructed from the *secretType* path parameter and, optionally, from query parameters determined by the *secretType*. Each *secretType* determines a specific transformation from the url path to a path in the vault. The *secretType* may require certain query parameters to be present on the request in order to construct the vault path. See the next section for details.  ### Secret Types The list below documents each *secretType* and their applicable query parameters. Highlighted parameter names indicate required parameters. When present, default values are listed first and also highlighted.    - **system**     - *sysid*: the unique system id     - *sysuser*: the accessing user (except when keytype=cert)     - keytype: *sshkey* | password | accesskey | token | tmskey | cert   - **dbcred**     - *dbhost*:  the DBMS hostname, IP address or alias     - *dbname*:  the database name or alias     - *dbservice*: service name   - **jwtsigning** - *no query parameters*   - **user** - *no query parameters*   - **service** - *no query parameters*  ### Authorization Requestors are authorized based on the secret type specified in the URL path. The following authorizations are enforced:  - system: limited to the systems service - dbcred: any service - jwtsigning: limited to the tokens service - user: any user - service: any service
      */
-    destroySecretMeta(requestParameters: DestroySecretMetaRequest, initOverrides?: RequestInit): Promise<RespBasic>;
+    listSecretMeta(requestParameters: ListSecretMetaRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<RespSecretList>;
     /**
-     * List the secret names at the specified path. The path must represent a folder, not an actual secret name. If the path does not have a trailing slash one will be inserted. Secret names should not encode private information.  A valid tenant and user must be specified as query parameters.  ### Naming Secrets Secrets can be arranged hierarchically by using the \"+\" characters in the secret name.  These characters will be converted to slashes upon receipt, allowing secrets to be arranged in folders.  A secret is assigned a path name constructed from the *secretType* path parameter and, optionally, from query parameters determined by the *secretType*. Each *secretType* determines a specific transformation from the url path to a path in the vault.  The *secretType* may require certain query parameters to be present on the request in order to construct the vault path.  See the next section for details.  ### Secret Types The list below documents each *secretType* and their applicable query parameters. Highlighted parameter names indicate required parameters. When present, default values are listed first and also highlighted.    - **system**     - *sysid*: the unique system id     - *sysuser*: the accessing user (except when keytype=cert)     - keytype: *sshkey* | password | accesskey | cert   - **dbcred**     - *dbhost*:  the DBMS hostname, IP address or alias     - *dbname*:  the database name or alias     - *dbservice*: service name   - **jwtsigning** - *no query parameters*   - **user** - *no query parameters*   - **service** - *no query parameters* ### Authorization Requestors are authorized based on the secret type specified in the URL path.  The following authorizations are enforced:  - system: limited to the systems service - dbcred: any service - jwtsigning: limited to the tokens service - user: any user - service: any service
+     * Read a versioned secret. By default, the latest version of the secret is read. If the *version* query parameter is specified then that version of the secret is read. The *version* parameter should be passed as an integer with zero indicating the latest version of the secret. A NOT FOUND status code is returned if the secret version does not exist or if it\'s deleted or destroyed.  The response object includes the map of zero or more key/value pairs and metadata that describes the secret. The metadata includes which version of the secret was returned.  A valid tenant and user must be specified as query parameters.  ### Naming Secrets Secrets can be arranged hierarchically by using the \"+\" characters in the *secretName*. These characters will be converted to slashes upon receipt, allowing secrets to be arranged in folders.  A secret is assigned a path name constructed from the *secretType* and *secretName* path parameters and, optionally, from query parameters determined by the *secretType*. Each *secretType* determines a specific transformation from the url path to a path in the vault. The *secretType* may require certain query parameters to be present on the request in order to construct the vault path. See the next section for details.  ### Secret Types The list below documents each *secretType* and their applicable query parameters. Highlighted parameter names indicate required parameters. When present, default values are listed first and also highlighted.    - **system**     - *sysid*: the unique system id     - *sysuser*: the accessing user (except when keytype=cert)     - keytype: *sshkey* | password | accesskey | token | tmskey | cert   - **dbcred**     - *dbhost*:  the DBMS hostname, IP address or alias     - *dbname*:  the database name or alias     - *dbservice*: service name   - **jwtsigning** - *no query parameters*   - **user** - *no query parameters*   - **service** - *no query parameters*  ### Authorization Requestors are authorized based on the secret type specified in the URL path. The following authorizations are enforced:  - system: limited to the systems service - dbcred: any service - jwtsigning: limited to the tokens service - user: any user - service: any service
      */
-    listSecretMetaRaw(requestParameters: ListSecretMetaRequest, initOverrides?: RequestInit): Promise<runtime.ApiResponse<RespSecretList>>;
+    readSecretRaw(requestParameters: ReadSecretRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<RespSecret>>;
     /**
-     * List the secret names at the specified path. The path must represent a folder, not an actual secret name. If the path does not have a trailing slash one will be inserted. Secret names should not encode private information.  A valid tenant and user must be specified as query parameters.  ### Naming Secrets Secrets can be arranged hierarchically by using the \"+\" characters in the secret name.  These characters will be converted to slashes upon receipt, allowing secrets to be arranged in folders.  A secret is assigned a path name constructed from the *secretType* path parameter and, optionally, from query parameters determined by the *secretType*. Each *secretType* determines a specific transformation from the url path to a path in the vault.  The *secretType* may require certain query parameters to be present on the request in order to construct the vault path.  See the next section for details.  ### Secret Types The list below documents each *secretType* and their applicable query parameters. Highlighted parameter names indicate required parameters. When present, default values are listed first and also highlighted.    - **system**     - *sysid*: the unique system id     - *sysuser*: the accessing user (except when keytype=cert)     - keytype: *sshkey* | password | accesskey | cert   - **dbcred**     - *dbhost*:  the DBMS hostname, IP address or alias     - *dbname*:  the database name or alias     - *dbservice*: service name   - **jwtsigning** - *no query parameters*   - **user** - *no query parameters*   - **service** - *no query parameters* ### Authorization Requestors are authorized based on the secret type specified in the URL path.  The following authorizations are enforced:  - system: limited to the systems service - dbcred: any service - jwtsigning: limited to the tokens service - user: any user - service: any service
+     * Read a versioned secret. By default, the latest version of the secret is read. If the *version* query parameter is specified then that version of the secret is read. The *version* parameter should be passed as an integer with zero indicating the latest version of the secret. A NOT FOUND status code is returned if the secret version does not exist or if it\'s deleted or destroyed.  The response object includes the map of zero or more key/value pairs and metadata that describes the secret. The metadata includes which version of the secret was returned.  A valid tenant and user must be specified as query parameters.  ### Naming Secrets Secrets can be arranged hierarchically by using the \"+\" characters in the *secretName*. These characters will be converted to slashes upon receipt, allowing secrets to be arranged in folders.  A secret is assigned a path name constructed from the *secretType* and *secretName* path parameters and, optionally, from query parameters determined by the *secretType*. Each *secretType* determines a specific transformation from the url path to a path in the vault. The *secretType* may require certain query parameters to be present on the request in order to construct the vault path. See the next section for details.  ### Secret Types The list below documents each *secretType* and their applicable query parameters. Highlighted parameter names indicate required parameters. When present, default values are listed first and also highlighted.    - **system**     - *sysid*: the unique system id     - *sysuser*: the accessing user (except when keytype=cert)     - keytype: *sshkey* | password | accesskey | token | tmskey | cert   - **dbcred**     - *dbhost*:  the DBMS hostname, IP address or alias     - *dbname*:  the database name or alias     - *dbservice*: service name   - **jwtsigning** - *no query parameters*   - **user** - *no query parameters*   - **service** - *no query parameters*  ### Authorization Requestors are authorized based on the secret type specified in the URL path. The following authorizations are enforced:  - system: limited to the systems service - dbcred: any service - jwtsigning: limited to the tokens service - user: any user - service: any service
      */
-    listSecretMeta(requestParameters: ListSecretMetaRequest, initOverrides?: RequestInit): Promise<RespSecretList>;
+    readSecret(requestParameters: ReadSecretRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<RespSecret>;
     /**
-     * Read a versioned secret. By default, the latest version of the secret is read. If the *version* query parameter is specified then that version of the secret is read.  The *version* parameter should be passed as an integer with zero indicating the latest version of the secret. A NOT FOUND status code is returned if the secret version does not exist or if it\'s deleted or destroyed.  The response object includes the map of zero or more key/value pairs and metadata that describes the secret. The metadata includes which version of the secret was returned.  A valid tenant and user must be specified as query parameters.  ### Naming Secrets Secrets can be arranged hierarchically by using the \"+\" characters in the *secretName*.  These characters will be converted to slashes upon receipt, allowing secrets to be arranged in folders.  A secret is assigned a path name constructed from the *secretType* and *secretName* path parameters and, optionally, from query parameters determined by the *secretType*. Each *secretType* determines a specific transformation from the url path to a path in the vault.  The *secretType* may require certain query parameters to be present on the request in order to construct the vault path.  See the next section for details.  ### Secret Types The list below documents each *secretType* and their applicable query parameters. Highlighted parameter names indicate required parameters. When present, default values are listed first and also highlighted.    - **system**     - *sysid*: the unique system id     - *sysuser*: the accessing user (except when keytype=cert)     - keytype: *sshkey* | password | accesskey | cert   - **dbcred**     - *dbhost*:  the DBMS hostname, IP address or alias     - *dbname*:  the database name or alias     - *dbservice*: service name   - **jwtsigning** - *no query parameters*   - **user** - *no query parameters*   - **service** - *no query parameters* ### Authorization Requestors are authorized based on the secret type specified in the URL path.  The following authorizations are enforced:  - system: limited to the systems service - dbcred: any service - jwtsigning: limited to the tokens service - user: any user - service: any service
+     * List a secret\'s metadata including its version information. The input parameter must be a secret name, not a folder. The result includes which version of the secret is the latest.  A valid tenant and user must be specified as query parameters.  ### Naming Secrets Secrets can be arranged hierarchically by using the \"+\" characters in the *secretName*. These characters will be converted to slashes upon receipt, allowing secrets to be arranged in folders.  A secret is assigned a path name constructed from the *secretType* and *secretName* path parameters and, optionally, from query parameters determined by the *secretType*. Each *secretType* determines a specific transformation from the url path to a path in the vault. The *secretType* may require certain query parameters to be present on the request in order to construct the vault path. See the next section for details.  ### Secret Types The list below documents each *secretType* and their applicable query parameters. Highlighted parameter names indicate required parameters. When present, default values are listed first and also highlighted.    - **system**     - *sysid*: the unique system id     - *sysuser*: the accessing user (except when keytype=cert)     - keytype: *sshkey* | password | accesskey | token | tmskey | cert   - **dbcred**     - *dbhost*:  the DBMS hostname, IP address or alias     - *dbname*:  the database name or alias     - *dbservice*: service name   - **jwtsigning** - *no query parameters*   - **user** - *no query parameters*   - **service** - *no query parameters*  ### Authorization Requestors are authorized based on the secret type specified in the URL path. The following authorizations are enforced:  - system: limited to the systems service - dbcred: any service - jwtsigning: limited to the tokens service - user: any user - service: any service
      */
-    readSecretRaw(requestParameters: ReadSecretRequest, initOverrides?: RequestInit): Promise<runtime.ApiResponse<RespSecret>>;
+    readSecretMetaRaw(requestParameters: ReadSecretMetaRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<RespSecretVersionMetadata>>;
     /**
-     * Read a versioned secret. By default, the latest version of the secret is read. If the *version* query parameter is specified then that version of the secret is read.  The *version* parameter should be passed as an integer with zero indicating the latest version of the secret. A NOT FOUND status code is returned if the secret version does not exist or if it\'s deleted or destroyed.  The response object includes the map of zero or more key/value pairs and metadata that describes the secret. The metadata includes which version of the secret was returned.  A valid tenant and user must be specified as query parameters.  ### Naming Secrets Secrets can be arranged hierarchically by using the \"+\" characters in the *secretName*.  These characters will be converted to slashes upon receipt, allowing secrets to be arranged in folders.  A secret is assigned a path name constructed from the *secretType* and *secretName* path parameters and, optionally, from query parameters determined by the *secretType*. Each *secretType* determines a specific transformation from the url path to a path in the vault.  The *secretType* may require certain query parameters to be present on the request in order to construct the vault path.  See the next section for details.  ### Secret Types The list below documents each *secretType* and their applicable query parameters. Highlighted parameter names indicate required parameters. When present, default values are listed first and also highlighted.    - **system**     - *sysid*: the unique system id     - *sysuser*: the accessing user (except when keytype=cert)     - keytype: *sshkey* | password | accesskey | cert   - **dbcred**     - *dbhost*:  the DBMS hostname, IP address or alias     - *dbname*:  the database name or alias     - *dbservice*: service name   - **jwtsigning** - *no query parameters*   - **user** - *no query parameters*   - **service** - *no query parameters* ### Authorization Requestors are authorized based on the secret type specified in the URL path.  The following authorizations are enforced:  - system: limited to the systems service - dbcred: any service - jwtsigning: limited to the tokens service - user: any user - service: any service
+     * List a secret\'s metadata including its version information. The input parameter must be a secret name, not a folder. The result includes which version of the secret is the latest.  A valid tenant and user must be specified as query parameters.  ### Naming Secrets Secrets can be arranged hierarchically by using the \"+\" characters in the *secretName*. These characters will be converted to slashes upon receipt, allowing secrets to be arranged in folders.  A secret is assigned a path name constructed from the *secretType* and *secretName* path parameters and, optionally, from query parameters determined by the *secretType*. Each *secretType* determines a specific transformation from the url path to a path in the vault. The *secretType* may require certain query parameters to be present on the request in order to construct the vault path. See the next section for details.  ### Secret Types The list below documents each *secretType* and their applicable query parameters. Highlighted parameter names indicate required parameters. When present, default values are listed first and also highlighted.    - **system**     - *sysid*: the unique system id     - *sysuser*: the accessing user (except when keytype=cert)     - keytype: *sshkey* | password | accesskey | token | tmskey | cert   - **dbcred**     - *dbhost*:  the DBMS hostname, IP address or alias     - *dbname*:  the database name or alias     - *dbservice*: service name   - **jwtsigning** - *no query parameters*   - **user** - *no query parameters*   - **service** - *no query parameters*  ### Authorization Requestors are authorized based on the secret type specified in the URL path. The following authorizations are enforced:  - system: limited to the systems service - dbcred: any service - jwtsigning: limited to the tokens service - user: any user - service: any service
      */
-    readSecret(requestParameters: ReadSecretRequest, initOverrides?: RequestInit): Promise<RespSecret>;
+    readSecretMeta(requestParameters: ReadSecretMetaRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<RespSecretVersionMetadata>;
     /**
-     * List a secret\'s metadata including its version information. The input parameter must be a secret name, not a folder. The result includes which version of the secret is the latest.  A valid tenant and user must be specified as query parameters.  ### Naming Secrets Secrets can be arranged hierarchically by using the \"+\" characters in the *secretName*.  These characters will be converted to slashes upon receipt, allowing secrets to be arranged in folders.  A secret is assigned a path name constructed from the *secretType* and *secretName* path parameters and, optionally, from query parameters determined by the *secretType*. Each *secretType* determines a specific transformation from the url path to a path in the vault.  The *secretType* may require certain query parameters to be present on the request in order to construct the vault path.  See the next section for details.  ### Secret Types The list below documents each *secretType* and their applicable query parameters. Highlighted parameter names indicate required parameters. When present, default values are listed first and also highlighted.    - **system**     - *sysid*: the unique system id     - *sysuser*: the accessing user (except when keytype=cert)     - keytype: *sshkey* | password | accesskey | cert   - **dbcred**     - *dbhost*:  the DBMS hostname, IP address or alias     - *dbname*:  the database name or alias     - *dbservice*: service name   - **jwtsigning** - *no query parameters*   - **user** - *no query parameters*   - **service** - *no query parameters* ### Authorization Requestors are authorized based on the secret type specified in the URL path.  The following authorizations are enforced:  - system: limited to the systems service - dbcred: any service - jwtsigning: limited to the tokens service - user: any user - service: any service
+     * Restore one or more versions of a secret that have previously been deleted. This endpoint undoes soft deletions performed using the *secret/delete/{secretType}/{secretName}* endpoint.  The input versions array is interpreted as follows:     * [-] - empty = undelete all versions    * [0] - zero = undelete only the latest version    * [1, 3, ...] - list = undelete the specified versions  A valid tenant and user must be specified in the body.  ### Naming Secrets Secrets can be arranged hierarchically by using the \"+\" characters in the *secretName*. These characters will be converted to slashes upon receipt, allowing secrets to be arranged in folders.  A secret is assigned a path name constructed from the *secretType* and *secretName* path parameters and, optionally, from query parameters determined by the *secretType*. Each *secretType* determines a specific transformation from the url path to a path in the vault. The *secretType* may require certain query parameters to be present on the request in order to construct the vault path. See the next section for details.  ### Secret Types The list below documents each *secretType* and their applicable query parameters. Highlighted parameter names indicate required parameters. When present, default values are listed first and also highlighted.    - **system**     - *sysid*: the unique system id     - *sysuser*: the accessing user (except when keytype=cert)     - keytype: *sshkey* | password | accesskey | token | tmskey | cert   - **dbcred**     - *dbhost*:  the DBMS hostname, IP address or alias     - *dbname*:  the database name or alias     - *dbservice*: service name   - **jwtsigning** - *no query parameters*   - **user** - *no query parameters*   - **service** - *no query parameters*  ### Authorization Requestors are authorized based on the secret type specified in the URL path. The following authorizations are enforced:  - system: limited to the systems service - dbcred: any service - jwtsigning: limited to the tokens service - user: any user - service: any service
      */
-    readSecretMetaRaw(requestParameters: ReadSecretMetaRequest, initOverrides?: RequestInit): Promise<runtime.ApiResponse<RespSecretVersionMetadata>>;
+    undeleteSecretRaw(requestParameters: UndeleteSecretRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<RespVersions>>;
     /**
-     * List a secret\'s metadata including its version information. The input parameter must be a secret name, not a folder. The result includes which version of the secret is the latest.  A valid tenant and user must be specified as query parameters.  ### Naming Secrets Secrets can be arranged hierarchically by using the \"+\" characters in the *secretName*.  These characters will be converted to slashes upon receipt, allowing secrets to be arranged in folders.  A secret is assigned a path name constructed from the *secretType* and *secretName* path parameters and, optionally, from query parameters determined by the *secretType*. Each *secretType* determines a specific transformation from the url path to a path in the vault.  The *secretType* may require certain query parameters to be present on the request in order to construct the vault path.  See the next section for details.  ### Secret Types The list below documents each *secretType* and their applicable query parameters. Highlighted parameter names indicate required parameters. When present, default values are listed first and also highlighted.    - **system**     - *sysid*: the unique system id     - *sysuser*: the accessing user (except when keytype=cert)     - keytype: *sshkey* | password | accesskey | cert   - **dbcred**     - *dbhost*:  the DBMS hostname, IP address or alias     - *dbname*:  the database name or alias     - *dbservice*: service name   - **jwtsigning** - *no query parameters*   - **user** - *no query parameters*   - **service** - *no query parameters* ### Authorization Requestors are authorized based on the secret type specified in the URL path.  The following authorizations are enforced:  - system: limited to the systems service - dbcred: any service - jwtsigning: limited to the tokens service - user: any user - service: any service
+     * Restore one or more versions of a secret that have previously been deleted. This endpoint undoes soft deletions performed using the *secret/delete/{secretType}/{secretName}* endpoint.  The input versions array is interpreted as follows:     * [-] - empty = undelete all versions    * [0] - zero = undelete only the latest version    * [1, 3, ...] - list = undelete the specified versions  A valid tenant and user must be specified in the body.  ### Naming Secrets Secrets can be arranged hierarchically by using the \"+\" characters in the *secretName*. These characters will be converted to slashes upon receipt, allowing secrets to be arranged in folders.  A secret is assigned a path name constructed from the *secretType* and *secretName* path parameters and, optionally, from query parameters determined by the *secretType*. Each *secretType* determines a specific transformation from the url path to a path in the vault. The *secretType* may require certain query parameters to be present on the request in order to construct the vault path. See the next section for details.  ### Secret Types The list below documents each *secretType* and their applicable query parameters. Highlighted parameter names indicate required parameters. When present, default values are listed first and also highlighted.    - **system**     - *sysid*: the unique system id     - *sysuser*: the accessing user (except when keytype=cert)     - keytype: *sshkey* | password | accesskey | token | tmskey | cert   - **dbcred**     - *dbhost*:  the DBMS hostname, IP address or alias     - *dbname*:  the database name or alias     - *dbservice*: service name   - **jwtsigning** - *no query parameters*   - **user** - *no query parameters*   - **service** - *no query parameters*  ### Authorization Requestors are authorized based on the secret type specified in the URL path. The following authorizations are enforced:  - system: limited to the systems service - dbcred: any service - jwtsigning: limited to the tokens service - user: any user - service: any service
      */
-    readSecretMeta(requestParameters: ReadSecretMetaRequest, initOverrides?: RequestInit): Promise<RespSecretVersionMetadata>;
+    undeleteSecret(requestParameters: UndeleteSecretRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<RespVersions>;
     /**
-     * Restore one or more versions of a secret that have previously been deleted. This endpoint undoes soft deletions performed using the *secret/delete/{secretType}/{secretName}* endpoint.  The input versions array is interpreted as follows:     * [-] - empty = undelete all versions    * [0] - zero = undelete only the latest version    * [1, 3, ...] - list = undelete the specified versions  A valid tenant and user must be specified in the body.  ### Naming Secrets Secrets can be arranged hierarchically by using the \"+\" characters in the *secretName*.  These characters will be converted to slashes upon receipt, allowing secrets to be arranged in folders.  A secret is assigned a path name constructed from the *secretType* and *secretName* path parameters and, optionally, from query parameters determined by the *secretType*. Each *secretType* determines a specific transformation from the url path to a path in the vault.  The *secretType* may require certain query parameters to be present on the request in order to construct the vault path.  See the next section for details.  ### Secret Types The list below documents each *secretType* and their applicable query parameters. Highlighted parameter names indicate required parameters. When present, default values are listed first and also highlighted.    - **system**     - *sysid*: the unique system id     - *sysuser*: the accessing user (except when keytype=cert)     - keytype: *sshkey* | password | accesskey | cert   - **dbcred**     - *dbhost*:  the DBMS hostname, IP address or alias     - *dbname*:  the database name or alias     - *dbservice*: service name   - **jwtsigning** - *no query parameters*   - **user** - *no query parameters*   - **service** - *no query parameters* ### Authorization Requestors are authorized based on the secret type specified in the URL path.  The following authorizations are enforced:  - system: limited to the systems service - dbcred: any service - jwtsigning: limited to the tokens service - user: any user - service: any service
+     * Validate a service\'s password. The JSON payload contains the password that needs to be validated against the password stored in the vault for the service specifie din the X-Tapis-User header. The secret name is the path under which the password was stored.  A valid tenant and user must also be specified in the payload.  ### Naming Secrets Secrets can be arranged hierarchically by using the \"+\" characters in the *secretName*. These characters will be converted to slashes upon receipt, allowing secrets to be arranged in folders.  Only services can make this request.
      */
-    undeleteSecretRaw(requestParameters: UndeleteSecretRequest, initOverrides?: RequestInit): Promise<runtime.ApiResponse<RespVersions>>;
+    validateServicePasswordRaw(requestParameters: ValidateServicePasswordRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<RespAuthorized>>;
     /**
-     * Restore one or more versions of a secret that have previously been deleted. This endpoint undoes soft deletions performed using the *secret/delete/{secretType}/{secretName}* endpoint.  The input versions array is interpreted as follows:     * [-] - empty = undelete all versions    * [0] - zero = undelete only the latest version    * [1, 3, ...] - list = undelete the specified versions  A valid tenant and user must be specified in the body.  ### Naming Secrets Secrets can be arranged hierarchically by using the \"+\" characters in the *secretName*.  These characters will be converted to slashes upon receipt, allowing secrets to be arranged in folders.  A secret is assigned a path name constructed from the *secretType* and *secretName* path parameters and, optionally, from query parameters determined by the *secretType*. Each *secretType* determines a specific transformation from the url path to a path in the vault.  The *secretType* may require certain query parameters to be present on the request in order to construct the vault path.  See the next section for details.  ### Secret Types The list below documents each *secretType* and their applicable query parameters. Highlighted parameter names indicate required parameters. When present, default values are listed first and also highlighted.    - **system**     - *sysid*: the unique system id     - *sysuser*: the accessing user (except when keytype=cert)     - keytype: *sshkey* | password | accesskey | cert   - **dbcred**     - *dbhost*:  the DBMS hostname, IP address or alias     - *dbname*:  the database name or alias     - *dbservice*: service name   - **jwtsigning** - *no query parameters*   - **user** - *no query parameters*   - **service** - *no query parameters* ### Authorization Requestors are authorized based on the secret type specified in the URL path.  The following authorizations are enforced:  - system: limited to the systems service - dbcred: any service - jwtsigning: limited to the tokens service - user: any user - service: any service
+     * Validate a service\'s password. The JSON payload contains the password that needs to be validated against the password stored in the vault for the service specifie din the X-Tapis-User header. The secret name is the path under which the password was stored.  A valid tenant and user must also be specified in the payload.  ### Naming Secrets Secrets can be arranged hierarchically by using the \"+\" characters in the *secretName*. These characters will be converted to slashes upon receipt, allowing secrets to be arranged in folders.  Only services can make this request.
      */
-    undeleteSecret(requestParameters: UndeleteSecretRequest, initOverrides?: RequestInit): Promise<RespVersions>;
+    validateServicePassword(requestParameters: ValidateServicePasswordRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<RespAuthorized>;
     /**
-     * Validate a service\'s password. The JSON payload contains the password that needs to be validated against the password stored in the vault for the service specifiedin the X-Tapis-User header. The secret name is the path under whichthe password was stored.  A valid tenant and user must also be specified in the payload.  ### Naming Secrets Secrets can be arranged hierarchically by using the \"+\" characters in the *secretName*.  These characters will be converted to slashes upon receipt, allowing secrets to be arranged in folders.  Only services can make this request.
+     * Validate a Site Admin\'s password. The JSON payload contains the password that needs to be validated against the password stored in the vault for the site admin specified in the X-Tapis-User header. The secret name is the path under which the password was stored.  A valid tenant and user must also be specified in the payload.  ### Naming Secrets Secrets can be arranged hierarchically by using the \"+\" characters in the *secretName*. These characters will be converted to slashes upon receipt, allowing secrets to be arranged in folders.  Only services can make this request.
      */
-    validateServicePasswordRaw(requestParameters: ValidateServicePasswordRequest, initOverrides?: RequestInit): Promise<runtime.ApiResponse<RespAuthorized>>;
+    validateSiteAdminPasswordRaw(requestParameters: ValidateSiteAdminPasswordRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<RespAuthorized>>;
     /**
-     * Validate a service\'s password. The JSON payload contains the password that needs to be validated against the password stored in the vault for the service specifiedin the X-Tapis-User header. The secret name is the path under whichthe password was stored.  A valid tenant and user must also be specified in the payload.  ### Naming Secrets Secrets can be arranged hierarchically by using the \"+\" characters in the *secretName*.  These characters will be converted to slashes upon receipt, allowing secrets to be arranged in folders.  Only services can make this request.
+     * Validate a Site Admin\'s password. The JSON payload contains the password that needs to be validated against the password stored in the vault for the site admin specified in the X-Tapis-User header. The secret name is the path under which the password was stored.  A valid tenant and user must also be specified in the payload.  ### Naming Secrets Secrets can be arranged hierarchically by using the \"+\" characters in the *secretName*. These characters will be converted to slashes upon receipt, allowing secrets to be arranged in folders.  Only services can make this request.
      */
-    validateServicePassword(requestParameters: ValidateServicePasswordRequest, initOverrides?: RequestInit): Promise<RespAuthorized>;
+    validateSiteAdminPassword(requestParameters: ValidateSiteAdminPasswordRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<RespAuthorized>;
     /**
-     * Create or update a secret. The JSON payload contains a required *data* object and an optional *options* object.  It also contains the required tenant and user fields.  The *data* object is a JSON object that contains one or more key/value pairs in which both the key and value are strings. These are the individual secrets that are saved under the path name. The secrets are automatically versioned, which allows a pre-configured number of past secret values to be accessible even after new values are assigned. See the various GET operations for details on how to access different aspects of secrets.  NOTE: The *cas* option is currently ignored but documented here for future reference.  The *options* object can contain a *cas* key and with an integer value that represents a secret version.  CAS stands for check-and-set and will check an existing secret\'s version before updating.  If cas is not set the write will be always be allowed. If set to 0, a write will only be allowed if the key doesn’t exist. If the index is greater than zero, then the write will only be allowed if the key’s current version matches the version specified in the cas parameter.  ### Naming Secrets Secrets can be arranged hierarchically by using the \"+\" characters in the *secretName*.  These characters will be converted to slashes upon receipt, allowing secrets to be arranged in folders.  A secret is assigned a path name constructed from the *secretType* and *secretName* path parameters and, optionally, from query parameters determined by the *secretType*. Each *secretType* determines a specific transformation from the url path to a path in the vault.  The *secretType* may require certain query parameters to be present on the request in order to construct the vault path.  See the next section for details.  ### Secret Types The list below documents each *secretType* and their applicable query parameters. Highlighted parameter names indicate required parameters. When present, default values are listed first and also highlighted.    - **system**     - *sysid*: the unique system id     - *sysuser*: the accessing user (except when keytype=cert)     - keytype: *sshkey* | password | accesskey | cert   - **dbcred**     - *dbhost*:  the DBMS hostname, IP address or alias     - *dbname*:  the database name or alias     - *dbservice*: service name   - **jwtsigning** - *no query parameters*   - **user** - *no query parameters*   - **service** - *no query parameters* ### Authorization Requestors are authorized based on the secret type specified in the URL path.  The following authorizations are enforced:  - system: limited to the systems service - dbcred: any service - jwtsigning: limited to the tokens service - user: any user - service: any service
+     * Create or update a secret. The JSON payload contains a required *data* object and an optional *options* object. It also contains the required tenant and user fields.  The *data* object is a JSON object that contains one or more key/value pairs in which both the key and value are strings. These are the individual secrets that are saved under the path name. The secrets are automatically versioned, which allows a pre-configured number of past secret values to be accessible even after new values are assigned. See the various GET operations for details on how to access different aspects of secrets.  NOTE: The *cas* option is currently ignored but documented here for future reference.  The *options* object can contain a *cas* key and with an integer value that represents a secret version. CAS stands for check-and-set and will check an existing secret\'s version before updating. If cas is not set the write will be always be allowed. If set to 0, a write will only be allowed if the key doesn’t exist. If the index is greater than zero, then the write will only be allowed if the key’s current version matches the version specified in the cas parameter.  ### Naming Secrets Secrets can be arranged hierarchically by using the \"+\" characters in the *secretName*. These characters will be converted to slashes upon receipt, allowing secrets to be arranged in folders.  A secret is assigned a path name constructed from the *secretType* and *secretName* path parameters and, optionally, from query parameters determined by the *secretType*. Each *secretType* determines a specific transformation from the url path to a path in the vault. The *secretType* may require certain query parameters to be present on the request in order to construct the vault path. See the next section for details.  ### Secret Types The list below documents each *secretType* and their applicable query parameters. Highlighted parameter names indicate required parameters. When present, default values are listed first and also highlighted.    - **system**     - *sysid*: the unique system id     - *sysuser*: the accessing user (except when keytype=cert)     - keytype: *sshkey* | password | accesskey | token | tmskey | cert   - **dbcred**     - *dbhost*:  the DBMS hostname, IP address or alias     - *dbname*:  the database name or alias     - *dbservice*: service name   - **jwtsigning** - *no query parameters*   - **user** - *no query parameters*   - **service** - *no query parameters*  ### Authorization Requestors are authorized based on the secret type specified in the URL path. The following authorizations are enforced:  - system: limited to the systems service - dbcred: any service - jwtsigning: limited to the tokens service - user: any user - service: any service  ### Generating Secrets Passwords and public/private key pairs appropriate for Tapis use can be generated as part of this secret write call. To direct SK to create a secret, assign the special value `<generate-secret>` to a key. When SK detects this value, it generates a password or key pair depending on context, and replaces the `<generate-secret>` text with the generated secret. In the case of a key pair, both the public and private keys are saved.  Key pairs are always generated for secrets of type JWTSigning, while passwords are generated for all other secret types unless the key is named *privateKey*.  To generate a key pair, insert the following key/value pair into the payload\'s data map:      key=\"privateKey\", value=\"<generate-secret>\"  When the key pair is generated, the above key/value item is replaced by these two key/value pairs:      key=\"privateKey\", value=<private key in pem format>     key=\"publicKey\",  value=<public key in pem format>  In non-JWTSigning secret types, passwords are generated whenever the following key/value pair is encountered in the payload\'s data map:      key=<name other than privateKey>, value=\"<generate-secret>\"  The generated password simply replaces the item\'s value and the key name is left unchanged.
      */
-    writeSecretRaw(requestParameters: WriteSecretRequest, initOverrides?: RequestInit): Promise<runtime.ApiResponse<RespSecretMeta>>;
+    writeSecretRaw(requestParameters: WriteSecretRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<RespSecretMeta>>;
     /**
-     * Create or update a secret. The JSON payload contains a required *data* object and an optional *options* object.  It also contains the required tenant and user fields.  The *data* object is a JSON object that contains one or more key/value pairs in which both the key and value are strings. These are the individual secrets that are saved under the path name. The secrets are automatically versioned, which allows a pre-configured number of past secret values to be accessible even after new values are assigned. See the various GET operations for details on how to access different aspects of secrets.  NOTE: The *cas* option is currently ignored but documented here for future reference.  The *options* object can contain a *cas* key and with an integer value that represents a secret version.  CAS stands for check-and-set and will check an existing secret\'s version before updating.  If cas is not set the write will be always be allowed. If set to 0, a write will only be allowed if the key doesn’t exist. If the index is greater than zero, then the write will only be allowed if the key’s current version matches the version specified in the cas parameter.  ### Naming Secrets Secrets can be arranged hierarchically by using the \"+\" characters in the *secretName*.  These characters will be converted to slashes upon receipt, allowing secrets to be arranged in folders.  A secret is assigned a path name constructed from the *secretType* and *secretName* path parameters and, optionally, from query parameters determined by the *secretType*. Each *secretType* determines a specific transformation from the url path to a path in the vault.  The *secretType* may require certain query parameters to be present on the request in order to construct the vault path.  See the next section for details.  ### Secret Types The list below documents each *secretType* and their applicable query parameters. Highlighted parameter names indicate required parameters. When present, default values are listed first and also highlighted.    - **system**     - *sysid*: the unique system id     - *sysuser*: the accessing user (except when keytype=cert)     - keytype: *sshkey* | password | accesskey | cert   - **dbcred**     - *dbhost*:  the DBMS hostname, IP address or alias     - *dbname*:  the database name or alias     - *dbservice*: service name   - **jwtsigning** - *no query parameters*   - **user** - *no query parameters*   - **service** - *no query parameters* ### Authorization Requestors are authorized based on the secret type specified in the URL path.  The following authorizations are enforced:  - system: limited to the systems service - dbcred: any service - jwtsigning: limited to the tokens service - user: any user - service: any service
+     * Create or update a secret. The JSON payload contains a required *data* object and an optional *options* object. It also contains the required tenant and user fields.  The *data* object is a JSON object that contains one or more key/value pairs in which both the key and value are strings. These are the individual secrets that are saved under the path name. The secrets are automatically versioned, which allows a pre-configured number of past secret values to be accessible even after new values are assigned. See the various GET operations for details on how to access different aspects of secrets.  NOTE: The *cas* option is currently ignored but documented here for future reference.  The *options* object can contain a *cas* key and with an integer value that represents a secret version. CAS stands for check-and-set and will check an existing secret\'s version before updating. If cas is not set the write will be always be allowed. If set to 0, a write will only be allowed if the key doesn’t exist. If the index is greater than zero, then the write will only be allowed if the key’s current version matches the version specified in the cas parameter.  ### Naming Secrets Secrets can be arranged hierarchically by using the \"+\" characters in the *secretName*. These characters will be converted to slashes upon receipt, allowing secrets to be arranged in folders.  A secret is assigned a path name constructed from the *secretType* and *secretName* path parameters and, optionally, from query parameters determined by the *secretType*. Each *secretType* determines a specific transformation from the url path to a path in the vault. The *secretType* may require certain query parameters to be present on the request in order to construct the vault path. See the next section for details.  ### Secret Types The list below documents each *secretType* and their applicable query parameters. Highlighted parameter names indicate required parameters. When present, default values are listed first and also highlighted.    - **system**     - *sysid*: the unique system id     - *sysuser*: the accessing user (except when keytype=cert)     - keytype: *sshkey* | password | accesskey | token | tmskey | cert   - **dbcred**     - *dbhost*:  the DBMS hostname, IP address or alias     - *dbname*:  the database name or alias     - *dbservice*: service name   - **jwtsigning** - *no query parameters*   - **user** - *no query parameters*   - **service** - *no query parameters*  ### Authorization Requestors are authorized based on the secret type specified in the URL path. The following authorizations are enforced:  - system: limited to the systems service - dbcred: any service - jwtsigning: limited to the tokens service - user: any user - service: any service  ### Generating Secrets Passwords and public/private key pairs appropriate for Tapis use can be generated as part of this secret write call. To direct SK to create a secret, assign the special value `<generate-secret>` to a key. When SK detects this value, it generates a password or key pair depending on context, and replaces the `<generate-secret>` text with the generated secret. In the case of a key pair, both the public and private keys are saved.  Key pairs are always generated for secrets of type JWTSigning, while passwords are generated for all other secret types unless the key is named *privateKey*.  To generate a key pair, insert the following key/value pair into the payload\'s data map:      key=\"privateKey\", value=\"<generate-secret>\"  When the key pair is generated, the above key/value item is replaced by these two key/value pairs:      key=\"privateKey\", value=<private key in pem format>     key=\"publicKey\",  value=<public key in pem format>  In non-JWTSigning secret types, passwords are generated whenever the following key/value pair is encountered in the payload\'s data map:      key=<name other than privateKey>, value=\"<generate-secret>\"  The generated password simply replaces the item\'s value and the key name is left unchanged.
      */
-    writeSecret(requestParameters: WriteSecretRequest, initOverrides?: RequestInit): Promise<RespSecretMeta>;
+    writeSecret(requestParameters: WriteSecretRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<RespSecretMeta>;
 }