Migrating from Plaid Exchange

Plaid Exchange is closed to new integrations; its own documentation directs implementers to Core Exchange, the only specification Plaid continues to develop, covering FDX 4.6 and later. Core Exchange offers self-serve tooling that Plaid Exchange lacks: a Data Partner Dashboard, an in-browser Validator, Permissions Manager, and App Directory.

Plaid Exchange collapsed identity, account, and transaction data into two endpoints. Core Exchange splits the same data across purpose-specific FDX endpoints:

The overall shape carries over: an OAuth 2.0 authorization code grant, with Plaid redirecting the user to your authorization_endpoint and later exchanging a code at your token_endpoint. A handful of specifics change:

Plaid Exchange defined a deprecated direct-credential flow (POST /users/auth_token) with Plaid-visible multi-factor escalation: MfaOtpEscalationChallenge, MfaKbaEscalationChallenge, and MfaTotpEscalationChallenge responses, followed by POST /users/{user_id}/sendOtp and POST /users/{user_id}/2fa. Core Exchange has no equivalent endpoints. Plaid requires 2FA for every Core Exchange connection, but the entire authentication flow, including any second factor, happens inside your hosted authorization_endpoint, before redirecting back to Plaid with an authorization code.

What to update: if your PX integration relies on the OTP/KBA/TOTP endpoints rather than pure OAuth, move that challenge logic into your own login flow. There is no code-level migration path for these endpoints; they are removed, not renamed.

Plaid Exchange did not support OIDC discovery or JWKS; you gave Plaid your authorization_endpoint and token_endpoint directly. Core Exchange strongly recommends OIDC, discovered via .well-known/openid-configuration, with ID tokens verified against keys published at your jwks_uri.

What to update: if you're moving to OIDC as part of this migration (recommended, since OIDC supplies the ID token's sub, the identifier the returning user experience relies on), stand up a discovery document and a JWKS endpoint. See OAuth server setup. Plain OAuth 2.0 without OIDC is still supported; resolve the identifier via /customers/current instead.

Core Exchange's authorization redirect includes prompt=login, and its token request includes prompt=consent. Plaid Exchange's flow didn't send either.

What to update: treat an unrecognized prompt value as informational rather than rejecting the request, unless you choose to act on it.

Plaid Exchange didn't specify a response body for a failed token request. Core Exchange requires HTTP 400 with a JSON body containing error (from a defined code list: invalid_request, invalid_client, invalid_grant, unauthorized_client, unsupported_grant_type, invalid_scope) and optional error_description/error_uri, per RFC 6749 §5.2. Core Exchange defines a convention for an expired access token: return HTTP 401 with error code 602 not authorized. Plaid treats this as an error for that request; it refreshes tokens before the expiration in the expires_in you returned, so don't expire tokens early.

What to update: if your PX token endpoint returns a bare 400/401 with no structured body, add the error field so Plaid can distinguish failure modes.

No changes needed: the authorization-redirect error vocabulary (invalid_request, unauthorized_client, access_denied, unsupported_response_type, invalid_scope, server_error, temporarily_unavailable) is identical between PX and CX, as is the redirect_uri you send authorization codes back to (https://cdn.plaid.com/link/v2/stable/oauth.html) and the client ID / client secret model.

Plaid Exchange used a Plaid-specific schema (BaseAccount, DepositoryAccount, InvestmentAccount, LoanAccount, CreditCardAccount, BasicIdentity, FullIdentity, and so on), with account type/subtype expressed as lowercase strings (for example depository / checking). Core Exchange uses the FDX-aligned schema documented per version in the API reference. Check the version you're targeting for exact field names, enum values, and discriminators (for example accountCategory), and re-map directly from that schema rather than assuming a 1:1 rename from the PX models.

Plaid Exchange's BasicErrorResponse/AuthenticationError/InstitutionError distinguish failures mainly by HTTP status. Core Exchange's error entity carries a persistent FDX code (for example 705 for "account is closed") alongside message and debugMessage, independent of the HTTP status returned. Build your error handling around the FDX code, not just the status code.

• Data Partner Dashboard and Validator: self-serve configuration and endpoint-by-endpoint testing.
• Permissions Manager: visibility into authorization records for your customers' connections, including revocation and reauthorization tracking.
• App Directory: a catalog of the applications your customers connect to, via GET /fdx/recipients and GET /fdx/recipient/<recipient_id> or the Dashboard, without implementing Dynamic Client Registration.
• Data Transparency Messaging: Plaid-hosted disclosure of the data types an app is requesting, supporting 1033 compliance.
• App2App implementation guide: deep-link parameters and an implementation checklist; Plaid Exchange described App2App only at the UX level.

None of these require changes to your core data or auth implementation; they are additive once you are live on Core Exchange.

Plaid Exchange support runs through your Solutions Engineer directly, for both routine questions and bug reports. Core Exchange moves this to a self-serve flow: file tickets from the Dashboard under Get Help by selecting Create case and choosing Open finance issues, which route to a dedicated Data Partner Support Engineering (DPSE) team. Solutions Engineering may still re-engage for major expansions or architectural changes.

What to update: update any internal runbooks or on-call documentation that name your Solutions Engineer as the support contact to reference the Dashboard ticketing flow instead.

Core Exchange introduces a logging identifier with no Plaid Exchange equivalent: the X-Request-ID header Plaid sends with requests to your resource server, correlated with the Dashboard's Integration Health view. Keep logging the OAuth state parameter and your user identifier as you did in Plaid Exchange (as oauth_state_id and FI_UNIQUE_ID), and add X-Request-ID alongside them.

Before any cohort work begins, sign up for a Data Partner Dashboard account and complete your institution profile: business and compliance details (legal entity name, address, tax ID, Legal Entity Identifier, industry, and licensing or registration such as FDIC, NCUA, or SIPC) and technical contacts. Plaid Exchange never required this; provisioning happened directly with your Plaid contact. See Implementation checklist for the full list.

If your institution already has live PX traffic, Plaid coordinates a phased migration rather than a single cutover, similar to a fresh Core Exchange launch:

1. Pilot cohort: new connections move to Core Exchange in production for a small cohort while Plaid Exchange keeps serving existing traffic.
2. Remaining cohorts: expand to the rest of your users, cohort by cohort.
3. Existing user migration: once integration health is validated, Plaid migrates existing Items from Plaid Exchange over to the Core Exchange OAuth + API connection. This phase runs over approximately 90 days (Plaid Exchange's own migration guidance cites roughly 120 days for the equivalent phase), and in select cases backend token exchange can avoid requiring users to reauthenticate.

Actual timelines depend on institutional health validation and issue resolution; confirm them with your Plaid contact.

• Update your IP allowlist: keep every IP already allowlisted for Plaid Exchange, and add Core Exchange's ranges, 162.120.88.0/22 and 2602:F74B::/40. See IP allowlisting.
• Run your integration through the Validator before requesting production access on Core Exchange.
• Decommission the Plaid Exchange OTP/KBA/TOTP endpoints only once Plaid has moved all of your institution's traffic, including any pilot cohorts, over to Core Exchange.
• Point any internal documentation, client libraries, or generated code at the Core Exchange API reference instead of the Plaid Exchange data definitions.

These aren't specific to migrating from Plaid Exchange, but cover the rest of the Core Exchange onboarding journey:

• Onboarding guide: the end-to-end integration journey, from setup through post-launch.
• Dashboard overview: configuring your institution profile, environments, and branding in the Data Partner Dashboard.
• Implementation checklist: every step required during build, testing, and go-live.
• Testing & validation: using the Validator to test authentication and data endpoints.
• Production access: requesting production access and running stealth testing.
• Post-launch operations: support, monitoring, target metrics, and logging identifiers.
• Troubleshooting: debugging common OAuth and data-flow issues.
• Security best practices: IP allowlisting, mTLS, and PKCE.