Quickstart
You create a test ABHA here, with your own sandbox credentials, in four calls that run live from this page: create a session, encrypt the Aadhaar number, request an OTP, create the account.
Before you start
Have your clientId and clientSecret
(get them) and a sandbox test identity: an
Aadhaar number issued to you for sandbox use, with access to the mobile number registered
against it, because that is where the OTP goes.
Create a gateway session
Exchange your sandbox client id and secret for the access token every later call carries.
Encrypt the Aadhaar number
Fetch the ABDM public certificate, then encrypt the number here in your browser. The ABHA service never accepts a raw Aadhaar number.
Request and enter the OTP
NHA sends a one time password to the mobile number registered against that Aadhaar, and hands you a transaction id. Type the code back here, with the mobile number the new account should carry.
Create the ABHA
Send the code from step 3 with its transaction id. This creates a real account on the sandbox, so send it once.
How this fits your product
The registration desk is where most of this lands. Your intake screen either finds the patient's existing ABHA or creates one on the spot, which is the flow you just ran. The token from step 1 is not specific to ABHA creation: it is the token every later ABDM call carries, so whatever your system does next starts by getting one. Once the patient has an ABHA, records attach to it, and that is a different module.
- Session, step 1. Every call in every module carries this token. Mint it once, watch
expiresIn, refresh it before it lapses. - Identity, M1. Creating and verifying an ABHA at intake, which is the runner above.
- Linking, M2. Telling ABDM that you hold records for that ABHA, and sending them when they are asked for.
- Reading, M3. Requesting consent and fetching records held by somebody else.
Your integration path sets out which of these you need and in what order.
If a call fails
Under the four steps you get the request each call sent and the response it got back, including the error body. A 401 on the session call means the request was not authorised, so see Everything returns 401.
A rejected loginId may be the encryption rather than the number. The runner encrypts
with the padding the certificate declares rather than one you pick, and the certificate's
own response is in the log below, so you can read which one it asked for.
Encryption sets out what is confirmed and what is
not.