Link best practices

Discover recommendations for improving Link conversion, avoiding common Link configuration errors, and more

Prefer to learn by watching? A video guide is available for this topic.

This guide contains tips for optimizing your existing Link implementation to help increase conversion, improve your users’ experiences with Link, and avoid common mistakes and misconfiguration errors. If you are new to Link or don’t yet have a working Link integration, see Link overview for instructions on getting started with Link.

Improving Link conversion

Successful Link attempts will result in an onSuccess callback; unsuccessful attempts will result in an onExit callback. By tracking the counts of these callbacks, you can measure both successful and unsuccessful attempts to link accounts. In addition, you can obtain insight into at what point a user abandoned Link by tracking the metadata.status field within onExit.

Some steps you can take that may help increase successful Link attempts can be found below.

Customizing Link

Plaid enables you to customize certain visual aspects of your app’s interactions with Link via the customization pane in the dashboard.

Select the “co-branded” option for the Consent customization to upload a brand logo and highlight the shared trust between your app and Plaid.

Customize the title of the consent screen to best align with how your customers refer to their information being shared. For example, “[App name] uses Plaid to connect your [custom field]”.

Tweak the customizations offered around text strings, buttons, and colors to match your brand.

Create customized profiles corresponding to language and country settings to display Link to your users in a way that matches their preferred internationalization settings in your app.

For more details on all of the aspects of Link you can customize, and how to do so, see Link Customization.

Providing pre-Link messaging

Set user expectations about the Link experience before launching Link. Explain why you are prompting them to link their account and the benefits of completing the Link flow. Tell the user what the next steps within the flow will be: for example, let them know beforehand that they’ll be asked to log into their financial institution account.

Using the Returning User Experience

If your application’s onboarding flow verifies the user’s phone number before they enter Plaid Link, you may be able to take advantage of the returning user experience (RUX), which allows users to authenticate using a streamlined flow with less data entry. For more information, see Returning User Experience.

Prompting users to remediate ITEM_LOGIN_REQUIRED errors

When a user changes their credentials, MFA, or security settings, or when a bank makes changes to its infrastructure, Plaid’s connection to the user’s bank account may be disconnected. This results in an ITEM_LOGIN_REQUIRED error. When an Item enters this state, the user’s data is no longer retrievable. To be alerted when Items enter bad states, listen for Item webhooks. To resolve the ITEM_LOGIN_REQUIRED error, you will need to prompt the user to re-authenticate using Link’s update mode.

To encourage users to re-authenticate, you can:

Notify users in-app or via email if they have Items in an error state. Alert them that there’s a problem with the connection to their financial institution account, which they can resolve by re-authenticating.

Message users about why it’s important to re-link their account(s) and ask them to do so by taking them directly to the screen with Link’s update mode.

Other usability recommendations

Implementing error handling for onExit

The onExit callback is called when a user exits Link without successfully linking their account; appropriately handling this callback and connecting it to a logical flow can improve user experience. For example, if an onExit callback contains a metadata status of institution_not_found, consider automatically navigating the user to a backup flow (e.g. micro-deposits for an Auth use case).

De-duping duplicate Items

To avoid user confusion and avoid double-billing, implement logic to prevent users from Linking the same Item twice.

Specifying a webhook handler

A webhook destination URL can be configured at the point of creating your Link Token. Webhooks are a core part of Plaid's API, and most applications that integrate with Plaid should be configured to listen to Plaid webhooks. To learn more, see Webhooks.

Choosing when to initialize products

The products you choose to configure Link with can have implications for billing, the Institution Select Pane, and product performance. While Link must be initialized with at least one product, you can often choose whether initialize Link with a product or to instead initialize the Item with that product post-Link.

If an Item was not initialized with a given product at the time of Link, making a product endpoint call for information about that Item will automatically initialize the Item. For example, if an Item was not initialized with Transactions during Link, calling /transactions/get on that Item for the first time will initialize it with the Transactions product.

There are some exceptions to this flexibility:

To use Instant Match, Automated Micro-deposits, or Same Day Micro-deposits, Auth cannot be initialized post-Link.
To use Same Day Micro-deposits, Auth must be the only product Link is initialized with.
To use Income, Income must be the only product Link is initialized with.
Assets, Income, and Payment Initiation cannot be initialized post-Link.
If using the pre-authenticated Returning User Experience, you cannot initialize any products post-Link.

Impacts on billing

If you initialize Link with a product that is billed under an initialization or subscription model, you will be billed when an Item for the product is created, even if you are not yet using the product’s endpoints.

To avoid unwanted charges, do not initialize Link with a product in Production unless you are sure you are going to use that product.

To learn more about how Plaid bills each product, see Billing.

Impacts on institution select

Plaid filters the institution list displayed to the user based on the products Link is initialized with. If Link is initialized with multiple products, only institutions supporting all of those products will be available.

To avoid overly filtering the institution list, initialize Link with your required products and call other products’ endpoints later.

Impacts on performance

Plaid begins to prepare transactions data upon Item link if Link is initialized with transactions, or upon the first call to /transactions/get otherwise. Similarly, Plaid begins to prepare investments transactions data upon Item link if Link is initialized with investments, or upon the first call to /investments/transactions/get otherwise.

Preparing transactions data can take up to several minutes depending on the amount of history available, so you may be able to retrieve transactions more quickly by initializing Link with Transactions and/or Investments.

Choosing when to enable Select Account and account filtering

Select Account

Select Account, if enabled, creates a pane that allows users to select one or more of the account(s) at their institution. If using Select Account, the Connected pane will be skipped and the onSuccess callback will fire after the user selects their account(s).

Enable Select Account if you believe users may only want your application to interact with a subset of their accounts at a specific institution, or if your application expects only one account to be used with it.

For example, if you anticipate a use case where users want to move money with Auth -- and know which specific account(s) they need to have money coming from and going to -- enable Select Account.

For more information on Select Account, see Link Customization.

Account filtering

Account type/subtype filtering lets you configure the Link flow to show only the institutions that support the account types and subtypes relevant to your use case. Account filtering can be enabled when calling /link/token/create and applies to both the Institution Select pane and the Select Account pane (if enabled).

If your app should only work with certain account subtypes, enable account subtype filtering.

As an example, say your app can perform frequent funds transfers out of the linked account, but savings accounts in the US are limited to six outgoing transfers per month. In this case, you may want to apply a checking account subtype filter in conjunction with enabling Select Account. Then, the user will only see checking accounts on the Select Account pane. For more information, see Account subtype filters.