Data freshness
How current the data is, told straight. Connect serves from a synced cache, not a live pull on every request, and this page explains exactly what that means.
Sync cadence
Connect does not call the bank on every API request. It syncs each connected account on a schedule and serves the most recent data it holds. Reading from the API is fast and never rate-limited by the bank; the trade-off is that data is as fresh as the last successful sync, not the current second.
- Typically hourly. Most accounts are refreshed about once an hour.
- Some banks a few times a day. Open banking rules cap background refreshes for many banks at roughly four per day when you are not actively using the connection.
- Effective cadence around two hours for some banks. Provider cooldowns mean the practical refresh interval for certain banks settles near two hours.
Build for eventual freshness: poll on a sensible interval rather than in a tight loop, and expect a new transaction to appear within the account's refresh window, not instantly.
What the sync timestamp means
last_synced_at means last DATA, not last poll
last_synced_at is when transaction data was last received, not when we last checked. A quiet account with no new transactions keeps an older timestamp even though it is being polled on schedule. Do not treat a stale last_synced_at as a broken connection on its own; check the connection status for that.History depth
When an account is first connected, Connect captures as much history as the bank will provide, up to 730 days. The actual depth varies by bank; some return the full window, others less. History is captured once at connection and then kept up to date by the ongoing sync.
From that point on the stored feed only ever grows: new transactions accumulate on top of the captured history, and nothing is trimmed or expired. A year in, the feed holds the original window plus the whole year; the API serves all of it. Each account advertises its depth as oldest_booking_date on the accounts endpoint, so you can see how far back the feed reaches without paging through it.
An unfiltered transactions request serves the whole feed, newest first, in fixed-size pages. To fetch a specific period instead, use the from and to booking-date filters. For ongoing polling, request a small window that overlaps your last poll by a few days and de-duplicate on id: banks sometimes deliver transactions late with older booking dates, and the overlap catches them.
For investment accounts, activity history runs from when the account was first connected, not the account's lifetime. There is no back-fill of activity from before the link existed.
Potential duplicates are served
The transaction feed serves the bank feed faithfully. The only status we exclude is transactions you have explicitly discarded. Everything else is served, including rows our own app flags as potential duplicates. We do not silently drop them, because for an integrator that decision is yours to make.
De-duplicate on the transaction id
id as you ingest. See Pagination & errors.Balances are cached
Balances are served from cache, and every balance response includes a fetched_at timestamp telling you when that value was last refreshed from the bank. Reading a balance never triggers a live bank fetch, so the timestamp is the source of truth for how current the figure is. Both balance and fetched_at are null until the first balance sync completes.
What this means for you
- Show a "last updated" time in your app from
fetched_at/last_synced_atrather than implying real-time balances. - De-duplicate transactions on
id. - Read the connection status (see Consent & reconnection) to distinguish a quiet account from a stalled one.