How Aadhaar eSign actually works for developers (no jargon).

Most developers in India have heard about Aadhaar eSign without ever wiring it up themselves. The phrase shows up in compliance memos, sales decks, and product roadmaps, and somewhere along the way it picked up a reputation as either a regulatory black box or a magic stamp that legally binds anyone with an Aadhaar card. Both are wrong.

Aadhaar eSign is a clearly documented HTTP flow with a defined set of actors, a defined set of artefacts, and one OTP. This post walks through what actually happens, in plain English, with no NDA stuff swept under the rug.

The cast of characters

Three parties matter in an Aadhaar eSign transaction. Most posts only mention two, which is why everyone is confused.

• The signer. The actual person whose signature is going on the document. They need an Aadhaar number and a phone number linked to it.
• The ASP, or Application Service Provider. This is your product. The application the signer is signing inside. Mezdoc plays this role when you generate a PDF and send it for signature through us.
• The ESP, or eSign Service Provider. A licensed Certifying Authority in India that holds the actual relationship with UIDAI and is allowed to issue digital signatures. eMudhra, NSDL e-Gov, Capricorn, and others.

You, the developer, build the ASP side. You do not get to talk to UIDAI directly. You go through an ESP, who is the only party allowed to authenticate the signer's Aadhaar and issue the resulting signature.

What actually happens, end to end

Here is the flow stripped of jargon. Pretend the signer is your customer Priya and the document is a loan agreement.

• Your backend renders the loan agreement PDF and computes its SHA-256 hash. This is what gets signed, not the PDF bytes.
• You send the hash, your ASP ID, and the signer's context to the ESP via their signed-request API.
• The ESP responds with a URL. You redirect Priya's browser there, or you embed the URL in an iframe.
• The ESP shows Priya a consent screen. She enters her Aadhaar number and her OTP.
• The ESP authenticates her with UIDAI behind the scenes. If it succeeds, the ESP signs the hash with a digital certificate issued in her name and posted back to your callback URL.
• You receive a PKCS#7 signed blob. You embed it into the PDF as a signature object. The PDF now contains a verifiable, legally binding signature.

That is it. There is no Aadhaar number stored on your side. There is no biometric scan. The OTP is the only authentication factor. The whole transaction completes in under thirty seconds end to end.

You sign a hash, not a document. The PDF is just the wrapper that carries the signed hash around.

What the signed PDF looks like afterwards

Open the resulting PDF in Adobe Reader and you will see a signature panel on the left. Click into it and you will get:

• The signer's name, exactly as it appears on their Aadhaar.
• The Certifying Authority that issued the signature.
• A timestamp.
• A verification status that says either "signature is valid" or "identity unknown" depending on whether the verifier's machine has the right CA chain installed.

That last bit is what trips up most teams. The signature is valid under the IT Act 2000 regardless of whether Adobe Reader thinks the identity is known. Reader just does not ship the Indian CA chain by default. Your auditor will not care.

Where Mezdoc fits

Mezdoc is the ASP. When you call our API to send a document for Aadhaar eSign, we do four things on your behalf:

• Render the final PDF from your template at a pinned version.
• Hash it with SHA-256 and request a signing transaction from the ESP.
• Host the signer flow on a tokenised link so the signer never sees your internal endpoints.
• Stitch the signed blob back into the PDF and fire a webhook to your callback with the final signed file and the audit record.

Here is what that looks like from your code:

curl https://api.mezdoc.com/v1/templates/loan_agreement_v3/submissions \
  -H "Authorization: Bearer $MEZDOC_KEY" \
  -H "Idempotency-Key: loan_app_2026_05_19_00481" \
  -d '{
    "environment": "production",
    "data": {
      "borrower_name":   "Priya Mehta",
      "loan_amount":     750000,
      "tenure_months":   60,
      "interest_rate":   10.5
    },
    "esign": {
      "method":          "aadhaar_otp",
      "signer_name":     "Priya Mehta",
      "signer_phone":    "+919876543210",
      "callback_url":    "https://your-backend.example.com/webhooks/mezdoc"
    }
  }'

The response is a submission id and a signer URL. You SMS or WhatsApp the signer URL to Priya. She clicks it, sees your branded review page, hits sign, enters her OTP, and you get a webhook with the final signed PDF in your callback.

The legal layer, in two paragraphs

Aadhaar eSign falls under the Second Schedule of the IT Act 2000. A signature created through this flow is admissible in Indian courts as a valid electronic signature. The signer's identity is established through their Aadhaar number and the OTP delivered to their UIDAI-linked phone, both verified by UIDAI through the ESP.

This matters for two reasons. First, you do not need the signer to print and scan anything. The PDF is the original. Second, the audit record (signer name, timestamp, signature hash, ESP transaction id) is what a regulator will ask for if there is ever a dispute. Mezdoc stores all of this for you and exposes it through one API call so you can attach it to your own compliance reports.

The things teams get wrong

Treating it as a checkbox

Aadhaar eSign is a transaction with a cost (you pay the ESP per signature) and a failure mode (the OTP can fail, the signer can abandon). Treat it like a payment, not a checkbox. Show the signer where they are in the flow, what they are signing, and what happens next.

Sending the wrong document

The hash is computed once and sent to the ESP. If your PDF has a timestamp in it, or a session-specific watermark, your hash will not match the final PDF. Generate the PDF once, hash it once, send it once. If your template engine cannot guarantee deterministic output, you have a bug.

Skipping the audit record

The ESP gives you a transaction id when the signature succeeds. Store it. Map it to your internal loan id, claim id, or whatever your domain object is. When the auditor calls in two years, you want to be able to produce the transaction id in thirty seconds, not three days.

The roadmap question, briefly

Two related signing methods come up in the same conversation. Mezdoc supports the first today and is wiring the second this year.

• DSC, or Digital Signature Certificate. A USB-token-based signature used by company directors and CAs. We pass through to the same ESP for this. Same API surface, different signer flow on the front end.
• National eSign (DSC over Aadhaar). A newer flow that issues a long-lived DSC bound to your Aadhaar so you do not need an OTP on every signature. We will support this when the ESP API stabilises.

The US parallel

For US-only readers, the equivalent flow is governed by the ESIGN Act (2000) and UETA. The mechanics differ in two ways. First, there is no national identity database equivalent to Aadhaar, so the identity proofing layer is usually email-plus-knowledge-based-authentication or SMS-OTP rather than a government OTP. Second, the signing service does not need to be a Certifying Authority licensed by a regulator; any provider that meets the audit-trail requirements (signer intent, IP, user agent, document hash) qualifies. The Mezdoc API is the same: you POST the document and signer details, we host the signing flow, you get a signed PDF and an audit record back. The difference is the auth provider on the back end and the regulator that audits it later.

A practical next step

If you are wiring eSign into a product for India, the cheapest first version is this:

• Pick the one document your team sends most often. Loan agreement, NDA, policy proposal, anything.
• Make it a Mezdoc template. Drop a signature field where you currently print and sign.
• Call the API with `esign.method: "aadhaar_otp"` and a real signer phone.
• Watch the webhook come back with the signed PDF and the audit record.
• Forward the audit record to your storage. You are done.

Aadhaar eSign is not a regulatory mystery. It is an HTTP flow that ends with a legally binding signature in a PDF. Try it once and you stop being scared of it. Try our live demo if you want to see the request body shape before you commit a line of code.