How to Integrate ABHA in a Telemedicine App

To integrate ABHA in a telemedicine app, you register on the ABDM sandbox, get a gateway access token, and fetch ABDM’s public key. You then create or verify the patient’s ABHA through the V3 enrollment and login APIs, with the Aadhaar number and OTP RSA-encrypted before you send them. That covers ABDM milestone M1. To share and fetch consultation records you add M2 and M3, then pass NHA’s functional tests and a security audit before you get production keys.

Here is why it matters in practice. A patient in Kozhikode joins a video consultation, and the doctor asks for last year’s HbA1c report. Without ABHA, the patient digs through WhatsApp photos while the clock runs. With ABHA linked, the patient approves a request on their phone and the report shows up in the doctor’s screen. That small moment is what you are building.

The API calls below follow ABDM’s V3 APIs, which replaced the older V1 and V2 flows.

Quick answer

• What ABHA is: a 14-digit health ID under the Ayushman Bharat Digital Mission (ABDM), run by the National Health Authority (NHA)
• What your app does with it: create a new ABHA, verify an existing one, show the ABHA card, and link consultation records
• Which milestone: ABHA creation and verification is M1. Sharing records is M2 (HIP). Fetching records is M3 (HIU)
• Where you build it: the ABDM sandbox, using V3 APIs
• What you need to go live: NHA functional testing, a security audit by a CERT-In empanelled agency, and production credentials

Why ABHA integration matters for telemedicine in 2026

ABHA is no longer a niche ID. The Health Ministry told the Lok Sabha that 95.99 crore ABHA IDs had been created by 31 July 2026. At the ABDM Mission Steering Group meeting on 10 July 2026, the ministry also reported more than 105 crore linked health records, 5.33 lakh registered facilities and 2.72 lakh facilities using ABDM-enabled software.

For a telemedicine business, that changes three things:

• Patients already have an ABHA
  Many of them got one at a government hospital or a camp. Asking them to retype their details feels slow when a QR scan or OTP would do.
  
• Hospital clients ask for it
  Hospitals and clinics that work with government schemes increasingly expect ABDM-ready software.
  
• Doctors get better context
  Past prescriptions and reports reach the doctor with consent, so the consultation is shorter and safer.

If you want the business view of ABDM, including milestones, consent and certification, read our companion guide on ABHA and ABDM integration for telemedicine apps. This post stays practical: what your developers actually call.

ABHA integration milestones: M1, M2 and M3

Start with M1 and get it working with real patients first. Note that NHA has told sandbox users on its developer forum that at least two milestones are needed before the sandbox exit demo, so plan M1 and M2 together.

ABHA API integration: the V3 calls, step by step

The base hosts in the sandbox are abhasbx.abdm.gov.in/abha/api for ABHA calls and dev.abdm.gov.in for the gateway. Production uses different hosts and new credentials, which NHA issues after sandbox exit.

Step 1: Get sandbox access

Apply on the ABDM sandbox with your organisation details and the use case (for example, a teleconsultation app). After approval you receive a client ID and client secret. Store the secret in a secrets manager from day one, not in your code.

Step 2: Get a gateway access token

Call the gateway sessions API with your client ID and secret to get a bearer token. Every later call sends these headers:

Tokens expire, so cache the token and refresh it before expiry rather than calling the sessions API on every request.

Step 3: Fetch ABDM’s public key

Call GET /v3/profile/public/certificate. ABDM uses this key to protect Aadhaar numbers, mobile numbers and OTPs in transit. Cache it, but refresh it on a schedule, because the key is rotated.

Step 4: Encrypt the Aadhaar number

V3 rejects plain-text Aadhaar numbers and OTPs. Encrypt them with the public key using RSA with OAEP padding (SHA-1, MGF1), which ABDM’s integration support describes as RSA/ECB/OAEPWithSHA-1AndMGF1Padding. In Node.js:

import crypto from ‘node:crypto’;

// publicKeyPem: the key from /v3/profile/public/certificate, wrapped as a PEM public key
export function encryptForAbdm(value, publicKeyPem) {
  return crypto.publicEncrypt(
    { key: publicKeyPem, padding: crypto.constants.RSA_PKCS1_OAEP_PADDING, oaepHash: ‘sha1’ },
    Buffer.from(value, ‘utf8’)
  ).toString(‘base64’);
}

Step 5: Request the Aadhaar OTP

POST /v3/enrollment/request/otp

{
  “txnId”: “”,
  “scope”: [“abha-enrol”],
  “loginHint”: “aadhaar”,
  “loginId”: “<encrypted Aadhaar number>”,
  “otpSystem”: “aadhaar”
}

The response returns a txnId and a message saying the OTP went to the mobile number linked to the patient’s Aadhaar. Keep the txnId for the next call.

Step 6: Verify the OTP and create the ABHA

POST /v3/enrollment/enrol/byAadhaar

{
  “authData”: {
    “authMethods”: [“otp”],
    “otp”: {
      “txnId”: “<txnId from step 5>”,
      “otpValue”: “<encrypted OTP>”,
      “mobile”: “<patient’s mobile number>”
    }
  },
  “consent”: { “code”: “abha-enrollment”, “version”: “1.4” }
}

If the mobile number the patient gives is different from their Aadhaar-linked number, ABDM asks you to verify it with a second OTP. Call /v3/enrollment/request/otp again with the mobile-verify scope and otpSystem set to abdm, then /v3/enrollment/auth/byAbdm.

Step 7: Let existing ABHA holders log in

Most of your patients will already have an ABHA. For them, use the login flow instead of enrollment: /v3/profile/login/request/otp, then /v3/profile/login/verify. Patients can log in with their ABHA number or mobile number.

Step 8: Show the ABHA card and accept Scan & Share

After creation or login, show the patient their ABHA card (/v3/profile/account/abha-card) and QR code (/v3/profile/account/qrCode). For clinics that also see walk-in patients, support Scan & Share, where the patient scans your facility’s QR code and their details reach your registration screen. The ministry reports nearly 24 crore Scan & Register tokens generated so far, so patients are used to it.

Step 9: Link consultations and fetch records (M2 and M3)

Once M1 works, each teleconsultation becomes a care context linked to the patient’s ABHA. When another provider asks with the patient’s consent, your app sends the records as an encrypted FHIR bundle. For M3, your doctor raises a consent request, the patient approves it in their PHR app, and the records arrive in your app.

One V3 change catches many teams: the gateway calls your server back. In V3, patient discovery is synchronous, and all callbacks arrive at a single bridge URL, with the X-HIP-ID header telling you which facility the request is for. Your backend needs public, reliable callback endpoints, not just outbound API calls.

From ABDM sandbox to production

1. Build and test M1, then M2 or M3, in the sandbox.
2. Pass NHA’s functional test cases for each milestone.
3. Get a web application security audit (WASA) from a CERT-In empanelled agency. Security firms also call the result a Safe-to-Host certificate.
4. Demo the software to NHA and submit the sandbox exit form.
5. Receive production credentials and switch to production hosts.
6. Register each facility on the Health Facility Registry. Certification covers the software, not each clinic that uses it.

NHA updates this process, so confirm the current steps on the ABDM sandbox site before you plan dates.

Common ABHA integration mistakes

1. Copying old tutorials
   Many blog posts, including our own earlier version of this one, show V1 or V2 paths. Build on V3 only.
   
2. Sending plain Aadhaar or OTP values
   V3 expects RSA-encrypted values. Plain values fail.
   
3. Wrong timestamps
   Send UTC in ISO 8601 format and keep your server clock synced with NTP. A drifting clock causes rejected requests that look random.
   
4. “Resource forbidden” (code 900908)
   This usually means your client ID is not subscribed to that API. Ask ABDM integration support to enable it instead of changing your code.
   
5. Credentials with hidden spaces
   Copying a client secret from the portal can add a trailing space or newline. Trim it.
   
6. Treating ABDM as outbound only
   M2 and M3 depend on your callback endpoints being reachable from the gateway.
   
7. Ignoring data protection
   ABHA flows handle Aadhaar numbers and health records. Plan consent logs, encryption and Indian data residency under the DPDP Act for healthcare apps from the start.

Designing ABHA screens patients actually finish

The API is only half the job. Patients abandon ABHA flows when they feel lost. A few habits help:

• Ask first whether the patient already has an ABHA, and default to login, not creation
• Say where the OTP will go (“to the mobile linked with your Aadhaar”) before you send it
• Offer Malayalam, Hindi, Tamil and other languages your patients use
• Explain consent requests in plain words: who wants which records, for how long
• Let the patient continue the consultation if ABHA fails, and retry later

How Sigosoft builds ABHA-ready telemedicine apps

Sigosoft builds telemedicine apps for clinics, hospitals and health startups. Our Medicino app, for example, combines doctor booking, video consultation and medicine delivery in one product. For Indian clients, we plan ABHA into the first release, not as a later add-on.

In an ABHA project, our team handles:

• The sandbox journey: application, client setup and milestone planning (M1 with M2, or M1 with M3)
• The M1 flows: ABHA creation, login, card, QR and Scan & Share, built on V3
• The callback layer: reliable bridge endpoints for M2 and M3, with an audit log for every consent and transfer
• Security and compliance: preparing for the CERT-In empanelled security audit, plus DPDP Act consent and data handling through our compliance management services
• The rest of the product: WebRTC video calls, e-prescriptions, payments and secure cloud architecture

If you are planning a new product, our guide on building a telemedicine MVP without rebuilding it later explains how to leave room for ABDM from the start.

FAQ

What is ABHA integration?

It lets your app create or verify a patient’s ABHA number and link their health records to it. In ABDM terms, this is milestone M1.

Which ABHA API version should I use in 2026?

Use the V3 APIs. Older V1 and V2 flows are legacy, and V3 requires RSA-encrypted Aadhaar numbers and OTPs.

Is ABHA integration mandatory for telemedicine apps?

There is no general rule that every telemedicine app must integrate ABHA. In practice, hospitals and government programmes increasingly expect ABDM-ready software, so it affects which clients you can serve.

How long does ABHA integration take?

M1 alone can be built in weeks if your team knows the sandbox. The full path to production also depends on NHA’s functional testing, the security audit and the demo, so plan in months, not weeks.

Do I need M2 and M3 as well?

M1 covers the ABHA itself. To share consultation records you need M2, and to fetch records from other providers you need M3. NHA has asked for at least two milestones before sandbox exit.

Do I need a certified partner to integrate ABHA?

No, any registered organisation can apply for sandbox access. A partner who has worked in the sandbox mainly saves you time on the V3 details, callbacks and audit preparation.

Planning ABHA integration?

Tell us about your app, the milestones you need and your launch date. Email [email protected], call +91 98462 37384, or send your requirements, and we will reply with a project roadmap.

Sources

• ABHA count, 95.99 crore as of 31 July 2026 (Lok Sabha answer): Kashmir Life
• ABDM figures from the 10 July 2026 Mission Steering Group meeting: Indian Pharma Post, The Statesman
• ABHA IDs by year, 2021 to 2025: Digital Health News, May 2026
• V3 enrollment calls, headers and RSA OAEP encryption: ABDM developer forum, ABHA address flow; ABDM developer forum, M1 creation for V3; ABHA V3 API reference guide (Medium)
• V3 login, card and certificate endpoints: PSMRI FHIR-API configuration
• Sandbox hosts, production hosts and certification steps: Nirmitee, ABDM integration step by step (2026)
• V3 synchronous discovery and single bridge URL: Nirmitee, V3 migration guide
• Common errors (timestamps, credentials, 403): Nirmitee, 25 common errors; ABDM developer forum, code 900908
• Two milestones before sandbox exit: ABDM developer forum
• Security audit by a CERT-In empanelled agency: Astra, December 2025
• DHIS extension to 30 June 2025: Shankar IAS Parliament

Written by

Praveen Soman CEO, Sigosoft

Technology entrepreneur and digital product strategist with a passion for building scalable software products and solving real-world business challenges. Enjoys exploring AI, emerging technologies, startups, and the ideas shaping the future of technology.

Connect on LinkedIn →