fksar/docs/mibapi/07-profile.md

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) carries the user's details at the root:

{
  "fullName": "Mohamed Ali",
  "email": "user@example.com",
  "lastLoginTime": "2026-05-16 15:10:25",
  "customerImgHash": "<image hash>",
  "roleName": "Consumer Premium"
}

Alias Suggestions — getAliasTypes

POST https://faisamobilex-wv-v2.mib.com.mv/ajaxAlias/getAliasTypes

WebView session cookies and AJAX headers (see README). 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).

Response

{
  "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

{
  "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": "<address>",
      "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 and 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).

Fetch — routePath: P41

Request (encrypted payload):

{
  "sfunc": "n",
  "xxid": "<session xxid>",
  "data": {
    "imageHash": "<customerImage or customerImgHash>",
    "nonce": "<computed nonce>",
    "appId": "<appId>",
    "sodium": "<random>",
    "routePath": "P41",
    "xxid": "<session xxid>"
  }
}

Response:

{
  "success": true,
  "reasonCode": "201",
  "profileImage": "<base64-encoded JPEG>"
}

profileImage is raw base64 with no data URI prefix.

Upload — routePath: P40

Request (encrypted payload):

{
  "sfunc": "n",
  "xxid": "<session xxid>",
  "data": {
    "profileId": "<active profile ID>",
    "profileImage": "<base64-encoded JPEG>",
    "nonce": "<computed nonce>",
    "appId": "<appId>",
    "sodium": "<random>",
    "routePath": "P40",
    "xxid": "<session xxid>"
  }
}

Response:

{
  "success": true,
  "imageHash": "<new hash>",
  "customerImage": "<new hash, alternate field name>"
}

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):

{
  "sfunc": "n",
  "xxid": "<session xxid>",
  "data": {
    "profileId": "<active profile ID>",
    "nonce": "<computed nonce>",
    "appId": "<appId>",
    "sodium": "<random>",
    "routePath": "P42",
    "xxid": "<session xxid>"
  }
}

Response:

{ "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     Next → Transfer