Post-launch operations

After launch, the Data Partner Dashboard becomes the primary hub for monitoring integration health.

You will have visibility into API errors, OAuth conversion trends, latency, response behavior, and data extraction success rates.

The first few weeks post-launch are critical. Real-world usage may surface issues not seen during testing, so teams should be prepared to respond quickly.

Your OAuth server should meet these performance targets to ensure a smooth user experience and reliable API access. Plaid also monitors integration health to help identify and resolve performance issues.

Latency: Slow responses increase user drop-off rates. Sub-3.5 second responses keep users engaged.

Throughput: Connection volumes can spike during peak times. Insufficient throughput creates bottlenecks that cascade to downstream apps.

Uptime: Downtime blocks new connections and refresh flows. In payment use cases, even 30 minutes of downtime can lead to ACH failures and customer complaints.

Conversion rate: Low conversion indicates UX problems (confusing screens, slow responses) or technical issues (timeout errors, redirect failures).

Track these metrics continuously:

• P50, P95, P99 latency for each OAuth endpoint
• HTTP status code distribution (200, 400, 401, 500, 503)
• OAuth flow completion rate (authorization → token exchange success)
• Token refresh success rate
• JWKS endpoint availability and latency

Set up alerts for:

• Latency P95 exceeding 3.5 seconds
• Error rate exceeding 2%
• Uptime dropping below 99.5%
• Throughput capacity issues

Plan for growth:

• Volume projections for traffic increases over time
• Peak load during traffic spikes
• Refresh traffic from background calls (can generate significant additional load)
• JWKS caching (Plaid caches for 60 seconds, reducing load on that endpoint)

Test your infrastructure under load before going live. Use load-testing tools to simulate hundreds of concurrent OAuth flows and verify that performance holds up.

Log the following identifiers to aid in troubleshooting issues with Plaid:

• OAuth state parameter: Plaid sends a unique string in the state parameter when redirecting the user's browser to the authorization_endpoint. Useful in debugging OAuth flow errors.
• X-Request-ID header: Plaid sends this header in requests to your resource server. It can be correlated with error logs in the Dashboard's Integration Health view.
• User identifier: Useful in debugging the request flow for a given user. Depending on how you set up your API, this value can be from the following sources:
  • The value of sub from your OIDC token
  • The value of sub from your OIDC userinfo_endpoint
  • Value of customerId from the /customers/current endpoint

Once your integration is live, Data Partner Support Engineering (DPSE) is your primary point of contact.

Submit support tickets from the Dashboard by navigating to Get Help → Open New Case → Open Finance Issue. Tickets are routed directly to the DPSE team for triage. You can also reach support directly at https://dashboard.plaid.com/support/new.

When submitting a support request, include:

• Institution name and ID if available
• Environment configuration
• Timestamp and approximate time range
• Relevant request IDs
• Description of the issue and expected behavior
• Whether the issue occurred during testing or production traffic

Solutions Engineering may re-engage for major expansions or architectural changes.

• Notify Plaid of any planned outages or downtime at least 24 hours in advance by emailing plaid_bank_traffic@plaid.com.
• Ensure that you are logging User Identifier and OAuth State to help troubleshoot your integration going forward.
• When reaching out about a user issue, providing a User Identifier enables faster troubleshooting of specific user connection issues.

After going live, consider ways to strengthen your integration:

• Increase user throughput with App2App functionality
• Enable Permissions Manager and App Directory for transparency into user consent and connected applications