Launch in Production checklist

Check off these recommended steps before launching your app in Production

Below is a list of recommended steps to take before launching your Plaid integration in production. While they might not all be required for the minimal operation of your application, the steps below will help to make your Plaid integration more robust, secure, efficient, and maintainable.

Production setup

You must migrate to Production to use more than 100 live (non-Sandbox) Items. Note that Items created on the Sandbox or Development environments cannot be migrated to Production.

If you haven't already done so, request Production access.

Complete your application profile, which is required to access certain institutions that use OAuth-based connections.

For European Union countries and the UK, there is a separate compliance process required to access financial institutions in Production. If your Plaid integration will support financial institutions in Europe (including the UK), and your business is not based in Europe, file a support ticket to request Production access for Europe. Allow at least one week for your request to be processed.

Configure both Plaid Link and your server-side code to use the Production environment by setting the appropriate value when configuring your client object or (if not using a client library) your HTTP request. For language-specific details, see the GitHub page for your client library, or API host information if not using a library.

Ensure you are using your Production secret, which can be found on the dashboard.

If migrating from Sandbox, ensure that you remove any usage of Sandbox-specific functionality, such as the user_good test user or calls to /sandbox/ endpoints.

Add teammates to the dashboard to give other users access. For more details, see Plaid teams.

Link setup

Follow the steps below to assist users in completing the Link flow, help ensure compliance with Plaid's policies, and avoid being billed for unneeded products.

Configure Link customizations within the dashboard and ensure that the countries and languages selected for the customizations match the settings provided to /link/token/create. For more details, see Link customization.

Ensure the client_name parameter of /link/token/create is set to display your company's name as you'd like it to appear within Link.

Ensure that the products parameter of /link/token/create includes only the products you intend to use. The products listed here will influence which institutions appear in Link (only institutions that support all products will appear in Link) and will trigger a billing event for listed products upon successful token exchange.

If you already have a verified phone number from your end user before they launch Link, implement the returning user flow to provide a faster login experience.

Implement OAuth support. Some institutions in both Europe and the US require the use of OAuth-based connections. While OAuth will typically "just work" on desktop, as long as you have completed your application profile, you may need to implement client-side redirect logic for users on mobile devices.

Provide any notice and obtain any consent required for Plaid to process end user information in accordance with Plaid's End User Privacy Policy.

You may find it helpful to know that some of our customers link to Plaid's privacy policy within their own privacy policy, while others surface a separate just-in-time notice and consent page during their onboarding flow. Ultimately, it is up to you to determine how to obtain any legally required consents.

For a more extensive and detailed list of recommendations for configuring Link, see Link best practices.

Callbacks

Handle callbacks beyond just onSuccess in order to gracefully handle errors and build analytics around Link.

Listen to the onExit() and onEvent() callbacks for error_type and error_code in order to implement error handling.

Listen to the onEvent() callback for exit_status or timestamp in order to implement Link conversion analytics.

Institution handling

Call /institution/get_by_id to check the status / health of an Item's associated institution before making a product endpoint call, and implement retry logic or error handling as necessary if the institution is down.

Storage & logging

Log Plaid identifiers and IDs properly to enhance security, when contacting Support about a specific request or callback, and for finding specific entries in the Activity Log. For more information, see Dashboard logs and troubleshooting.

Access tokens and Item IDs are the core identifiers that map your users to their financial institutions. Store them securely and associate them with users of your application. Make sure, however, that these identifiers are never exposed client-side. Keep in mind that one user can create multiple Items if they have accounts with multiple financial institutions.

Ensure that the following identifiers are securely logged, as they will be needed when contacting Support about a specific request or callback.

link_session_id: Included in the onExit, onEvent, and onSuccess callback of a Link integration.

request_id: Included in all Plaid API responses.

account_id: Included in all successful Plaid API responses that relate to a specific Item or account.

Webhook configuration

Plaid uses webhooks for many common flows. If your integration does any of the following, webhooks are required or strongly recommended:

(All products) Your application is calling a Plaid endpoint for an Item repeatedly, over a period of time, not just immediately after Link.
(Transactions or Investments) You are accessing transactions made after the end user linked their Item.
(Auth) You are using automated micro-deposits for account verification.
(Assets) You are creating Asset Reports.
(Payment Initiation (UK and Europe)) You are initiating payments.

Make sure Link has been initialized with your URL for receiving webhooks via /link/token/create.

Make sure you can receive webhooks from Plaid's webhook IPs.

Link in update mode

Update mode is used to fix Items that have entered an error state (for example, because a user changed their password). If your application needs to access an Item repeatedly over a period of time, rather than just immediately after Link, implementing update mode logic is strongly recommended.

Handle the Item error: ITEM_LOGIN_REQUIRED and (European institutions only) Item error: PENDING_EXPIRATION webhooks by launching update mode to ensure your users retain access to their Items. For more information, see Updating Items via Link.

Item management

Before adding a new Item, check the metadata in the onSuccess() callback against what you already have stored in your database (e.g., institution, account name, account mask) to determine if a user may have already linked their account. For more details, see Preventing duplicate Items.

Delete Items for churned users using /item/remove. Deleting unneeded Items is a security best practice and will also prevent you from being charged for these Items when using a subscription-based product such as Transactions.

Product-specific recommendations

Auth

If launching in the US, support the Instant Match, Automated micro-deposit, and Same-day micro-deposit flows for maximum institution coverage.

If supporting the Instant Match, Automated micro-deposit, or Same-Day micro-deposit flows, make sure that the country codes parameter provided to /link/token/create (or directly to Link, if using a legacy public key implementation) for these flows includes only the US and no other countries.

If supporting the Automated micro-deposit flow, make sure to listen for Auth webhooks to know when the transaction is completed.

Transactions

If fetching historical Transactions data, make sure your app implements pagination logic. For more details, see Paginating transactions.

Handle Transactions webhooks INITIAL_UPDATE and HISTORICAL_UPDATE to ensure you are retrieving all available Transactions data. For more details, see Handling Transaction webhooks.

Handle Transactions webhooks DEFAULT_UPDATE and TRANSACTIONS_REMOVED if your app needs to keep Transactions data up-to-date. For more details, see Handling Transaction webhooks.