Authentication: All endpoints require Authorization: Bearer <access_token>.
Overview The user row is created by the Auth module on first login. This module reads and writes the profile fields on top of it. The User Profile module does not create users — it only enriches them.
Updatable Fields first_name · last_name · email · dob · gender · address · occupation · employer
Immutable Fields phone — identity anchor, set by Auth and never changed. aadhaar_last4 — set via a separate KYC flow; returns 400 if attempted via PATCH.
Endpoints Method Path Description GET/user/profileFetch authenticated user’s full profile PATCH/user/profilePartial update — send only fields you want to change
Profile Fields — Field by Field Field Type Description Constraints user_idUUID Immutable primary key Set at creation, never changes phonestring 10-digit mobile number, +91 prefix stored Immutable — identity anchor first_namestring Given name Max 255 chars last_namestring Family name Max 255 chars emailstring Email address Valid RFC 5322 email format dobstring Date of birth YYYY-MM-DD; must be in the past; used for insurance age loadinggenderstring Gender identity Male | Female | Other (see enum below)addressstring Residential address Free text; max 500 chars occupationstring Type of gig work Enum — see OccupationType list below employerstring Platform / company name Free text; max 255 chars; e.g. “Namma Yatri”, “Swiggy” aadhaar_last4string Last 4 digits of Aadhaar Set via separate KYC; returned masked as XXXXXXXX{last4} profile_completeboolean Computed flag true when both first_name and last_name are set
Occupation Types The occupation field accepts values from the OccupationType enum. These represent the primary gig work segments that Aarokya serves:
Value Description DriverCab / auto driver (Ola, Namma Yatri, Uber, etc.) Delivery PartnerPackage / food delivery rider (Swiggy, Zomato, Blinkit, etc.) Domestic WorkerHouse cleaner, cook, nanny, etc. Construction WorkerDaily-wage construction labourer Factory WorkerManufacturing / industrial floor worker Healthcare WorkerNursing aide, health worker, ASHA worker Retail WorkerKirana store, mall, or shop employee Security GuardBuilding / premises security OtherAny gig work not listed above
Occupation is used for analytics and product personalisation (e.g. surfacing plans relevant to outdoor workers vs indoor workers). It is not used for insurance underwriting — NH plans are not occupation-rated.
Gender Enum Value Notes MaleFemaleOtherInclusive catch-all for non-binary and prefer-not-to-say
profile_complete Flag — SemanticsThe profile_complete boolean is a computed field — not a stored column. It is evaluated on every GET and returned in the response:
profile_complete = (first_name IS NOT NULL AND first_name != '') AND (last_name IS NOT NULL AND last_name != '')
What the app does with it
is_new_user: true (from /auth/otp/verify) + profile_complete: false → show full onboarding screen with all fieldsis_new_user: false + profile_complete: false → user previously logged in but never completed their profile; show a lighter promptprofile_complete: true → skip onboarding; go directly to the home screen
Why only name fields? DOB and gender are required for insurance premium calculation, but they can be collected lazily — at the point when the user actually tries to buy insurance. Requiring all fields before entering the app creates unnecessary friction for users who just want to check their wallet balance or call a doctor.
Transition effect When profile_complete transitions from false to true (a PATCH that sets both name fields), the app should:
Dismiss the onboarding screen
Persist profile_complete: true in local state to avoid re-checking on every launch
(Optionally) trigger a “welcome” animation or confetti — the user has committed to the product
Onboarding Flow PII Policy Aadhaar Masking Logic The Aadhaar masking is applied in two places:
Client-side (app): The app’s UI collects the full 12-digit Aadhaar number for display purposes, but sends only the last 4 digits to the API. The full number never travels over the network.Server-side (response): The API always returns Aadhaar in masked format regardless of what is in the database.
Field What client sends What DB stores What API returns Aadhaar Last 4 digits only aadhaar_last4 = "9012""XXXXXXXX9012"Phone 9876543210 (10 digits)+919876543210+919876543210Email Plaintext Plaintext Plaintext Name Plaintext Plaintext Plaintext DOB YYYY-MM-DDDATE columnYYYY-MM-DD
Why last-4 only? Storing the full 12-digit Aadhaar number would classify Aarokya’s database as a sensitive PII repository under DPDP Act 2023, requiring additional data protection compliance. The last 4 digits are sufficient for:
Identity confirmation (“does this look like your Aadhaar?”)
Basic KYC for insurance — the exact 4-digit suffix is confirmed at claim time by NH
Request / Response Examples GET /user/profile
Response 200
Response 401 — missing token
curl http://localhost:8080/user/profile \ -H 'Authorization: Bearer eyJhbGci...'
PATCH /user/profile — full update
PATCH /user/profile — partial update (name only)
Response 200
Response 400 — attempt to update phone
Response 400 — invalid date
curl -X PATCH http://localhost:8080/user/profile \ -H 'Authorization: Bearer eyJhbGci...' \ -H 'Content-Type: application/json' \ -d '{ "first_name": "Priya", "last_name": "Sharma", "dob": "1990-05-15", "gender": "Female", "occupation": "Driver", "employer": "Namma Yatri" }'
Field Reference Field Type Constraints first_namestring Max 255 chars last_namestring Max 255 chars emailstring Valid email format (RFC 5322) dobstring YYYY-MM-DD, must be a past dategenderstring Male | Female | Otheraddressstring Free text, max 500 chars occupationstring See OccupationType enum above employerstring Max 255 chars
Sending phone or aadhaar in the PATCH body will return 400 Bad Request . These are identity fields managed by dedicated flows.
