ABHA creation, Aadhaar OTP
Send an OTP to begin or continue an enrolment
The first call of most enrolment flows, and the one people reuse without noticing. What it does depends on scope and loginHint.
Certification cases CRT_ABHA_101, CRT_ABHA_102, CRT_ABHA_103, CRT_ABHA_104, CRT_ABHA_105, CRT_ABHA_106, CRT_ABHA_107, CRT_ABHA_108, CRT_ABHA_109, CRT_ABHA_112, CRT_ABHA_113, CRT_ABHA_114, CRT_ABHA_115, CRT_ABHA_201, CRT_ABHA_202, CRT_ABHA_203, CRT_ABHA_204, CRT_ABHA_205, CRT_ABHA_206, CRT_ABHA_207, CRT_ABHA_208, CRT_ABHA_209, CRT_ABHA_210, CRT_ABHA_401, CRT_ABHA_402, CRT_ABHA_403, CRT_ABHA_404, CRT_ABHA_405, CRT_ABHA_406, CRT_ABHA_407, CRT_ABHA_408, CRT_ABHA_410, CRT_ABHA_411
Starting an enrolment: scope is ["abha-enrol"], loginHint is aadhaar, loginId is the encrypted Aadhaar number and otpSystem is aadhaar. The OTP goes to the mobile registered with Aadhaar.
Verifying a mobile or email afterwards: scope gains mobile-verify or email-verify, otpSystem becomes abdm, and you pass the txnId from the enrolment you are continuing.
The Unique UUID v4 per request. Used for idempotency and distributed tracing. Generate a fresh UUID for every call. ISO 8601 UTC timestamp of the request. The transaction id to carry into the next step, with a message.loginId is encrypted, never the raw value. Encrypt it against the ABDM public key first.Authorizations
Authorizationbearer tokenRequiredaccessToken from POST /api/hiecm/gateway/v3/sessions. Send it as Authorization: Bearer <ACCESS_TOKEN>.Headers
REQUEST-IDstringRequiredTIMESTAMPstringRequiredBody
scopestring[]RequiredloginHintstringRequiredloginIdstringRequiredotpSystemstringRequiredtxnIdstringResponses
200