Supporting non-Plaid traffic

Run Plaid’s user-scoped access token architecture alongside per-app tokens for other aggregators

Core Exchange asks you to issue Plaid a single user-scoped access token per user. Other aggregators and third parties may ask for the opposite: a separate token per downstream app. Both patterns can be used against the same FDX-compatible API, so you don't need to choose one client model for every caller.

This guide covers how to easily support both patterns.

Why the two patterns differ

Plaid's user-scoped access token reduces the number of tokens your authorization server issues and the number of requests your resource server serves: one token covers every app a user connects through Plaid, instead of one token per app. See Planning your integration for the traffic and consent-management benefits.

Most other aggregators haven't adopted that model. They register each downstream app as its own OAuth client, the model RFC 7591 (Dynamic Client Registration) describes, and so end up with a token per app.

Supporting both patterns on one API

This table is a high-level comparison, not a spec. Check the relevant aggregator's own documentation for their exact requirements.

	For Plaid	For other aggregators
Client registration	Issue Plaid one client ID and secret, used on behalf of every app connected through Plaid. App Directory gives you app-level visibility in place of registration.	Issue a client ID and secret per downstream app, registered through your Dynamic Client Registration endpoint.
OAuth user experience	Plaid Link handles consent, data-type scoping, and account selection for Plaid traffic, so these screens should be suppressed when the caller is Plaid. Suppress them by branching on Plaid's `client_id`, which is sent on every `/authorize` request.	Show whatever consent, scoping, and account-selection screens you'd otherwise show.
Authorization record creation	Plaid is the source of truth for who's authorized. Subscribe to the `AUTHORIZATION_GRANTED` webhook to be notified when a user connects a new app, then record that connection in your own consent records.	After the end user completes your OAuth flow, store the authorization record directly in your own consent records.
Ongoing authorization management	Use Plaid's Consent API to see which apps a user has connected through Plaid, and to process revocations.	Query your own consent records for a user's connected apps, and revoke the refresh token for that client ID/user directly.

Identifying the caller

In order to support both models, your integration must be able to tell Plaid's traffic apart from everyone else's at the point a request comes in. The most reliable signal is client_id: register Plaid under a single, known client ID, and branch your OAuth and consent-record logic on whether the request came from it. If every other caller registers through Dynamic Client Registration, Plaid is your only manually registered client, so you can already tell them apart.

Dynamic Client Registration

Even though Plaid does not require Dynamic Client Registration, if you serve other aggregators or third parties that register each downstream app as its own client, you will still need to implement Dynamic Client Registration to support those clients.