Get All Latest Data

​

Overview

​

Use Cases

• 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

​

HTTP Request

POST {{Base_URL}}/getalllatestfidata

​

Request Parameters

​

Request Body Example

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

​

Response Format

​

Success Response

​

Response Parameters

​

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": "john.doe@example.com",
                        "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

​

Common Error Codes

​

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.

​

Consent Lifecycle Awareness

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

​

Related Endpoints

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