solutions

One integration. Five very different products.

The same key reaches banks, credit unions, brokerages, crypto exchanges and wallets, payment apps and business platforms — 22 core endpoints, 9 AI enrichment endpoints, 11 SDKs and an MCP server. What differs between the products below is which endpoints you spend your time in.

one catalogue

Every account type your product has to include.

938 institutions across 61 countries, each carrying an ordered routing chain so the platform picks the best available provider for it.

  • 475

    Banks

    Retail and commercial. Checking, savings, card and loan accounts with history.

  • 151

    Credit unions

    Member-owned institutions, routed exactly like any other bank.

  • 105

    Business platforms

    Commerce, payroll and accounting platforms that hold a balance or a ledger.

  • 89

    Investment platforms

    Brokerages and retirement providers: positions, securities, trade history.

  • 50

    Crypto exchanges

    Custodial accounts: asset balances, holdings and ledger activity.

  • 38

    Payment apps

    Balance-and-transfer accounts held at a payment provider, not a bank.

  • 30

    Crypto wallets

    Self-custody, tracked by public address. Read-only by construction.

Routing is what makes one integration cover all of it. Each institution lists its providers in preference order and the registry uses the first one whose credentials are present — so adding a provider moves institutions from hidden to connectable without a data migration or a code change. There are 14 upstream providers implemented, plus three paths that need nobody's permission: the sandbox, manual CSV/OFX/QFX import, and public-address crypto.

903 of those institutions carry a real logo, and every one is served from our own origin rather than a third-party CDN — a CDN would learn each user's IP address and which bank they were about to connect. The simulated sandbox institutions keep monogram tiles, so demo data never wears a real brand's mark.

shared by all five

The parts you would otherwise build twice.

Endpoints under /v1
31

22 core plus 9 AI enrichment. Every data endpoint is POST with a JSON body.

Client libraries
11

TypeScript / Node, Link JS (browser), Python, Go, Rust, Java, Kotlin, Swift, Dart / Flutter, PHP, .NET

MCP tools
15

An agent can search institutions, hand off Link, exchange a token and read real data without a hand-written wrapper.

Months of sandbox history
24

Deterministic per item: payroll, rent, subscriptions, groceries, travel bursts, holdings and liabilities that stay consistent.

Sandbox test credentials and what each one does
Sandbox loginWhat happens
user_good / pass_goodConnects cleanly
user_mfa / pass_goodChallenges for MFA — the code is 1234
user_lockedFails with ITEM.ERROR so you can design the unhappy path

The unhappy paths are the point of that third row. An item can enter LOGIN_REQUIRED, and the two sandbox helper endpoints let you fire any webhook type and force a re-auth on demand — so error handling is something you design deliberately rather than discover in production.

the proof

We are our own first customer.

feels.money — the consumer app on this domain — runs entirely on the platform. It is not a demo built for a screenshot.

The consumer app connects accounts through the same Link flow you would embed, holds the same fc_at_… access tokens, syncs with the same cursor loop, and receives the same signed webhooks. Its categorization, subscription detection, cash-flow forecast, health score and purchase analysis are the same nine AI endpoints on your key.

That is the honest version of a case study: no logo wall, no invented uptime figure, no customer quote nobody said. One product, shipped, on the platform being sold — and you can read what it does and how it handles data before you believe a word of it.

The fastest way to evaluate this is to use it.

A sandbox key needs no approval and no card. Institution search, OAuth and MFA simulation, consent, and 24 months of data per connection — all of it working within minutes.