Skip to the operations

Banking

Pluggy in a decision flow.

11 Pluggy operations a decision flow can call directly, with the credentials your own contract issued. The response is data the rest of the flow reads, branches on, and keeps in the trace.

Category
Banking
Type
Integration
Authentication
Token exchange
Test environment
Production host only

Who they are

Open Finance and bank data for Brazil.

Pluggy connects to Brazilian banks, both through the regulated Open Finance rails and through direct connections, and returns accounts, transactions, investments, loans and identity. Lenders use it to evidence income and existing debt for applicants whose bureau file says little. It also initiates Pix payments, including the scheduled and automatic variants.

What a flow can call

11 operations, each one a step you can place on the canvas.

  1. POST/connect_token

    Start a bank connection (Connect token)

    Mints the short-lived token that initialises the Pluggy Connect widget in the applicant's browser, so bank credentials never touch us.

  2. POST/items

    Create a bank connection (Item)

    Creates an item directly, without the widget, and starts the first sync.

  3. GET/items/$data.pluggy_item_id

    Check a connection's state (Item)

    The state of one connection. Read this before pulling data — an item in LOGIN_ERROR or WAITING_USER_INPUT has no fresh data behind it, and a flow that skips the check silently scores a stale file.

  4. POST/items/$data.pluggy_item_id/mfa

    Answer a bank's second factor (MFA)

    Submits the value the bank asked for while the item is WAITING_USER_INPUT.

  5. GET/accounts?itemId=$data.pluggy_item_id

    List accounts

    Every account behind a connection, with its current and available balance.

  6. GET/accounts/$data.pluggy_account_id/balance

    Get a real-time balance

    Reads the balance straight from the institution without a full item sync.

  7. GET/v2/transactions?accountId=$data.pluggy_account_id

    List transactions

    Up to twelve months of transactions for one account, cursor paginated.

  8. GET/identity?itemId=$data.pluggy_item_id

    Read the identity the bank holds

    Name, document, addresses, phone numbers and emails as the institution has them.

  9. GET/loans?itemId=$data.pluggy_item_id

    List existing loans

    Credit already outstanding at the institution — the debt side of affordability.

  10. GET/bills?accountId=$data.pluggy_account_id

    List credit card bills

    Statement history for a credit card account: totals, minimum payments and due dates.

  11. GET/connectors

    List institutions

    Every institution Pluggy can reach, with the parameters each one needs and whether it is an Open Finance regulated connection or a direct one.

Where it sits in the decision

Banking calls have a natural place in a flow.

Bank data answers the question a stated income cannot: what actually arrives, how regularly, and what leaves again. It is usually pulled once per application and then read by several nodes — affordability, income verification, any rule about balance volatility — so it is worth fetching early and deriving from, rather than calling repeatedly.

Whatever Pluggy returns is part of the run, so it is part of the record. When someone asks months later why an applicant was declined, the answer cites what came back at the time rather than re-fetching from a service whose answer has since changed.

  • 01Add Pluggy as a connection authenticating with a token exchange.
  • 02Pluggy has one host for both environments, so guard test runs with your own credentials and limits.
  • 03Place a Connection node and pick an operation — “Start a bank connection (Connect token)” is usually the first one a flow needs.
  • 04Map the response into the fields your rules read, then test the whole path before it carries live traffic.

Common questions

Using Pluggy in a flow.

How do I connect Pluggy to a decision flow?

Add Pluggy as a connection in your workspace authenticating with a token exchange, with the credentials your own contract issued — ArboRule calls the provider as you, and never holds a contract on your behalf. Once the connection exists, any flow in the workspace can place a Connection node and choose one of its operations. The credentials live on the connection, not in the flow, so a policy owner can use Pluggy in a decision without ever seeing the secret.

Can I test Pluggy without touching production?

Pluggy exposes one host for both environments, so there is no separate sandbox to point at. Test runs still execute in Sandbox and are recorded separately in decision history, but the call goes to the same place as production — so guard it with your own test credentials, rate limits, or data.

What can a flow call on Pluggy?

11 operations, including “Start a bank connection (Connect token)”, “Create a bank connection (Item)”, “Check a connection's state (Item)”. Each one is a step you place on the canvas and map into the fields your rules read, and most flows start with “Start a bank connection (Connect token)”. The list comes from the same manifest the engine uses to make the call, so this page cannot describe an operation the product does not have.

Where in a decision should Pluggy be called?

Bank data answers the question a stated income cannot: what actually arrives, how regularly, and what leaves again. It is usually pulled once per application and then read by several nodes — affordability, income verification, any rule about balance volatility — so it is worth fetching early and deriving from, rather than calling repeatedly.

Also in Banking

Ready when you are

Wire Pluggy into a real decision.

Build the flow in Sandbox, connect your account, and watch the decision pull what it needs before it answers.

Read the docs