canonical: https://jentic.com/apis/ndhm.gov.in

# NDHM (Ayushman Bharat Digital Mission) APIs

NDHM (the National Digital Health Mission, now Ayushman Bharat Digital Mission) is India's national health-data interoperability network. Its APIs let developers issue and manage ABHA Health IDs, route consent and care-context discovery through the central Gateway, implement the Health Information Provider (HIP) and Health Information User (HIU) roles, and build a patient-facing Consent Manager that shares health records only with explicit patient consent. Jentic publishes and maintains the OpenAPI specifications for these services because NDHM does not itself publish maintained specs, keeping all five validated and agent-ready.

## For AI agents

An agent can register and manage ABHA Health IDs, initiate and fetch patient consent artefacts, discover care contexts across providers, and coordinate encrypted health-information transfers between HIPs, HIUs, and Consent Managers on the NDHM network.

## Scope

Use for: Building India NDHM/ABHA integrations: issuing Health IDs, routing consent and care-context discovery, and transferring consented encrypted health records between HIPs, HIUs, and Consent Managers.

Not supported:
- clinical decision support
- FHIR record storage
- insurance claim adjudication
- non-Indian health networks
- real-time streaming

## APIs

| API | Category | Endpoints | Description |
| --- | --- | --- | --- |
| NDHM Health ID Service | healthcare | 73 | Issue and manage ABHA Health IDs with Aadhaar or mobile-based registration, KYC, profile updates, password recovery, and Health ID card generation. |
| NDHM Gateway | healthcare | 48 | Route consent requests, care-context discovery, and health-data flows between Indian Consent Managers, Health Information Providers, and Health Information Users on the NDHM network. |
| NDHM HIU Specifications | healthcare | 32 | Implement the HIU role in the NDHM network - initiating consent requests, receiving encrypted health-information bundles, and responding to Gateway callbacks. |
| NDHM HIP Specifications | healthcare | 30 | Implement the HIP role in the NDHM network - handling care-context discovery, link confirmations, consent notifications, and encrypted health-information transfers. |
| NDHM Health Data Consent Manager | healthcare | 22 | Build a patient-facing Consent Manager that aggregates Indian health data across HIPs and shares it with HIUs based on explicit consent. |

## Which API to use

| Need | API | Why |
| --- | --- | --- |
| Create or look up a patient's ABHA Health ID | health-id-service | The Health ID Service handles Aadhaar and mobile-OTP registration, KYC, profile updates, and card generation; the other four use the ABHA it issues but do not create it. |
| Orchestrate consent and data flows across all roles | gateway | The Gateway is the central router that broadcasts discovery, consent, and data-flow messages between CMs, HIPs, and HIUs; use it when you need cross-role coordination rather than one participant's endpoints. |
| Build the app that requests and consumes patient records | health-repository-provider-specifications-for-hiu | The HIU specification bundles the consumer-side operations that initiate consent requests and receive encrypted bundles, distinct from the provider that serves the data. |
| Serve patient records as a provider | health-repository-provider-specifications-for-hip | The HIP specification bundles the provider-side discovery, linking, consent-notification, and encrypted-transfer callbacks a record-holding hospital must implement. |
| Run the patient-facing consent aggregator | health-data-consent-manager | The Consent Manager holds consent records and presents the patient UI for grant and revocation; the Gateway routes to it but does not itself store consent or show the patient interface. |

## Cross-API use cases

### Onboard a patient and request their records

A telehealth app issues a new ABHA Health ID for a patient through the Health ID Service, then acts as an HIU to initiate a consent request and pull the patient's cross-hospital history once they approve. Identity issuance and consented retrieval run as one flow.

Example prompt: Register the ABHA via POST /v1/account/aadhaar/verifyOTP, then as the HIU call POST /v0.5/consent-requests/init and on approval POST /v0.5/health-information/cm/request

### End-to-end consent and data delivery

An HIU asks the Consent Manager to raise a consent request, the patient approves, and the Gateway routes the fetched artefact and the subsequent encrypted data request between the parties. This spans the consumer, aggregator, and router roles.

Example prompt: Call POST /v0.5/consent-requests/init on the CM, then via the Gateway forward the artefact and listen for /v0.5/health-information/notify delivery events

### Provider and consumer record exchange

A hospital acting as an HIP responds to care-context discovery and transfers an encrypted bundle, while an HIU on the other side initiates the request and receives the data. The two role specs implement opposite ends of the same exchange coordinated by the Gateway.

Example prompt: On the HIP, reply to POST /v0.5/care-contexts/discover and POST /v0.5/health-information/transfer; on the HIU, initiate the consent request and decrypt the received bundle

### Consent Manager aggregating linked providers

A patient-facing Consent Manager receives care-context discovery responses from HIPs registered on the network and presents linkable records to the patient, using the Gateway as the router that broadcasts discovery to those providers.

Example prompt: Receive POST /v0.5/care-contexts/on-discover responses on the CM after the Gateway broadcasts discovery to registered HIPs, then confirm links via /v0.5/links/link/add-contexts

## Why Jentic

- **Setup:** Standing up NDHM by hand means signing JWTs, managing separate client credentials for the Health ID Service and each Gateway-facing role, and handling asynchronous discovery, consent, and data-flow callbacks yourself. Through Jentic you install once, import the NDHM specifications you need from the Jentic API Directory, store the credentials once, and your agent calls them.
- **Permission scoping:** NDHM operations carry Health IDs, consent ids, and care-context links in the signed request body rather than the URL path, so you scope the agent to the operations it needs per role. Because you pick that operation set, sensitive calls such as profile deletion, consent revocation, or health-information transfer stay unavailable unless you add them.
- **Credential handling:** Your NDHM JWT signing keys, Health ID bearer tokens, and per-role client credentials are stored once, encrypted, by your own Jentic One instance and injected at execution time. Private keys and raw tokens never enter the agent's prompt, logs, or context.
- **Discovery method:** Agents search the Jentic directory by intent such as 'register an ABHA Health ID' or 'initiate an NDHM consent request', and Jentic returns the matching operation with its input schema so the agent calls the right endpoint across roles without browsing the reference docs.

## Related vendors

- **UIDAI (Aadhaar)** — NDHM Health ID registration and KYC run on Aadhaar OTP verification issued by UIDAI.
- **HL7 FHIR** — NDHM health-information bundles are carried as FHIR resources, so FHIR tooling pairs with the transfer flows.
- **ABDM** — ABDM is the current umbrella program that continues the NDHM digital health stack and its ABHA identity.

## FAQ

### What is NDHM and how do its APIs fit together?

NDHM, now the Ayushman Bharat Digital Mission, is India's national health-data network. The Health ID Service issues the ABHA identifier for each patient, the Gateway routes messages between roles, the HIP and HIU specifications define the provider and consumer sides of record exchange, and the Consent Manager holds consent records and the patient-facing UI. Together they cover identity, consent, and consented data transfer.

### Does one credential work across all five NDHM APIs?

No. The Health ID Service uses a bearer JWT from its own OTP-based login, while the Gateway, HIP, HIU, and Consent Manager specs use signed JWTs issued through the Gateway and validated against its certificate endpoint. Participants share the Gateway trust model but each hold their own signing keys and client credentials.

### Why does Jentic publish these specs instead of NDHM?

NDHM does not publish maintained OpenAPI specifications for these services, offering only reference documentation and a deprecated third-party import. Jentic generates and maintains all five specs, validates them against the live sandbox, and keeps them current so agents and developers can call them through structured tooling.

### Which NDHM API should I start with?

Start with the Health ID Service if you need to issue or resolve a patient's ABHA identity. If you are building a relying app that consumes records, implement the HIU specification; if you hold patient records, implement the HIP specification; and use the Consent Manager to run the patient-facing consent aggregator. The Gateway ties these roles together.

### Are the NDHM APIs free and how do I get production access?

The services are operated by India's National Health Authority and are free for accredited integrators. The sandbox hosts are open for development and certification testing, while production access requires onboarding and role certification through the NHA developer portal.

### Can an AI agent operate across the NDHM network safely?

Yes. Through Jentic an agent can issue Health IDs, initiate and fetch consent artefacts, and coordinate encrypted transfers, while the JWT signing keys and client credentials stay in your own Jentic One instance and never enter the agent's context. You scope which operations the agent may call per role.