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](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": "<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](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": "<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](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": "<session xxid>",
  "data": {
    "imageHash": "<customerImage or customerImgHash>",
    "nonce": "<computed nonce>",
    "appId": "<appId>",
    "sodium": "<random>",
    "routePath": "P41",
    "xxid": "<session xxid>"
  }
}
```

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

`profileImage` is raw base64 with no data URI prefix.

### Upload — `routePath: P40`

**Request** (encrypted payload):
```json
{
  "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**:
```json
{
  "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):
```json
{
  "sfunc": "n",
  "xxid": "<session xxid>",
  "data": {
    "profileId": "<active profile ID>",
    "nonce": "<computed nonce>",
    "appId": "<appId>",
    "sodium": "<random>",
    "routePath": "P42",
    "xxid": "<session 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.

---

&nbsp;

---

[← Financing](06-financing.md) &nbsp;&nbsp;&nbsp; **Next →** [Transfer](08-transfer.md)