ABDM Integration: Build vs Buy vs SDK (2026 Guide to Choosing Your Approach)

There are three ways to add ABDM to your software: build the integration yourself, buy it as part of a platform or managed service, or use an SDK or the NHA wrapper and run it on your own servers. Build if ABDM is core to a product you sell and you have backend developers who can own asynchronous callbacks, FHIR bundles and Fidelius encryption. Buy if you have no developers, or have a partner such as our ABDM integration services team build it with you. Use an SDK, or one shared ABDM service layer, if you have a small team, several systems that need ABDM, or patient data that must stay on your infrastructure.

Whichever you choose, the finish line is the same: NHA's test cases, a WASA security audit and sandbox exit with at least two milestones. This guide compares the three approaches on what they actually involve, what each costs you in effort and control, and how to decide, with a flowchart you can use in a leadership meeting. Updated September 2026.

Build, buy or SDK in one table

Watch: ABDM Integration: Build, Buy or Partner? Six Questions to Ask Your Vendor (5:28). Three ways to get ABDM into hospital software, and six questions that show who really owns it: who owns the source, who holds the keys and the callback domain, can it move, what is logged, how it handles lost callbacks and consent, and what happens if the vendor goes away.

If you want an experienced team to take one of these paths with you, our ABDM integration services cover all three: building inside your product, adding a shared ABDM service layer, or reviewing a vendor or SDK choice before you commit.

What every approach must handle: the ABDM technology stack

Whatever you choose, something in your system has to speak the ABDM technology stack: a gateway session, asynchronous REST APIs with callbacks, the ABHA service, FHIR records, Fidelius encryption and consent artefacts. The gateway protocol is simple; the asynchronous callback model is where most of the engineering goes.

For the order in which these come together, see our ABDM integration step-by-step guide.

Building ABDM integration yourself: where the time really goes

Building yourself gives full control and no licence, but most of the effort is not where teams expect it. M1 (ABHA) is ordinary REST work. M2 is where schedules slip, because it combines three hard problems at once.

• Asynchronous callbacks. Discovery, linking, consent and data requests all arrive at your bridge URL. You need a queue, request-ID correlation, retries and monitoring, and a lost consent notification is not resent by ABDM. Our callback debugging guide covers the failure patterns.
• FHIR bundles. Each document type has its own NRCeS profile, coding systems and required fields. "It parses" is not the bar; passing validation and NHA's review is. See ABDM FHIR bundles explained.
• Fidelius encryption. The official examples use BouncyCastle in Java and C#. Porting to Node.js, Python, Go or PHP means reproducing the curve arithmetic and key derivation exactly, or the other side cannot decrypt. Our Fidelius in Node.js guide shows a working port.

After go-live you also own every ABDM change. The V2 to V3 move changed endpoints, authentication and callback payloads; our V3 migration guide lists what broke. Building makes sense when ABDM is part of a product you sell to many hospitals, so the effort is shared across customers.

Buying ABDM: platforms, managed services and partners

Buying comes in three forms, and they are not interchangeable:

1. An HMIS or EMR with ABDM built in. The fastest route for a hospital that is choosing new software anyway. You inherit the vendor's milestones and their production credentials.
2. A managed ABDM service. Your existing software calls a simpler API and the vendor talks to ABDM. It removes FHIR and Fidelius work from your team, at the cost of a recurring fee and dependence on the vendor's uptime, pricing and roadmap.
3. An implementation partner. A team builds ABDM into your software as a project and hands over the code. You keep ownership; you pay once for the build and choose who maintains it.

Before you buy, ask where patient data is processed and stored, who holds the production credentials, how the vendor handles ABDM API changes, and how you would leave. Data residency matters more than it looks: under a managed service, health records may pass through infrastructure you do not control.

Using an SDK or the NHA wrapper

An SDK or wrapper handles the hard internals (token management, callback plumbing, FHIR builders, Fidelius) while your code and data stay on your servers. Two kinds exist:

• The NHA ABDM wrapper. NHA's own open-source project: a Spring Boot application packaged with MongoDB that you deploy next to your HMIS. According to its README it abstracts the HIP and HIU workflows of Milestones 2 and 3 behind simpler interfaces, and your HMIS exposes interfaces the wrapper calls to fetch records. It is free and official. Check its activity and open issues on GitHub before relying on it: when we checked in September 2026, the last code push was in February 2025 and 34 issues were open.
• Language SDKs. Libraries that run inside your application. We publish an open-source TypeScript SDK for the ABDM V3 APIs covering ABHA, HIP, HIU, consent and health information exchange, and we have built the same flows in .NET for hospital software that runs on it.

What an SDK does not do for you: pass NHA's test cases (they check your screens and behaviour, not just API calls), host your callback endpoint, or get your WASA audit done. Those stay with you on every path except buying a platform that already has production credentials.

One ABDM service layer for hospitals with several systems

Hospitals rarely run one system. Registration, lab, radiology, pharmacy and billing often come from different vendors, and each one can create records that belong in ABDM. Integrating ABDM into each separately multiplies the work and the testing.

The pattern we use is a single ABDM service layer that owns ABHA, care-context linking, consent, FHIR building, Fidelius and the callback queue. Every other system calls a few simple internal APIs, one bridge URL receives all callbacks, and the ABDM behaviour is tested once. It can be built with an SDK, the NHA wrapper or your own code; the point is that it is built once.

How to decide: the build vs buy vs SDK flowchart

Four questions settle most decisions. Answer them in order.

1. Do you have backend developers? If not, buy: an HMIS with ABDM built in, or a managed service.
2. Must patient data stay on your servers? If not, a managed service is an option; if it must, build or use an SDK.
3. Do several systems need ABDM? If yes, build one ABDM service layer and have every system call it.
4. Is there an SDK for your stack? If yes, use it inside your application. If not, build it yourself or run a small sidecar service in a language that has one, and call it from your application.

Choosing by technology stack

Matching the approach to the milestones you need

• M1 only (ABHA at registration). Straightforward REST work that most teams can build. But M1 alone cannot exit the sandbox, so you either add a second milestone or use software whose ABDM stack has already exited the sandbox.
• M1 and M2 (hospitals, clinics, labs). The common combination for anyone who creates records. M2 is where an SDK or a service layer saves the most time.
• M1 and M3 (apps and payers that read records). Consent requests, Fidelius decryption and purge on revocation. M3 does not require M2 if your software never shares records it holds.
• All three. Build the callback and consent infrastructure once and share it across M2 and M3.

Questions to ask a vendor, SDK or partner

1. Which milestones does it cover today on the V3 APIs, and which test cases has it passed in the sandbox?
2. Where is patient data processed and stored, and who holds the production credentials?
3. How are callbacks hosted, monitored and replayed when something is lost?
4. How quickly did it adapt to the last ABDM API change?
5. Which FHIR document types does it generate, and against which NRCeS profile version?
6. How is consent revocation handled: are data and keys purged?
7. What does leaving look like: can you export links, consents and records?

What drives the cost of each approach

We do not publish price ranges, because they depend on your software more than on the approach. These are the cost drivers to estimate for your own case:

The WASA security audit is carried out by a CERT-In empanelled auditor on every path where you hold the production credentials yourself. Our ABDM certification process guide covers the audit and NHA testing in detail.

Risks of each path, and how to reduce them

• Build: underestimating M2. Teams that finish M1 quickly often plan M2 the same way and then spend months on callbacks and validation. Reduce the risk by building callback handling, request-ID logging and monitoring first.
• Buy: vendor dependence. Put data residency, credential ownership, API-change handling and an exit plan into the contract.
• SDK: integration surface. An old monolith can make even a good SDK hard to fit. Define a clean internal boundary (often the service layer above) before integrating.
• All paths: the two-milestone rule. Sandbox exit needs at least two milestones, so plan M1 plus M2 (or M1 plus M3 for apps that only read records) from the start. See why M1 alone cannot exit the sandbox.

What we have seen across ABDM projects

We have built ABDM on all three paths: inside an existing .NET HMIS that has cleared sandbox exit and runs ABDM in production, as an open-source TypeScript SDK, and as a shared ABDM service layer that runs inside the hospital's own infrastructure. In a live M3 test against the ABDM sandbox in September 2026, every value in every test record arrived intact at the requesting side: 526 of 526 values and 30 of 30 attachments. The choice of approach mattered less than two habits: treating callbacks as the core of the product, and following an already-certified implementation screen by screen when a test case was ambiguous. For developers taking the .NET path, our guide to FHIR integration in .NET offers a language-specific next step.

Not sure which path fits your product? Our ABDM integration team can review your stack, systems and data rules and recommend one. Talk to our team for a scoped assessment.