Launch in Production checklist

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.

Complete your security questionnaire, which is required to access certain US 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.

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 and security questionnaire, you may need to implement client-side redirect logic for users on mobile devices.

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 and accounts appear in Link (only institutions and account types that support all specified 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. If you do not already collect verified phone numbers or email addresses from users, consider collecting this information before the Link flow in order to support the returning user flow.

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

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.

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.

Sometimes, Plaid API calls may fail due to intermittent outages or connectivity errors at supported institutions. Implement retry logic or error handling as necessary for product API calls.

Handle the Item error: ITEM_LOGIN_REQUIRED and 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.

Listen for the NEW_ACCOUNTS_AVAILABLE webhook to learn when an Item has a new account associated with it. To request access to that account, launch Link in update mode.

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.

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.

item_id: Included in all successful Plaid API responses that relate to a specific Item.

Before you exchange a public token for an access token when 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). This can help determine if a user has previously linked an account. For more details, see Preventing duplicate Items.

Delete Items using /item/remove when they are no longer being used. When to do this will depend on your use case, but, as an example, you may wish to delete Items when a user deletes their account with your service or becomes inactive, or if the Item has been in an error state for an extended period. 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.

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.

Make sure to specify min_last_updated_datetime when calling /accounts/balance/get to ensure balance calls to Capital One can succeed.

If fetching historical Transactions data, make sure your app implements pagination logic. For more details, see the integration instructions.

Handle Transactions webhooks, see Handling Transaction webhooks.

Handle the HOLDINGS-type DEFAULT_UPDATE webhook if your app needs to keep holdings, values, and balances up-to-date.

Handle the INVESTMENTS_TRANSACTIONS-type DEFAULT_UPDATE webhook if your app needs to keep Investments transactions up-to-date.

Handle the ASSETS-type PRODUCT_READY webhook to know when to call /asset_report/get.

Handle the ASSETS-type ERROR webhook to gracefully handle errors from failures in /asset_report/create.

Handle the PAYMENT_STATUS_UPDATE webhook to keep updated on payment status information.

Handle the INCOME-type income_verification webhook to know when the verification is complete and endpoints that show income or employment related data are ready to be called.