Extract Aadhaar Data with Make.com: Gmail to Airtable (Masked UID Handling)

Aadhaar shows up in inboxes as “KYC docs” threads with one or two JPEG attachments. This Make.com scenario watches Gmail, sends attachments to Cryvis POST /v1/documents/aadhaar, and writes structured fields to Airtable — with explicit handling for is_masked and PII hygiene.

PAN Drive→Sheets twin: Extract PAN card data. Full KYC router: Automate KYC.

Why PII gets its own section

Aadhaar numbers are sensitive under Indian data-protection practice and UIDAI guidance on display/storage. Cryvis returns whatever is printed: full UID or masked (e.g. XXXX XXXX 9012) plus is_masked: true|false. Your Make scenario must treat that flag as a first-class control, not an afterthought.

Architecture

Gmail inbox label: kyc-aadhaar
        |
        v
Make: Watch emails
  download 1–2 image attachments
        |
        v
POST https://api.cryvis.com/v1/documents/aadhaar
  multipart field name: file (x1 or x2)
  Authorization: Bearer ...
        |
        v
Airtable Applicants
  + is_masked checkbox
  + restricted Aadhaar field

Step 1: Gmail intake rules

1. Create label kyc-aadhaar.
2. Filter: has attachment, subject contains Aadhaar or KYC, apply label.
3. In Make: Gmail → Watch Emails filtered by that label.

Instruct senders: front only, back only, or front+back. Cryvis accepts 1–2 files, same field name file.

Step 2: Collect attachment binaries

Gmail modules expose attachments as collections. Use an Iterator over attachments, then Filter MIME ∈ image/jpeg, image/png, image/webp, application/pdf.

Aggregate into an array (Make Array aggregator) capped at 2. If more than two images arrive, take the first two and set Airtable note extra_attachments_ignored.

files[1] -> aadhaar_part_1
files[2] -> aadhaar_part_2 (optional)

Step 3: Cryvis Aadhaar HTTP call

HTTP → Make a request

Multipart rows:

Both parts must be named file — not front/back. Front/back naming is for Indian Vehicle RC, not Aadhaar.

cURL:

curl -X POST https://api.cryvis.com/v1/documents/aadhaar \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -F "file=@aadhaar-front.jpg" \
  -F "file=@aadhaar-back.jpg"

Step 4: Response schema

{
  "success": true,
  "data": {
    "aadhaar_number": "1234 5678 9012",
    "full_name": "RAHUL SHARMA",
    "date_of_birth": "1992-08-14",
    "year_of_birth": null,
    "gender": "Male",
    "care_of": "S/O SURESH SHARMA",
    "address": "12 MG Road, Bengaluru, Karnataka 560001",
    "pincode": "560001",
    "is_masked": false
  }
}

Field notes:

Docs: /docs/api/extractAadhaar · /apis/aadhaar.

Step 5: Airtable table

Status values: extracted_full, extracted_masked, needs_resubmit, error.

Step 6: Map with is_masked logic

name        = data.full_name
dob_or_yob  = IFEMPTY(data.date_of_birth; data.year_of_birth)
gender      = data.gender
care_of     = data.care_of
address     = data.address
pincode     = data.pincode
aadhaar     = data.aadhaar_number
is_masked   = data.is_masked

IF is_masked
  KYC status = extracted_masked
ELSE
  KYC status = extracted_full

Policy variants you can encode in Make:

1. Accept masked for address proof only → status extracted_masked is terminal success.
2. Require full UID for account opening → if is_masked, status needs_resubmit and auto-reply Gmail asking for an unmasked copy (only if your legal basis allows).
3. Never store full UID in Airtable → write only last 4 characters via substring; leave full number out of the base.

Pick one policy and document it next to the scenario. Do not log full Aadhaar in Slack error messages.

Step 7: Gmail acknowledgment (optional)

Gmail → Send an Email reply:

• Success + unmasked policy OK: “We received your Aadhaar and extracted details.”
• Masked + require full: “Please resend with unmasked Aadhaar as per onboarding policy.”
• Error: “Could not read the attachment; send JPEG/PNG/PDF under 2 files.”

Avoid echoing aadhaar_number in email bodies.

Step 8: Error handler and retention

HTTP Cryvis
  |
  +-- success --> Airtable --> optional Gmail reply
  |
  +-- error --> Airtable status=error
            --> Slack: message id + HTTP status only

Make.com scenario history may retain file binaries. For Aadhaar:

• Shorten data retention on the scenario if your plan allows
• Prefer downloading attachments to ephemeral handling only
• Delete or archive Gmail threads per retention schedule outside Make

Testing

1. Front+back unmasked → is_masked=false, address filled, status extracted_full.
2. Masked front only → is_masked=true, status per policy.
3. YOB-only card → date_of_birth null, year_of_birth set; Airtable uses YOB.
4. Three attachments → aggregator caps at 2; note field set.

Why two files share the name file

OpenAPI defines Aadhaar uploads as an array of 1–2 binaries under file. That is different from RC (front/back) and passport (first_page/last_page). In Make, duplicate the multipart row name; do not rename the second part to file2.

Address merge behavior

When front and back are both sent, name/UID and address/PIN typically merge into one data object. If address is still null, the back image may be unreadable — set status needs_resubmit for the back only rather than discarding a good front extract. Store what you have; ask for a retake of the missing side.

Legal basis reminder

This tutorial is engineering guidance, not legal advice. Confirm with counsel how long you may retain Aadhaar images in Gmail and Airtable, and whether masked UIDs satisfy your use case under applicable UIDAI and DPDP rules.

Credits

1 credit per image. Front+back = two credits. Prefer that over a single blurry combined photo.

Related reading

• Extract PAN from Drive
• Sequential webhook KYC
• Driver's license + country
• /blog/make-com

CTA

Extract Aadhaar front/back to JSON with Cryvis: /apis/aadhaar. Docs: /docs/api/extractAadhaar. POST one or two multipart parts named file to https://api.cryvis.com/v1/documents/aadhaar with Bearer auth, and branch on data.is_masked before you write Airtable.