Plaid is usually described as “the API that connects your app to bank accounts.” That framing was accurate in 2015. In 2026 the catalog shows what the surface has actually grown into — 39 distinct APIs spanning identity, income, asset reports, consumer credit, fraud, and the new consumer-permissioned data layer that sits underneath the CFPB Section 1033 rule.
It’s a useful provider to look at from the apis.io angle because the work isn’t the bank connection anymore. The connection is the table stakes. The 39 APIs are about everything you do after the link succeeds.
What’s actually in the surface
The Plaid profile decomposes into a handful of recognizable product groupings:
- Link and item lifecycle —
Item,Application,Profile,Auth,Sandbox. The infrastructure for the Plaid Link flow itself: token exchange, item state, ACH-routing verification, the auth surface every other API depends on. - Reports —
Asset Report,Base Report,Consumer Report,Statements,CRA(Consumer Reporting Agency). The lending-stack surface. Each report type is a distinct API because each is a distinct regulatory artifact. - Identity and income — verification flows that anchor underwriting, account opening, and fraud reduction.
- Payment initiation, transfer, and disbursement — the European-style PIS layer plus the US transfer/disbursement product Plaid grew into after the Galileo acquisition pressure.
- Investments, liabilities, transactions — the actual financial-data primitives that downstream apps consume.
Thirty-nine APIs is a lot for a company most developers think of as “one API.” It’s the correct count once you internalise that a separate regulatory and contractual envelope wraps each of those product lines — and a separate spec is what makes each of them properly catalogable.
Why the catalog likes this shape
Plaid is one of the providers in the network that ships separate OpenAPI files per product, not a single monolithic spec. The catalog ingests all 39 as discrete entries, which means:
- A capability like “pull a consumer credit report” is one API, not a hidden sub-section of a 4,000-line YAML.
- An agent looking for “income verification” can find the income endpoints without having to grok the entire Plaid surface.
- Per-API capability extraction (the Naftiko layer) gets a cleaner per-product view of operations and personas.
This is the shape we want every enterprise API publisher to converge on. The opposite shape — one bag-of-everything OpenAPI — is the default for a lot of providers in the catalog, and it makes downstream capability mapping much harder.
What’s interesting up close
Two specifics worth knowing about the Plaid surface in 2026:
- The CRA-flagged endpoints are a separate API in the catalog. Plaid’s positioning as a Consumer Reporting Agency under the FCRA is the reason these are partitioned. The catalog reflects the regulatory boundary, which is exactly what an integrator’s compliance team wants to see before scoping a project.
- The Profile API is the surface Plaid is building to comply with Section 1033 (the CFPB consumer-permissioned data rule that’s moving from rule to enforcement timeline). If you’re tracking the open-banking-in-the-US story, that’s the API to watch.
The takeaway
The Plaid profile is a good answer to “what does a fully mature banking-data-fabric API surface look like in 2026?” Thirty-nine APIs, separated by product and regulatory regime, each with its own OpenAPI file. Browsable per-product, indexable by capability, ready for agents to compose.
If you’re integrating Plaid, providers.apis.io/providers/plaid is a cleaner index of the surface than starting from plaid.com/docs. If you’re publishing a comparable enterprise fintech API portfolio, the per-product split is the pattern to copy.