All drops
Forge BIView project

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

The Good

Webhook fires an incremental transactionsSync the moment a bank posts; a twice-daily cron is the safety net. Zero double-counts.

The Bad

Plaid's days_requested param is silently ignored after the first cursor exists. Cost a full debug session.

The Ugly

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.

Tech