Skip to main content
POST
/
v2
/
getconsentslist
Error
A valid request URL is required to generate request examples
{
  "ver": "1.21.0",
  "status": "success",
  "data": [
    {
      "consentID": "8d8dbf30-7057-441a-9486-6e67c70b4b2e",
      "consentHandle": "3a3f2d96-fc3b-42e5-804f-e65d10a4be98",
      "status": "ACTIVE",
      "productID": "TESTWM01",
      "accountID": "test123",
      "aaId": "onemoney-aa",
      "createdOn": "2025-09-15T10:30:00.000Z",
      "modifiedOn": "2025-09-15T11:00:00.000Z",
      "consentStart": "2025-09-15T10:30:00.000Z",
      "consentExpiry": "2026-09-15T10:30:00.000Z",
      "fetchType": "PERIODIC",
      "fiTypes": [
        "DEPOSIT",
        "TERM_DEPOSIT"
      ],
      "fipId": "HDFC-FIP",
      "maskedAccountNumber": "XXXXXXXX1234",
      "partyIdentifierType": "MOBILE",
      "partyIdentifierValue": "9876543210"
    }
  ]
}
{
  "ver": "1.21.0",
  "timestamp": "2025-10-01T11:43:56.125Z",
  "errorCode": "InvalidRequest",
  "errorMsg": " [ partyIdentifierValue must be valid Mobile number ] "
}
{
  "ver": "<string>",
  "timestamp": "2023-11-07T05:31:56Z",
  "errorCode": "<string>",
  "errorMsg": "<string>",
  "status": "<string>"
}

​
Overview

The Consent List V2 API provides an enhanced version of consent listing with support for flexible party identifiers. While V1 only supports mobile numbers, V2 allows you to query consents using different identifier types including mobile numbers, email addresses, PAN (Permanent Account Number), AADHAR, DOB (Date of Birth), or GSTIN. This flexibility is particularly valuable when:
  • Your customer identification strategy varies across products or channels
  • You need to support multiple identifier types within the same application
  • You’re integrating with systems that use PAN or email as primary identifiers
  • You want more precise filtering using the account ID along with party identifiers
V2 maintains the same simple, flat list structure as V1 while providing enhanced querying capabilities through the party identifier system. This makes it the recommended choice for new integrations that need flexible customer identification.

​
Endpoint

POST {{Base_URL}}/v2/getconsentslist

​
Authentication

This API requires authentication through the following headers that must be included in every request:
HeaderTypeRequiredDescription
Content-TypestringYesMust be set to application/json to indicate the request body format.
client_idstringYesYour unique client identifier provided by MoneyOne during FIU onboarding. This credential identifies your organization in the FinPro system.
client_secretstringYesYour confidential client secret provided by MoneyOne. This must be kept secure and never exposed in client-side code or public repositories.
organisationIdstringYesYour organization’s unique identifier in the FinPro system. This is assigned during onboarding and links all API calls to your FIU entity.
appIdentifierstringYesApplication-specific identifier that helps track which application or service within your organization is making the API call. Useful for multi-application FIU setups.

​
Request Body

The request body must be a JSON object containing the following parameters:
ParameterTypeRequiredDescription
partyIdentifierTypestringYesThe type of identifier being used to query consents. Valid values are MOBILE, EMAIL, PAN, AADHAR, DOB, or GSTIN. This determines how the partyIdentifierValue will be validated and matched against consent records.
partyIdentifierValuestringYesThe actual identifier value to search for. Format must match the partyIdentifierType (see the validation format table below).
productIDstringYesThe unique identifier of the consent template (product) for which you want to retrieve consents. This filters the consent list to only show consents created using this specific product configuration.
accountIDstringYesThe account identifier that links consents to specific customer interactions in your system. This provides an additional level of filtering, returning only consents associated with this specific account ID. Use the same value that was provided during consent creation.
consentHandlestringNoAn optional consent handle to filter results to a specific consent request. Must be alphanumeric (hyphens allowed). Use this when you need to look up a specific consent by its handle.
statusstringNoAn optional consent status value to filter the results. Valid values: ACTIVE, PAUSED, REVOKED, EXPIRED, PENDING. If not provided, consents of all statuses are returned.

​
Party Identifier Type Validation

The partyIdentifierValue format is validated based on the partyIdentifierType:
partyIdentifierTypeExpected FormatExample
MOBILE10-digit numeric string (no country code)9876543210
EMAILValid email addresscustomer@example.com
PAN5 uppercase letters + 4 digits + 1 uppercase letterABCDE1234F
AADHAR12-digit numeric string123456789012
DOBDate in YYYY-MM-DD format1990-01-15
GSTIN15-character GSTIN number22ABCDE1234F1Z5

​
Important Notes

  • Identifier Validation: The API validates that the partyIdentifierValue matches the expected format for the partyIdentifierType. Mismatched formats will result in validation errors.
  • Mobile Format: Mobile numbers must be exactly 10 digits without country code (+91), spaces, hyphens, or other special characters. Example: 9876543210 (correct), +919876543210 (incorrect).
  • Email Format: Email addresses must follow standard email format validation. The API checks for valid email structure including @ symbol and domain.
  • PAN Format: PAN numbers must follow the Indian PAN format: 5 uppercase letters, 4 digits, and 1 uppercase letter. Example: ABCDE1234F.
  • AADHAR Format: Aadhaar numbers must be exactly 12 digits. Example: 123456789012.
  • DOB Format: Date of birth must follow the YYYY-MM-DD format. Example: 1990-01-15.
  • GSTIN Format: GSTIN must be a 15-character alphanumeric string following the standard Indian GSTIN format. Example: 22ABCDE1234F1Z5.
  • Account ID Filtering: Unlike V1 which returns all consents for a product, V2 requires and filters by accountID, providing more targeted results for specific customer journeys.

​
Response

​
Success Response (200 OK)

When consents are found matching all the specified criteria, the API returns an array of consent objects: 
{
  "ver": "1.21.0",
  "status": "success",
  "data": [
    {
      "consentID": "8d8dbf30-7057-441a-9486-6e67c70b4b2e",
      "consentHandle": "3a3f2d96-fc3b-42e5-804f-e65d10a4be98",
      "status": "ACTIVE",
      "productID": "TESTWM01",
      "accountID": "test123",
      "aaId": "onemoney-aa",
      "createdOn": "2025-09-15T10:30:00.000Z",
      "modifiedOn": "2025-09-15T11:00:00.000Z",
      "consentStart": "2025-09-15T10:30:00.000Z",
      "consentExpiry": "2026-09-15T10:30:00.000Z",
      "fetchType": "PERIODIC",
      "fiTypes": ["DEPOSIT", "TERM_DEPOSIT"],
      "fipId": "HDFC-FIP",
      "maskedAccountNumber": "XXXXXXXX1234",
      "partyIdentifierType": "MOBILE",
      "partyIdentifierValue": "9876543210"
    }
  ]
}
FieldTypeDescription
statusstringOverall API call status. Will be success for successful requests.
verstringThe version of the FinPro API that processed this request. Useful for debugging and version tracking.
dataarrayAn array of consent objects matching the query criteria. Each object represents one consent record. The array may be empty if no matching consents exist.
Each consent object in the data array contains the following fields:
FieldTypeDescription
consentIDstringThe unique consent identifier assigned by the Account Aggregator after the customer approves the consent. This is null for consents that are still pending or were rejected. Use this ID for operations like revocation or data fetching.
consentHandlestringThe consent handle that was generated when the consent request was created. This identifies the consent request throughout its lifecycle and is available immediately upon creation.
statusstringCurrent status of the consent. Possible values: PENDING (awaiting customer action), ACTIVE (approved and currently valid), REJECTED (customer declined), REVOKED (customer or FIU cancelled), EXPIRED (validity period ended), PAUSED (temporarily suspended).
productIDstringThe product/consent template identifier that was used to create this consent. Matches the product ID from your request.
accountIDstringThe account identifier that was provided when creating the consent request. Matches the account ID from your query, as this is used as a filter.
aaIdstringIdentifier of the Account Aggregator that processed this consent. Typically onemoney-aa for MoneyOne’s AA service.
createdOnstringISO 8601 timestamp indicating when the consent request was created in the FinPro system.
modifiedOnstringISO 8601 timestamp indicating when the consent record was last updated. This changes when status transitions occur (approval, revocation, etc.).
consentStartstringISO 8601 timestamp indicating when the consent becomes valid and data fetching can begin. Usually matches or is close to the creation time.
consentExpirystringISO 8601 timestamp indicating when the consent will automatically expire. After this time, the consent can no longer be used for data fetching.
fetchTypestringThe type of data fetch allowed by this consent. PERIODIC allows multiple fetches within the validity period. ONETIME allows only a single data fetch, after which the consent becomes unusable.
fiTypesarrayArray of Financial Information types that this consent covers. Examples: DEPOSIT, TERM_DEPOSIT, RECURRING_DEPOSIT, SIP, MUTUAL_FUNDS, INSURANCE_POLICIES, etc.
fipIdstringThe Financial Information Provider (typically a bank or financial institution) identifier for which this consent was approved.
maskedAccountNumberstringThe customer’s account number at the FIP, with most digits masked for privacy. Format typically shows last 4 digits: XXXXXXXX1234.
partyIdentifierTypestringThe type of identifier associated with this consent. Matches the query parameter and confirms the identifier type used during consent creation.
partyIdentifierValuestringThe actual identifier value associated with this consent. For security, sensitive identifiers may be partially masked in some implementations.

​
Empty Result Response

If no consents match all the specified criteria: 
{
  "ver": "1.21.0",
  "status": "success",
  "data": []
}
This can occur when:
  • No consents have been created for this combination of party identifier, product ID, and account ID
  • All consents matching the criteria have been deleted or purged from the system
  • The party identifier value doesn’t match any consent records (possible typo or incorrect identifier)

​
Error Response (400 Bad Request)

When the request contains invalid data or fails validation: 
{
  "ver": "1.21.0",
  "timestamp": "2025-10-01T11:43:56.125Z",
  "errorCode": "InvalidRequest",
  "errorMsg": " [ partyIdentifierValue must be valid Mobile number ] "
}
FieldTypeDescription
verstringThe version of the FinPro API that processed this request.
timestampstringISO 8601 formatted timestamp indicating when the error occurred. Useful for debugging and correlating with server logs.
errorCodestringA human-readable error code indicating the category of error. Common values include InvalidRequest, AuthenticationFailed, etc.
errorMsgstringA detailed error message explaining what went wrong. This provides specific information about which field or validation rule caused the failure. The message indicates which field has validation issues.

​
Common Error Codes

Error CodeStatus CodeDescriptionResolution
InvalidRequest400The request body contains invalid data or missing required fields.Verify that all four required fields (partyIdentifierType, partyIdentifierValue, productID, accountID) are present and correctly formatted.
InvalidPartyIdentifier400The partyIdentifierValue does not match the format expected by partyIdentifierType.For MOBILE: 10 digits only. For EMAIL: valid email format. For PAN: 5 letters + 4 digits + 1 letter format.
InvalidProductID400The specified productID does not exist or is not configured for your organization.Verify the product ID in the FinPro admin portal and ensure it’s active.
InvalidAccountID400The accountID format is invalid or contains unsupported characters.Use alphanumeric characters only for account IDs. Avoid special characters that might cause parsing issues.
AuthenticationFailed401The provided credentials (client_id, client_secret, organisationId) are invalid or expired.Verify your credentials in the FinPro admin portal. Ensure you’re using the correct credentials for the environment.

​
Example Request

curl --location '{{Base_URL}}/v2/getconsentslist' \
--header 'Content-Type: application/json' \
--header 'client_id: {{Client_Id}}' \
--header 'client_secret: {{Client_Secret}}' \
--header 'organisationId: {{Organisation_Id}}' \
--header 'appIdentifier: {{App_Identifier}}' \
--data '{
    "partyIdentifierType": "MOBILE",
    "partyIdentifierValue": "9876543210",
    "productID": "TESTWM01",
    "accountID": "test123"
}'

curl --location '{{Base_URL}}/v2/getconsentslist' \
--header 'Content-Type: application/json' \
--header 'client_id: {{Client_Id}}' \
--header 'client_secret: {{Client_Secret}}' \
--header 'organisationId: {{Organisation_Id}}' \
--header 'appIdentifier: {{App_Identifier}}' \
--data '{
    "partyIdentifierType": "EMAIL",
    "partyIdentifierValue": "customer@example.com",
    "productID": "TESTWM01",
    "accountID": "test123"
}'

curl --location '{{Base_URL}}/v2/getconsentslist' \
--header 'Content-Type: application/json' \
--header 'client_id: {{Client_Id}}' \
--header 'client_secret: {{Client_Secret}}' \
--header 'organisationId: {{Organisation_Id}}' \
--header 'appIdentifier: {{App_Identifier}}' \
--data '{
    "partyIdentifierType": "PAN",
    "partyIdentifierValue": "ABCDE1234F",
    "productID": "TESTWM01",
    "accountID": "test123"
}'

async function getConsentsV2(identifierType, identifierValue, productID, accountID) {
  const response = await fetch('{{Base_URL}}/v2/getconsentslist', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'client_id': '{{Client_Id}}',
      'client_secret': '{{Client_Secret}}',
      'organisationId': '{{Organisation_Id}}',
      'appIdentifier': '{{App_Identifier}}'
    },
    body: JSON.stringify({
      partyIdentifierType: identifierType,
      partyIdentifierValue: identifierValue,
      productID: productID,
      accountID: accountID
    })
  });

  return await response.json();
}

// Usage examples
const mobileConsents = await getConsentsV2('MOBILE', '9876543210', 'TESTWM01', 'test123');
const emailConsents = await getConsentsV2('EMAIL', 'customer@example.com', 'TESTWM01', 'test123');
const panConsents = await getConsentsV2('PAN', 'ABCDE1234F', 'TESTWM01', 'test123');

import requests

def get_consents_v2(identifier_type, identifier_value, product_id, account_id):
    """Get consents using flexible party identifiers"""
    url = "{{Base_URL}}/v2/getconsentslist"
    headers = {
        "Content-Type": "application/json",
        "client_id": "{{Client_Id}}",
        "client_secret": "{{Client_Secret}}",
        "organisationId": "{{Organisation_Id}}",
        "appIdentifier": "{{App_Identifier}}"
    }
    payload = {
        "partyIdentifierType": identifier_type,
        "partyIdentifierValue": identifier_value,
        "productID": product_id,
        "accountID": account_id
    }

    response = requests.post(url, json=payload, headers=headers)
    return response.json()

# Usage examples
mobile_consents = get_consents_v2('MOBILE', '9876543210', 'TESTWM01', 'test123')
email_consents = get_consents_v2('EMAIL', 'customer@example.com', 'TESTWM01', 'test123')
pan_consents = get_consents_v2('PAN', 'ABCDE1234F', 'TESTWM01', 'test123')

​
Use Cases

​
Multi-Channel Customer Identification

Support different identifier types based on the customer acquisition channel: 
async function getCustomerConsents(customer, productID, accountID) {
  // Determine which identifier to use based on what's available
  if (customer.mobile) {
    return await getConsentsV2('MOBILE', customer.mobile, productID, accountID);
  } else if (customer.email) {
    return await getConsentsV2('EMAIL', customer.email, productID, accountID);
  } else if (customer.pan) {
    return await getConsentsV2('PAN', customer.pan, productID, accountID);
  } else {
    throw new Error('No valid identifier available for customer');
  }
}
Track consents for specific loan applications or customer interactions: 
def get_loan_application_consents(application_id, customer_mobile, product_id):
    """Get consents specific to a loan application"""
    account_id = f"LOAN_{application_id}"

    response = get_consents_v2(
        identifier_type='MOBILE',
        identifier_value=customer_mobile,
        product_id=product_id,
        account_id=account_id
    )

    # Check if active consents exist for this application
    active_consents = [
        c for c in response['data']
        if c['status'] == 'ACTIVE'
    ]

    return {
        'application_id': application_id,
        'has_active_consents': len(active_consents) > 0,
        'consent_count': len(active_consents),
        'consents': active_consents
    }

​
Cross-Reference Identifier Types

Validate that the same customer entity has consents across different identifier types: 
async function validateCustomerConsents(customer) {
  const results = {};

  // Query with different identifiers
  if (customer.mobile) {
    const mobileResults = await getConsentsV2(
      'MOBILE',
      customer.mobile,
      'TESTWM01',
      customer.accountID
    );
    results.mobile = mobileResults.data;
  }

  if (customer.pan) {
    const panResults = await getConsentsV2(
      'PAN',
      customer.pan,
      'TESTWM01',
      customer.accountID
    );
    results.pan = panResults.data;
  }

  // Verify consistency - same consents should appear in both queries
  const mobileConsentIDs = new Set(results.mobile?.map(c => c.consentID) || []);
  const panConsentIDs = new Set(results.pan?.map(c => c.consentID) || []);

  const isConsistent =
    mobileConsentIDs.size === panConsentIDs.size &&
    [...mobileConsentIDs].every(id => panConsentIDs.has(id));

  return {
    isConsistent,
    mobileCount: mobileConsentIDs.size,
    panCount: panConsentIDs.size,
    consents: results
  };
}

​
Best Practices

  1. Choose the Right Identifier: Use the identifier type that best matches your customer data model and acquisition channel. Mobile is most common, but PAN may be required for certain financial products.
  2. Account ID Strategy: Design a consistent account ID naming convention that allows you to correlate consents with your internal workflows. Examples: LOAN_${applicationId}, WM_${customerId}, INS_${policyId}.
  3. Identifier Validation: Validate identifier formats on the client side before making API calls to reduce unnecessary error responses and improve user experience.
  4. Caching Strategy: Cache consent lists per account ID for reasonable durations, but ensure cache invalidation when webhook notifications indicate status changes.
  5. Error Handling: Handle validation errors gracefully by providing clear user feedback about identifier format requirements.

​
API Version Comparison

  • V1: Uses only mobile number as identifier. No account ID filtering. Returns all consents for a product.
  • V2 (this API): Supports multiple identifier types (MOBILE, EMAIL, PAN, AADHAR, DOB, GSTIN). Requires account ID for more targeted filtering. Optional consentHandle and status filters. Recommended for new integrations.
  • V1 Unique Accounts: Provides deduplicated view with pagination. Best for scenarios needing unique account lists across multiple consents.
Choose V2 when:
  • You need flexibility in customer identification methods
  • You want more precise filtering using account IDs
  • You’re building new integrations and want to future-proof identifier handling
  • Your system uses PAN, email, AADHAR, DOB, or GSTIN as primary identifiers alongside or instead of mobile numbers
  • You need to filter by specific consent handle or status

Authorizations

​
client_id
string
header
required

Your unique client identifier provided by MoneyOne during FIU onboarding

​
client_secret
string
header
required

Your confidential client secret provided by MoneyOne

​
organisationId
string
header
required

Your organization's unique identifier in the FinPro system

​
appIdentifier
string
header
required

Application-specific identifier for tracking API calls

Body

application/json
​
partyIdentifierType
enum<string>
required

The type of identifier being used to query consents. Valid values are MOBILE, EMAIL, PAN, AADHAR, DOB, or GSTIN. This determines how the partyIdentifierValue will be validated and matched against consent records.

Available options:
MOBILE,
EMAIL,
PAN,
AADHAR,
DOB,
GSTIN
​
partyIdentifierValue
string
required

The actual identifier value to search for. Format must match the partyIdentifierType: for MOBILE, provide a 10-digit number; for EMAIL, provide a valid email address; for PAN, provide a 10-character PAN number (5 uppercase letters, 4 digits, 1 uppercase letter); for AADHAR, provide a 12-digit number; for DOB, provide date in YYYY-MM-DD format; for GSTIN, provide a 15-character GSTIN number.

​
productID
string
required

The unique identifier of the consent template (product) for which you want to retrieve consents. This filters the consent list to only show consents created using this specific product configuration.

​
accountID
string
required

The account identifier that links consents to specific customer interactions in your system. This provides an additional level of filtering, returning only consents associated with this specific account ID.

​
consentHandle
string

An optional consent handle to filter results to a specific consent request. Must be alphanumeric (hyphens allowed). Use this when you need to look up a specific consent by its handle.

Pattern: ^[a-zA-Z0-9-]+$
​
status
enum<string>

An optional consent status value to filter the results. If not provided, consents of all statuses are returned.

Available options:
ACTIVE,
PAUSED,
REVOKED,
EXPIRED,
PENDING

Response

Consents retrieved successfully

​
ver
string

The version of the FinPro API that processed this request.

​
status
string

Overall API call status. Will be 'success' for successful requests.

​
data
object[]

An array of consent objects matching the query criteria. Each object represents one consent record. The array may be empty if no matching consents exist.