Dual-direction Plaid sync
Webhook plus cron as safety net. Zero double-counts. Two sources of truth that agree.
What
Forge BI needs bank data to stay fresh. A Plaid webhook fires the moment a bank posts a transaction. A twice-daily cron is the backup for anything the webhook missed. Together they keep the dashboard accurate without polling, and without the balance going stale for hours waiting on a schedule.
The decision that mattered
Reconcile from two directions and assume the convenient path will lie to you. The webhook is fast. The cursor-based cron is correct. Neither one alone is enough.
Two writers racing the same cursor means the idempotent upsert on Plaid transaction ID is the only thing preventing double-counts. Skip the upsert and you get phantom transactions on every webhook-plus-cron overlap.
Good / Bad / Ugly
Webhook fires an incremental transactionsSync the moment a bank posts; a twice-daily cron is the safety net. Zero double-counts.
Plaid's days_requested param is silently ignored after the first cursor exists. Cost a full debug session.
The cron and webhook can race on the same cursor; idempotent upsert on Plaid's transaction id is the only thing saving consistency.
Shipped
Webhook + cron live; balance freshness within seconds on a live bank update.
Next
Expose stale-balance age as a UI indicator.