Skip to main content
The Transactions product returns a customer’s account transaction history. Developers use it for cash-flow modeling, risk analysis, expenditure categorization, and similar use cases.
API Reference
  • Search financial transactions: GET /bank-linking/transactions
  • Get a financial transaction: GET /bank-linking/transactions/{transactionId}

​
Overview

Transactional data helps you understand a customer’s expenditure, timing, and frequency of purchases. Call the transactions endpoint to filter transactions. See Retrieving Connection Data for an example. Transactions are typically only available for the following account types:
  • Depository accounts such as checking and savings.
  • Credit-type accounts, such as credit cards or student loan accounts.

​
Fetching transactions

See Fetching Transaction Information for how to fetch Meld transactions.

​
Updating transactions

Transactions can get updated, especially their status. See When Is Your Data Available? for more.

​
Data normalization

Meld normalizes transaction data, including the type, signage, and status. See Data Normalization for more information.

​
Transaction days fetched by refresh type

Meld loads a different period of transaction history depending on several factors — whether it is the first load (INITIAL), a subsequent refresh (SUBSEQUENT), or a historical aggregation (HISTORICAL).

​
Initial loads

For INITIAL loads (immediately following completing or reconnecting a connection), only a limited transaction history is available. Meld loads whatever the service provider has initially available:
  • Plaid: last 30 days
  • Finicity: last 180 days
  • MX: last 90 days
  • Other service providers: 30 days

​
Historical loads

After completing an INITIAL aggregation, Meld triggers a HISTORICAL aggregation with the service provider. Historical aggregations collect 2 years of transaction history across all service providers. Historical transaction data typically takes longer to aggregate (and is billed separately by the service provider), which is why it is executed after the initial aggregation. Because of this, a secondary BANK_LINKING_HISTORICAL_TRANSACTIONS_AGGREGATED webhook is issued after the first BANK_LINKING_TRANSACTIONS_AGGREGATED webhook to indicate that historical transactions are now also available (as well as how many were loaded). Since each service provider varies on what is immediately available during the INITIAL load, the HISTORICAL load collects whatever remains up to 2 years (i.e., from 30 days to 2 years for Plaid, from 180 days to 2 years for Finicity, etc.). The numbers of transactions loaded are broken down by period and reflected in the aforementioned webhooks.

​
Subsequent loads

Following both the INITIAL and HISTORICAL loads, only the recent transaction history is aggregated daily to capture any new transactions or updates to existing transactions. These loads are considered SUBSEQUENT and only retrieve the last 20 days of transaction data. This is sufficient to capture recent transactions as well as updates to existing transactions (such as transactions transitioning from PENDING to POSTED, or cancellations of transactions).

​
Recurring transactions

Certain providers identify recurring transactions (such as a monthly subscription). For Plaid and MX specifically, recurring transactions in the transaction details object have recurring=TRUE, while all other transactions have recurring=FALSE.

​
Sample response

{
    "id": "W9ja24xnWMVFc1s7D3rewfw",
    "accountId": "W9kbkRme9VT2iz623efee",
    "customerId": "W9ja24edcTHBks8hz2cvvf",
    "financialAccountId": "W9ja25UmrZF25xb2E3WSQ",
    "amount": 2018.27,
    "currency": "USD",
    "description": "Payment to Chase card ending in 1234",
    "status": "POSTED",
    "category": "Fee",
    "transactionDate": "2022-02-28T11:00:00Z",
    "postedDate": "2022-02-28T11:00:00Z",
    "serviceProviderDetails": [
        // data
    ]
}