Track Status - Moneyone FinPro

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

{
  "transactionId": "string",      // required
  "consentId": ["string"],        // optional, array — batch lookup
  "sessionId": ["string"],        // optional, array — batch lookup
  "consentHandle": ["string"]     // optional, array — batch lookup
}

string

required

The transactionId returned by Consent Creation.

Batch lookup by one or more consent IDs (up to 15). Mutually exclusive with sessionId/consentHandle — supply exactly one of the three.

array

Batch lookup by one or more session IDs (up to 15). Mutually exclusive with consentId/consentHandle — supply exactly one of the three.

Batch lookup by one or more consent handles (up to 15). Mutually exclusive with consentId/sessionId — supply exactly one of the three.

transactionId only
Batch lookup

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

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>"
  }'

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

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

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

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>"]
  }'

Response

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

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

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

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

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

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

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.

Error Codes

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

​Endpoint

​Headers

​Request body

​Sample request

​Response

​Sample request

​Response

​Status Codes

​Error Codes

​Next step

Endpoint

Headers

Request body

Sample request

Response

Sample request

Response

Status Codes

Error Codes

Next step