Pluggy returns the same objects — Transaction, Account, Identity — whichever way an item
was connected. The objects are the same shape, but not every field is filled from both
sources. A field that is always present for one customer can be permanently null for another,
purely because of the connection type.
This page lists the fields that exist on one side only, so you can tell "this institution does not send it" apart from "this never arrives through this kind of connection".
Missing a field that is not listed here?
Then it is a per-institution coverage question, not a connection-type one. The coverage pages break it down per connector: Credit Cards, Accounts, Payment Data, Identity.
Why they differ#
Open Finance (regulated) connections read the institution's regulated APIs. The schema is fixed by the Open Finance Brasil specification, so every institution returns the same shape and Pluggy maps it once. If the specification has no field for something, no institution can send it — the gap is regulatory, not technical, and no amount of per-institution work closes it.
Direct connections read the institution's own channels. There is no common schema, so what arrives depends on what each institution exposes. This is why direct coverage is published per connector, while Open Finance coverage is essentially uniform.
The practical consequence: Open Finance gives you breadth and consistency, direct connectors sometimes give you fields the regulation never defined.
Open Finance only#
| Field | Object | Notes |
|---|---|---|
providerId | Transaction | The institution's own transaction id. The only stable provider-side identifier we expose. Direct connectors have no guaranteed equivalent — reconcile on date + amount + description instead. |
creditCardMetadata.billId | Transaction | Links the transaction to the bill it was charged to. |
brandAdditionalInfo | Account | Free text describing the brand when brand is OTHER. |
investorProfile | Identity | Investor profile classification (Conservative, Moderate, Aggressive). |
qualifications | Identity | Income, patrimony and occupation data. |
financialRelationships | Identity | The customer's products and relationship start date with the institution. |
openFinancePermissionsGranted | Consent | The permissions the user actually consented to. Has no meaning for a direct connection. |
The real-time balance endpoint is also Open Finance only — calling it on a non-Open-Finance account returns an error.
Direct only#
| Field | Object | Notes |
|---|---|---|
creditCardMetadata.totalAmount | Transaction | The total value of an instalment purchase (the sum of every instalment). The Open Finance credit-card schema has no equivalent: it reports each instalment, never the purchase total. Available on some direct connectors — see Credit Cards Coverage. |
balance on each transaction | Transaction | Running balance after the transaction. Supported by Itaú PJ, Sicredi PF & PJ and Bradesco PJ. |
totalAmount appears twice, and the two are unrelated
creditCardMetadata.totalAmount, on a transaction — the purchase total of an instalment plan. Direct only.totalAmount, on a bill — the amount of the whole bill. Available on Open Finance, mapped frombillTotalAmount.
Seeing a populated totalAmount on a bill in an Open Finance connection does not mean the transaction-level field will be populated too.
Fields people expect to be exclusive, but are not#
paymentData — the payer/payee detail on a transfer — is populated by both. Open Finance
maps it from the regulated transaction parties, and direct connectors extract it where the
institution exposes it. What varies is how completely it is filled, per institution, which is
what Payment Data Coverage tracks.
The same holds for merchant, category and operationType: both sides can populate them, with
per-institution differences in how much detail arrives.
Scope and freshness#
This page covers Transactions, Accounts, Identity and Consents, which is where the question comes up in practice. Investments, Loans and Brokerage Notes are not broken down here yet; for those, treat the per-connector coverage pages as the source of truth.
The list is derived from the connector mappers, not from sampling production data — a field
listed as available can still be null for a given institution or a given transaction. Presence
here means this connection type can return it, not it is always there.
Last reviewed: 2026-09-07, against the Open Finance Brasil Credit Card API v2.4.0 mapping.
Keeping this page true
This page is maintained alongside the connectors. When a connector change adds or removes a field on one side only — a new Open Finance mapping, or a direct connector that starts returning something new — update this page in the same change. pluggy-connectors/docs/PRODUCTS.md points here for that reason.