Transaction Sync Windows and Lookback#

Each bank provider (Plaid, Akahu, Enable Banking) uses a distinct strategy to determine the date window for fetching transactions. The Sync model supports dynamic window expansion when multiple syncs queue up while one is still pending.

Plaid#

Plaid uses a cursor-based incremental sync via transactions_sync 1, so there is no explicit start_date passed per sync call — Plaid's API tracks position via a cursor. The historical window is established at link time: MAX_HISTORY_DAYS is requested when creating a link token 2, which is 730 days in production, 90 days in development 3.

Investment transactions use a date-based window and fall back to the same MAX_HISTORY_DAYS constant when no start_date is provided 4.

Akahu#

The determine_sync_start_date method in AkahuItem::Importer implements a three-level priority:

1. Account-level override — akahu_account.sync_start_date if set 5
2. Item-level override — akahu_item.sync_start_date if set 6
3. Auto-computed:
   • Incremental sync (has existing transactions + last_synced_at present): last_synced_at - 7 days 7
   • Initial sync (no stored transactions): 90.days.ago 8

Both akahu_items.sync_start_date and akahu_accounts.sync_start_date are stored as date columns in the database 9 10, allowing per-item and per-account user overrides.

Enable Banking#

The determine_sync_start_date method in EnableBankingItem::Importer uses a two-level strategy:

• Incremental sync (has stored transactions):
  • If last_synced_at is known: last_synced_at - 7 days 11
  • Otherwise: 30.days.ago 12
• Initial sync (no stored transactions): user-configured sync_start_date if set, otherwise 3.months.ago 13

The 7-day overlap on incremental syncs (shared by both Akahu and Enable Banking) guards against late-arriving or modified transactions that may not appear in real-time.

Sync Model: Dynamic Window Expansion#

The Sync model stores an optional window_start_date / window_end_date on each sync record. If a new sync is requested while an existing sync is still pending (not yet started), the expand_window_if_needed method widens the pending sync's window to cover both the old and new request:

• Takes the earlier of the two start dates 14
• Takes the later of the two end dates 15
• If either side has a nil date (unbounded), the result is also nil / unbounded 16
• Only applies when the sync is still pending — once a sync has started (syncing), its window is fixed 17

The window is validated to ensure window_start_date <= window_end_date 18.

Summary Table#