Jentic publishes the only available OpenAPI specification for Gateway, keeping it validated and agent-ready. The NDHM Gateway is the central hub of India's National Digital Health Mission that routes interactions between Consent Managers (CMs), Health Information Providers (HIPs), and Health Information Users (HIUs). The 48-endpoint surface covers care-context discovery, account linking, consent flows, health-data flow, identification, and monitoring — split across CM-facing, HIP-facing, and HIU-facing roles. Authorisation uses signed JWTs distributed via the Gateway's openid-configuration and certs endpoints.
48 endpointsJentic publishes the only available OpenAPI specification for Gateway, keeping it validated and agent-ready. The NDHM Gateway is the central routing hub of India's National Digital Health Mission, brokering interactions between Consent Managers, Health Information Providers, and Health Information Users. It exposes 48 endpoints grouped into discovery, link, consent flow, data flow, monitoring, and session management, plus the well-known OpenID configuration and JWT signing certificate endpoints. Participants register with the Gateway and call its APIs to find each other, raise consent, and exchange encrypted health records under the NDHM 0.5 specification.
48 endpointsJentic publishes the only available OpenAPI specification for Health Data Consent Manager, keeping it validated and agent-ready. The Health Data Consent Manager (CM) is the patient-facing component of India's NDHM that aggregates health information across Health Information Providers and shares it with Health Information Users based on the patient's explicit consent. The 22-endpoint surface covers care-context discovery responses, consent request initiation and fetching, health-information request handling, link confirmation, and heartbeat monitoring.
22 endpointsJentic publishes the only available OpenAPI specification for Health Data Consent Manager, keeping it validated and agent-ready. The Health Data Consent Manager API implements India's National Digital Health Mission (NDHM) Consent Manager role, allowing patients to authorise the aggregation and sharing of medical records across hospitals, diagnostic labs, insurers, and researchers. It exposes endpoints for raising consent requests, fetching signed consent artefacts, notifying Health Information Providers and Users about consent state changes, and orchestrating the resulting data flow. The 22 endpoints cover discovery, linking, consent lifecycle, and health information transfer flows defined in the NDHM 0.5 specification.
22 endpointsJentic publishes the only available OpenAPI specification for Health ID Service, keeping it validated and agent-ready. The NDHM Health ID Service issues and manages the ABHA Health ID — a unique identifier used across India's National Digital Health Mission to issue, access, and share health records with patient consent. The 73-endpoint surface covers Aadhaar and mobile-OTP based registration, KYC, profile management, password and credential recovery, health-facility linkage, integrated programs, search, and Health ID card generation in PDF, PNG, and SVG formats.
73 endpointsJentic publishes the only available OpenAPI specification for Health ID Service, keeping it validated and agent-ready. The Health ID Service is the ABHA (formerly Health ID) issuance and lifecycle API of India's National Digital Health Mission, allowing citizens to register a unique health identifier using either Aadhaar or a mobile number. The 73 endpoints cover OTP-based registration, KYC verification, profile updates, password management, ABHA card generation in PDF, PNG, and SVG formats, QR code retrieval, and integrated programme tagging. It is the citizen-facing identity layer underneath the NDHM Consent Manager and Gateway.
73 endpointsJentic publishes the only available OpenAPI specification for Health Repository Provider Specifications for HIP, keeping it validated and agent-ready. This spec bundles the 30 endpoints that an entity acting as a Health Information Provider (HIP) must implement to participate in India's NDHM network. It draws operations from the Gateway and Health Repository specs and groups them so HIPs can implement only what is required of them — covering care-context discovery, account linking, consent-grant notifications, health-information data requests, encrypted transfers, and heartbeat monitoring.
30 endpointsJentic publishes the only available OpenAPI specification for Health Repository Provider Specifications for HIP, keeping it validated and agent-ready. This specification covers the endpoints a Health Information Provider must implement and call to participate in India's NDHM network as a record-holding party — typically a hospital, lab, or clinic. The 30 endpoints cover discovery callbacks, care-context linking, consent notification, encrypted health information transfer, and Gateway-facing helpers such as the certs and OpenID configuration. It is the producer side of the NDHM data flow.
30 endpointsJentic publishes the only available OpenAPI specification for Health Repository Provider Specifications for HIU, keeping it validated and agent-ready. This spec bundles the 32 endpoints that an entity acting as a Health Information User (HIU) must implement and consume to participate in India's NDHM network. It draws operations from the Gateway and Bridge specs and groups them under identification, consent flow, data flow, subscriptions, and monitoring — making it clear which calls an HIU originates against the Gateway and which callbacks the Gateway invokes against the HIU.
32 endpointsJentic publishes the only available OpenAPI specification for Health Repository Provider Specifications for HIU, keeping it validated and agent-ready. This specification covers the endpoints a Health Information User must implement and call to participate in India's NDHM network — typically an insurer, doctor, telehealth platform, or research entity that needs consented access to patient records. The 32 endpoints cover identification, consent flow callbacks, health information requests and on-request callbacks, encrypted record receipt via /v0.5/health-information/transfer, and Gateway-facing helpers such as certs and OpenID configuration.
32 endpointsStep 1: Jentic One Host machine
# On the machine that will host your Jentic One instance:
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | shStep 2: Agent machine
# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh
jentic register # connects your agent to your Jentic One instanceJentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.