Get All Latest Data

Overview

The Get All Latest Data API fetches incremental financial information (FI) that has been updated since the last data retrieval for consents configured with PERIODIC fetch type. This endpoint is designed to optimize data synchronization by returning only new or modified records, rather than the complete dataset each time.

For ONETIME fetch type consents, there is no concept of incremental data. In such cases, this API returns the same response as the Get All FI Data endpoint, containing the complete dataset available for that consent.

Use Cases

This API is particularly useful for:

Real-time account monitoring: Applications that need to keep track of new transactions as they occur without repeatedly downloading the entire transaction history.
Periodic data synchronization: Systems that perform scheduled updates (daily, weekly, etc.) and only need to process changes since the last synchronization cycle.
Personal Finance Management (PFM) applications: Apps that display recent activity and need efficient backend updates to minimize data transfer and processing overhead.
Spend analysis and categorization: Services that analyze transaction patterns and only need to categorize new transactions rather than reprocessing historical data.

Authentication

All requests to this endpoint must include the following authentication headers:

Header	Type	Required	Description
`client_id`	string	Yes	The unique client identifier assigned to your organization during onboarding. This value is available in the FinPro admin portal.
`client_secret`	string	Yes	The confidential client secret key paired with your client_id. Store this securely and never expose it in client-side code.
`organisationId`	string	Yes	Your organization’s unique identifier in the FinPro system, used to scope all API requests to your tenant.
`appIdentifier`	string	Yes	The application identifier that distinguishes different applications within your organization, useful for multi-product setups.
`Content-Type`	string	Yes	Must be set to `application/json` to indicate the request body format.

HTTP Request

POST {{Base_URL}}/getalllatestfidata

Request Parameters

Parameter	Type	Required	Validation	Description
`consentID`	string	Yes	Must be a valid GUID (Globally Unique Identifier) provided by the Account Aggregator after consent approval.	The unique identifier for the consent record. This consent must be in ACTIVE status and have PERIODIC fetch type configured to receive incremental updates.

Request Body Example

{
    "consentID": "3c92001e-57ea-4320-bbb8-66d524bfb435"
}

Response Format

Success Response

A successful response returns a JSON object containing the incremental financial data for all accounts linked to the specified consent.

Response Parameters

Parameter	Type	Required	Description	Supported Values
`ver`	string	Yes	The version number of the API specification being used in this response.	e.g., “1.21.0”
`status`	string	Yes	Indicates whether the request was processed successfully or encountered an error.	`success`, `failure`
`data`	array	Yes	An array of account objects, each containing incremental data for a linked account.	Array of account data objects
`data[].linkReferenceNumber`	string	Yes	The unique identifier linking this specific account to the consent. This reference is generated when an account is linked through the AA flow.	UUID format
`data[].maskedAccountNumber`	string	Yes	The account number with most digits masked for security purposes, typically showing only the last 4 digits.	e.g., “XXXXXXXX3900”
`data[].fiType`	string	Yes	Categorizes the type of financial information being shared from this account.	`DEPOSIT`, `TERM_DEPOSIT`, `TERM-DEPOSIT`, `RECURRING_DEPOSIT`, `SIP`, `CP`, `GOVT_SECURITIES`, `EQUITIES`, `BONDS`, `DEBENTURES`, `MUTUAL_FUNDS`, `ETF`, `IDR`, `CIS`, `AIF`, `INSURANCE_POLICIES`, `NPS`, `INVIT`, `REIT`, `GSTR1_3B`, `LIFE_INSURANCE`, `GENERAL_INSURANCE`, `OTHER`
`data[].bank`	string	Yes	The name of the financial institution (bank or Financial Information Provider) holding this account.	e.g., “FinShareBankServer”
`data[].Profile`	object	Yes	Contains comprehensive profile information about the account holder(s), including personal details and KYC status.	Profile object
`data[].Profile.Holders.type`	string	Yes	Indicates whether the account has a single owner or multiple joint holders.	`SINGLE`, `JOINT`
`data[].Profile.Holders.Holder`	object/array	Yes	Details about the account holder(s). For SINGLE type, this is an object; for JOINT type, this is an array of holder objects.	Holder object(s)
`data[].Profile.Holders.Holder.name`	string	Yes	The full legal name of the account holder as registered with the financial institution.	Full name string
`data[].Profile.Holders.Holder.dob`	string	Yes	The account holder’s date of birth, used for identity verification and KYC compliance.	Date string (YYYY-MM-DD format)
`data[].Profile.Holders.Holder.mobile`	string	Yes	The primary mobile number registered with the account, may be partially masked for privacy.	Mobile number string
`data[].Profile.Holders.Holder.nominee`	string	Yes	Indicates whether a nominee has been registered for this account, important for succession planning and compliance.	`Registered`, `Not-Registered`
`data[].Profile.Holders.Holder.landline`	string	Yes	The landline contact number if available, may be empty or partially masked.	Landline number string
`data[].Profile.Holders.Holder.address`	string	Yes	The complete registered address for the account holder, may be partially masked for privacy.	Address string
`data[].Profile.Holders.Holder.email`	string	Yes	The email address registered with the account, may be partially masked.	Email string
`data[].Profile.Holders.Holder.pan`	string	Yes	The Permanent Account Number (PAN) issued by the Income Tax Department of India, used for tax compliance and identity verification.	PAN format string (e.g., “ABCDE1234F”)
`data[].Profile.Holders.Holder.ckycCompliance`	string	Yes	Indicates whether the Central KYC (CKYC) verification has been completed for this account holder, ensuring regulatory compliance across financial institutions.	`YES`, `NO`, `NO_DATA_AVAILABLE`
`data[].Summary`	object	Yes	Provides a consolidated snapshot of the account’s current state, including balance and account characteristics.	Summary object
`data[].Summary.currentBalance`	string	Yes	The account balance as of the most recent update, represented as a string to preserve decimal precision.	Numeric string (e.g., “101666.33”)
`data[].Summary.currency`	string	Yes	The currency code in which the account balance is denominated.	ISO 4217 currency codes (e.g., “INR”, “USD”)
`data[].Summary.exchgeRate`	string	Yes	The exchange rate applied if currency conversion is relevant, typically “1.0” for domestic accounts.	Numeric string
`data[].Summary.balanceDateTime`	string	Yes	The exact timestamp when the current balance was calculated or last updated by the financial institution.	ISO 8601 timestamp
`data[].Summary.type`	string	Yes	The operational classification of the account, determining transaction rules and features available.	`SAVINGS`, `CURRENT`
`data[].Summary.branch`	string	Yes	The branch name or code where the account is held, useful for identifying the servicing location.	Branch identifier string
`data[].Summary.facility`	string	Yes	Additional banking facilities associated with the account, such as overdraft protection.	e.g., “OD” (Overdraft), or empty string
`data[].Summary.ifscCode`	string	Yes	The Indian Financial System Code uniquely identifying the bank branch, essential for electronic fund transfers (NEFT, RTGS, IMPS).	IFSC format string (e.g., “HDFC0001234”)
`data[].Summary.micrCode`	string	Yes	The Magnetic Ink Character Recognition code printed on cheques, used for check processing and clearance.	MICR format string (9 digits)
`data[].Transactions`	object	Yes	Contains the incremental transaction data retrieved since the last fetch, organized by transaction type and time period.	Transactions object

Response Example

{
    "ver": "1.21.0",
    "status": "success",
    "data": [
        {
            "linkReferenceNumber": "e72534d6-0016-4f0e-9da5-3e05ad405394",
            "maskedAccountNumber": "XXXXXXXX3900",
            "fiType": "DEPOSIT",
            "bank": "FinShareBankServer",
            "Profile": {
                "Holders": {
                    "type": "SINGLE",
                    "Holder": {
                        "name": "John Doe",
                        "dob": "1990-01-15",
                        "mobile": "9876543210",
                        "nominee": "Registered",
                        "landline": "",
                        "address": "123 Main Street, Mumbai, Maharashtra - 400001",
                        "email": "[email protected]",
                        "pan": "ABCDE1234F",
                        "ckycCompliance": "YES"
                    }
                }
            },
            "Summary": {
                "currentBalance": "101666.33",
                "currency": "INR",
                "exchgeRate": "1.0",
                "balanceDateTime": "2025-11-14T10:30:00.000Z",
                "type": "SAVINGS",
                "branch": "Mumbai Central",
                "facility": "OD",
                "ifscCode": "FSBS0001234",
                "micrCode": "400211002"
            },
            "Transactions": {
                "Transaction": [
                    {
                        "txnId": "TXN123456789",
                        "type": "CREDIT",
                        "mode": "UPI",
                        "amount": "5000.00",
                        "currentBalance": "101666.33",
                        "transactionTimestamp": "2025-11-13T14:25:30.000Z",
                        "valueDate": "2025-11-13",
                        "narration": "UPI/SALARY CREDIT/REF123",
                        "reference": "REF123"
                    }
                ]
            }
        }
    ]
}

Error Handling

Error Response Format

When an error occurs during request processing, the API returns a standardized error response containing diagnostic information to help identify and resolve the issue.

Field	Type	Required	Description
`ver`	string	Optional	The API version number, included when the error occurs after version validation.
`timestamp`	string	Optional	The exact time when the error was encountered, useful for log correlation and debugging.
`errorCode`	string	Optional	A machine-readable error identifier that categorizes the type of failure encountered.
`errorMsg`	string	Optional	A human-readable description of the error, providing context about what went wrong and potentially how to fix it.
`status`	string	Optional	Set to “failure” to indicate the request did not complete successfully.

Common Error Codes

Error Code	Error Message	Description	Resolution
`InvalidRequest`	”consentID is required”	The request body is missing the mandatory consentID parameter.	Include a valid consentID in the request body.
`InvalidConsentId`	”Consent ID does not exist”	The provided consent ID is not found in the system or belongs to a different organization.	Verify the consent ID is correct and was successfully created for your organization.
`ConsentNotActive`	”Consent is not in active state”	The consent has been paused, revoked, or expired, preventing data access.	Check the consent status and obtain a new consent approval if needed.
`NoIncrementalData`	”No new data available”	There have been no new transactions or updates since the last fetch for this consent.	This is informational; retry the request after the expected update interval.
`Unauthorized`	”Invalid credentials”	The authentication headers are incorrect, missing, or the credentials have expired.	Verify your client_id, client_secret, organisationId, and appIdentifier are correct and active.
`RateLimitExceeded`	”Too many requests”	The API rate limit has been exceeded for your organization.	Implement exponential backoff and reduce request frequency. Check rate limit headers in the response.

Error Response Example

{
    "ver": "1.21.0",
    "timestamp": "2025-11-14T11:51:28.773Z",
    "errorCode": "InvalidConsentId",
    "errorMsg": "Consent ID does not exist.",
    "status": "failure"
}

Usage Notes and Best Practices

Periodic Fetch Type Requirement

This API is specifically designed for consents configured with PERIODIC fetch type, which enables incremental data updates at scheduled intervals.
For ONETIME fetch type consents, this API behaves identically to the Get All FI Data endpoint, returning the complete dataset since there is no incremental update mechanism.
Verify your consent template configuration in the FinPro admin portal to ensure the fetch type matches your integration requirements.

Data Freshness and Polling Strategy

Implement a polling mechanism that respects the fetch frequency configured in your consent template (e.g., hourly, daily, weekly).
The incremental data returned represents updates since your last successful API call for that specific consent, tracked server-side by FinPro.
Consider implementing webhook listeners for DATA_READY events to trigger data retrieval only when new information is available, rather than polling on a fixed schedule.

Handling Multiple Accounts

A single consent may be linked to multiple financial accounts across different institutions (banks, mutual funds, insurance providers, etc.).
The response includes separate objects for each linked account, each containing its own incremental updates.
Process each account’s data independently, as different accounts may have different update frequencies and data availability patterns.

Data Completeness Considerations

Incremental data may not include all fields present in the initial full data fetch, focusing only on changed or new records (primarily new transactions).
If you need complete account information including profile details that rarely change, consider periodically calling the Get All FI Data endpoint to refresh your baseline dataset.
Transaction data is typically provided in reverse chronological order (most recent transactions first), though the exact ordering depends on the Financial Information Provider.

Performance and Optimization

The incremental approach significantly reduces response payload sizes compared to fetching complete historical data, improving API response times and reducing bandwidth consumption.
For high-volume integrations with many consents, implement parallel API calls with appropriate rate limiting to efficiently process updates across your user base.
Cache account profile information (holder details, account characteristics) as this data changes infrequently, and focus incremental processing on transaction data.

Always handle consent state transitions gracefully; a consent may become inactive between API calls due to user revocation, expiry, or pause actions.
Monitor webhook notifications for consent lifecycle events to maintain an accurate view of which consents are available for data retrieval.
Implement retry logic with exponential backoff for transient failures, but respect terminal error states (invalid consent, authorization failures) to avoid unnecessary API calls.

Get All FI Data: Retrieves the complete financial data for a consent, including full transaction history within the consent period.
Get FI Data: Fetches data for a specific account identified by linkReferenceNumber, useful when you need to update information for just one account.
Get FI Data XML: Provides account data in XML format for integrations that require structured XML parsing rather than JSON.
Get FI Balance: Retrieves only the current balance information for accounts, optimized for display purposes without full transaction details.

Consent Management

Data Management

Web Redirection

User Management

Miscellaneous

Overview

Use Cases

Authentication

HTTP Request

Request Parameters

Request Body Example

Response Format

Success Response

Response Parameters

Response Example

Error Handling

Error Response Format

Common Error Codes

Error Response Example

Usage Notes and Best Practices

Periodic Fetch Type Requirement

Data Freshness and Polling Strategy

Handling Multiple Accounts

Data Completeness Considerations

Performance and Optimization

Consent Management

Data Management

Web Redirection

User Management

Miscellaneous

​Overview

​Use Cases

​Authentication

​HTTP Request

​Request Parameters

​Request Body Example

​Response Format

​Success Response

​Response Parameters

​Response Example

​Error Handling

​Error Response Format

​Common Error Codes

​Error Response Example

​Usage Notes and Best Practices

​Periodic Fetch Type Requirement

​Data Freshness and Polling Strategy

​Handling Multiple Accounts

​Data Completeness Considerations

​Performance and Optimization

​Consent Lifecycle Awareness

​Related Endpoints

Overview

Use Cases

Authentication

HTTP Request

Request Parameters

Request Body Example

Response Format

Success Response

Response Parameters

Response Example

Error Handling

Error Response Format

Common Error Codes

Error Response Example

Usage Notes and Best Practices

Periodic Fetch Type Requirement

Data Freshness and Polling Strategy

Handling Multiple Accounts

Data Completeness Considerations

Performance and Optimization

Consent Lifecycle Awareness

Related Endpoints