What is the Combined Credit Snapshot API?

This API is a wrapper over 4 independent APIs - and was build for you to simplify building landing pages/ credit widgets and re-usage credit sections on your UI.

The API wraps over 4 commonly used Unity APIs (so you only have to integrate once) and enables these common user states and use cases.

Scenario 1 - Credit limit simulation

If you have the user's holdings (mutual funds/stocks), you can use the API to fetch the user's potential credit limit. If multiple lenders are available, the API evaluates the credit limit offered by each lender and returns the offer with the maximum loan amount.

If you provide a user identifier (PAN/Unity user ID) - it takes into account the user context and returns the credit limit offered by the lender selected by the user.

Scenario 2 - Loan application states

If a user ID is provided, the API returns the loan application states for all in progress/disbursed loans of the user. You can use this information to nudge the user to either resume the loan application, or view the active loan dashboard.

The API response also helps you with context if a user has multiple active loan applications/loans.

Response structure

The response stitches together the outputs of the four APIs this endpoint wraps — each linked value below points to that API's reference.

Expected output:

{
    user: response from get Unity user,
    creditLimit: [
        {
            lender: "bajaj_finserv",
            product: "lamf",   // only if MF holdings input is provided
            data: response from Credit simulation for MFs
        },
        {
            lender: "bajaj_finserv",
            product: "lamf",   // only if stock holdings are provided
            data: response from Credit simulation for STOCKs
        }
    ],
    loanDetails: [   // only if there are one or more lids in the get user response
        {
            lid: <lid from user.data.loans list>,
            journeyStatus: response from application status API,
            loanSummary: response from loan summary API   // call the right API based on lender + product
        }
    ]
}

One request returns the complete landing-page state for a user.

Use it for:

• Pre-onboarding pure eligibility (omit unityUserId).
• Connected-user LP UI render — what loans the user has, their journey state, and what they can top up.

Request fields

Holding entry shapes

stockHoldings[]:

{
  "assetType": "STOCKS",
  "isin": "INE467B01029",
  "quantity": 50,
  "isDemat": true,
  "dpId": "1208160075231086",
  "iscid": "",
  "lockInQuantity": 0
}

mfHoldings[]:

{
  "assetType": "MUTUALFUND",
  "isin": "INF209K01VA3",
  "quantity": 1375.823,
  "isDemat": false,
  "lockInQuantity": 0
}

Loan relationships (response.data.user.loans) for your landing page

LID lifecycle

A loan moves through a single journey, surfaced as loanStatus:

{
  "lid": "67f0aa11ce42e3a9b7c40012",
  "status": "ACTIVE",
  "productType": "lamf",
  "assetType": "MUTUALFUND",
  "lender": "bajaj_finserv",
  "flowId": "67f0aa11ce42e3a9b7c40010",
  "createdAt": "2026-04-28T14:00:00.000Z",
  "purpose": "LOAN_APPLICATION",
  "isDefault": true,
  "loanStatus": "PRE_SUBMITTED"
}

(no LID yet)
   │  user starts journey
   ▼
PRE_SUBMITTED
   │  user submits to lender
   ▼
SUBMITTED
   │  lender approves & disburses
   ▼
DISBURSED   ◀── servicing dashboard active
   │  user closes loan
   ▼
CLOSED

Sibling vs parent-child

There are two distinct patterns. Both are server-managed; the snapshot reflects whichever applies right now.

Same-asset top-up (e.g. LAMF over LAMF). The parent-child link is established at top-up creation, before submission. The child appears in the parent's loanSummary.topUpLoans[] immediately with topUpStatus: IN_PROGRESS. When the child gets DISBURSED, it becomes the new servicing dashboard owner; the old parent flips to status: INACTIVE and topUpStatus: APPLIED.

Cross-asset (LAMF + LAS, same lender). When a user has a LAMF and starts a LAS application (or vice versa), the two loans are siblings while both are PRE_SUBMITTED — not parent-child. When one of the two is SUBMITTED, the server flips the relationship to parent-child, and the child shows up in the parent's loanSummary.topUpLoans[] once the parent is DISBURSED.

How to detect each pattern from the snapshot:

Scenario matrix

What to expect in each end-state, and what to render.

Known limitations

• The child loan does not carry a back-pointer (parentLid) to its parent. Derive the relationship from the parent's topUpLoans[] or from the child's purpose: LOAN_APPLICATION:TOP_UP marker.
• Sibling loans are not annotated with siblingLid in the response. Detect them from shape (see Loan relationships).
• For EIMPL loans, loanDetails[].loanSummary will be null because EIMPL has no servicing dashboard endpoint exposed today.