Skip to main content
This page explains the recommended strategies for fetching and updating transactions in your application after Meld signals new data is available. Pick the strategy that best matches how aggressive your refresh cadence is and how much extra data you are willing to fetch.

​
Before you begin

  • You have an active bank linking connection.
  • You are subscribed to the BANK_LINKING_TRANSACTIONS_AGGREGATED webhook (see Webhooks Quickstart) or you are polling the connection’s successfullyAggregatedAt timestamp.

​
When to fetch

Fetching and updating transactions follows a general process:
  1. Wait for an indication that updates have occurred — either via the BANK_LINKING_TRANSACTIONS_AGGREGATED webhook or by noticing an updated successfullyAggregatedAt time for the connection.
  2. Capture those updates using one of the strategies below.
Transactions are ordered by date descending (newest first, oldest last) for each financial account, and each transaction has an associated key field that represents its position in this sequence. When capturing additions/updates, retrieving the full transaction history each time isn’t necessary (except right after the initial connection). Transactions typically aren’t added or modified beyond 2 weeks of the time of fetching them. Use one of the following to ensure all transaction additions/updates are captured during each refresh:
  1. Date-range fetch. Fetch transactions using the startDate and endDate params. Following a successful refresh, set them so the last 2 weeks of transaction history is fetched. This reasonably ensures all transaction updates are captured. The length of this period can be modified to be longer or shorter depending on how conservative you want to be. Paginate through these results using the after param set to the key of the last transaction on each page until reaching the end of the results for that time period.
  2. Oldest-updated key (forward). Use the oldestTransactionUpdatedSearchKey present for each financial account on the BANK_LINKING_TRANSACTIONS_AGGREGATED webhook. This key can be used as a baseline so all updates are captured without also capturing unnecessary older transactions that weren’t updated (which could occur with option 1). Call the search transactions endpoint with no key initially, then paginate through the results using the after key until you reach the transaction with key matching the oldestTransactionUpdatedSearchKey (newest transaction → oldest transaction updated).
  3. Oldest-updated key (reverse). The reverse of strategy #2: call the search transactions endpoint with the before key set to the oldestTransactionUpdatedSearchKey, and paginate through the results in the opposite direction using the before key until there are none remaining (oldest transaction updated → newest transaction).
The after and before fields refer to pagination order, not occurrence order. This is standard across all bank-linking search endpoints. In particular for transactions, this can be misleading: they do not mean “occurred after” or “occurred before”. Since transactions are ordered with the newest first and oldest last, each call with an after key returns the transactions on the next page (which are actually older), and each call with a before key returns the results on the previous page (which are actually newer).
When updating transactions, Meld recommends searching by financial account ID rather than connection ID. The ordering of transactions is done by transaction date per financial account, so searching by connection ID would yield a sequence of: account1 transactions ordered by date → account2 transactions ordered by date → etc. This can be misleading when parsing the transactions, as some recent transactions may appear missing when in reality they are later in the sequence because they belong to a different financial account for the connection.