Using a Table as a Feed Destination

Send a feed into a BankSync table with one click: no connection, no field mapping. Covers upsert and append write modes, duplicate handling, row quotas, and deleting a table a feed writes to.

6 min read

On this page

The short version
Point a feed at a table
Write modes
How duplicates are avoided
What happens when you hit the row quota
Deleting a table a feed writes to
Where your data lives
Where to go next

"BankSync Table" is a destination like Google Sheets or Notion, except there is nothing to connect. There is no account to authorize, no permission to grant, no external service that can go down or revoke your token. Pick it in a feed's Destination tab and the feed writes into your own workspace.

Before you start

You need a connected bank and a feed to configure. Tables are in beta and are enabled per workspace. Storing data in a table is an explicit opt-in: feeds that write to any other destination still pass data through without retaining it.

The short version#

Pick BankSync Table in the Destination tab; there is nothing to connect or authorize.
Create a typed table inline, or choose an existing table with the same data type.
Use Upsert for normal financial data so provider corrections update the existing row.
Use Append only when every delivery must become a new row, including retries.

Point a feed at a table#

Send a feed to a table

Open the feed's Destination tab
Create a feed and pick your accounts and data type as usual, then open the Destination tab.
Choose BankSync Table
"BankSync Table" is the first card. There is no connect step, so selecting it takes you straight to the options.
Create a new table or pick an existing one
"Create new table" is the default and names the table after the feed. Choosing an existing table lists only the tables whose schema matches the feed's data type.
Set a schedule and save
Pick how often the feed runs, then save. The Mapping tab is already filled in.

Creating a new table this way builds it typed to the feed's data type, so every field in the feed has a matching column. There is no mapping to configure: both sides use the same field definitions, so the mapping is exact by construction. If you have added custom columns of your own, you can map extra source fields into them from the Mapping tab.

After the first successful sync, the feed offers a link straight to the filled table, and the option to add a second destination if you also want the data pushed somewhere external. A feed can write to a table and to a spreadsheet.

Several feeds can write to one table. Feeds from different banks, or covering different accounts, land side by side in the same dataset, which is usually what you want for a consolidated transaction ledger.

Write modes#

Every table destination runs in one of two modes.

Mode	What a sync does	Use it for
Upsert (default)	Updates the row if it already exists, inserts it if it does not	Bank data, where the provider revises rows after first sending them
Append	Inserts every incoming row, without checking whether it is already there	Immutable event logs where you want every delivery kept

Upsert is the right default for financial data. Providers routinely revise rows after first sending them: a pending transaction posts with a final amount, a merchant name is cleaned up, a trade is corrected inside its settlement window. Upsert means those revisions land on the existing row instead of creating a second, contradictory copy.

Append mode can double-write

Append mode has no identity, so it cannot tell a re-delivery from a new row. If a sync is retried after a partial failure, some rows are written twice. This is the same caveat as append mode on database destinations. Use upsert unless you specifically need every delivery preserved.

How duplicates are avoided#

In upsert mode, each table has an identity: the set of columns that decide whether two rows are the same row.

On a typed table, BankSync sets the identity for you. Where the provider gives a stable transaction identifier, that identifier is the identity. Where it does not, the identity is a composite that always includes the account the row came from, plus date, amount, and description. The account is part of it deliberately: without it, a $12.00 coffee on the same day in two different accounts would collapse into one row.
On a custom table, there is no identity until you set one. Until you do, the table is append-only. Mark the columns that make a row unique from the schema panel, and upserts start working.

You can override the identity on any table if you know your data better than the default does.

Because identity lives on the table, several feeds writing to it deduplicate against each other, not just against their own past runs. Two feeds that overlap on an account will not produce two copies of the same transaction.

This also makes retries safe. If a sync fails partway through and the run is replayed, the rows already written are matched and updated rather than duplicated.

What happens when you hit the row quota#

Your plan caps the total number of rows stored across all tables in the workspace. See the plan limits for the numbers.

At 80% of the limit, BankSync shows a banner on the Tables surface and notifies the workspace. Nothing stops.
At 100%, table writes stop. The sync job fails with table_quota_exceeded, the failure appears on the feed like any other destination error, and the feed's status turns red.

Failing the whole job is a deliberate choice. The alternative — writing rows until the quota is reached and quietly dropping the rest — produces a table that looks complete, a feed that reports success, and a silent hole in your data that you find weeks later when a report does not reconcile. A loud failure is recoverable in five minutes. A silent one is not recoverable at all.

To clear it: delete rows or a table you no longer need, or upgrade your plan. Then re-run the feed. Because upserts are idempotent, re-running is safe and picks up exactly what was missed.

Deleting a table a feed writes to#

Deleting a table that a feed targets is allowed, but BankSync makes you see the consequences first.

Deleting a connected table

You are told which feeds write to it
The delete dialog lists every feed with this table as its destination, with links to each one.
The table moves to trash, not to nothing
The table and its rows go to trash and can be restored for 30 days.
Affected feeds are paused, not left failing
The next run of a feed whose table is gone fails with a table_not_found error and the feed's schedule is automatically disabled, with the reason recorded on the feed.

Auto-disabling is intentional: a feed whose destination no longer exists has nothing useful to do, and retrying it every hour would just fill your feed history with identical failures and send you identical alerts. Repoint the feed at another table, or restore the deleted one, then re-enable the schedule.

Deleting a table does not touch the bank connection or the accounts it read from.

Where your data lives#

Rows written to a table stay inside BankSync. They are not sent to a third party, and the Destination tab says so where you pick it. Table data is covered by the same protections as the rest of your workspace:

Cell values never appear in logs or error messages.
Each table can carry a retention policy: keep rows forever, or purge anything older than a number of days you choose.
Withdrawing bank consent, or deleting your workspace, purges the stored rows and any attached files immediately.