Plaid quickstart runs the same API from five backends against one React frontend

One integration, five client libraries, one frontend

The plaid quickstart repository accompanies Plaid's quickstart guide and contains full example integration apps using the official client libraries. The README describes it as the main Plaid Quickstart, designed to show as many products and configurations as possible, including all five officially supported client libraries and multiple Plaid APIs, against a React frontend.

The repository layout makes the structure obvious. There are directories for node, python, ruby, go and java, plus a frontend directory, an assets directory, a .env.example, a LICENSE and a README.

Having five backends is the unusual part, and it is deliberate. Each one is a complete working app against the same API, so a developer can read the same flow in the language they already use, and can compare how two client libraries express the same request.

There is a wider family of sibling quickstarts, and the README points at them rather than duplicating their content. The Tiny Quickstart covers a more minimal backend in one language with one endpoint, for JavaScript, Next.js, React and React Native frontends. A community Blazor quickstart exists for the Going.Plaid .NET SDK, and there are separate quickstarts for Identity Verification, for Plaid Check products under the Credit Quickstart, a more in-depth Transfer Quickstart, a Transactions tutorial, and an Income sample app for legacy non CRA Income.

The Plaid CLI can set the whole thing up for you

The setup section offers two routes, and the faster one is the Plaid CLI, described as a command-line utility for the Plaid API that streamlines common development operations and can configure the Quickstart for you. It requires macOS, Linux, or WSL on Windows.

brew install plaid/plaid-cli/plaid
plaid register    # skip if you already have a Plaid account
plaid login
plaid samples create quickstart --language node   # also: python, ruby, go, java
cd quickstart

The samples create command takes a language argument, and the comment lists the five supported ones, which is the same set of backends the repository ships. The register step is the one you skip if you already have a Plaid account.

If you have already cloned the repository and registered, the shorter path is to log in and write your sandbox keys:

brew install plaid/plaid-cli/plaid
plaid login
plaid keys write --env sandbox

The CLI needs Homebrew even on Linux and WSL, which is a small but real constraint for someone on a bare Linux box.

Cloning on Windows needs symbolic links enabled

Manual setup starts with cloning the repository, and there are two documented forms, one over https and one over ssh:

git clone https://github.com/plaid/quickstart
cd quickstart

git clone [email protected]:plaid/quickstart.git
cd quickstart

The Windows note is the part that trips people up, and it exists because the repository makes use of symbolic links. On Windows you need to have checked the enable symbolic links box when you install Git, or you can open Git Bash as an administrator and clone with the setting forced:

git clone -c core.symlinks=true https://github.com/plaid/quickstart

That is a genuine first-run failure mode on Windows, and the fact that the quickstart uses symlinks is worth knowing about before you start, since it also means some editors and tools in the tree will behave oddly if the links were not created.

The next step is the environment file, and it is a copy rather than an edit:

cp .env.example .env

The minimum requirement is PLAID_CLIENT_ID and PLAID_SECRET, taken from the Plaid dashboard keys page, and the README is explicit that a .env file is a convenient local development tool and that you should never run a production application using an environment file with secrets in it.

Five backends, one set of start scripts

Each backend directory has its own dependency install and its own start script, and the README is careful about version assumptions. The pre-requisites say the language you intend to use must be installed and available at the command line, that the repo should generally work with active LTS versions such as node >= 20.19, python >= 3.10 and ruby >= 3.2, and that npm is needed along with, on Windows, a command line utility capable of running basic Unix shell commands.

The Node backend is three commands, an install and a start script:

$ cd ./node
$ npm install
$ ./start.sh

Python carries an explicit warning that python2 has reached end of life and only python3 is supported, and it also handles the virtualenv case in comments:

cd ./python

# If you use virtualenv
# virtualenv venv
# source venv/bin/activate

pip3 install -r requirements.txt
./start.sh

Ruby is bundle and start, Go is go build and start, and Java is mvn clean package and start. The Go and Java versions are worth noting because they compile rather than install, which means the first run of those backends is slower than the interpreted ones.

The backend serves on http://localhost:8000 once started, and the frontend is a separate step on http://localhost:3000.

The frontend and the port collision it handles

The frontend is a React app installed and started with npm:

cd ./frontend
npm ci
npm start

The detail worth noticing is the port behaviour. The README says the frontend runs on http://localhost:3000, and that if that port is already in use, which happens if you are running a second copy of the Quickstart, it will start on the next free port instead, and print the URL it chose.

That is a small design decision with a real purpose. A developer comparing two client libraries, for example the Node and the Go backends against the same frontend, needs to have both running at once, and a hard failure on a port collision would get in the way of exactly the comparison the repository exists to support.

The same reasoning applies to the environment. Each backend reads the same .env file from the repository root, so switching languages means changing which directory you start rather than reconfiguring anything.

Sandbox credentials and the environment settings that change the UI

The test credentials section is what makes the whole thing usable without a bank account. In Sandbox you can log in to any supported institution using user_good as the username and pass_good as the password, and if you are prompted for a two factor code, enter 1234. In Production you use real credentials.

Link may open on a phone number prompt before the institution list, and the README says you can skip it or enter a number.

The .env.example file carries the settings that decide which parts of the API the frontend touches. PLAID_ENV is set to sandbox, with a comment that production should be used for real data and that approval is requested through the dashboard, and that some institutions such as Chase, Fidelity and Schwab take longer to approve and are not available immediately. It also notes that using Production requires setting a use case for Link in the dashboard under Link Customization and Data Transparency.

PLAID_PRODUCTS is a comma separated list of products to use when initialising Link, and the comment gives auth and transactions as the example, pointing at the Link token create request products documentation for the full list.

SIGNAL_RULESET_KEY only matters if you are exercising the Signal Transaction Scores and Balance button at /signal/evaluate, which appears when PLAID_PRODUCTS includes signal. Leave it blank to use the default ruleset, whose key is always default, or set it to the key of a ruleset you created in the dashboard.

Editorial conclusion

plaid quickstart suits a developer who needs to see Plaid Link working end to end before writing their own integration, since the sandbox credentials and the five parallel backends let you compare client libraries against one another on identical flows. It is the wrong starting point for a production service, because the credential handling and configuration are explicitly development oriented. Before building on it, copy .env.example to .env, set PLAID_CLIENT_ID and PLAID_SECRET from the Plaid dashboard, and read the .env notes about SIGNAL_RULESET_KEY and PLAID_PRODUCTS, since both change which buttons the frontend shows.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. plaid/quickstart on GitHub
4. Project website
5. README