Skip to main content
POST

Overview

The Get All FI Data PDF API allows you to download complete financial information in PDF format for accounts associated with a specific consent. This API is ideal when you need human-readable, formatted financial statements that can be easily viewed, printed, or shared with end users. The PDF includes formatted account details, transaction history, balance information, and account holder details in a professional document layout.

Key Use Cases

  • User-Facing Reports: Generate formatted financial statements that users can easily read and understand.
  • Document Archival: Create permanent records of financial data in a standardized PDF format.
  • Regulatory Compliance: Provide formatted financial documents for compliance and audit purposes.
  • Selective Account Retrieval: Download PDFs for specific accounts by providing their link reference numbers.
  • Transaction Filtering: Generate PDFs containing only transactions within a specified date range.

Important Notes

  • Data will only be returned if it is available in FinPro. Ensure the FI Request has been completed and the status shows DATA_READY before calling this API.
  • The requested data must align with the parameters specified in the approved consent.
  • If you need data in structured JSON format for programmatic processing, use the Get All FI Data API instead.
  • The response is a binary PDF file, not JSON. Handle the response accordingly in your application.

Authentication

This API requires authentication using the following headers:
string
required
Your unique client identifier provided by FinPro during onboarding. This ID is used to authenticate your application.
string
required
Your confidential client secret key provided by FinPro. This must be kept secure and never exposed in client-side code.
string
required
The unique identifier for your application (e.g., your application’s package name or bundle ID). This helps FinPro identify which application is making the request.
string
required
Your organization’s unique identifier assigned by FinPro. This identifies your organization in the FinPro system.
string
required
Must be set to application/json to indicate that the request body contains JSON data. Note that the response will be a PDF file (binary content).

Request Body

The unique consent identifier provided by the Account Aggregator after consent approval. This must be a valid GUID format identifier.
An array of link reference numbers for specific accounts for which PDF data is required. If this parameter is not provided, PDFs will be generated for all accounts linked to the consent. Use this to generate PDFs for selected accounts only.
string
The start date from when transaction data should be included in the PDF. Must be in ISO 8601 UTC date-time format (e.g., 2023-01-01T00:00:00Z). When provided, only transactions on or after this date will be included.
string
The end date until when transaction data should be included in the PDF. Must be in ISO 8601 UTC date-time format (e.g., 2023-01-31T23:59:59Z). When provided, only transactions on or before this date will be included.

Request Example - All Accounts

Request Example - Specific Accounts

Request Example - With Transaction Date Filtering

Response Format

Success Response

The API returns a binary PDF file as the response body with the following characteristics:
  • Content-Type: application/pdf (the response header will indicate this)
  • Format: PDF version 1.3 or higher
  • Content: Formatted financial information including:
    • Account profile details
    • Account holder information (name, DOB, mobile, email, PAN, address)
    • Account summary (balance, account type, branch, IFSC, MICR codes)
    • Transaction history in a tabular format
    • Bank/FIP name and account details
The PDF is professionally formatted with:
  • Clear section headers for Profile, Summary, and Transactions
  • Tabular layout for transaction data
  • Masked account numbers for security
  • All relevant account holder and account details
Note: The response is binary PDF content, not JSON. Your application should handle the response as a file download.

PDF Content Structure

The generated PDF contains the following sections:

1. Header Section

  • Financial Institution Provider (FIP) name
  • FI Type (e.g., Deposit, Mutual Funds)

2. Profile Section

Contains account holder information organized in a table:

3. Summary Section

Contains account summary details:

4. Transactions Section

Contains transaction history in tabular format:

Response Field Descriptions

All fields present in the PDF are derived from the structured financial data. The table below describes the data fields and their possible values:

Profile Fields

Summary Fields

Transaction Fields

Error Responses

When the provided consent ID does not exist:
HTTP Status Code: 400 Bad Request

Common Error Scenarios

When errors occur, the response will be JSON (not PDF) containing error details:
  • InvalidConsentId: The provided consent ID does not exist in the system or has been deleted.
  • InvalidRequest: The request body contains invalid data, such as malformed date formats or invalid link reference numbers.
  • NoDataAvailable: No financial data has been fetched for this consent yet. Ensure you’ve completed the FI Request and the status is DATA_READY.
  • DataIsDeleted: The data has expired and been deleted according to the data retention policy.
  • ConsentRevoked: The consent has been revoked by the user and can no longer be used.

Rate Limiting

This API is subject to rate limiting to ensure fair usage and system stability:
  • Rate Limit: 1000 requests per time window
  • Headers Returned:
    • X-RateLimit-Limit: Maximum number of requests allowed
    • X-RateLimit-Remaining: Number of requests remaining in current window
    • X-RateLimit-Reset: Unix timestamp when the rate limit resets
If you exceed the rate limit, you will receive a 429 Too Many Requests response.

Usage Flow

  1. Verify Data Readiness: Use the FI Request Status API to ensure the eventStatus is DATA_READY before calling this API.
  2. Identify Required Accounts: If you only need PDFs for specific accounts, collect their linkRefNumber values from the FI Request Status API response.
  3. Request PDF: Call this API with the consentID and optionally the linkRefNumber array to specify which accounts you want.
  4. Handle Binary Response: The response will be a binary PDF file. Save it to disk or stream it to the user as appropriate for your application.
  5. Check Response Type: If the response is JSON instead of PDF, it indicates an error. Parse the JSON to understand the error.
  6. Present to User: Display, download, or share the PDF with the end user as needed.

Best Practices

  • Status Check First: Always verify that data is ready using the FI Request Status API before attempting to retrieve the PDF. Calling this API when data is not ready will result in an error.
  • Selective Downloads: If you only need data for specific accounts, use the linkRefNumber parameter to request only those accounts. This reduces response size and processing time.
  • Transaction Filtering: Use transactionsStartDate and transactionsEndDate to generate PDFs with only relevant transactions. This is especially useful for monthly or quarterly statements.
  • Error Handling: Check the response Content-Type header. If it’s application/json, parse it as an error response. If it’s application/pdf, handle it as a binary file.
  • File Naming: When saving the PDF, use a meaningful filename that includes the consent ID, account details, and date range for easy identification (e.g., FI_Data_ConsentID_StartDate_EndDate.pdf).
  • User Presentation: For user-facing applications, provide options to view the PDF in-browser, download it, or share it via email.
  • Storage Considerations: PDF files can be large, especially for accounts with many transactions. Consider the storage implications when archiving PDFs.
  • Security: PDFs contain sensitive financial information. Ensure they are:
    • Transmitted over HTTPS
    • Stored securely with appropriate access controls
    • Protected with encryption if stored long-term
    • Deleted when no longer needed according to your data retention policy
  • Multiple Accounts: When requesting PDFs for multiple accounts (by not specifying linkRefNumber), the API may return a single consolidated PDF or multiple PDFs. Handle accordingly based on the actual implementation.
  • Date Range Validation: Ensure the transaction date range falls within the consent’s approved FI data range to avoid errors.
  • Timeout Handling: PDF generation can take longer for accounts with extensive transaction histories. Implement appropriate timeout values in your HTTP client.

PDF Viewing and Compatibility

The generated PDFs are compliant with standard PDF specifications and can be:
  • Viewed in any standard PDF reader (Adobe Acrobat, Preview, Chrome, Firefox, etc.)
  • Printed on standard paper sizes
  • Digitally archived for long-term storage
  • Shared via email or messaging platforms
  • Embedded in web applications using PDF viewers
The PDF format ensures consistent rendering across all devices and platforms, making it ideal for user-facing financial statements.

Handling Compressed Content Streams (Raw PDF Parsing)

You can request this PDF to be delivered with compressed content streams. When enabled for your integration, PDFs from this API use Flate compression (/Filter /FlateDecode) on their content streams β€” a standard part of the PDF specification (ISO 32000) that every conforming PDF library (Apache PDFBox, iText, pypdf, PyMuPDF, pdf-lib, pdfjs-dist, etc.) and viewer already supports. If you haven’t requested this, the PDF you receive already contains plaintext content streams and none of this section applies β€” no extra handling is needed either way you consume the file. When compression is enabled, this section only matters if you parse the raw PDF bytes yourself β€” for example, extracting text with regular expressions directly against the file instead of using a PDF library. In that scenario, the text-showing content inside a compressed stream will appear as opaque compressed binary rather than plaintext, and your existing text matching will stop finding it. The code below finds each Flate-compressed content stream in the PDF and decompresses it back to plaintext bytes, leaving everything else (fonts, images, cross-reference tables, other filters) untouched.

How it works

  1. Scan the PDF for N 0 obj << ... >> stream headers.
  2. For each one, check the object’s own dictionary for a sole /Filter /FlateDecode entry β€” filter chains (e.g. [/ASCII85Decode /FlateDecode]) are left alone, since inflating still-encoded bytes directly would produce garbage.
  3. Read the stream’s declared /Length. An indirect reference (/Length 5 0 R) is rejected rather than misread as a literal number β€” that stream is left compressed.
  4. Inflate the stream bytes (zlib/DEFLATE) and splice them back in place of the compressed bytes.
  5. If inflation fails for any reason, leave that stream untouched rather than corrupting the file.
This is a workaround for byte-level PDF parsing, not a replacement for a real PDF library. If you’re only rendering, displaying, or saving the PDF, no code changes are needed β€” pass the bytes straight to any standard PDF viewer or library, which already decodes FlateDecode streams transparently.

Notes and limitations

  • Only a sole /FlateDecode filter is handled. A filter chain (e.g. /Filter [/ASCII85Decode /FlateDecode]) is intentionally left compressed.
  • /Length given as an indirect reference (5 0 R) is not resolved β€” that stream is skipped and left compressed. This only affects the small minority of PDF generators that use indirect lengths; direct integer lengths (the common case) are handled fully.
  • Object dictionaries themselves (e.g. /Type /Catalog, /Pages) are never compressed by this feature and remain plaintext regardless β€” only the content stream bodies are affected.
  • If a stream fails to inflate, it’s left as-is rather than raising an error, so a partially-matched or already-plaintext stream never corrupts the rest of the file.

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

Request body for retrieving financial information in PDF format for accounts associated with an approved consent.

The unique consent identifier provided by the Account Aggregator after consent approval. This must be a valid GUID format identifier for an ACTIVE consent.

An array of link reference numbers for specific accounts for which PDF data is required. If this parameter is not provided, PDFs will be generated for all accounts linked to the consent. Use this to generate PDFs for selected accounts only.

transactionsStartDate
string<date-time>

The start date from when transaction data should be included in the PDF. Must be in ISO 8601 UTC date-time format (e.g., 2023-01-01T00:00:00Z). When provided, only transactions on or after this date will be included.

transactionsEndDate
string<date-time>

The end date until when transaction data should be included in the PDF. Must be in ISO 8601 UTC date-time format (e.g., 2023-01-31T23:59:59Z). When provided, only transactions on or before this date will be included.

Response

PDF generated successfully. The response is a binary PDF file containing formatted financial information including account profile details, account holder information, account summary, and transaction history.

Binary PDF file containing formatted financial information