For the complete documentation index, see llms.txt. This page is also available as Markdown.

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_000 and above.

  • Integration errors: triggered by a KeylessSDK integration misconfiguration.

    • These span from 20_000 to 30_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.

Error
Code
Description
Notes /Recommendation

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.

Error
Code
Description
Notes / Recommendation

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.

Error
Code
Description
Notes / Recommendation

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.

Error
Code
Description

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?