Error handling
Common errors, what they mean and recommended next steps.
The Keyless SDK uses three classes of errors, each error has an error code and an error message. Errors follow 3 main categories:
User errors: triggered by unintended or suspicious user behavior.
30_000and above.
Integration errors: triggered by a KeylessSDK integration misconfiguration.
These span from
20_000to30_000.
Internal errors: triggered by Keyless internals.
All errors below
20_000
If you're implementing the Keyless SDK, you should handle errors coming from the SDK since the error message is not intended for end users.
User errors
User errors have code that are 30_000 and above.
Note that many of these errors are predictions only, when writing messages for your users it's often best to assume positive intent. For example, suggest that they make sure that nothing is obstructing the camera instead of suggesting that they are attempting to spoof.
Spoofing
30000
The user genuine presence cannot be established.
The user might be placing a picture or a video in front of the camera. Our system is probabilistic, upon failure, advise users to ensure their face is well-lit and fully visible before retrying. The user can utilize live feedback during the camera scan for real-time guidance.
Timeout
30001
The face could not be recognized before the specified timed out.
Note: This error is no longer returned from SDK version 5.0.1 and above given the Liveness timeout feature was deprecated. See Changelog for details.
The user can retry placing the face in front of the camera as soon as the camera opens.
Mask detected
30002
The user might be wearing a mask, or there might be something hiding their face. Note: mask detected will be part of live feedback and no longer returned as an error from SDK version 4.8.0 and above.
It is very likely that there is some occlusion on the face. We advise to retry and utilize the live feedback during the camera scan for real-time guidance.
User cancelled
30003
The user manually cancelled the face recognition or image processing.
This occurs when the user cancels the face scan via the back button. We recommend either suppressing the error (the event is logged internally for debugging) or prompting the user to retry in case the cancellation was accidental.
Face not matching
30004
The face of the user in front of the camera does not match the face currently enrolled with Keyless.
This indicates a biometric mismatch: a face was detected, but it does not match the enrolled profile. We recommend prompting a retry or advising the user to verify they have selected the correct account.
No network connection
30005
The device appears to be offline.
This error indicates a loss of network connectivity. We recommend prompting the user to verify their internet connection and restart the scan. If the issue persists, advise them to wait a few minutes before retrying.
Device tampered
30006
The device seems tampered and could have been rooted or jailbroken.
Note: this error has been superseded by the runtime application self protection.
This signifies that the device is likely rooted/jailbroken. Advise the user to try on another device. If not possible reach out to Keyless support for further guidance.
User lockout
30007
The user is temporarily locked out of Keyless after too many failed authentication attempts.
Note: in case of a new device activation a different lockout code 523 is returned.
We advise the user to wait for the indicated time. We advise to expose to the user a functionality to check check the remaining time from the app before retrying. The customer can use the APIs in the lockout management section.
Rejected
30008
Keyless did not manage to recognize the user but does not suspect any spoofing attempt.
In this case the model is not providing further hints on the issue. We advise users to utilize the live feedback during the camera scan for real-time guidance.
Camera denied
30009
The user denied camera permission.
We advise the customer app to ensure camera permissions are granted. If needed prepare an informative screen on why the camera permissions are necessary to perform the face scan.
Integration errors
Integration errors have codes that span from 20_000 to 30_000.
Integration errors can be solved by making sure you are not misusing the API surface of the SDK. You can solve it by reading the error message and addressing the issue. If errors persist, please keep the error code, error message and stacktrace and contact us.
Legacy
SDK configure failed
20005
This should no longer be returned and has been replaced by the error 20010
Refer to 20010
SDK configure failed
20010
There was an error when calling Keyless.configure.
Note: from SDK version 6.0.0 and above the configuration error will be more fine grained; check the error message to understand the actual issue.
This error typically occurs due to misconfigured tenant feature flags or a failure to reach the feature flag service during SDK setup. In rare cases, it may also be caused by insufficient device storage preventing the SDK from writing necessary local files.
Liveness Environment Aware
20021
The device does not meet the requirements for environment-aware liveness detection.
Note: from SDK version 6.0.0 and above the liveness environment aware check will be managed internally in the SDK.
We advise the customer to turn-off the liveness environment aware feature if this creates frictions for the users.
Internal errors
All errors below 20_000 are classed as internal errors in that they relate to the response from our Core platform. Typically internal errors require investigation from Keyless support, however we've highlighted some of the more common ones here where action may be taken by the integrator.
PROTOCOL_INVALID_MESSAGE
507
client-server mismatch suggesting an issue in communicating with the Core backend.
This could be due the network dropping, or an outdated (unsupported) core client trying to contact the latest core backend.
PROTOCOL_FAILED_TO_AUTHENTICATE_USER
512
The given user selfie was did not meet the threshold of an approved match - in simple terms we were not confident enough that this was the same face as the one registered to this Keyless ID
In most cases we advise our customers to advise positive intent and request that the user retries reminding them to make sure they are in a well lit environment, their face is centred and they do not anything covering their face.
Of course integrators should consider that this error code is triggered because the person attempting to authenticate is not the same person that is registered and handle accordingly.
PROTOCOL_BAD_REQUEST
537
Core backend returned a 400 HTTP status error.
We advise to retry the operation. If the issue persists prompt the user to wait a few minutes before retrying. Lastly, if the user still sees the same error we advise to enroll the user anew.
PROTOCOL_MAX_NUMBER_OF_DEVICES_REACHED
539
The maximum number of devices in this has been reached. Note a maximum of 50 devices per Keyless ID is allowed. Note also that these do not all necessarily represent physical devices of a user (they could be backup or temporary client states that can be use to bind future devices for example).
Revoke some of the existing states/devices in order to generate new ones.
For SaaS customers this can be done either manually via the Keyless dashboard or programmatically via the Server API.
NET_CONNECTION_FAILED
1004
Network unavailable or server response unexpected.
If networking is available refer to 507.
CLIENT_INVALID_INPUT
1134
Incorrect or invalid parameter passed to a core function.
This may be solved by re-running the Keyless enrollment or authentication request. Alternatively the SDK and core client sync may be in a corrupted state.
CLIENT_UNKNOWN_ERROR
1142
The local state of the Keyless SDK - core client - might not be in sync with the core backend.
This may happen also in case the device time is not set correctly. We advise to ensure the device is genuine and has a correct time setting, If the issue persists, we advise to enroll the user anew.
If errors in this range persist and are unclear, please keep the error code, error message and stacktrace and contact us. If possible we'd also recommend enabling Keyless logging at TRACE level and sending these logs to us to further speed up the Keyless investigation.
Anti-Inject errors
The errors in the following table apply to Keyless Anti-Inject variant only.
Anti-inject initialization failed
40000
Keyless Anti-Inject variant only. The initialization of the Anti-Inject failed for an internal error.
License expired
40001
Keyless Anti-Inject variant only. The license "configFile.tak" is expired, contact Keyless team to receive an updated license.
Device might not be genuine.
40002
Keyless Anti-Inject variant only. We have detected signals that this device may be compromised or may not be genuine. This error prevents a user from continuing and it won't be possible to enroll or authenticate.
Examples
Last updated
Was this helpful?