National Health AuthorityNHA Docs

Command Palette

Search for a command to run...

Network & Protocol

The shared UHI protocol — the context block, the ACK pattern, request signatures, and the Gateway endpoints.

Every UHI service uses the same protocol envelope. This page describes the parts that all services share. Read this page before you read a service page.

The asynchronous pattern

UHI API calls are asynchronous. A request never returns business data in the HTTP response.

  1. The sender posts a request, for example search.
  2. The receiver returns an HTTP 200 ACK at once. The ACK confirms receipt only.
  3. The receiver processes the request.
  4. The receiver posts the result to the callback endpoint of the sender, for example on_search. The Gateway delivers callbacks to the consumer_uri of the EUA.
Standard ACK response
{
  "message": {
    "ack": {
      "status": "ACK"
    }
  },
  "error": {}
}

A receiver that rejects a request returns a NACK with an error object:

FieldTypeMandatoryDescription
typestringYesThe error type
codestringYesThe UHI error code
pathstringNoThe JSON path to the field that caused the error
messagestringNoA human-readable error description

The context block

Every UHI API call carries a context block. The block routes and correlates the message.

FieldTypeMandatoryDescriptionExample
domainstringYesThe service domain codenic2004:85111
countrystringYesThe ISO 3166-1 country code. Always INDIND
citystringYesThe city STD code with the std: prefixstd:011
actionstringYesThe API action name. It must match the endpointsearch
core_versionstringYesThe UHI core protocol version. Currently 0.7.10.7.1
consumer_idstringYesThe unique ID of the EUA on the networkeua-nha
consumer_uristring (URI)YesThe HTTPS callback URL of the EUA. It must share the domain of consumer_idhttps://uhieuasandbox.abdm.gov.in/api/v1/euaService
provider_idstringConditionalThe unique ID of the HSPA. Required in all P2P calls. Not required in searchhspa-nha
provider_uristring (URI)ConditionalThe base URL of the HSPA. Required in all P2P calls. Taken from the on_search contexthttps://hspasbx.abdm.gov.in/api/v1
transaction_idstring (UUID)YesThe ID that links all calls in 1 transactione9a19230-f951-11ec-b135-53aea776f66b
message_idstring (UUID)YesA new UUID for each request and callback cycled29a41e0-a412-4b21-9c1f-0b3a54b18a1c
timestampstring (ISO 8601)YesThe time of request generation, RFC 3339 format2026-06-18T06:52:13.969464Z
keystringNoThe encryption public key of the sender
ttlstring (ISO 8601)NoThe duration for which the message is validPT30S

Keep the transaction_id constant

The transaction_id must stay identical across all API calls in 1 transaction lifecycle. A mismatch prevents response correlation. The message_id changes with each call.

Authentication and signatures

You must sign every UHI API call. The network uses 2 cryptographic components:

ComponentDetail
Hash algorithmBLAKE-512, applied to the request body to compute the digest
Signature algorithmEd25519
Authorization headerThe signature envelope from the sender. See the format below
X-Gateway-Authorization headerThe same format. The Gateway adds it to each forwarded request. The keyId has the gateway-nha prefix
Authorization header format
Authorization: {"headers":"(created) (expires) digest","algorithm":"ed25519","keyId":"<subscriber-id>|<key-id>|ed25519","created":"<epoch>","expires":"<epoch>","signature":"<base64-sig>"}

Follow these steps to prepare your keys:

Generate the key pair

Clone the NHA header generator utility. Run Generator.java with Option 1. The utility creates an Ed25519 key pair and the request headers.

Register the public key

Submit only the public key to the NHA in the onboarding form. Keep the private key secret.

Verify counterparties

Before each signed P2P call, look up the public key of the counterparty. Use the network registry lookup endpoint.

Gateway endpoints

The NHA develops and operates the UHI Gateway. You do not build these endpoints. You call them, or you receive calls from them.

EndpointCallerPurpose
POST /api/v1/uhi/searchEUAThe EUA sends a search. The Gateway broadcasts it to all registered HSPAs in the domain
POST /api/v1/uhi/on_searchHSPAThe HSPA sends its catalog. The Gateway forwards it to the consumer_uri of the EUA
POST /api/v1/uhi/on_confirm_auditHSPAThe HSPA sends an exact copy of each on_confirm payload for the audit log
POST /api/v1/uhi/on_update_auditHSPAThe HSPA sends an exact copy of each on_update payload for the audit log
POST /api/v1/uhi/on_cancel_auditHSPAThe HSPA sends an exact copy of each on_cancel payload for the audit log
POST /api/v1/uhi/on_status_auditHSPAThe HSPA sends an exact copy of each on_status payload for the audit log
POST /api/v1/networkregistry/lookupEUA or HSPALook up the public key and the details of a subscriber

Network registry lookup

POST/api/v1/networkregistry/lookup

Look up the registered public key of a network participant before you verify or generate an Authorization header. The type field accepts EUA, HSPA, or gateway.

cURL
curl -X POST "https://uhigatewaysandbox.abdm.gov.in/api/v1/networkregistry/lookup" \
-H "Content-Type: application/json" \
-d '{
  "subscriber_id": "nha.eua",
  "type": "EUA",
  "domain": "nic2004:85111",
  "country": "IND",
  "city": "std:08752",
  "pub_key_id": "nha.eua.k1"
}'

Sandbox environment

ParameterValue
Gateway base URIhttps://uhigatewaysandbox.abdm.gov.in
Reference EUA (consumer URI)http://uhieuasandbox.abdm.gov.in/api/v1/euaService
Reference HSPA (provider URI)https://hspasbx.abdm.gov.in/api/v1/hspa
Gateway Swaggeruhigatewaysandbox.abdm.gov.in/swagger-ui

Communication models

UHI uses 2 communication models. Each service page states which model applies to each call.

ModelRouteUse
BroadcastEUA → Gateway → all HSPAsDiscovery (search / on_search)
Point-to-Point (P2P)EUA ↔ HSPA, directBooking, fulfilment, and post-fulfilment calls

P2P calls do not pass through the Gateway

For P2P calls, the EUA calls the provider_uri of the HSPA directly. The EUA gets the provider_uri from the on_search response. Both sides still sign each request and verify each signature.

Sources

  • UHI Physical Consultation v2.0 — Onboarding Document (June 2026)
  • UHI PM-JAY HEM Onboarding v1.4