Build with AI
Use ABDM documentation with AI-assisted development tools. Developers may use supported AI-assisted tools to search ABDM integration guides, API references and milestone-specific documentation while building their solution.
Review all AI-generated code against the official ABDM documentation and test it in the Sandbox.
Every fact on this site is a public URL. There are three ways to put it in front of your agent, and they combine: the plugin is the one command that sets up the other two.
Use the documentation service while developing to find API endpoints, review request formats and understand error codes.
Follow the setup guide to connect a supported coding assistant with the ABDM documentation and begin using it for integration support.
Provide the coding assistant with the relevant references for ABHA, record linking, consent, registries or FHIR bundles.
Learn how to use AI
Never built with a coding assistant before? Start here. Three things have to be in place before anything else on this page works.
| What you need | Why |
|---|---|
| A coding assistant | Claude, Cursor, VS Code with GitHub Copilot, Codex and ChatGPT are the ones set up below. Any of them is enough. Pick one and stay on it. |
| A paid plan on it | Free tiers stop partway through a long task. The cheapest paid plan on any of these carries a milestone. |
| Your own project open in it | The assistant reads and writes the folder it is opened in. Open the repository you are integrating ABDM into first. |
Then work down the page in order.
- Connect the Docs MCP server, so the assistant looks ABDM up here instead of recalling an older version of it.
- Install the plugin, which is one command or one pasted line.
- Install the skill for the milestone you are on, M1 first if you are starting.
- Ask for what you want in plain language, one flow at a time. "Add ABHA creation by Aadhaar OTP to this project, using the M1 skill" is a good first prompt.
You do not need to know what MCP, a plugin or a skill is to use them. They are three ways of handing the same documentation to the assistant: live lookup, one install for everything, and one file for one milestone.
Read what it writes before you run it. An assistant is fast and confident, and it is wrong in ways only the Sandbox will show you.
Connect the Docs MCP server
A skill is a snapshot. The Docs MCP server is the same catalogue live, queried a paragraph at a time instead of loaded whole.
Install the plugin
One command for both halves: the skills as files and the server as a connection. Claude and Codex take it as a plugin; Cursor, VS Code, ChatGPT and anything else that can fetch a URL take the same setup as a line to paste.
Install a skill
One file per job, in three shapes. A module skill carries every endpoint, header and error code for that milestone, provider side (M1 to M4) or patient side (P1 to P4). A scaffold or debug skill is a procedure instead: it works against the sandbox in a loop that ends on an observed result, not on a call returning 200. Every module skill carries both, under its references/. The FHIR skills build or audit NRCES compliant bundles.
Prompting an agent to build against ABDM
An agent with this site loaded still writes a plausible integration rather than a correct one, because the parts of ABDM that catch people are the parts a model cannot infer. Tell it these, and check its output against them.
| Tell it | Because |
|---|---|
| Look the operation up here before writing the call | The ABDM v3 APIs differ from the v1 and v2 an agent was trained on. The MCP server above is this site answering live, so it cannot be recalling an older shape |
| Identifiers are encrypted, and the plaintext has a shape | An agent encrypts what looks like the value. An ABHA number keeps its dashes, and the bare digits are refused. See encryption |
| Callbacks are how the answer arrives in M2 and M3 | Left alone, an agent writes a synchronous call and a response handler for a flow where the 202 means accepted and nothing else. See the gateway |
| Do not invent an error code or an endpoint | Both exist here in full. An invented ABDM- code is indistinguishable from a real one until somebody hits it |
| One bridge serves every facility, so the callback URL and the credentials are not facility settings | Left alone, an agent builds a settings screen per facility and puts them on it. That works for the first facility. See one bridge, many facilities |
| Aadhaar numbers, one time passwords and passwords never reach a log, a fixture or a test | An agent writing test data will otherwise put a real looking Aadhaar number in your repository |
Point it at Build it well for the handling rules themselves: what to validate, what each error means, what is safe to retry, and what the screen should say.
Read this site as an agent
llms.txt is a map of every page here; llms-full.txt is every page's text in one file. Add /index.md to any URL on this site to get that page as plain Markdown, no scraping required.
Ask AI
Ask this catalogue a question directly, without setting anything up.
The same assistant sits in the search box at the top of every page, labelled "Search or ask AI".
Attaching a file
Ask AI takes a file with your question: a failing request body, a FHIR bundle, a log, a CSV, a PDF, or a screenshot. The paperclip is on the left of the box. At most 20,000 characters of text, 256KB for a text file and 8MB for a PDF or an image.
What happens to it is worth knowing before you attach one.
- The file is read in your own browser and only the text it gives up travels with your question. A PDF gives up the text it already carries. A screenshot is read by a text recognition engine your browser downloads once, from this site, and runs on your own machine. The picture itself is never sent, so nothing is uploaded and nothing is stored: the conversation lives in the panel and is gone when you close it.
- A PDF that is only pictures of text, a scan, gives up nothing. Screenshot the part you mean instead and that will be read.
- Text read from a picture carries reading mistakes. The assistant is told where the text came from, so it can say when an answer turns on a character it cannot trust.
- Personal data is removed before the file reaches the model. A file that
parses as JSON is masked by its field names, so
name,telecom,address,birthDateand identifier values in a FHIR bundle are replaced with placeholders such as<MASKED_NAME>. Aadhaar, ABHA, PAN, passport, voter, mobile, email and bearer tokens are matched by pattern anywhere in the file, JSON or not. - A file with no field names, a log or the text read from a screenshot, gets
the same pattern masking, and a name on a labelled line goes too:
patient: Rakesh Sharmaleaves aspatient: <MASKED_NAME>. - What none of that catches is a name written in running prose, with nothing marking it as a name. Redact those yourself, the same way you would in a support request. The panel says so next to any file it read for you.
- Your question is logged, masked, to improve the answers. The file is not logged.