Plaid logo
Core Exchange
ALL DOCS

Consent management

Open nav
Core Exchange
Plaid.comGet Started

Consent management

Manage user consent with Permissions Manager

Authorization records and consent management

Data Providers may want access to authorization records for every connection. This includes when users granted consent, the accounts and data types they authorized, and the apps they connected. Plaid's Permissions Manager provides this visibility while keeping the ecosystem in sync.

What are authorization records?

An authorization record captures the full context of a user's consent:

  • Application details - Which app has access (name, ID, logo)
  • Accounts shared - Specific accounts the user authorized
  • Data types - What data the app can access (transactions, balances, identity, etc.)
  • Consent timestamp - When the user granted authorization
  • Connection status - Active, revoked, or expired

Accessing authorization records

MethodBest forSetup timeFeatures
Permissions Manager APIsAutomated systems, high volume2-4 weeksProgrammatic access, bulk queries, webhook integration
Data Partner DashboardManual review, low volumeSame dayNo-code interface, search by user, and visual browsing
BothComplete visibility2-4 weeksBest of both worlds

Choose based on your volume and automation needs.

Option 1: Permissions Manager APIs

Integrate with Plaid's Permissions Manager APIs to programmatically access authorization records. Query by user identifier to see all active connections for that user. These APIs align with the FDX Consent API specification.

Key endpoints:

  • GET /consents - Retrieve all consent grants for a specific user (filter by customerId and status)
  • GET /consents/{consentId} - View full details for a single consent grant
  • PUT /consents/{consentId}/revocation - Revoke a specific consent grant (see Revocation below)

Option 2: Data Partner Dashboard (no code required)

Use Plaid's Data Partner Dashboard to search authorization records by user identifier. Browse connections, view details, and manage access. No API integration needed.

How to access: Reach out to your Plaid contact to enable dashboard access.

Revocation and ecosystem sync

If you offer users the ability to revoke access to connected apps (for example, via a consumer-facing consent portal), you must keep the ecosystem in sync. When a user revokes access on your side, Plaid and the downstream app need to know immediately.

How it works:

  1. User revokes access on your domain - User visits your consent portal and disconnects an app
  2. Call PUT /consents/{consentId}/revocation - Your system calls Plaid's revocation endpoint
  3. Plaid notifies the app - Plaid sends a webhook to the disconnected app
  4. Plaid severs the connection - Plaid will prohibit the app from accessing data
  5. App stops requesting data - The app knows the user revoked access and stops making requests

This ensures revocation is instant and synchronized across all parties. Without this sync, the app won't know the user revoked access. The app continues requesting data, Plaid serves cached data when available, and the Item appears healthy to the user. Eventually, when Plaid attempts to fetch fresh data (during a scheduled sync or real-time request), the request fails, and the Item enters an error state. Only then does the app learn about the disconnection. This creates a confusing experience in which the app shows a connection as active and healthy even after the user has revoked it.

Webhooks for real-time updates

Plaid can also send webhooks to you when authorization events occur, keeping your systems in sync with user actions across the ecosystem:

permission_granted (optional)

Notifies you every time a user connects a new app via Plaid. Useful if you want real-time visibility into new connections, especially for connections created via the returning user experience (where the user doesn't go through your OAuth flow).

When it fires: After a user successfully authorizes a new app.

Payload includes: User identifier, app details, authorized accounts, shared data types, and timestamp.

What to do: Store the authorization record in your system. If you offer a consent portal, display this new connection so users can view and manage it.

permission_revoked (required for consent portals)

Notifies you when a user revokes access to an app, either through the third-party app itself or via my.plaid.com (Plaid Portal). If you offer a consent management portal, you need this webhook to keep your records in sync.

When it fires: After a user or app revokes authorization.

Payload includes: User identifier, app details, and revocation timestamp.

What to do: Update your authorization records to mark the connection as revoked. If you offer a consent portal, update the display to show that the connection is no longer active. This keeps your portal in sync with actions users take outside your domain.

Plaid Portal (my.plaid.com)

Users can view and manage all their Plaid connections at my.plaid.com. This consumer-facing portal shows:

  • Which apps have access to their data
  • Which accounts are shared with each app
  • When users created connections
  • Options to revoke access

You can also use Plaid's Permissions Manager APIs to enable the same visibility through your own consumer-facing consent portal.

Best practices

  • Integrate with Permissions Manager APIs or the dashboard to access authorization records
  • Implement the permission_revoked webhook if you offer a consent portal
  • Use PUT /consents/{consentId}/revocation to keep the ecosystem in sync during revocations
  • Set refresh token expiration to 13+ months (allows buffer for reauthorization)
  • Direct users to my.plaid.com for self-service connection management