​

Configuring Pluggy as a Source

​

1. Add account access

• Client ID: the Client ID of your Pluggy application. Required.
• Client Secret: the Client Secret of the same application. Required.
• Item IDs: the item ids of the connections to sync. Leave it empty to sync every item of the application.

• Start Date: the earliest transaction date to sync. Leave it empty to sync every transaction Pluggy holds. It only applies to transactions; the other tables always bring the current state.
• Transactions lookback (days): (Default: 30) transactions dated within this many days are read again on every sync, to pick up changes of status (pending to posted), category or description. Pending transactions older than that are followed one by one until they settle (see How transactions are kept up to date).

​

2. Select streams

Tip: The stream can be found more easily by typing its name.

​

3. Configure data streams

• Layer: choose between the existing layers on your catalog. This is where you will find your new extracted tables as the extraction runs successfully.
• Folder: a folder can be created inside the selected layer to group all tables being created from this new data source.
• Table name: we suggest a name, but feel free to customize it. You have the option to add a prefix to all tables at once and make this process faster!
• Sync Type: use INCREMENTAL for Transactions, which reads only what changed on each sync. Every other stream is FULL_TABLE: Pluggy has no “changed since” filter for them, so each sync reads their current state. Read more about Sync Types here.

​

4. Configure data source

• Configure Delta Log Retention and determine for how long we should store old states of this table as it gets updated. Read more about this resource here.
• Determine when to execute an Additional Full Sync. Transactions do not need it: incremental syncs already mark the transactions Pluggy removed (see Data Quality Considerations). If you schedule one, read the warning in that section first.

​

5. Check your new source

​

Streams and Fields

​

Available streams

​

Fields by stream

​

How transactions are kept up to date

1. every transaction Pluggy received since the previous sync, whatever its date;
2. every transaction dated within the Transactions lookback (days) window, to update status, category and description;
3. every transaction that was pending on an earlier sync and is now older than the window, until Pluggy reports it as posted or removes it.

​

Data Quality Considerations

• Use removed_at IS NULL for totals. When an institution restates a transaction (its date, amount or description changes, mostly on credit cards around the bill closing), Pluggy deletes it and creates a new one with a new id; a cancelled scheduled payment is deleted too. The connector keeps the old row and fills in removed_at with the time it noticed the removal. A removed row keeps only id, account_id, item_id, date, updated_at and removed_at, so it also drops out of sums by itself. Filter removed_at IS NULL to see only the transactions that exist in Pluggy today. The same filter also hides the rows that hold only id, date and removed_at with every other column empty: they can appear after a full sync of Transactions, when the next incremental sync marks a transaction that the full sync had already left out:

SELECT *
FROM transactions
WHERE removed_at IS NULL

• Removals are detected within the lookback window. A transaction removed after it left the Transactions lookback (days) window (and that was not pending) cannot be noticed by an incremental sync. A full sync of Transactions rebuilds the table from what Pluggy holds; read the warning below first.
• provider_id is the institution’s own transaction id. It does not change when Pluggy recreates a transaction, but Pluggy only returns it for Open Finance connections; for direct connections it is always empty, and transactions can only be matched by date, amount and description.
• Reconnecting creates a new item. When a user revokes a consent and connects the same bank again, Pluggy creates a new item, with new account and transaction ids, and does not deduplicate it against the old one. The old item’s transactions stay in your table, so the same purchase can appear under two account_id values. Remove the old item from Item IDs (or delete it in Pluggy) and reconcile with provider_id (Open Finance) or with date, amount and description.
• Expired or revoked consents return no data. When the consent of a connection expires or is revoked, Pluggy keeps the item but returns no accounts, transactions or other data for it until the user connects again. The sync log lists those connections, and tables synced as FULL_TABLE lose that connection’s rows on the next sync; Transactions synced incrementally keep what was already loaded. The sync stops instead, before writing any table and with the list of connections to reconnect, when the consent of every connection expired or was revoked, and when Transactions is set to be fully replaced while a connection is expired.

• Connections that Pluggy could not refresh. Items with status LOGIN_ERROR, OUTDATED or WAITING_USER_INPUT keep serving the data of their last successful sync until the user updates the connection, so the sync goes on (even when every connection is in that state). The sync log lists them, and the items table shows their status and error.
• Availability depends on the institution and your Pluggy plan. Investments, loans, identity and credit card bills exist only for institutions that provide them. Transaction categories and merchant data require those features in your Pluggy subscription; without them the columns are empty.
• Amounts and signs. Amounts keep the precision Pluggy returns. On credit cards, a positive amount is a charge and a negative amount is a payment or credit; on bank accounts, type tells inflows (CREDIT) from outflows (DEBIT).
• Errors stop the sync. If Pluggy keeps failing, returns an unexpected answer or a list changes while it is being read, the sync stops with a message instead of loading incomplete data; the next sync tries again. Rate limits are handled automatically by waiting.