# Personal Profile This document covers two profile-adjacent surfaces: 1. **Personal details** — full name, email, mobile number and National ID, shown on the login details screen. 2. **Profile image management** — three encrypted-API endpoints (`P40`/`P41`/`P42`) that fetch, upload, and delete the avatar. --- ## 1. Personal Details The details come from two sources and are fetched once at login, then cached (`MibProfileClient.kt`). | Field | Source | |---|---| | Full name | `A41` login init response — `fullName` | | Email | Alias suggestions — type `1` (falls back to `A41` `email`) | | Mobile number | Alias suggestions — type `0` | | National ID | Alias suggestions — type `3` | ### Full name — `A41` The `A41` login init response (see [02-login.md](02-login.md)) carries the user's details at the root: ```json { "fullName": "Mohamed Ali", "email": "user@example.com", "lastLoginTime": "2026-05-16 15:10:25", "customerImgHash": "", "roleName": "Consumer Premium" } ``` ### Alias Suggestions — `getAliasTypes` ``` POST https://faisamobilex-wv-v2.mib.com.mv/ajaxAlias/getAliasTypes ``` WebView session cookies and AJAX headers (see [README](README.md)). Empty POST body. ``` Referer: https://faisamobilex-wv-v2.mib.com.mv/Alias/Alias?dashurl=1 ``` The suggestions belong to the **currently selected** profile and differ between personal and business profiles. Select the personal profile (`profileType: "0"`) with `P47` first (see [03-accounts.md](03-accounts.md)). #### Response ```json { "success": true, "responseCode": "2", "reasonCode": "203", "reasonText": "Alias Types Search Success.", "data": [ { "id": 0, "aliasTypeName": "Mobile Number", "suggestedAlias": "+9609600001" }, { "id": 1, "aliasTypeName": "E-Mail", "suggestedAlias": "user@example.com" }, { "id": 3, "aliasTypeName": "National ID", "suggestedAlias": "A000001" } ] } ``` | `id` | `aliasTypeName` | Used as | |---|---|---| | `0` | Mobile Number | Mobile number (with `+960` prefix) | | `1` | E-Mail | Email | | `3` | National ID | ID card number | A type may be missing from `data` when the user has no value for it. ### Registered Aliases — `ajaxAlias/main` ``` POST https://faisamobilex-wv-v2.mib.com.mv/ajaxAlias/main ``` Lists the user's registered Favara aliases. Not consumed by the app. Body: `page=1&search=&searchAccount=&searchAliasType=&sort=AlsId&sortDir=asc&start=1&end=20&includeCount=1` ```json { "success": true, "reasonText": "Favara ID Search Success.", "data": [ { "AlsBfy": { "Tp": "MSISDN", "Id": "+9609600001" }, "BfyNm": "Mohamed", "BfySnm": "Ali", "CdtrAcct": { "Acct": "90100000000000000", "FinInstnId": "MADVMVMV" }, "AcctHldrId": "A000001", "AcctHldrIdTp": "IDENTITY_NUMBER", "AcctHldrTp": "INDIVIDUAL", "AdrLine": "
", "Ctry": "MDV", "RegDtTm": "2026-05-12T20:07:44", "AlsSt": "ACTIVE", "PhneNb": "+9609600001", "EmailAdr": "user@example.com" } ], "Pg": { "Size": 20, "TtlElms": 1, "TtlPgs": 1, "Nmb": 0 } } ``` `AlsBfy.Tp` is the alias type, e.g. `MSISDN` or `NATIONAL_ID`. --- ## 2. Profile Image Management The avatar lives on the **encrypted API** (`faisamobilex-smvc-v2.mib.com.mv`), not the WebView host. Three `sfunc=n` route paths cover fetch, upload, and delete. All three follow the standard encrypted-request format (see [01-encryption.md](01-encryption.md) and [02-login.md](02-login.md)) and include the standard `baseData` fields (`nonce`, `appId`, `sodium`, `routePath`, `xxid`). | `routePath` | Operation | Source | |---|---|---| | `P41` | Fetch image by hash | `MibLoginFlow.kt:368-375` | | `P40` | Upload new image | `MibLoginFlow.kt:382-391` | | `P42` | Delete current image | `MibLoginFlow.kt:397-403` | ### Image-hash field naming The same conceptual value — "the hash that identifies a customer's avatar" — is exposed under **two different field names** depending on which endpoint returned it: | Source endpoint | Field name | |---|---| | `A41` login init (`operatingProfiles[]`) | `customerImage` | | `A41` login init (root) | `customerImgHash` | | `C41` registration init (root) | `customerImgHash` | Both are non-empty hash strings that can be passed straight into `P41` as `imageHash`. Treat them as the same value with two names. Contact photos use a separate route, `B46` (see [09-contacts.md](09-contacts.md)). ### Fetch — `routePath: P41` **Request** (encrypted payload): ```json { "sfunc": "n", "xxid": "", "data": { "imageHash": "", "nonce": "", "appId": "", "sodium": "", "routePath": "P41", "xxid": "" } } ``` **Response**: ```json { "success": true, "reasonCode": "201", "profileImage": "" } ``` `profileImage` is raw base64 with no data URI prefix. ### Upload — `routePath: P40` **Request** (encrypted payload): ```json { "sfunc": "n", "xxid": "", "data": { "profileId": "", "profileImage": "", "nonce": "", "appId": "", "sodium": "", "routePath": "P40", "xxid": "" } } ``` **Response**: ```json { "success": true, "imageHash": "", "customerImage": "" } ``` The server may populate either `imageHash` or `customerImage` for the new hash — the client reads both (`MibLoginFlow.kt:389-390`) and prefers `imageHash` when present. ### Delete — `routePath: P42` **Request** (encrypted payload): ```json { "sfunc": "n", "xxid": "", "data": { "profileId": "", "nonce": "", "appId": "", "sodium": "", "routePath": "P42", "xxid": "" } } ``` **Response**: ```json { "success": true } ``` After a successful delete, the `customerImage` field on subsequent `A41` responses is blank. > Note: BML and Fahipay profile images are stored locally on-device only (`util/ProfileImageStore.kt`). Only MIB persists avatars server-side via these endpoints. ---   --- [← Financing](06-financing.md)     **Next →** [Transfer](08-transfer.md)