API 2.
0 Error Handling document
API Error Provision Required in the
Description
Code Application
User should be allowed to re-
enter his/her personal
"Pi" (basic) attributes of information attributes like
100 demographic data did name, lname, gender, dob,
not match dobt, age, phone, email
whichever is used for
authentication in application
User should be allowed to re-
enter his/her personal address
attribute like co (care of),
"Pa" (address) attributes
house, street, lm (land mark),
200 of demographic data did
loc (locality), vtc, subdist, dist,
not match
state, pc (postal pin code), po
(post office) whichever is used
for authentication in application
User should be allowed to give
his finger prints "n" number of
times. N should be configurable
Biometric data did not and should be set as per
300
match application requirement. (E.g.
For Banking Applications it can
be set at a maximum of 5
times)
Application should prompt user
310 Duplicate fingers used
to try again with distinct fingers.
Suggested Message to
the User
Please re-enter your
<name, lname, gender,
dob, dobt, age, phone,
email>.
Please re-enter your <co
(care of), house, street, lm
(land mark), loc (locality),
vtc, subdist, dist, state, pc
(postal pin code), po (post
office)>.
Please give your finger
prints again.
Please try again with
distinct fingers.
Suggested instructions to the
Probable Reasons
user
Operator should re-enter correct
details personal information as per
One or more personal information
the Aadhaar letter.
attributes not matching.
Ensure correct Aadhaar
Information is entered.
Operator should re-enter correct
details personal information as per
the Aadhaar letter.
One or more personal address
Ensure correct Aadhaar
attributes not matching.
Information is entered.
Ensure correct Aadhaar number is
entered and try authenticating
again with another finger; ensure
finger is placed correctly; ensure
fingers are clean; ensure finger is
not very dry; ensure fingerprint
scanner is clean. Finger print is not given properly,
scanner has some dust accumulated,
After repeated failure, if the
fingers were wet, position of finger not
resident is genuine, exception appropriate, scanned finger NFIQ not
handling provision would need to good
be followed to provide service.
Please contact UIDAI helpdesk to
inform about the issue and to
understand the steps for the
updation of the biometric
information in CIDR.
Error occurs when same finger is sent
Operator should insure that the
as two or more separate records within
resident is providing distinct fingers
same request. For two-finger auth, if
(two different fingers) for "two
resident puts same finger again, then
finger" authentication.
this happens.
API Error Provision Required in the
Description
Code Application
Application should prompt user
311 Duplicate Irises used
to try again with distinct irises.
Application should ensure that
authentication request does not
mix FMR and FIR in the same
FMR and FIR cannot be transaction e.g. in case of two
312
used in same transaction finger authentication, data for
two distinct fingers should
either be sent in FMR format or
in FIR format.
Single FIR record Application should prompt user
313 contains more than one to try again by placing single
finger finger.
Application should ensure that
Number of FMR/FIR one auth request should not
314
should not exceed 10 contain more than 10 FMR/FIR
records.
Application should ensure that
Number of IIR should not one auth request should not
315
exceed 2 contain more than 2 IIR
records.
The biometric data is of type
“Face Image Data”, application
Number of FID should
316 must ensure that one auth
not exceed 1.
request should contain only
one face image data
Biometrics locked by Resident has securely locked
330
Aadhaar holder his Biometrics
Suggested Message to Suggested instructions to the
the User user
Operator should ensure that the
Please try again with resident is providing distinct irises
distinct irises. (two different irises) for
authentication.
Technical Exception <No> Contact technical helpdesk.
Please try again by placing Operator should ensure that the
Single finger on the resident is providing single finger
authentication device. for authentication.
Resident has locked his biometrics
, he can invoke Resident portal or
M-Aadhaar and get his biometric
unlocked and get himself
authenticated
Probable Reasons
Error occurs when same iris is sent as
two or more separate records within
same request.
Auth packet cannot mix fingerprint
"image" records (FIR) and fingerprint
"minutiae" records (FMR). AUA app
should choose either one or another.
FMR is recommended.
As per ISO spec, one FIR can contain
one or more finger images within itself
(like slap, etc). UIDAI currently
supports single finger record only. If
there is a requirement to send 2
fingers, 2 different biometric records
should be sent.
Auth Request has more than 10 finger
records
Auth Request has more than 2 iris
records
Auth request has more than one " Face
image Data "
Resident can go to uidai resident portal
or maadhaar and get his biometrics
unlocked and get himself authenticated
API Error Provision Required in the
Description
Code Application
Application should have
provision for allowing user to
provide OTP value again and
400 "OTP" validation failed
after some retries
(configurable) option to
generate OTP again.
Authenticator specific
transaction identifier.
“txn” value did not match Application must ensure that in
402 with “txn” value used in case of OTP based Auth
Request OTP API. transaction the "txn" must be
exactly the same as was used
during OTP request
Application should not have
hard coded digital certificate
500 Invalid Skeyencryption
information. It should be
configurable.
Invalid value for "ci" Application should not have
501 attribute in "Skey" hard coded "ci" attribute value.
element It should be configurable.
Application should do extensive
testing using UIDAI Test Auth
502 Invalid Pid Encryption
Service to ensure compliance
with auth API.
Application should do extensive
testing using UIDAI Test Auth
503 Invalid HMac encryption
Service to ensure compliance
with auth API.
Application should have a
Session key re-initiation
provision to send full session
504 required due to expiry or
key and initiate a new session
key out of sync
in case of such failure.
Suggested Message to Suggested instructions to the
Probable Reasons
the User user
If there are repeated failures user is
Please provide correct advised to generate new OTP and Incorrect OTP value is entered. Input
OTP value. send the authentication request not matching with the value in CIDR.
using the new OTP.
AUA application must ensure that
The transaction "txn" passed in auth
in case of OTP based
verify call doesnot match with the "txn"
Technical Exception <> authentication the "txn" must be the
that was used during OTP request
same as was used while otp
generation.
generation.
Note: Application can
throw Auth API error code
number on screen. So that Use of wrong digital certificate for
Please contact authsupport team of
contact centre or encryption of AES-256 Key (session
UIDAI
application support key).
helpline can understand
the reason.
Ensure that expiry date of UIDAI
Technical Exception <> certificate used for encryption of Skey
is specified as "ci" value.
Ensure that correct AES encryption has
been used.
Technical Exception <No> Ensure that AES key used for
encryption of "Pid" XML was encrypted
and specified as value for Skey.
Ensure that correct AES encryption has
been used.
Ensure that AES key used for
encryption of "Hmac" was encrypted
Technical Exception <No>
and specified as value for Skey.
Ensure that same AES key is used for
encryption of Pid and Hmac.
When Synchronized Session Key
scheme is used, this can happen if
Technical Exception <No> Please try again. either session is expired (currently
configured to max 4 hrs) or if the key
goes out of sync.
API Error Provision Required in the
Description
Code Application
Synchronized Skey
505 Application should use full skey
usage is not allowed
Application Authentication
request should comply to
Authentication API latest
510 Invalid Auth XML format version and application should
validate its structure before
sending it to CIDR for
authentication.
Application Authentication
request should comply to PID
XML format defined in
511 Invalid PID XML format Authentication API latest
version and structural validation
should be done before
encryption of PID XML.
Aadhaar holder consent to do
Invalid Aadhaar holder the Aadhaar based
512 consent in “rc” attribute authentication using OTP or
of “Auth” Biometrics. Only allowed value
is “Y”.
Incorrect Binary format of the
513 Invalid Protobuf Format
PID Block
In case of Registered devices,
value should be passed as
“registered” for all biometric
520 Invalid “tid” value based authentication and value
for the attribute “” in case of a
non biometric based
transaction.
"dc" is a mandatory attribute for
biometric based auth Unique
Invalid “dc” code under
521 Registered Device Code. " dc"
Meta tag
is returned by RD Service when
using biometric authentication
Suggested Message to Suggested instructions to the
the User user
Technical Exception <No> Switch to full skey scheme
Please ensure that the latest
recommended API is used for
application development. Refer
UIDAI website for the latest version
Technical Exception <No> of API.
If this does not resolve the issue
than please contact technical
helpdesk.
Please ensure that the latest
recommended API is used for
application development. Refer
UIDAI website for the latest version
Technical Exception <No> of API.
If this does not resolve the issue
than please contact technical
helpdesk.
Without explicit informed consent of
the Aadhaar holder AUA/Sub-AUA
application should not call this API
Technical Exception <No>
Technical Exception <No>
Technical Exception <No>
Probable Reasons
This happens when AUA does not have
privilage to use SSK scheme
Non compliance with supported
Authentication API version structure in
CIDR.
Non compliance with supported
Authentication API version structure in
CIDR.
"rc" is a mandatory attribute . AUA
/sub-AUA application must ensure to
have an explicit concent from the
aadhaar holder before making an API
call.
Application must verify the protobuf
format being used for PID creation
In case of Auth API 2.0 registered
device specification the "tid" attribute
must “registered” for all biometric
based authentication and value for the
attribute “” in case of a non biometric
based transaction. The value must be
all lower case, no spaces or special
char else will result in this error.
Application should obtain proper device
code from the certified RD service and
use the same for biometric based
authentication., non valid or non
registered devie would result in the
API Error Provision Required in the
Description
Code Application
"mi" Model Id is a mandatory
attribute for biometric based
Invalid “mi” code under auth as part of Registered
524
Meta tag device specification . Returned
by RD Service when using
biometric authentication.
"mc" attribute holds registered
device public key certificate.
Invalid “mc” code under This is signed with device
527
Meta tag. provider key. Returned by RD
Service when using biometric
authentication.
The device certificate used in
Device - Key Rotation the request is not meeting the
528
policy UIDAI key rotation policy
guidelines .
Application should pass valid
AUA code in authentication
Invalid authenticator
530 request which is registered with
code
UIDAI. Value of this code
should be configurable.
Application should pass
supported valid API version in
540 Invalid Auth XML version
authentication request. Value of
this should be configurable.
Application should pass
supported valid API PID XML
541 Invalid PID XML version version in authentication
request. Value of this should be
configurable.
Application should ensure link
AUA not authorized for is in place between AUA-ASA
542
ASA. before sending request to
CIDR.
Suggested Message to Suggested instructions to the
the User user
Technical Exception <No>
Technical Exception <No>
Please contact authsupport team of
Technical Exception <No>
UIDAI
Technical Exception <No>
Technical Exception <No>
Technical Exception <No>
Ensure the authentication request
is being sent through the
authorized ASA as per the records
of UIDAI.
or
Probable Reasons
same error
Application should obtain proper "mi"
Model Id details from the certified RD
service and use the same for biometric
based authentication., non valid or non
registered device model would fail with
same error
Application must ensure that a valid
"mc" is used in the request and is
signed by device provider key . A
wrong "mc" passed in the request
would result in same error
The Device certificate used the API
request is not meeting the UIDAI key
rotation policy guidelines
AUA code used in Authentication
request is not valid.
or
AUA code used in the Auth URL is not
same as the AUA code used in the
Auth XML.
API version used in Auth XML
(Authentication request) is either not
supported or invalid.
Version of the "Pid" element used
In the PID XML (Authentication
request) is either not supported or
invalid.
This error will be returned if AUA and
ASA do not have linking in the portal
API Error Provision Required in the
Description
Code Application
Application should ensure Sub-
Sub-AUA not associated AUA is added and associated
543
with "AUA" with correct AUA before
sending request to CIDR.
Application should use valid
attributes defined in API for
Invalid "Uses" element <Uses> tag and validation on
550
attributes Auth request should be done
before sending request to
CIDR.
"WADH" - Wrapper API data
hash , SHOULD BE empty for
all regular authentication
transactions and must be
ONLY used for specific
552 WADH Validation failed
transaction types such as
eKYC and Update APIs. We
can also result in similar error
in case of WADH validation
failure from auth side
Registered devices
Returned when the registered
currently not supported.
device services are not
553 This feature is being
supported . Request you to get
implemented in a
in touch with Athsupport team
phased manner.
Returned when the public
Public devices are not devices are not supported by
554
allowed to be used the API or completely faced out
from the UIDAI ecosystem .
Suggested Message to Suggested instructions to the
the User user
Please contact UIDAI helpdesk to
report the issue and to understand
further steps for the updation of
ASA-AUA linkage.
Ensure the authentication request
is being sent through the
associated AUA as per the records
of UIDAI.
or
Please contact UIDAI helpdesk to
report the issue and to understand
further steps for the updation of
ASA-AUA linkage.
Technical Exception <No>
Technical Exception <No>
Technical Exception <No>
Technical Exception <No>
Probable Reasons
This error will be returned if Sub-AUA
specified in "sa" attribute is not added
as "Sub-AUA" in portal
Invalid attributes used in Uses tag.
This error is typically reported if "bt"
attribute has been specified but
bio="n" in Uses element. "bt" attribute
is required only if bio="y" in Uses
element.
AUA application must ensure that the
"WADH" attribute is passed empty for
all regular authentication transactions
and used ONLY for wrapper API
transaction calls such as eKYC and
Update APIs.
Bug in AUA Application can also result
in similar error and result with WADH
validation failure
Returned when the registered device
services are not supported . Request
you to get in touch with Athsupport
team
Returned when the public devices are
not supported by the API or completely
faced out from the UIDAI ecosystem .
Request you to get in touch with
API Error Provision Required in the
Description
Code Application
Request you to get in touch
with Athsupport team
"rdsid" Registered Device
Service ID. The application
should input a valid rdsid which
is certified and listed in registry
xml and passed in the request
rdsId is invalid and not
. This attribute is mandatory for
555 part of certification
biometric based transactions. If
registry
the registered devices service
is not used, the value for the
attribute can be NA or else the
attribute itself may not part of
the request xml
"rdsVer" Registered Device
Service Version . The
application should input a valid
"rdsVer" which is certified and
listed in registry xml and
rdsVer is invalid and not passed in the request . This
556 part of certification attribute is mandatory for
registry. biometric based transactions. If
the registered devices service
is not used, the value for the
attribute can be NA or else the
attribute itself may not part of
the request xml
"dpid" Registered Device
Provider ID . The application
should input a valid "dpid"
which is certified and listed in
dpId is invalid and not registry xml . This attribute is
557 part of certification mandatory for biometric based
registry. transactions. If the registered
devices service is not used, the
value for the attribute can be
NA or else the attribute itself
may not part of the request xml
Suggested Message to Suggested instructions to the
the User
Technical Exception <No>
Technical Exception <No>
Technical Exception <No>
Probable Reasons
user
Athsupport team
AUA application should input a valid
rdsid which is certified and listed in
registry xml and passed in the request
. This attribute is mandatory for all
biometric based transaction and If the
registered devices service is not used,
the value for the attribute can be NA or
else the attribute itself may not part of
the request xml
AUA application should input a valid
rdsVer which is certified and listed in
registry xml . This attribute is
mandatory for all biometric based
transaction and If the registered
devices service is not used, the value
for the attribute can be NA or else the
attribute itself may not part of the
request xml
AUA application should input a valid
dpid which is certified and listed in
registry xml . This attribute is
mandatory for all biometric based
transaction and If the registered
devices service is not used, the value
for the attribute can be NA or else the
attribute itself may not part of the
request xml
API Error Provision Required in the
Description
Code Application
"dih" Device Info Hash is a
mandatory attribte and has to
be calculated by Registered
558 Invalid dih
Device (RD) service during the
PID block capture when using
biometrics
Application should use a valid
Device Certificate has device certificate, this error is
559
expired reported when the validity of
the device certificate is expired
Application should use a valid
device provider certificate, the
DP Master Certificate
560 subject error is reported when
has expired
the validity of the device
provider certificate is expired
AUA application should not
Request expired ("Pid-
store Pid block and in case of
>ts" value is older than N
application which are using
561 hours where N is a
thick client there should be a
configured threshold in
provision to sync up date with
authentication server)
server at start.
Timestamp value is AUA application should not
future time (value store Pid block and in case of
specified "Pid->ts" is application which are using
562
ahead of authentication thick client there should be a
server time beyond provision to sync up date with
acceptable threshold) server at start.
Suggested Message to Suggested instructions to the
Probable Reasons
the User user
"dih" Device Info Hash is a mandatory
attribte and has to be calculated by
Technical Exception <No> Registered Device (RD) service during
the PID block capture when using
biometrics
Application should use a valid device
certificate, this error is reported when
Technical Exception <No> the validity of the device certificate is
expired. Please contatct the device
provider
Application should use a valid device
provider certificate, the subject error is
Technical Exception <No> reported when the validity of the device
provider certificate is expired, please
contatct the device provider
1. In case of
Device/Client based
Application
a. Either device
date/time is behind current Please verify that the device/client
Either Device/Client/Server date/time is
date/time or request is old. date/time is synchronised with
behind current one or old stored pid is
Please try again. Indian Standard Time (IST) and
getting sent.
resend the authentication request.
2. In case of web
based Application
a. Technical Exception
<No>
1. In case of
Device/Client based
Application
a. Either device
date/time is ahead current Please verify that the device/client
date/time or request is old. date/time is synchronised with Device/Client/server date/time is ahead
Please try again. Indian Standard Time (IST) and than current date/time.
resend the authentication request.
2. In case of web
based Application
a. Technical Exception
<No>
API Error
Description
Code
Duplicate request (this
error occurs when
Application should ask user to
563 exactly same
authentication request
was re-sent by AUA)
564 HMAC Validation failed
AUA License key has
565
expired
Invalid non-decryptable
566
license key
Invalid input (this error
occurs when some
unsupported characters
567
were found in Indian stop users to input unsupported
language values,
"lname" or "lav")
568 Unsupported Language
Digital signature
verification failed (this
means that
569
authentication request
XML was modified after
it was signed)
Invalid key info in digital
signature (this means
that certificate used for
independent module for signing
signing the
570
authentication request is
not valid – it is either
expired, or does not
belong to the AUA or is
Provision Required in the
Application
try again.
Application should create
HMAC using SHA-256
Application should have a
configurable License key
management feature through
which one can manage Key
without changing application.
The licence key used is not
decryptable
Application should have
client/server level checks to
characters.
Application should have
client/server level checks to
restrict users to only select
language from API supported
local Language.
Application should ensure
security of data end to end ie.
From client/device to CIDR
server by using appropriate
communication protocol.
Application should have an
Auth XML and certificate
should be stored and manage
outside of the application.
Suggested Message to Suggested instructions to the
the User
Please submit your
request again. authentication request once again.
Technical Exception <No>
Technical Exception <No>
Technical Exception <No>
Technical Exception <No>
Technical Exception <No>
Technical Exception <No>
Technical Exception <No>
Probable Reasons
user
If same "Auth XML" is sent more than
User is required to send the once to server, then, 2nd and
subsequent requests will fail with this
error.
HMAC is not calculated using API
defined algorithm
Current AUA License has expired.
License key used in application is
invalid.
some unsupported characters were
found in Indian language values,
"lname" or "lav" in Auth request XML
Value of "lang" attribute is not from the
list supported by authapi.
Authentication request XML was
modified after it was signed.
Certificate used for signing the
authentication request is not valid – it is
either expired, or does not belong to
the AUA or is not created by a well-
known Certification Authority
API Error
Description
Code
not created by a well-
known Certification
Authority)
PIN Requires reset (this
error will be returned if
resident is using the
571
default PIN which needs
to be reset before
usage)
Invalid biometric position
(This error is returned if
biometric position value -
"pos" attribute in "Bio" level validation to check "type"
572 element - is not and corresponding valid "pos"
applicable for a given
biometric type - "type"
attribute in "Bio"
element.)
Pi usage not allowed as
573 which can restrict the usage of
per license
Pa usage not allowed as
574
per license
Pfa usage not allowed
575
as per license
FMR usage not allowed
576
as per license entry of "FMR" attribute as per
FIR usage not allowed
577
as per license
Provision Required in the Suggested Message to Suggested instructions to the
Probable Reasons
Application the User user
Please reset your PIN in
Please change your default PIN This error will be returned if resident is
UIDAI updation application
through UIDAI updation client and using the default PIN which needs to
and use new PIN in this
resend your authentication request. be reset before usage.
application.
Application should have client This error is returned if biometric
position value - "pos" attribute in "Bio"
Technical Exception <no> element - is not applicable for a given
values before creating PID biometric type - "type" attribute in "Bio"
block. element
Application should have a
configurable business rule
Technical Exception <No> Pi usage not allowed as per license
Pi attribute based on AUA
license authorization.
Application can have a client
level check to restrict/allow
Technical Exception <No> Pa usage not allowed as per license
entry of "pa" attribute as per
license of AUA.
Application can have a client
level check to restrict/allow
Technical Exception <No> Pfa usage not allowed as per license
entry of "pfa" attribute as per
license of AUA.
Application can have a client
level check to restrict/allow
Technical Exception <No> FMR usage not allowed as per license
license of AUA.
Application can have a client
level check to restrict/allow
Technical Exception <No> FIR usage not allowed as per license
entry of "FIR" attribute as per
license of AUA.
API Error Provision Required in the Suggested Message to Suggested instructions to the
Description Probable Reasons
Code Application the User user
Application can have a client
IIR usage not allowed as level check to restrict/allow
578 Technical Exception <No> IIR usage not allowed as per license
per license entry of "IIR" attribute as per
license of AUA.
Application can have a client
OTP usage not allowed level check to restrict/allow
579 Technical Exception <No> OTP usage not allowed as per license
as per license entry of "OTP" attribute as per
license of AUA.
Application can have a client
PIN usage not allowed level check to restrict/allow
580 Technical Exception <No> PIN usage not allowed as per license
as per license entry of "PIN" attribute as per
license of AUA.
Application can have a client
Fuzzy matching usage level check to restrict/allow
Fuzzy matching usage not allowed as
581 not allowed as per entry of "ms" attribute in pi, pa Technical Exception <No>
per license
license and pfa element as per license
of AUA.
Application can have a client
Local language usage level check to restrict/allow
Local language usage not allowed as
582 not allowed as per entry of local language attribute Technical Exception <No>
per license
license in pi, pa and pfa element as per
license of AUA.
FID usage not allowed as per
FID usage not allowed as per license.
FID usage not allowed license. This feature is being Please contact authsupport team of
586 Technical Exception <No> This feature is being implemented in a
as per license. implemented in a phased UIDAI
phased manner.
manner
Name space usage is allowed Name space usage is allowed for
Name space not
587 for wrapper API applications Technical Exception <No> wrapper API applications like eKYC
allowed.
like eKYC ,MOU etc ,MOU etc
The licence key used doesn't
support usage of Registered The licence key used doesn't support
devices services, contact Auth usage of Registered devices services,
Registered device not Please contact authsupport team of
588 support and get the new Technical Exception <No> contact Auth support and get the new
allowed as per license UIDAI
lincencekey generated that lincencekey generated that supports
supports registered device registered device services
services
Usage of Public devices not
Public device not Please contact authsupport team of Usage of Public devices not allowed as
590 allowed as per the Licence Technical Exception <No>
allowed as per license. UIDAI per the Licence provided
provided
API Error Provision Required in the Suggested Message to Suggested instructions to the
Description Probable Reasons
Code Application the User user
Application should validate pid
block before encrypting data
with API specified PID block
structure and "Uses" element
Missing "Pi" data as attributes values to ensure PID
710 Technical Exception <No> Missing "Pi" data as specified in "Uses"
specified in "Uses" block have all the elements and
attributes. Client level validation
should also be put to check all
mandatory and conditional
fields of API XML.
Missing "Pa" data as Missing "Pa" data as specified in
720 Same as 710 Technical Exception <No>
specified in "Uses" "Uses"
Missing "Pfa" data as Missing "Pfa" data as specified in
721 Same as 710 Technical Exception <No>
specified in "Uses" "Uses"
Missing PIN data as
730 Same as 710 Technical Exception <No> Missing PIN data as specified in "Uses"
specified in "Uses"
Missing OTP data as Missing OTP data as specified in
740 Same as 710 Technical Exception <No>
specified in "Uses" "Uses"
FMR value is not ISO compliant – bad
AUA to review biometric device header or other issue with templates.
800 Invalid biometric data being used and whether Technical Exception <No> FIR/IIR value is not compliant, or
templates are ISO compliant. templates could not be extracted for the
given FIR/IIR for matching purposes.
Missing biometric data Missing biometric data as specified in
810 Same as 710 Technical Exception <No>
as specified in "Uses" "Uses"
Ensure correct Aadhaar number is
entered and try authenticating
again. AUAapplication must ensure that the
correct aadhaar number isused while
Missing biometric data in transacting.
Your Biometric data is not
811 CIDR for the given After repeated failure, if the In case of repeated failures and if the
available in CIDR.
Aadhaar number resident is genuine, exception resident is genuine , exception handling
handling provision would need to mechanism must be followed to provide
be followed to provide service. service to resident.
API Error Provision Required in the Suggested Message to Suggested instructions to the
Description Probable Reasons
Code Application the User user
Please contact UIDAI helpdesk to
inform about the issue and to
understand the steps for the
updation of biometric information in
CIDR.

Resident has not done

"Best Finger Detection".
Application should You have not done best
Application should make
initiate BFD application finger detection so kindly Refer Aadhaar Best Detection API
provison to initiate BFD API call Resident has not done "Best Finger
812 to help resident identify proceed with the BFD specifications for details on the
to help Aadhaar holder to Detection".
their best fingers. See process for successful BFD process.
identify their best fingers.
Aadhaar Best Finger authentication.
Detection API
specification.

Missing or empty value

Missing or empty value for "bt" attribute
820 for "bt" attribute in Same as 710 Technical Exception <No>
in "Uses" element
"Uses" element

Invalid value in the "bt"

Invalid value in the "bt" attribute of
821 attribute of "Uses" Same as 710 Technical Exception <No>
"Uses" element
element
AUA application should call the
"bs" is Base-64 encoded signed
registered device capture
biometric hash of the bio record and
Invalid value in the “bs” function to obtain the bio record
formed by invoking the RD services
822 attribute of “Bio” element as well as the signature string
during the biometric capture method, if
within “Pid” (bs). "bs" is Base-64 encoded
the bs validation fails the error is
signed biometric hash of the
resulted
bio record
All factors of Auth are optional. Hence,
No authentication data it is possible to attempt an auth without
found in the request (this Application should validate that specify any values for any of the factors
corresponds to a User giveatleast one auth – Pi, Pa, Pfa, Bio or Pv. If none of
901 Technical Exception <No>
scenario wherein none factor before encryption of PID these elements have any value that
of the auth data – Demo, block. can be used for authentication
Pv, or Bios – is present) purposes, then, this error will be
reported.
API Error Provision Required in the Suggested Message to Suggested instructions to the
Description Probable Reasons
Code Application the User user

Invalid "dob" value in the

"Pi" element (this
Application should have a client
corresponds to a
level check to check dob date Please enter dob in
scenarios wherein "dob" Re-enter the date of birth or age "dob" attribute is not of the format
format and age business rules specified date format or
902 attribute is not of the and resend a new authentication "YYYY" or "YYYY-MM-DD", or the age
specified (Current Rule is that enter age in specified
format "YYYY" or request. of resident is not in valid range.
age should not be less than 0 range.
"YYYY-MM-DD", or the
and greater than 150 years)
age of resident is not in
valid range)

Invalid "mv" value in the

910 Same as 710 Technical Exception <No>
"Pi" element
Invalid "mv" value in the
911 Same as 710 Technical Exception <No>
"Pfa" element

912 Invalid "ms" value Same as 710 Technical Exception <No>

Both "Pa" and "Pfa" are

present in the
Attempt to use Pa and Pfa both in the
913 authentication request Same as 710 Technical Exception <No>
same request can result in this error.
(Pa and Pfa are mutually
exclusive)
Technical error that are UIDAI server side issues. UIDAI tech
AUA/ASA should call UIDAI
930-939 internal to authentication Technical Exception <No> support to review the scenario and take
tech support.
server appropriate action.
Unauthorized ASA
940 AUA should consult ASA. Technical Exception <No>
channel
Unspecified ASA
941 AUA should consult ASA. Technical Exception <No>
channel
OTP store related No action required contact auth
950 Technical Exception <No> No action required contact auth support
technical error support
Biometric lock related No action required contact auth
951 Technical Exception <No> No action required contact auth support
technical error support
AUA to review the auth client to
Currently this error is not reported.
980 Unsupported option check whether any dev feature Technical Exception <No>
Can be used in future.
is being used in prod
Aadhaar suspended by No action required contact auth
995 No action required contact auth support
competent authority support
API Error Provision Required in the
Description
Code Application
AUA Application must consume
the ACTN attribute of the API
Aadhaar Cancelled (
response , ACTN attribute
996 Aadhaar is not in
provides necessary feedback to
authenticable status )
the end AUA/resident on the
next action.
AUA application should have
Aadhaar Suspended (
mechanism to handle this
997 Aadhaar is not in
scenario as Aadhaar number is
authenticable status )
valid but its status is not active.
AUA application should have a
Invalid Aadhaar Number client level validation for
998 0r Non Availability of Aadhaar number validity ie.
Aadhaar data should be 12 digits and
conform to Verhoeff algorithm.
No action required contact auth
999 Unknown error
support
Suggested Message to Suggested instructions to the
Probable Reasons
the User user
Aadhaar is not in authenticable status.
Resident should re-enroll. **Please see ACTN attribute in
response for actionable by the resident.
Aadhaar is not in Auhenticatable
Your Aadhaar number status.
status is not active. Kindly **Please see ACTN attribute in
contact UIDAI Helpline. response for actionable by the
resident.
If client level validations are done then
Ensure you have entered Aadhaar number does not exist in
Ensure you have entered correct
correct Aadhaar number. CIDR. Please retry with correct
Aadhaar number. Please retry with
Please retry with correct Aadhaar number after sometime.
correct Aadhaar number after
Aadhaar number after
sometime. **Please see ACTN attribute in
sometime.
response for actionable by the resident.
Please contact authsupport team of
Technical Exception <No>
UIDAI