Onboarding guide
What to expect when building, testing, launching, and operating a Core Exchange integration
About Core Exchange
Plaid Core Exchange is a fully FDX-compliant API specification scoped to the data models and endpoints that power Plaid downstream products. This keeps implementation focused on real-world use cases while remaining aligned with the FDX standard.
Core Exchange is designed for reliability, scale, and ecosystem interoperability rather than bespoke, one-off integrations. Once live, your institution becomes available to the full Plaid ecosystem of applications.
The high-level journey
Onboarding and setup
- Get access to the Data Partner Dashboard
- Configure environments, branding, authentication, and endpoints
Build and test
- Test authentication and data endpoints in the Validator
- Iterate on validation failures and errors
Launch
- Request production access
- Optionally run stealth testing in production against real-world apps
- Launch broadly across the Plaid ecosystem
Post-launch
- Migrate existing users, if applicable
- Monitor health and transition to steady-state support
For platform integrations, some steps are completed once, while others repeat each time a new institution is added. Each institution added to a platform follows its own configuration, testing, and production launch lifecycle.
While some partners launch in as little as one week, integrations can take six to eight weeks once build work begins. Timelines vary based on engineering prioritization, security and change-management processes, data readiness, and whether a migration is required.
Token model
Core Exchange integrations use an aggregator-level access token (sometimes referred to as a "single token") by default.
Why this model is used:
- It enables a consistent user experience across Plaid-powered applications by allowing prior authorizations to be reused when appropriate.
- It simplifies token management by avoiding per-application token issuance while maintaining centralized consent enforcement.
- It establishes Plaid as the sole OAuth client interacting with your API, reducing integration complexity.
How it works:
- A single access token is issued to Plaid for a given end user.
- Plaid is the only entity that uses this token to call your Core Exchange endpoints.
- Downstream applications do not receive or present your access token directly; Plaid retrieves data on their behalf based on authorized permissions.
This token model is the default for Core Exchange implementations.
For more details, see Returning user experience.
Integration models: single institution vs platform
When onboarding in the Data Partner Dashboard, you must select the correct integration model during the Basic Information step. This choice determines how configuration, testing, and ongoing management work and cannot be easily changed later.
Core Exchange supports two onboarding models. While the APIs are the same, the operational lifecycle differs.
Single institution
- One Data Partner Dashboard account
- One institution configuration
- Configuration managed per environment (for example, Development and Production)
- One testing and production launch
- No-code Permissions Manager and App Directory tools
Platform
- One platform-level Dashboard account
- Multiple institutions configured and launched over time
- Configuration managed per institution rather than per environment
- Repeated testing and launch cycles for each institution
- Permissions Manager and App Directory available via API only
Platform-specific considerations are called out throughout this guide.
Before you start
Before building and testing your Core Exchange integration, ensure your Dashboard profile is complete.
This includes:
- Basic organization and institution information
- Business details
- Technical contact information
Some Dashboard functionality may remain unavailable until required profile steps are completed. Information provided during profile completion is reviewed by Plaid's risk team as part of onboarding.
For more details, see Implementation checklist.
Managing team access
Administrators can manage team access directly from the Data Partner Dashboard.
- Navigate to Settings → Members to invite teammates
- Assign granular permissions based on each user's role
Getting set up in the Data Partner Dashboard
Your integration journey begins in the Plaid Data Partner Dashboard. This is where you configure, test, validate, and request production access for Core Exchange.
Plaid provisions your initial Dashboard access. From there, most onboarding steps are self-serve, with Plaid available to help as questions arise.
From the Dashboard, you can:
- Configure OAuth and API settings
- Choose which backend endpoints Plaid should call
- Configure branding shown in Plaid Link
- Validate endpoints individually or end to end
- Inspect request and response payloads
- Preview how your data appears in Plaid-powered apps
- View validation results and error logs
Configuration depends on your integration model.
For single-institution dashboards, you can configure multiple environments (for example, Development, Staging, and Production), each pointing to different backend endpoints.
For platform dashboards, environments are not used. Each institution entry represents a distinct configuration. Partners often create separate institution records for development, testing, and production use cases.
At this stage:
- No production traffic is enabled
- Your institution is not discoverable to end users
- All testing is housed within the Dashboard
For more details, see Dashboard overview.
Account select behavior
Account Select is the step in Plaid Link where users choose which accounts to share. Although it appears in Link, this behavior is controlled by the third-party application using Plaid, not by Plaid or the data partner.
Applications may support single account selection, multiple account selection, or all accounts preselected, depending on the use case.
When testing in the Validator, Account Select is set to all accounts preselected to exercise as much data as possible.
For more details, see Account selection.
Configuring Plaid products
Plaid products rely on different account types and data capabilities. Not every product applies to every integration.
Product configuration depends on supported account types such as depository, credit, loan, or investment accounts.
If certain account types or data are not supported, corresponding products should be disabled. Product enablement can be adjusted over time in coordination with Plaid.
After launch, integrations can be expanded by enabling additional account types or adding new products. New capabilities can be validated and rolled out incrementally without a full re-launch.
Migrations
Plaid will work with you on a structured migration plan designed to minimize disruption to existing Plaid-connected users.
Typical migrations run over approximately 90 days, gradually ramp traffic, and require users to re-authenticate. In select cases, backend token exchange patterns may be available that do not require user reauthentication.