Fetching Account data

Read bank data after following Creating your first connection. Use an access token for the user who owns the connection.

Use the same userId when requesting the token, creating the connection and reading its data. Renew expired tokens for that same user identity. Begin data reads only when the connection is ACTIVE or COMPLETED and collection has finished; see the freshness check below for additional approvals and refreshes.

To keep a local copy, continue with Saving and synchronizing transactions. It explains full-history reads, changed identifiers and deletions. For cards connected through both a bank and an issuer, see duplicate sources and includeDuplicates.

Choose the data you need

Use connectionId to read one connection, or a returned account's id as accountId to read its transactions. Transaction date filters use YYYY-MM-DD. See the API Reference for full response fields and filters, and Account balance types for balance meanings.

Transaction dates are returned inside date: transactionDate is the purchase/transaction date, bookingDate is the provider's recording date, and a card transaction's valueDate is its billing date. Date filters use transactionDate first, then bookingDate, then valueDate if the earlier field is missing. See date examples and overlapping period reads before implementing a date-limited synchronization.

Read every page

Both endpoints return:

Keep the same filters and pass nextPage unchanged. URL-encode it; do not decode or construct cursors yourself. Continue even if items is empty when a cursor is present: filtering can produce an empty page before the final page.

This backend JavaScript example reads all transaction pages for one connection. apiBase includes /v2; processPage is your application's storage or processing function.

async function readTransactions(apiBase, token, connectionId, processPage) {
  let nextPage = null;
  do {
    const url = new URL(`${apiBase}/data/transactions`);
    url.searchParams.set('connectionId', connectionId);
    url.searchParams.set('limit', '100');
    if (nextPage) url.searchParams.set('nextPage', nextPage);

    const response = await fetch(url, {
      headers: { Authorization: `Bearer ${token}` }
    });
    if (!response.ok) throw new Error(`Read failed: ${response.status}`);
    const page = await response.json();
    await processPage(page.items);
    nextPage = page.nextPage;
  } while (nextPage);
}

The same pagination pattern applies to /data/accounts.

Check freshness

Read GET /connections/{connectionId} alongside the data:

• status must be ACTIVE or COMPLETED before your integration reads and synchronizes data. These normally follow successful collection. After additional account-owner approvals, ACTIVE can precede the initial collection, so also check collection progress and freshness.
• lastFetchedAt records collection activity and can also advance on failure. Inspect the current status and any error; a timestamp alone does not establish success.
• lastFetchedDataDate describes the data coverage date, not the time your application read it.

For an enabled refresh flow, GET /connections/refresh/{connectionId} returns 204 after queueing collection. The response contains no data and does not mean collection has finished. Recheck the connection and its freshness before presenting a refreshed result.

Troubleshoot missing data

See Connection states for the next action.