APP Management

Overview

The Approov Command Line Interface (CLI) is used for administering the operation of your Approov service. Builds of the tool are available for Linux, MacOS and Windows. Follow the Approov CLI Tool Installation instructions if you do not have it installed.

API Command

approov api [option]...

Option	Description
`-add <domain>`	Adds the given new `domain` to the set that Approov tokens will be served for. By default the tokens will be signed with the `HS256` algorithm using the account secret key. This may be overridden using the `-jwe`, `-keySetKID` or `-noApproovToken` options. Also by default, a leaf certificate public key pin will be set for the domain. A check is made to ensure that the local and remote views of the certificate at the given domain endpoint are the same; the command fails with an error if the checks don't pass. This behavior can be changed using the `-pinType` option. Note that additions are immediately added to all registered apps so that they are able to obtain Approov tokens for the new domain.
`-allowWeb`	Used in conjunction with the `-add` option to specify that the API domain may have web protection requests fetched for it (see `approov web`). Should not be used with `-noApproovToken`.
`-check`	Checks all of the API domains to ensure that they are both accessible and that the pins specified match at least one certificate in the chain. The certificate chain is obtained via a local network access and is shown in the output, along with the pins being matched against.
`-getAll <pathname>`	Gets all of the API domain attribute information and the pinning information and writes it to a JSON file with the given `pathname`. The format of this file is explained in API configuration.
`-getWildcardMode`	Gets the wildcard Approov token mode. If the status is `on` then failing Approov tokens are provided on all domains, instead of the Approov token fetch returning an `UNKNOWN_URL / unknownUL` error. This can be used for initial discovery of which API domains are being accessed by an app.
`-jwe`	Used in conjunction with the `-add` option to specify that the specified API domain should use encrypted Approov tokens (JWEs). This option should not be used with `-keySetKID` or `-noApproovToken`. This will change the token generation to use the account symmetric secret with the `A256GCMKW` encryption algorithm to generate JWEs for the API instead of JWSs.
`-keySetKID <type>`	Used in conjunction with the `-add` option to specify that the API domain should have tokens signed or encrypted using the specified key from the `keyset`. Should not be used with `-jwe` or `-noApproovToken`.
`-list`	Lists all of the API domains set for this account, along with the `type`, the applied signing or encryption algorithm (`alg`) and any key ID (`kid`). Possible types are as follows: `account`: Default, meaning that the account secret and basic signing or encryption algorithms are being used. `keyset`: Indicates that the signing or encryption key has been selected from the `keyset`. `none`: Indicates that no Approov tokens are being sent for the domain. `restricted`: Indicates that Approov has automatically assigned the algorithm and keys for the domain.
`-noApproovToken`	Can be used in conjunction with the `-add` option to specify that the no Approov token needs to be sent on requests to the domain. Fetches to obtain a token for the domain will result in a `UNPROTECTED_URL`/`unprotectedURL` status response. This is to allow Approov to be used to provide pinning facilities or managed trust roots on additional domains that do not require the use of Approov tokens. Should not be used with `-keySetKID`, `-allowWeb` or `-jwe`.
`-pinType <type>`	Selects the type of leaf public key pin that will be obtained for the `-add` command. Possible options are as follows: `matching`: This is the default. It indicates that a leaf pin should be obtained both via local network access and remotely using the Approov servers. They must match for the operation to succeed. `local`: Indicates that the pin used should be the one obtained from local network access. `remote`: Indicates that the pin used should be the one observed by the Approov servers rather than the one obtained from local network access. `none`: Indicates that no pin should be obtained and can be used to add a new domain where no pin is added.
`-port <number>`	Customizes the target port for the TLS connection (defaults to 443). Custom ports must be in the range 1024 to 65535.
`-remove <domain>`	Removes the given API `domain` from the set on which Approov tokens are served. Note that this has an immediate impact on production apps so must be used with care. An `admin` role is required to perform this operation.
`-setAll <pathname>`	Sets all of the API domain attribute information and the pinning information from the JSON file with the given `pathname`. The format of this file is explained in API configuration. An `admin` role is required to use this option and the impact on production is immediate so care must be taken with any modifications. An initial check of the domains is performed first to give the user confidence that they are correct.
`-setWildcardMode <state>`	Enables or disables wildcard Approov tokens mode, depending if `state` is `on` or `off`. If wildcard tokens are enabled then failing Approov tokens are provided on all domains, instead of the Approov token fetch returning an `UNKNOWN_URL / unknownUL` error. This can be used for initial discovery of which API domains are being accessed by an app.

Registration Command

approov registration [option]...

Option	Description
`-add <app-path>`	Adds (or updates) an app registration for the app package with the given `app-path`. This package must have an extension of `.ipa` for iOS/watchOS or `.apk` / `.aab` for Android. The required signature characteristics are extracted from the app and transmitted to the Approov cloud service. New registrations are active within 30 seconds. Note that it is important that the package provided is exactly the same one as will be provided in the app store. If an Android `.aab` is being registered then the `bundletool` must be accessible, and the appropriate app signing certificates need to have been added. The option `-playSigned` must be used if registering an Android `.apk` that is being signed by the Google Play store prior to release. Note that this option can also be performed using the `automation` role.
`-addFromDevice <device-ID>`	Adds (or updates) an app registration using information captured on the given `device-ID`. This allows a registration to be added if the original app package file is no longer available. Note that information must have been captured for the `device-ID`, which typically means it must have been setup as a custom device. For Android the `-playSigned` option can be used to indicate that the app was released using Google Play signing, in which case the app signing certificate must also be added using `approov appsigncert`.
`-appex`	This may be provided in conjunction with the `-add` option when registering an iOS IPA. This indicates that any app extensions associated with the package should also be registered.
`-bundletool <path>`	Location of the `bundletool` jar file that is needed if adding a registration of an Android `.aab` file. If this is not specified then the environment variable `APPROOV_BUNDLETOOL` can be used to specify the location instead.
`-checkSigType <app-path>`	Checks the signature type of the Android `.apk` app with the given `app-path`. This checks if the APK has been signed with a V2 or later signature scheme that allows it to be used with the `approov appsigncert` app signing certificates.
`-cloneToAccounts <accounts>`	Clones permanent app registrations to each of the comma separated target `accounts`. The clone is made from the account of the currently active role. Each of the target accounts must have a `delegate` role initialized into the Approov CLI. Note that this also deletes any registrations in the target accounts that were previously cloned from the account of the currently active role but whose registrations have since been removed.
`-cloneToAllDelegateAccounts`	Clones permanent app registrations to all accounts that have a `delegate` role initialized. The clone is made from the account of the currently active role. Note that this also deletes any registrations in the target accounts that were previously cloned from the account of the currently active role but whose registrations have since been removed.
`-expireAfter <duration>`	This may be used in conjunction with the `-add`, `-addFromDevice` or `-updateExpiry` options to set a temporary period for a registration. By default, a registration is permanent, and this means that it can only be removed using an `admin` role. Generally, registrations used for development purposes should be temporary and permanent registrations should be reserved for production apps. Note that if a registration already exists then it is updated to have the longer expiry time between its current one and the new one being set. The registration time for an app is always updated by a new registration. The options for the duration may be specified in `y` (years), `d` (days), `h` (hours), `m` (minutes) or `s` (seconds). Multiple time units may be used as long as they are specified in this order, e.g. `3d12h` to register for three and a half days.
`-libraryID <ID>`	The library ID against which an app is registered is normally extracted automatically from the app. If this is not possible, perhaps because the app uses the Approov SDK embedded inside some other SDK, then this option may be used in conjunction `-add` to specify the SDK library being used.
`-list`	Lists all of the app registrations that are active for the account. They are listed in order of their registration time, so that the most recent registration is always shown at the end of the list. The full registration signature (which may be used for a `-remove` option) is shown, along with information about the SDK version used and the registration time. The automatic expiry time of the registration is also shown for temporary registrations.
`-playSigned`	Indicates that, for an Android app, it is signed by Google Play prior to be released to the store. This is always the case with an Android App Bundle but it is also possible to release an APK in this way. You must use this option if so to indicate this and also add the app signing certificate using the `approov appsigncert` option. If you fail to do this then your app installed from the Play store will be marked as `app-not-registered` and valid Approov tokens will not be issued.
`-remove <signature>`	Removes the app registration with the given `signature`. The signature is the first contiguous string for the app registration obtained with the `-list` option. A partial signature may be used if it represents a unique prefix for all those that are available. Note the removal process assigns an expiry time for the registration two minutes into the future, at which point it is actually removed. Note that permanent app registrations can only be removed with an `admin` role or with a `dev` role belonging to the same user that originally registered it.
`-removeMatching <params>`	Removes multiple matching app registrations. It is designed to allow easier removal of older registrations that are no longer in active use. The `params` are two comma separated items as follows: `app-name`: The app package name that must match for the removal to occur. `age`: Specifies the minimum age for the registration time to match. This allows removal to be restricted to older registrations. The options for the duration may be specified in `y` (years), `d` (days), `h` (hours), `m` (minutes) or `s` (seconds). Note that an `admin` role is required to use this option.
`-unversioned`	This option may be used in conjunction with `-add` to create a registration that is not specific to any particular version of the app. Any app, signed by the same authority, with the same package name will be considered to be a valid registration. This means that you do not need to do a new app registration for each new version of the app released. However, this means that you lose the flexibility to remove registrations for specific (perhaps older) versions of your app. Note that this is not supported for Android `.apk`s, only for `.aab`s.
`-updateExpiry <signature>`	Updates the expiry time of the registration with the given `signature`. The signature is the first contiguous string for the app registration obtained with the `-list` option. A partial `signature` may be used if it represents a unique prefix for all those that are available. By default this will make the `signature` permanent, but the `-expireAfter` option may be used to specify a particular expiry time. Note though that this command may only be used to extend the expiry of an existing registration, not to shorten it.
`-versionName <override>`	This option may be used in conjunction with `-add` to overwrite the version number of the app in the registration with `override`. It is not advisable to use this option for permanent registrations so that the actual published app version number can be clearly seen, but for temporary development registrations this is useful for marking a particular registration with some ancillary information, such as a build number of hash from a CI system. Note that any spaces in the `override` value are removed.
`-watchOS`	This option may be used in conjunction with `-add` for a `.ipa` to indicate that the registration is for a watchOS app embedded within the overall iOS app. If this option is used then only the watchOS app is registered, not the overall iOS app.

Pin Command

approov pin [option]...

Option	Description
`-add <pin>`	Adds the given `pin` to the domain specified with `-api`. The `pin` should be specified as a base64 encoded 256-bit value, representing a subject public key hash, which is deemed acceptable for a connection to the domain.
`-addLeafPin <type>`	Adds the public key pin for the leaf certificate for the domain specified with `-api`. The `type` specifies the pin extraction requirement and may be one of: `matching`: Check local and remote pins and ensure they match. `local`: Extract the pin as observed via local network access. `remote`: Extract the pin as observed by the Approov servers,
`-api <domain>`	Specifies the API `domain` that various other options are acting upon. If adding or removing pins then this should be a domain that has already been added to the account.
`-forceApplyPins`	Forces application of the current level of pinning to all clients whose last obtained pins via a `getPins` call was to an earlier version. This asserts the `isForceApplyPins` flag for future fetches on those apps and the implementation should ensure that pin bindings are updated at the earliest convenience.
`-getCertChainPins`	Obtains the public key pins for the certificate chain for the domain specified with `-api`. The leaf certificate is shown first and then the chain right up to the root certificate. The public key pin, expiry date and subject information is provided for each element in the chain. This can be used to obtain the pins for intermediate certificates.
`-getCertPin <file>`	Extracts the public key pin for the certificate provided in the given `file`. This must be a base64 encoded PEM certificate. This can be used for obtaining the pin for a certificate that has not yet been put into active usage. The expiry date and subject information is also provided. Note that no `-api` is required.
`-getLeafPin <type>`	Obtains the public key pin for the leaf certificate at the domain specified with `-api`. The `type` specifies the pin extraction requirement and may one of: `matching`: Check local and remote pins and ensure they match. `local`: Extract the pin as observed via local network access. `remote`: Extract the pin as observed by the Approov servers,
`-getManagedTrustRoots`	Gets the status showing if managed trust roots are on or off.
`-getPinningTestURL`	Gets the test URL that has been specified for continuous pinning testing to help ensure it has not been compromised.
`-list`	Lists all of the pins associated with the API domain specified with `-api`.
`-port <number>`	If `-getLeafPin` or `-getCertChainPins` is used then this customizes the target port for the TLS connection (defaults to 443). Custom ports must be in the range 1024 to 65535.
`-remove <pin>`	Removes the specified `pin` from the API domain selected with the `-api` option.
`-removePinningTestURL`	Removes the test URL that has been specified for continuous pinning testing to help ensure it has not been compromised. This requires an `admin` role.
`-setManagedTrustRoots`	Sets the managed trust roots to be either `on` or `off`. If managed trust roots are on then the app is provided with the trust root pins in its configuration under the `*` domain. When trust roots are on, leaf pins are not added for new API domains that are added, on the basis that they will use trust roots instead. This requires an `admin` role.
`-setPinningTestURL <url>`	Enables the continuous pinning test and sets it to use the given `url`. This `url` should be something that it is possible to perform a successful `HTTP GET` operation with. Launched apps will check that the pinning mechanism prevents them from accessing this `url`; if they are able to, then the app is considered to be compromised. This option requires an `admin` role.

SDK Command

approov sdk [option]...

Option	Description
`-accessedURLs`	Gets the list of different URLs that the SDK may access. This may be required in order to setup firewall rules when running the SDK inside a private network. Note that the SDK must be able to access these domains directly without any TLS interception by a firewall. This option is also valid with a `delegate` role. An example `curl` command is provided to verify access to the primary Approov servers. This command should generate a `HTTP 200` response.
`-getClientPackage <pathname>`	Gets the client package specified with `-packageID` and writes it to the given `pathname`.
`-getConfig <pathname>`	This obtains the latest extended initial configuration string for the account and saves it to the given `pathname`. This file must be integrated into the mobile app and used to initialize the Approov SDK. Typically this option is only used if pins must always be available on initialization, otherwise the `-getConfigString` option is preferred. This option is also valid with a `delegate` or `automation` role.
`-getConfigOptions`	Obtains the list of configuration options that have been applied to the SDK. This enables individual features that must be setup on SDK initialization, before any Approov fetching has been performed.
`-getConfigString`	This obtains the latest short initial configuration string for the account. This can then be copied and pasted to provide the `initialConfig` for the SDK initialization. This option is also valid with a `delegate` or `automation` role.
`-getLibrary <pathname>`	This obtains a library SDK package that can be integrated with a mobile app. It is written to the given `pathname` that must have an extension of either `.zip`, `.framework`, `.xcframework` (for iOS SDKs) or `.aar` (for Android SDKs). By default the latest SDK library that is available is obtained. Note that the library obtained may be modified with either the `-simulator` or `-libraryID` options. This option is also valid with a `automation` role.
`-libraryID <ID>`	This option may be used in conjunction with the `-getLibrary` option to get a specific version `ID` of the library. In some cases Approov support may provide you with a specific ID to obtain a library with specific characteristics or one suitable for embedding inside another SDK.
`-list`	Lists all of the available SDK libraries, with their library ID, version number, and compatible platform. Note that, unless you have a specific reason you should use the version that is automatically selected when you use `-getLibrary`.
`-packageID <ID>`	Used in conjunction with the `-getClientPackage` option to specify which particular package `ID` should be downloaded.
`-setConfigOptions <options>`	Sets the list of configuration options that should be applied to the SDK. A comma separated list of string `options` should be provided. This is to enable individual features that must be setup on SDK initialization, before any Approov fetching has been performed. Use the option string `none` to clear all the options.
`-simulator`	This can be used in conjunction with the `-getLibrary` option when getting an iO/watchOS SDK in either `.zip` or `.framework` format. Use of this option causes a different SDK package to be obtained for running on a simulator (without this option, the `-getLibrary` option retrieves an SDK that only works successfully on hardware devices). By default the SDK obtained is for iOS, use `-watchOS` if this is required.
`-watchOS`	This can be used in conjunction with the `-getLibrary` option to obtain a watchOS SDK library.

App Signing Certificates Command

approov appsigncert [option]...

info

Note that the appsigncert command can also be used with a delegate role.

Option	Description
`-add <file>`	Adds the given app signing certificate in the given `file`. This may have a file extension of `.der`, `.cer`, `.pem`, `.keystore` or `.jks`. This may be a signing certificate downloaded from either the Apple or Google developer portal. In the case of Android it is also possible to use the keystore stored locally on a development machine, to use a particular key for local development signing. Once added, apps released that are signed using this certificate are considered to be valid. The options `-autoReg` or `-dev` may also be used alongside this option. The `-alias` and `-storePassword` options may also be used while reading a Java keystore file. The `-label` option may be used to specify an entry name. By default a maximum of 10 such app signing certificates may be added to an account. Note that it is not possible to add a certificate if it is already present so if you wish to change its properties then you must `-remove` it first, using the derived fingerprint which is shown in the error resulting from an overwriting attempt.
`-alias <key-name>`	This can be used when loading a `.keystore` or `.jks` file that may contain multiple different keys to identify the specific `key-name` to be used.
`-autoReg`	This may be used in conjunction with `-add` to indicate that any app signed with the certificate should be auto-registered. This means that there is no need to register the specific app using the `approov registration -add` command, avoiding the need to do this for each app build or release. (Note that apps published in the Apple AppStore, or run in TestFlight, are re-signed by Apple and the certificate used to do this may be shared across many apps. As such, for iOS app releases you should use direct or unversioned registration, see `approov registration`).
`-dev`	This may be used in conjunction with `-add` to indicate that any app signed with the certificate is associated with development. This means that the app will always pass attestation, even if being debugged, to make it easier to work with Approov during development. Furthermore the device properties will not be included in the live attestation or monthly billing metrics, so that these continue to only show real production usage.
`-label <name>`	Used in conjunction with `-add` to mark a particular entry, making it easier to identify when listing the entries.
`-list`	Lists all of the app signing certificates that are currently active, along with some metadata and their fingerprint hashes.
`-remove <fingerprint>`	Removes the app signing certificate with the given `fingerprint` hash. Note that this has an immediate impact on production apps so must be used with care. An `admin` or `delegate` role is required to perform this operation.
`-storePassword <password>`	This is required in conjunction with the `-add` option if reading from a password protected `.keystore` or `.jks` file.

Web Command

approov web [option]...
approov web <integration> [option]...

These commands may take a further optional subcommand to select the particular web integration that is being managed. The options for the integration are -fingerprint, -hcaptcha or -recaptcha.

info

Note that commands which modify the web configuration state need an admin role.

These are the commands to manage the overall integration.

Option	Description
`-list`	Lists the information about any web integrations. This also provides the site key that must be used in calls to obtain an Approov token from your web site.
`-setTokenLifetime <duration>`	Sets the Approov token lifetime (in seconds) for those tokens issued as part of a web integration. The default value is 120s.
`-setRefreshTokenLifetime <duration>`	Sets the refresh token lifetime (in seconds) for web integrations. The default refreshTokenLifetimeSecs is 2 hours (7200s).

These are the commands to manage any Fingerprint integration, of the form:

approov web -fingerprint [option]...

Option	Description
`-add <public-API-key>`	Adds a new Fingerprint subscription with the given `public-API-key`. The `-secret` and `-region` options must also be specified. This option may also be used to update the parameters associated with an existing subscription.
`-secret <secret>`	Specify the secret API key issued by Fingerprint to check the validity of a fingerprint. This must be specified if the `-add` option is used.
`-embedResult`	This may be specified with the `-add` option to include the full Fingerprint result whenever an encrypted Approov token is generated. By default only the Fingerprint `visitorId` is provided. An encrypted Approov token is generated when the target API is added using the `-jwe` flag, or when it uses a JWK with a signing method that uses encryption.
`-list`	Lists the information about the Fingerprint integration, including all of the subscriptions added.
`-maxBotProbability <score>`	This may be optionally used in conjunction with `-add` to specify the maximum probability of the browser instance being classified as a bot. The provided probability must be below the specified `score` for a valid Approov token to be issued. The default, if this option is not used, is 1.0.
`-maxElapsedTime <duration>`	This may be optionally used in conjunction with `-add` to specify the maximum elapsed time between the Fingerprint fingerprinting operation and the attempt to fetch an Approov token. We expect, under normal circumstances, for these operations to happen very closely together in time so any significant delay may be an indication of automation. The `duration` is specified in seconds, and decimal values are valid. The default, if this option is not used, is 2.0 seconds.
`-maxResultLifetime <duration>`	This can be used optionally with the `-add` option to specify the maximum lifetime for a Fingerprint result in seconds (the default of 0 seconds indicates that the result lifetime should be the same as the refresh token lifetime). The maximum lifetime cannot exceed the refresh token lifetime.
`-rateLimit <limit>`	This may be optionally used in conjunction with `-add` to specify the maximum number of requests per minute. Attempts to make requests beyond the limit will result in an error. The `limit` is specified in terms of the maximum number of requests per minute. If this is not specified then no limit is imposed. The limit can be removed by specifying 0 as the `limit`.
`-region <region>`	This must be provided with the `-add` to specify the region for the subscription. Valid values for `region` are `EU`(Europe) and `RoW`(Rest of the World).
`-remove <public-API-key>`	Removes any subscription associated with the given `public-API-key`.
`-setOptional`	Makes the use of Fingerprint optional, allowing an Approov token to be provided for a web protection via another integration even if a Fingerprint result is not provided. This is the default when the Fingerprint integration is first added.
`-setRequired`	Makes the use of Fingerprint a requirement. This means that in order to obtain an Approov token via web protection a Fingerprint result must always be submitted.

These are the commands to manage any hCaptcha integration, of the form:

approov web -hcaptcha [option]...

Option	Description
`-add <site-key>`	Adds a new hCaptcha site with the given `site-key`. The `-secret` option must also be specified. This option may also be used to update the parameters associated with an existing site.
`-domain <domain>`	Specify the `domain` of a site to be protected with hCaptcha where a web protection is to be performed. Note that this option may be used multiple times for a given site to specify multiple domains.
`-embedResult`	This may be specified with the `-add` option to include the full hCaptcha result whenever an encrypted Approov token is issued. By default only the `challenge_ts` and `hostname` properties are provided. An encrypted Approov token is generated when the target API is added using the `-jwe` flag, or when it uses a JWK with a signing method that uses encryption.
`-includeIP`	This may be specified with the `-add` option to force the IP of the client to be included when performing the hCaptcha verification. If this option is not specified then the IP is not included.
`-list`	Lists the information about the HCaptcha integration, including all of the sites added.
`-minScore <score>`	This may be optionally used in conjunction with `-add` to specify the minimum acceptable score for the hCaptcha. The computed value must be above the specified `score` for a valid Approov token to be issued. The default, if this option is not used, is 0.0.
`-maxResultLifetime <duration>`	This can be used optionally with the `-add` option to specify the maximum lifetime for a Fingerprint result in seconds (the default of 0 seconds indicates that the result lifetime should be the same as the refresh token lifetime). The maximum lifetime cannot exceed the refresh token lifetime.
`-rateLimit <limit>`	This may be optionally used in conjunction with `-add` to specify the maximum number of requests per minute. Attempts to make requests beyond the limit will result in an error. The `limit` is specified in terms of the maximum number of requests per minute. If this is not specified then no limit is imposed. The limit can be removed by specifying 0 as the `limit`.
`-remove <site-key>`	Removes any site associated with the given `site-key`.
`-secret <api-key>`	This must be used in conjunction with the `-add` option to set the secret `api-token` that is used to check the validity of the hCaptcha.
`-setOptional`	Makes the use of hCaptcha optional, allowing an Approov token to be provided for a web protection via another integration even if a hCaptcha result is not provided. This is the default when the HCaptcha integration is first added.
`-setRequired`	Makes the use of hCaptcha a requirement. This means that in order to obtain an Approov token via web protection a hCaptcha result must always be submitted.

These are the commands to manage any reCAPTCHA integration, of the form:

approov web -recaptcha [option]...

Option	Description
`-action <action>`	This may be used in conjunction with `-add` to specify a valid `action` to be used for the domains associated with the site. Note that multiple actions may be specified. If no actions are specified at all then any may be specified.
`-add <site-key>`	Adds a new reCAPTCHA site with the given `site-key`. The `-secret` option must also be specified. This option may also be used to update the parameters associated with an existing site.
`-domain <domain>`	Specify the `domain` of a site to be protected with reCAPTCHA where a web protection is to be performed. Note that this option may be used multiple times for a given site to specify multiple domains.
`-embedResult`	This may be specified with the `-add` option to include the full reCAPTCHA result whenever an encrypted Approov token is issued. By default only the `challenge_ts` and `hostname` properties are provided. An encrypted Approov token is generated when the target API is added using the `-jwe` flag, or when it uses a JWK with a signing method that uses encryption.
`-includeIP`	This may be specified with the `-add` option to force the IP of the client to be included when performing the reCAPTCHA verification. If this option is not specified then the IP is not included.
`-list`	Lists the information about the reCAPTCHA integration, including all of the sites added.
`-minScore <score>`	This may be optionally used in conjunction with `-add` to specify the minimum acceptable score for the reCAPTCHA. The computed value must be above the specified `score` for a valid Approov token to be issued. The default, if this option is not used, is 0.0.
`-maxResultLifetime <duration>`	This can be used optionally with the `-add` option to specify the maximum lifetime for a Fingerprint result in seconds (the default of 0 seconds indicates that the result lifetime should be the same as the refresh token lifetime). The maximum lifetime cannot exceed the refresh token lifetime.
`-rateLimit <limit>`	This may be optionally used in conjunction with `-add` to specify the maximum number of requests per minute. Attempts to make requests beyond the limit will result in an error. The `limit` is specified in terms of the maximum number of requests per minute. If this is not specified then no limit is imposed. The limit can be removed by specifying 0 as the `limit`.
`-remove <site-key>`	Removes any site associated with the given `site-key`.
`-secret <api-key>`	This must be used in conjunction with the `-add` option to set the secret `api-token` that is used to check the validity of the reCAPTCHA.
`-setOptional`	Makes the use of reCAPTCHA optional, allowing an Approov token to be provided for a web protection via another integration even if a reCAPTCHA result is not provided. This is the default when the reCAPTCHA integration is first added.
`-setRequired`	Makes the use of reCAPTCHA a requirement. This means that in order to obtain an Approov token via web protection a reCAPTCHA result must always be submitted.

Overview​

API Command​

Registration Command​

Pin Command​

SDK Command​

App Signing Certificates Command​

Web Command​