Transaction history and import limits

Sure does not always request all available history on the first sync. The result depends on your bank or provider, Sure’s integration defaults, your settings, and pagination or processing limits. A correct current balance does not mean all historical transactions have been imported.

Last verified: 3 October 2026, against Sure main at 14638a7. These are source-verified defaults, not live-bank guarantees. Your installed release may behave differently. FinanceKit mobile-client query behavior was not audited.

The Trade Republic row was reverified on 16 October 2026 against Sure 25b5f48. The Kraken row was reverified on 16 October 2026 against Sure 3801111.

How to read this reference

Initial request assumes a fresh account without a custom date, unless stated otherwise.
Limits distinguish Sure’s implementation limits from bank/provider availability. A 30-day request window can be repeated to retrieve years of history; it is not necessarily a total-history limit.
Older history / later sync explains whether subsequent syncs revisit older dates. Changing a start date or pressing Sync is not a universal backfill operation.
Source links point to the inspected implementation. Configuration fields mentioned below are not necessarily exposed in every setup screen.

The tables cover all account-source adapter families at the verified commit, plus file-import routes. Market-price, exchange-rate, and property-valuation providers are not transaction import sources.

Bank connections

Source	Sure initial request/default	Limits and caveats	Older history / later sync
Plaid (US and EU) Source 1 · Source 2	730 days requested outside development; 90 days in development. Investment requests use the same default lookback.	Bank availability can be shorter. Transaction sync pages through the history Plaid has stored; 730 days is the initial request, not a lifetime retention limit.	Initial Plaid history can arrive asynchronously. A larger initial request cannot retroactively expand an already initialized Plaid item.
SimpleFIN Source 1	Walks backward in 60-day chunks, up to 6 requests (about 360 days).	Stops after two consecutive empty chunks; requested target clamped to one year. Sure comments describe commonly available 60–90 days, not a universal provider guarantee.	Custom start date is supported, but cannot overcome the six-chunk budget or upstream availability. Regular sync is incremental.
Enable Banking Source 1	3 calendar months unless an explicit start date is configured.	100-page guard per paginated fetch. Banks may expose older history only shortly after authorization, then restrict access to about 90 days.	Choose the intended initial date before the first transaction fetch. After stored transactions exist, normal sync uses last sync minus 7 days; changing the date alone does not guarantee backfill.
Akahu Source 1 · Source 2	No start-date bound on a fresh account unless account/item start date is configured.	Fetches the full accessible range. Akahu personal apps have a 730-day pre-consent allowance; bank limits and production-app scope can differ.	Explicit account/item date overrides are honored. Otherwise subsequent fetches are incremental.
Sophtron Source 1 · Source 2	120 days by default.	Configured initial date is clamped to at most 3 years ago. Actual bank availability can be shorter.	Explicit sync window/item start supported; subsequent normal fetches use an overlap window.
Lunch Flow Source 1	Later of local provider-account creation minus 7 days and now minus 90 days: normally about 7 days for a new connection.	This is a Sure-side restriction, not proof of a Lunch Flow/bank history limit.	The importer does not consult the saved item sync_start_date. Subsequent syncs use last sync minus 7 days; older history needs an integration correction or file import.
Mercury Source 1	Later of local provider-account creation minus 7 days and now minus 90 days: normally about 7 days for a new connection.	Sure-side restriction; not a verified Mercury retention limit.	The importer does not consult the saved item sync_start_date. Subsequent syncs use last sync minus 7 days.
Brex Source 1 · Source 2	Without a passed sync window: later of local provider-account creation minus 7 days and now minus 90 days. Normally about 7 days.	Applies to card and cash transaction fetches. Sure-side default, not an upstream retention claim.	An explicitly passed sync.window_start_date overrides this calculation; do not assume the saved item date alone does.
Fio Source 1 · Source 2	90 days by default; configurable account/item date or FIO_INITIAL_HISTORY_DAYS.	Older data requires the bank’s temporary full-history authorization. When refused, Sure records the lock and confines later attempts to the allowed recent window.	Unlock history at Fio and use the connection recovery path; Sure tracks covered-from/through dates and can backfill an unfinished range.
Monobank Source 1 · Source 2	31 days by default; account/item start date or MONOBANK_INITIAL_HISTORY_DAYS can extend target.	31-day statement windows; default budget 4 statement requests across the connection per sync.	Older requested history is accumulated across later syncs, not necessarily returned on the first run.
Up Bank Source 1 · Source 2	90 days unless account/item date is configured.	Sure default, not a claim that Up only stores 90 days. Provider pagination follows available results.	Account/item start date overrides are honored; otherwise normal sync uses a recent overlap.
Wise Source 1 · Source 2	365 days by default, or an explicit sync/item date. Optional import-all-history mode.	Full-history statements start at the reported balance creation date, falling back to 2000-01-01. Transfers/activities and statements have distinct fetch paths; API permissions still matter.	Use import-all-history or the appropriate explicit date. Existing statement history can trigger a 7-day incremental overlap; toggling a flag is not a universal forced-backfill guarantee.
Redbark Source 1 · Source 2	90 days unless account sync_start_date is configured.	Pages through results and subdivides saturated date windows; safety limits can still fail a too-large fetch.	Once history exists, normal sync uses last sync minus 7 days, rather than replaying the configured initial date.

Brokerages and investments

Source	Sure initial request/default	Limits and caveats	Older history / later sync
SnapTrade Source 1 · Source 2	Account start date, else broker-reported first transaction date, else 1,095 days ago.	The three-year value is a fallback, not a hard oldest-date cap. Brokerage coverage and asynchronous activity retrieval can limit the first result.	Full-history versus incremental mode depends on stored activity and sync markers; established accounts normally use a 30-day overlap.
Questrade Source 1 · Source 2	1,095 days unless an account start date is configured.	Requested range is split into 30-day inclusive windows; this per-request restriction is not a 30-day total-history limit.	Configured start takes precedence; established accounts otherwise use last activity sync minus 30 days.
Interactive Brokers (IBKR Flex) Source 1 · Source 2	Whatever dates and sections are included in the configured Flex statement.	Sure downloads and parses the report; it does not independently ask for all IBKR history.	Configure/export an appropriate historical report. Missing statement sections cannot be reconstructed by Sure.
Trading 212 Source 1 · Source 2	No date cutoff passed to history endpoints; orders, dividends and cash transactions are paginated.	200-page cap × 50 rows per endpoint (nominally 10,000 per stream). Upstream availability still applies.	A very active account can exceed the page cap even without a date cutoff.
Trade Republic Source 1 · Source 2	Fetches timeline topics without a fixed lookback date on first sync.	Up to 50 pages per pagination pass for each timeline topic; head and backfill passes can both run in one sync; up to 200 detail enrichments per sync; raw merged timeline cache capped at 5,000 events per Sure provider account.	Sure stores a per-topic pagination cursor after each sync and continues the history backfill from that cursor on the next sync, working backwards until the topic is exhausted or the 5,000-event cache cap is reached. Backfill stops after five consecutive failed attempts without cursor progress; a websocket failure during a backfill carries the cursor forward so the next sync resumes at the failed page rather than starting over. Do not describe this as guaranteed all-time history, or the raw-cache cap as a blanket deletion of already imported entries.
Indexa Capital Source 1	No transaction-history fetch in the current importer.	Current path imports accounts, balances and holdings. Presence of activity-processing classes/start-date fields does not mean historical activities are fetched.	Use exported transaction data where supported; no promised date-based backfill through this sync path.

Crypto exchanges

Source	Sure initial request/default	Limits and caveats	Older history / later sync
Coinbase Source 1 · Source 2	Up to 100 transactions per wallet/account.	100 is a total returned-record cap in paginated_get, not merely the page size. Zero-balance non-USD wallets can also be skipped.	The history fetch does not use the saved sync_start_date; an earlier date alone cannot lift the cap.
Kraken Source 1 · Source 2	No start bound unless sync_start_date is configured; fetches both TradesHistory and ledgers. Quantity and cash independently prefer their ledger side (net of fees), falling back to TradesHistory where that side is absent.	200 pages × 50 records each: up to 10,000 trades and 10,000 ledger records per fetch. Unprotected trades can be corrected when missing ledger sides arrive.	Configured start supported, subject to the independent record caps. Existing unprotected trades can be corrected once their missing ledger sides are fetched; user-protected trades are preserved.
CoinSpot Source 1 · Source 2	365 days unless sync_start_date is configured.	Order history is requested in 30-day windows, subdividing saturated windows. A saturated single day fails rather than being accepted as complete. Other history endpoint availability still applies.	Set an earlier date to request a wider range; cannot promise upstream completeness.
Binance — spot Source 1	24 hours by default; configured start date enables an older initial walk.	24-hour API windows with trade pagination. Sure probes discovered/cached asset symbols against a fixed set of quote currencies; this is not an exhaustive historical pair inventory.	Choose the start date before initial history fetch. Cached pairs subsequently advance by trade ID.
Binance — futures Source 1	7 days by default; configured start is clamped to 180 days ago.	7-day fetch windows. Current implementation enforces a six-times-30-day oldest-date clamp. Pair-discovery limits also apply.	An earlier configured date cannot override the 180-day clamp.
Binance — P2P Source 1	30 days by default, or configured start date.	Walks history in 30-day request windows. Do not confuse this with all Binance wallet transfers, deposits, withdrawals or earn activity.	With cached P2P trades, advances from their latest timestamp.
CoinStats — exchanges Source 1 · Source 2	No from-date unless sync_start_date is set; paginated exchange history with portfolio-history fallback.	Actual history depends on what CoinStats has ingested and exposes for the exchange. No universal upstream age guarantee verified.	Explicit start is passed to exchange/portfolio endpoints.
CoinStats — wallets Source 1 · Source 2	One bulk wallet-transactions response; no date or pagination parameters passed by this path.	No evidence that this response represents all-time wallet history; the exchange pagination logic does not apply here.	Do not promise an earlier saved date will page through older wallet activity.

On-chain wallets and Apple FinanceKit

Source	Sure initial request/default	Limits and caveats	Older history / later sync
On-chain — Bitcoin Source 1 · Source 2 · Source 3	Recent address activity, bounded by a default 10-page history budget.	Page size 25 for confirmed history; unconfirmed activity and source response shape are separate. This is an address integration, not a full xpub wallet scan.	ONCHAIN_HISTORY_MAX_PAGES can raise budget up to 200. Date filter only removes fetched older records; it does not remove pagination limits.
On-chain — EVM Source 1 · Source 2 · Source 3 · Source 4	Default 10-page budget per history stream; Ethereum, Base, Arbitrum, Optimism, Polygon and Gnosis.	Blockscout page semantics differ from optional Etherscan (1,000 rows/page). Native and token activity have separate streams; not an all-chain all-history guarantee.	History budget can be raised up to 200 pages; usable history depends on explorer coverage and source availability.
On-chain — Solana Source 1 · Source 2	Default 25 transaction-detail reads per sync from bounded signature discovery.	Signature-source limits and detail budget can omit older activity even when balances are correct.	History page setting scales the detail budget; no guarantee of complete archival history.
Apple FinanceKit Source 1 · Source 2	Server receives device-supplied batches; there is no server-side bank lookback request.	Availability is constrained by FinanceKit data and the time range the user consents to share. Mobile-client query behavior was not audited here.	Check Wallet/FinanceKit sharing scope and device sync; do not assign a universal 90-day limit.

Files and statements

Source	Sure initial request/default	Limits and caveats	Older history / later sync
CSV transactions / trades Source 1 · Source 2 · Source 3 · Source 4 · Source 5	Dates contained in the supplied file; no provider-style lookback cutoff found.	Validation, mapping, duplicate handling and import size apply; base Import row ceiling is 10,000. A file cannot supply missing transactions it does not contain.	Useful for older history missing from a bank feed. Linked-account targeting is supported by backend; general mapping dropdown is manual-account-only.
QIF / Mint / Actual / YNAB / Sure export imports Source 1 · Source 2 · Source 3 · Source 4 · Source 5	History contained in the supplied export; no uniform 90-day provider cutoff.	Each format has its own supported fields, validation and account mapping. Metadata-only imports (accounts/categories/rules/merchants) are not transaction backfills.	Import historical exports through their matching importer; review account mapping and overlaps.
PDF / document statements Source 1	Dates and transactions actually extracted from the uploaded statement.	Statement date coverage, extraction accuracy and validation matter; this is not a provider-history request.	Review extracted rows and reconciliation before publishing.

Recovering older history

Check the source’s row above and its setup page. Choose your intended initial date before the first fetch where the integration supports it.
Distinguish missing older history from an incomplete first sync. Some providers deliver data asynchronously or spread historical requests over multiple syncs.
Check bank-specific authorization limits. Enable Banking explains that some banks allow deeper history only briefly after authorization, often about an hour, and then restrict later requests to approximately 90 days. Consent duration and transaction-history depth are different limits.
If the connection cannot retrieve the missing range, use a supported historical export. See CSV and other file imports for preparation and limitations.

Do not delete or unlink an account merely to test history recovery. Review overlapping dates and do not assume automatic deduplication between a bank feed and a file import.

Provider references

Maintaining this reference

When an integration changes its initial date, pagination budget, or backfill behavior, update its row and the verification date/commit together. Keep the comparison here and setup instructions on the individual provider pages, rather than copying the entire table into the FAQ.

Getting started

Key concepts

App features

Development

Authentication

Third party providers

Knowledge Base

Transaction history and import limits

How to read this reference

Bank connections

Brokerages and investments

Crypto exchanges

On-chain wallets and Apple FinanceKit

Files and statements

Recovering older history

Provider references

Maintaining this reference

​How to read this reference

​Bank connections

​Brokerages and investments

​Crypto exchanges

​On-chain wallets and Apple FinanceKit

​Files and statements

​Recovering older history

​Provider references

​Maintaining this reference

How to read this reference

Bank connections

Brokerages and investments

Crypto exchanges

On-chain wallets and Apple FinanceKit

Files and statements

Recovering older history

Provider references

Maintaining this reference