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

# Track Status

> Check the status of one or more consents, sessions, or handles under a transaction.

Status Lookup checks the status of one or more consents, sessions, or handles — or
looks up everything raised under a transaction. It has two response shapes depending
on what you supply in the request.

## Endpoint

```
POST /finpro/transaction/status
```

Base URL: provided to you at onboarding.

## Headers

| Header          | Description                             |
| --------------- | --------------------------------------- |
| `Content-Type`  | `application/json`                      |
| `Authorization` | `Basic base64(client_id:client_secret)` |

## Request body

```jsonc theme={null}
{
  "transactionId": "string",      // required
  "consentId": ["string"],        // optional, array — batch lookup
  "sessionId": ["string"],        // optional, array — batch lookup
  "consentHandle": ["string"]     // optional, array — batch lookup
}
```

<ParamField body="transactionId" type="string" required>
  The `transactionId` returned by Consent Creation.
</ParamField>

<ParamField body="consentId" type="array">
  Batch lookup by one or more consent IDs (up to 15). Mutually exclusive with
  `sessionId`/`consentHandle` — supply exactly one of the three.
</ParamField>

<ParamField body="sessionId" type="array">
  Batch lookup by one or more session IDs (up to 15). Mutually exclusive with
  `consentId`/`consentHandle` — supply exactly one of the three.
</ParamField>

<ParamField body="consentHandle" type="array">
  Batch lookup by one or more consent handles (up to 15). Mutually exclusive with
  `consentId`/`sessionId` — supply exactly one of the three.
</ParamField>

<Tabs>
  <Tab title="transactionId only">
    If only `transactionId` is supplied, the response returns every consent raised under
    that transaction — useful if you are not using the consolidated consent callback and
    want to poll for everything under one customer journey.

    ### Sample request

    <CodeGroup>
      ```bash cURL theme={null}
      curl --request POST \
        --url 'https://<base_url>/finpro/transaction/status' \
        --header 'Content-Type: application/json' \
        --header 'Authorization: Basic <base64(client_id:client_secret)>' \
        --data '{
          "transactionId": "<transaction_id>"
        }'
      ```
    </CodeGroup>

    ### Response

    Every consent raised under the transaction, with a lighter-weight session list (no
    per-account breakdown at this level — see the batch lookup tab for that):

    ```jsonc theme={null}
    {
      "transactionId": "string",
      "consents": [
        {
          "fiuId": "string",
          "fipId": ["string"],          // array — a consent can span multiple FIPs
          "productId": "string",        // your onboarded set — see "Products," under Initiate Consent
          "consentHandle": "string",
          "consentId": "string | null", // null until the consent is approved
          "status": "string",           // see "Status Codes" below
          "consentExpiry": "string | null",
          "accounts": [                 // linked accounts, present even before any data pull
            {
              "linkRefNumber": "string",
              "fipId": "string",
              "fipName": "string",
              "maskedAccountNumber": "string"
            }
          ],
          "sessions": [
            {
              "sessionId": "string",
              "eventStatus": "string",       // DATA_READY / DATA_DENIED / SESSION_FAILED / SESSION_EXPIRED
              "sessionStatus": "string",     // see "Status Codes" below
              "dataFetchDate": "string | null",
              "dataExpiry": "string | null"
            }
          ]
        }
      ]
    }
    ```
  </Tab>

  <Tab title="Batch lookup">
    Supply exactly one of `consentId`/`sessionId`/`consentHandle` alongside
    `transactionId` — these three are mutually exclusive; sending more than one, or an
    empty array, is rejected with `INVALID_REQUEST`. Each array accepts up to 15
    identifiers per call.

    Each matched consent is returned once, with its status wrapped in `sessions[]` —
    **always 0 or 1 entries** (0 only when no session exists at all, e.g. no data has
    been requested yet), carrying its full per-account fetch-status breakdown.

    A batch request with one identifier that doesn't resolve still returns results for
    the rest — a non-matching identifier is simply omitted, not treated as a
    whole-request error.

    ### Sample request

    <CodeGroup>
      ```bash cURL theme={null}
      curl --request POST \
        --url 'https://<base_url>/finpro/transaction/status' \
        --header 'Content-Type: application/json' \
        --header 'Authorization: Basic <base64(client_id:client_secret)>' \
        --data '{
          "transactionId": "<transaction_id>",
          "consentId": ["<consent_id>"]
        }'
      ```
    </CodeGroup>

    ### Response

    ```jsonc theme={null}
    {
      "results": [
        {
          "consentId": "string",
          "consentHandle": "string",
          "fiuId": "string",                // which FIU this result belongs to
          "productId": "string",
          "status": "string",               // consent-level status — see "Status Codes" below
          "consentExpiry": "string | null",
          "accounts": [
            {
              "linkRefNumber": "string",
              "fipId": "string",
              "fipName": "string",
              "maskedAccountNumber": "string"
            }
          ],
          "sessions": [
            {
              "sessionId": "string",
              "eventType": "DATA",             // always "DATA" — sessions[] only ever contains data-fetch sessions
              "eventStatus": "string",         // DATA_READY / DATA_DENIED / SESSION_FAILED / SESSION_EXPIRED
              "sessionStatus": "string",       // see "Status Codes" below
              "dataFetchDate": "string | null",
              "dataExpiry": "string | null",
              "linkRefNumbers": [
                {
                  "linkRefNumber": "string",
                  "fiStatus": "string",        // see "Status Codes" below
                  "fipName": "string",
                  "fipId": "string",
                  "maskedAccountNumber": "string"
                }
              ]
            }
          ]
        }
      ]
    }
    ```
  </Tab>
</Tabs>

## Status Codes

**Consent-level (`status`):**

| Status     | Meaning                                                                                                                                   |
| ---------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
| `ACTIVE`   | Consent approved and currently valid                                                                                                      |
| `REJECTED` | Customer explicitly declined consent                                                                                                      |
| `FAILED`   | The AA-side process itself failed before a real customer decision was recorded — a technical/AA failure, distinct from a customer decline |
| `REVOKED`  | Consent was withdrawn after being active                                                                                                  |
| `EXPIRED`  | Consent's validity period has elapsed                                                                                                     |

**Session-level (`sessionStatus`):**

| Status               | Meaning                                                                       |
| -------------------- | ----------------------------------------------------------------------------- |
| `PENDING`            | A data-fetch has been triggered and is in progress                            |
| `DATA_READY`         | All accounts under this session finished fetching successfully                |
| `PARTIAL_DATA_READY` | Some, but not all, accounts under this session finished fetching successfully |
| `SESSION_FAILED`     | The data-fetch session failed                                                 |
| `SESSION_EXPIRED`    | The data-fetch session expired before completing                              |

<Note>
  The data-fetch webhook's own `sessionStatus` field carries a similar but not
  identical value set — it can additionally be `DATA_DENIED`, and can never be
  `PENDING` (the webhook only fires on terminal outcomes).
</Note>

**Session-event (`eventStatus`, in `sessions[]`):**

| Status            | Meaning                                      |
| ----------------- | -------------------------------------------- |
| `DATA_READY`      | Data fetched successfully for this session   |
| `DATA_DENIED`     | The FIP declined the data-fetch request      |
| `SESSION_FAILED`  | The data-fetch session failed                |
| `SESSION_EXPIRED` | The session expired before the FIP responded |

<Note>
  This is a different value set from the consolidated consent callback's top-level
  `eventStatus` (`SUCCESS`/`FAILED`), despite sharing the same field name.
</Note>

**Per-account (`fiStatus`, in `linkRefNumbers[]`):**

| Status                | Meaning                                                                             |
| --------------------- | ----------------------------------------------------------------------------------- |
| `PENDING`             | The fetch for this account is still in progress                                     |
| `READY` / `DELIVERED` | Data is available for that account                                                  |
| `DENIED`              | The FIP declined the data-fetch request for this account                            |
| `TIMEOUT`             | The data-fetch request did not complete within the expected window for this account |

<Warning>
  Apply your own client-side ceiling on how long you'll wait for a `PENDING` account —
  don't assume it will always transition to a terminal state on its own.
</Warning>

## Error Codes

```jsonc theme={null}
{
  "status": "FAILURE",
  "errorCode": "TRANSACTION_NOT_FOUND",
  "message": "string"
}
```

| Error Code              | HTTP status | Meaning                                                                                                                                                                                       |
| ----------------------- | ----------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `UNAUTHORIZED`          | 401         | `Authorization` header is missing, malformed, or the credentials don't match your onboarded `client_id`/`client_secret`.                                                                      |
| `INVALID_REQUEST`       | 400         | Request body fails schema validation, more than one of `consentId`/`sessionId`/`consentHandle` is supplied, or a batch array exceeds 15 identifiers.                                          |
| `TRANSACTION_NOT_FOUND` | 404         | `transactionId` doesn't resolve to any known transaction — required on both the batch and single-lookup request shapes, so a bad value fails the same way regardless of which shape you send. |

## Next step

Once a consent's `status` is `ACTIVE`, trigger a data pull via
[Request Data](./request-data).