> ## Documentation Index
> Fetch the complete documentation index at: https://docs.fraudtraceai.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Audit a Mobile App for Fraud Risk with Mobile Trace

> Submit a mobile app for automated emulation to detect hidden deposit screens, UPI mule IDs, permission abuse, and embedded fraud modules.

Mobile Trace uses automated emulation to analyze Android apps for fraud-related behaviour that app store reviews miss entirely — hidden deposit screens, permission abuse, embedded payment handlers, and UPI IDs wired to mule accounts. Before this endpoint is live, you can join the waitlist to get early access.

<Warning>
  **Mobile Trace is coming soon.** This endpoint is not yet available. Join the waitlist at [fraudtraceai.com](https://fraudtraceai.com) to be notified when it launches.
</Warning>

## Endpoint

<Note>
  All requests must include an `Authorization: Bearer YOUR_API_KEY` header. See [Authentication](/authentication) for details.
</Note>

**Method:** `POST`\
**Path:** `/v1/audit/app`\
**Base URL:** `https://api.fraudtraceai.com`

Submit a mobile app package for automated risk emulation. Mobile Trace drives the app through its full UI flow inside an instrumented sandbox, captures screenshots, intercepts network calls, and extracts any UPI Virtual Payment Addresses (VPAs) surfaced in the app's deposit or payment screens. The result tells you whether the app is carrying hidden fraud infrastructure before it reaches your users or merchant ecosystem.

<Info>
  Audits are asynchronous. The API accepts your submission and returns a job ID. You poll a separate status endpoint to retrieve results. The exact polling mechanism will be documented at launch.
</Info>

## Request

### Request Body

<CodeGroup>
  ```json Body theme={null}
  {
    "package_id": "com.gamewin.india",
    "platform": "android"
  }
  ```
</CodeGroup>

<ParamField body="package_id" type="string" required>
  The Android package name of the app you want to audit (e.g. `com.example.app`). This must be the canonical package identifier as it appears in the app's manifest. APK upload support is also planned for apps not yet published to the Play Store.
</ParamField>

<ParamField body="platform" type="string" required>
  The mobile platform. Currently `android` is the supported value. iOS support is planned for a future release.
</ParamField>

### Example Request

<CodeGroup>
  ```bash cURL theme={null}
  curl -X POST https://api.fraudtraceai.com/v1/audit/app \
    -H "Authorization: Bearer YOUR_API_KEY" \
    -H "Content-Type: application/json" \
    -d '{
      "package_id": "com.gamewin.india",
      "platform": "android"
    }'
  ```

  ```python Python theme={null}
  import requests

  response = requests.post(
      "https://api.fraudtraceai.com/v1/audit/app",
      json={
          "package_id": "com.gamewin.india",
          "platform": "android",
      },
      headers={
          "Authorization": "Bearer YOUR_API_KEY",
          "Content-Type": "application/json",
      },
  )
  print(response.json())
  ```

  ```javascript Node.js theme={null}
  const response = await fetch("https://api.fraudtraceai.com/v1/audit/app", {
    method: "POST",
    headers: {
      Authorization: "Bearer YOUR_API_KEY",
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      package_id: "com.gamewin.india",
      platform: "android",
    }),
  });
  const data = await response.json();
  console.log(data);
  ```
</CodeGroup>

## Planned Response

When `status` is `FLAGGED`, the `findings` array is populated with detected risk signals and `risk_score` will be elevated. When `status` is `CLEARED`, `findings` is empty, `suspicious` permissions are absent, and `risk_score` is near zero.

<CodeGroup>
  ```json FLAGGED theme={null}
  {
    "package_id": "com.gamewin.india",
    "platform": "android",
    "status": "FLAGGED",
    "risk_score": 0.87,
    "findings": [
      {
        "type": "deposit_screen_detected",
        "severity": "high",
        "detail": "UPI deposit payment screen found in app flow"
      },
      {
        "type": "extracted_upis",
        "severity": "high",
        "detail": "4 UPI VPAs extracted from deposit screen",
        "upis": ["xxxxx@ybl", "yyyy7421@paytm", "zzz9801@okaxis", "mule4@upi"]
      },
      {
        "type": "permission_abuse",
        "severity": "medium",
        "detail": "Requests READ_CONTACTS and READ_SMS without justification"
      }
    ],
    "permissions": {
      "declared": ["INTERNET", "READ_CONTACTS", "READ_SMS", "RECEIVE_SMS"],
      "suspicious": ["READ_CONTACTS", "READ_SMS", "RECEIVE_SMS"]
    },
    "screenshot_count": 5,
    "audit_completed_at": "2026-04-01T10:30:00Z"
  }
  ```

  ```json CLEARED theme={null}
  {
    "package_id": "com.groceryhub.android",
    "platform": "android",
    "status": "CLEARED",
    "risk_score": 0.04,
    "findings": [],
    "permissions": {
      "declared": ["INTERNET", "CAMERA"],
      "suspicious": []
    },
    "screenshot_count": 0,
    "audit_completed_at": "2026-04-01T10:31:00Z"
  }
  ```
</CodeGroup>

### Response Fields

<ResponseField name="package_id" type="string">
  The Android package name you submitted, echoed back for correlation.
</ResponseField>

<ResponseField name="platform" type="string">
  The platform value you submitted (`android`).
</ResponseField>

<ResponseField name="status" type="string">
  Overall audit verdict. Possible values:

  * `FLAGGED` — one or more risk signals were detected during emulation.
  * `CLEARED` — no risk signals detected; the app passed the audit.
  * `PENDING` — the audit is still running (returned when polling before completion).
  * `ERROR` — the app could not be emulated (e.g. package not found, incompatible build).
</ResponseField>

<ResponseField name="risk_score" type="float">
  A normalized risk score between `0.0` (no risk) and `1.0` (highest risk), computed from the combination and severity of all findings. Use this as a quick triage signal — scores above `0.7` typically indicate apps with active fraud infrastructure.
</ResponseField>

<ResponseField name="findings" type="array">
  List of individual risk signals detected during the audit. Empty for `CLEARED` apps.

  <Expandable title="findings[n] fields">
    <ResponseField name="type" type="string">
      Machine-readable finding type. Planned values include:

      * `deposit_screen_detected` — a UPI or payment deposit screen was found in the app flow.
      * `extracted_upis` — UPI VPAs were extracted from a deposit screen.
      * `permission_abuse` — the app declares permissions with no apparent legitimate use.
      * `fraud_module_detected` — an embedded SDK or code module associated with fraud campaigns was identified.
      * `hidden_payment_handler` — a payment handler is present but not surfaced in the normal UI.
    </ResponseField>

    <ResponseField name="severity" type="string">
      Risk severity of this finding. One of `high`, `medium`, or `low`.
    </ResponseField>

    <ResponseField name="detail" type="string">
      Human-readable explanation of what was found and where in the app flow it was observed.
    </ResponseField>

    <ResponseField name="upis" type="array of strings">
      Present only on `extracted_upis` findings. The list of UPI VPAs (Virtual Payment Addresses) that were extracted from the app's deposit or payment screens.

      <Note>
        In production, each extracted UPI VPA will include a `muletrace_status` field showing whether the address is already flagged in the MuleTrace database. This cross-reference happens automatically — you do not need to call MuleTrace separately for extracted UPIs.
      </Note>
    </ResponseField>
  </Expandable>
</ResponseField>

<ResponseField name="permissions" type="object">
  A breakdown of the app's declared Android permissions and which ones Mobile Trace considers suspicious given the app's stated purpose.

  <Expandable title="permissions fields">
    <ResponseField name="declared" type="array of strings">
      The full list of Android permissions declared in the app's manifest.
    </ResponseField>

    <ResponseField name="suspicious" type="array of strings">
      The subset of declared permissions that Mobile Trace flagged as potentially abusive or unjustified — for example, `READ_SMS` or `RECEIVE_SMS` in an app that has no stated messaging or OTP-autofill function.
    </ResponseField>
  </Expandable>
</ResponseField>

<ResponseField name="screenshot_count" type="integer">
  The number of screenshots captured during emulation. These screenshots document the app screens that triggered findings. In a future release, screenshot URLs will be included in the response for manual review.
</ResponseField>

<ResponseField name="audit_completed_at" type="string (ISO 8601)">
  The UTC timestamp at which the audit finished. Format: `YYYY-MM-DDTHH:MM:SSZ`.
</ResponseField>

## Use Case

Fraudulent apps targeting Indian payment users typically operate through a predictable pattern: they embed a deposit screen that directs users to send money to mule UPI accounts, while the app's surface-level description presents a harmless use case (gaming, grocery delivery, investment). App store reviews and manual sampling rarely catch these flows because they are triggered only under specific navigation paths or after a delay.

Mobile Trace automates the full emulation path, surfaces those hidden screens, and extracts the UPI VPAs being used — giving you actionable intelligence to block the app and report the mule accounts before your users lose funds.

<Tip>
  Pair Mobile Trace with MuleTrace: any UPI VPAs extracted by the audit are automatically cross-referenced against the MuleTrace mule account database. A single flagged app can reveal a cluster of mule accounts you can block across your entire platform simultaneously.
</Tip>

<Tip>
  Use the `risk_score` field to prioritize your review queue. If you are auditing large batches of apps, triage all results with `risk_score >= 0.7` for immediate investigation and route lower-score results to a secondary review queue.
</Tip>