01Getting the HPR ID
An HPR ID is created from Aadhaar. The route that works through the API is HPR’s link flow: HPR returns a URL to ABDM’s own Aadhaar page, the professional enters their Aadhaar number and the OTP UIDAI sends, and the software collects the verified details afterwards. An OTP typed into a third-party form is not accepted at HPR’s verify step, however correct it is.
Then a mobile number, verified by a second OTP unless it is the
Aadhaar-linked one, a choice of HPR address, a password, and an email,
which HPR requires even where its documentation marks it optional. The
result is an HPR ID number in the form 71-1234-5678-9012 and
an address such as name@hpr.abdm.
One Aadhaar can hold one HPR ID. If one exists, HPR refuses to create a second, and the right move is to sign in with the existing one.
02Categories and what they allow
Every HPR ID carries a category and a sub-category, and they are not labels. They decide which council will verify the record and what may be attached to the ID. HPR’s clinical list is Doctor (code 1, with sub-categories such as Modern Medicine, Dentist, Ayurveda and Unani), Nurse (code 2) and Pharmacist (code 6). Its administrative list is Facility Manager (code 100) and Administrator (code 11).
HPR’s professional registration takes a doctor’s or a nurse’s record and nothing else. Filed against a Facility Manager ID it fails with HPR’s generic error and no field named. A person who manages a hospital in HFR and practises in it needs both IDs, on different Aadhaar-holders or with NHA’s help, and the software has to check the category before sending.
03The professional record
HPR takes the whole record in one call: personal details it already holds from Aadhaar, a salutation and the languages spoken, the council registration with its certificate, every qualification with its degree certificate, and the current place of work with an optional proof. There is no per-section save; the sections are collected and sent together, and the answer is a reference number once the record is queued for verification.
- Council registration: the council from HPR’s list, the registration number and date, whether it is permanent or renewable, and the certificate.
- Qualifications: for each, the course, the state, the college and the university from HPR’s lists, the year awarded, and the certificate.
- Work: whether currently working, private or government, the nature of the work, and the facility, by HFR id where it has one.
04The codes HPR insists on
HPR’s field table types most of the record as integers from its master data, and it means it. The salutation is a code. Languages are a comma-joined string of ids. States and districts are HPR’s ISO codes, which differ from the ids its own college list is asked by. The college and university are ids from lists keyed by state and college.
The degree is the one that catches people. HPR wants its course id, and the integrator gateway does not publish a course master, so a form that offers a free-text box sends “MBBS” and gets HIS-500. In HPR’s master MBBS is course 4060, BDS 4074, BAMS 4079 and MD 3841, and the list runs to more than two thousand entries across the systems of medicine, with duplicates. The connector bundles that list and offers it as a searchable picker, and resolves a name typed through the API to the canonical row.
05Place of work
A facility HFR knows is named by its HFR id, with a department and a designation; a facility HFR does not know is described by name, address, PIN, state, district and type. Sending both halves is how a work declaration attaches to the wrong hospital. Government work needs a ministry from HPR’s list and a proof-of-work document.
06Verification and what follows
Once submitted, the council named in the record verifies it, which takes days rather than minutes. The status can be read back from HPR, and a verified record carries the practitioner’s name, council and speciality as HPR holds them, which is what a hospital’s roster should show. A record HPR already holds is updated with the same call at a different path, and the update restates every section: sending only the changed one silently blanks the rest.
07Reading HPR’s refusals
- HIS-500, “An unexpected error has occurred”: a value in a shape HPR cannot read. Check the degree is a course id, the college and university are ids from HPR’s lists, the flags are “1” and “0” rather than true and false, and the account’s category allows the record.
- HIS-1029, “already exist with aadhaar number”: sign in with the existing HPR ID instead of creating one.
- HIS-601: the email is required for a new ID.
- “X is mandatory” lists: HPR’s own field names; map them back to your form.
- “Failed to retrieve aadhaar transaction details”: the OTP route is not the one HPR completes; use the link flow.
The connector applies these checks before a record travels and words the refusals that still come back, so a desk sees the field, not the code. See HPR integration.