DocsAPI Reference
Log In
Docs

Transactions

📘

API Reference

Search financial transactions
Get a financial transaction

Overview

Transactional data helps you understand a customer's expenditure, timing, and frequency of purchases. These details can be helpful for many different applications, such as cash flow modeling, risk analysis, etc. You can call the transactions endpoint to filter transactions. Also see here for an example on fetching the data.

Transactions are typically only available for the following account types:

  • Depository accounts such as checking and saving funds.
  • Credit type accounts, such as credit cards or student loan accounts.

Fetching Transactions

See here for information on how to fetch Meld transactions.

Updating Transactions

Transactions can get updated, especially their status. See more about this here.

Data Normalization

Meld normalizes transaction data, including the type, signage and the status. Seehere for more information.

Transaction Days Fetched By Refresh Type

Meld loads a different period of transaction history depending on several factors like 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 at this time. Meld loads whatever the service provider has initially available, but this varies by service provider with the following breakdown:

  • 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 will then trigger a HISTORICAL type 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 will be 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 providers varies on what is immediately available during the INITIAL load, then the HISTORICAL load will collect whatever remains up to 2 years (i.e. from 30 days - 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, then 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 retrieves the last 20 days of transaction data. This is sufficient to capture both any recent transactions that may have occurred, 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 to a service). Therfore, for Plaid and MX specifically, you will notice that 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
    ]
}