How to Integrate UserTesting with V0

Begin by prompting V0 to generate the front-end components for your UX research dashboard. The key UI elements are: a studies list or grid showing high-level study metadata, a sessions view showing individual participant sessions within a study, and optionally a metrics summary section with charts. V0 excels at data-dense dashboard layouts with Tailwind CSS. When prompting, be explicit about the data structure you expect from the API — tell V0 the field names like study_name, participant_count, completion_rate, status, and start_date so it generates components that reference these fields correctly in the JSX. This reduces the amount of code editing you need to do after generation. For displaying session video links, V0 can generate a list component where each session item has a thumbnail area, participant information, key metrics, and an external link button that opens the session recording URL in a new tab. UserTesting's API returns direct links to session recordings for users with appropriate permissions — these open in the UserTesting player. Ask V0 to include loading skeleton states for the dashboard components. Because the API route needs to fetch data from UserTesting on each request, there will be a noticeable loading delay. Skeleton screens (animated gray placeholder rectangles that mimic the final layout) provide a much better user experience than a spinning loader or blank white screen. V0 can generate these using Tailwind's animate-pulse class on placeholder divs. For charts showing metrics like rating distributions or task completion rates over time, prompt V0 to use Recharts — it is already in the V0 default stack and generates clean, responsive bar and line charts with minimal configuration.

UserTesting's API uses OAuth2 client credentials flow for authentication. Unlike a simple API key, you need to exchange your client ID and secret for a bearer token, which then expires and needs to be refreshed. Create a helper module at lib/usertesting-auth.ts that handles token acquisition so your API routes can call it without duplicating the authentication logic. The token endpoint for UserTesting is POST https://app.usertesting.com/oauth/token with a Basic Authorization header (base64-encoded clientId:clientSecret) and a body of grant_type=client_credentials. The response includes an access_token string and expires_in value (typically 3600 seconds). For a production-grade implementation, cache the token in memory or in Vercel's KV store and reuse it until it is close to expiration. For a simpler initial implementation, request a new token on every API route invocation — this adds a small latency overhead but eliminates token management complexity. Given that UserTesting API calls are for a dashboard (not a high-throughput path), the simpler approach works fine in most cases. Store your client credentials as USERTESTING_CLIENT_ID and USERTESTING_CLIENT_SECRET in Vercel environment variables. Neither value should have the NEXT_PUBLIC_ prefix — both are server-only secrets. The client secret especially must never appear in browser-side code, as it would allow anyone who sees it to call the UserTesting API on your behalf. Also note a V0-specific limitation here: V0 generates client-side React components that cannot directly call the UserTesting API because the API requires server-side credentials. If you prompt V0 to 'add UserTesting integration,' it may attempt to call the API directly from a client component using environment variables. Always redirect this to the API route pattern described in this guide.

1// lib/usertesting-auth.ts
2export async function getAccessToken(): Promise<string> {
3  const clientId = process.env.USERTESTING_CLIENT_ID;
4  const clientSecret = process.env.USERTESTING_CLIENT_SECRET;
5
6  if (!clientId || !clientSecret) {
7    throw new Error('UserTesting credentials not configured');
8  }
9
10  const credentials = Buffer.from(`${clientId}:${clientSecret}`).toString('base64');
11
12  const response = await fetch('https://app.usertesting.com/oauth/token', {
13    method: 'POST',
14    headers: {
15      Authorization: `Basic ${credentials}`,
16      'Content-Type': 'application/x-www-form-urlencoded',
17    },
18    body: 'grant_type=client_credentials',
19  });
20
21  if (!response.ok) {
22    throw new Error(`UserTesting auth failed: ${response.status}`);
23  }
24
25  const data = await response.json();
26  return data.access_token;
27}

Create the Next.js API routes that your dashboard components call to fetch UserTesting data. You need at minimum two routes: one for listing studies and one for listing sessions within a study (or across all studies). Create app/api/usertesting/studies/route.ts for fetching the list of studies. This calls GET https://api.usertesting.com/v1/studies using the bearer token from your auth helper. The UserTesting API returns paginated results — handle the page and per_page query parameters by forwarding them from your route's search params to the UserTesting API call. Create app/api/usertesting/sessions/route.ts for fetching session data. This can fetch all sessions across studies, or accept a study_id query parameter to scope results to a specific study. Sessions include participant data, task results, ratings, video URLs (for plans with recording access), and timestamps. For the individual study detail route, create app/api/usertesting/studies/[id]/route.ts using dynamic route segments. Extract the study ID from the params object and fetch from https://api.usertesting.com/v1/studies/{id} to get detailed metrics for a single study. In all routes, use the getAccessToken() helper from your lib module, add the returned token as an Authorization: Bearer {token} header on every UserTesting API call, and handle potential 401 errors (token expired or invalid credentials) with a clear error response. Also handle 403 errors which indicate your plan does not have access to the requested resource — this is common if you try to access session recordings on a plan that does not include them.

1import { NextRequest, NextResponse } from 'next/server';
2import { getAccessToken } from '@/lib/usertesting-auth';
3
4export async function GET(request: NextRequest) {
5  try {
6    const { searchParams } = new URL(request.url);
7    const page = searchParams.get('page') || '1';
8    const perPage = searchParams.get('per_page') || '20';
9
10    const token = await getAccessToken();
11
12    const response = await fetch(
13      `https://api.usertesting.com/v1/studies?page=${page}&per_page=${perPage}`,
14      {
15        headers: {
16          Authorization: `Bearer ${token}`,
17          Accept: 'application/json',
18        },
19      }
20    );
21
22    if (response.status === 401) {
23      return NextResponse.json(
24        { error: 'UserTesting authentication failed. Check your API credentials.' },
25        { status: 401 }
26      );
27    }
28
29    if (response.status === 403) {
30      return NextResponse.json(
31        { error: 'Your UserTesting plan does not have API access to this resource.' },
32        { status: 403 }
33      );
34    }
35
36    if (!response.ok) {
37      return NextResponse.json(
38        { error: `UserTesting API error: ${response.status}` },
39        { status: response.status }
40      );
41    }
42
43    const data = await response.json();
44    return NextResponse.json({
45      studies: data.studies || data,
46      total: data.total,
47      page: parseInt(page),
48    });
49  } catch (error) {
50    console.error('UserTesting studies fetch error:', error);
51    return NextResponse.json(
52      { error: 'Failed to fetch studies' },
53      { status: 500 }
54    );
55  }
56}

Add your UserTesting API credentials to Vercel's environment variables and test the complete data flow from the dashboard to the API routes to UserTesting's API. Go to Vercel Dashboard → your project → Settings → Environment Variables. Add two variables: USERTESTING_CLIENT_ID with your UserTesting OAuth client ID, and USERTESTING_CLIENT_SECRET with your client secret. Both should be available on the Production, Preview, and Development environments. Neither should have the NEXT_PUBLIC_ prefix. You can find your client ID and secret in UserTesting Dashboard → Settings → Developer → API Credentials (the exact path may vary by UserTesting plan and version). If you do not see an API credentials section in your UserTesting settings, your plan may not include API access — contact UserTesting support to confirm your plan's API entitlements. For local development, create a .env.local file with the same two variables. Then run npm run dev and navigate to your dashboard. Check the browser's network tab to confirm the fetch calls to /api/usertesting/studies are returning 200 responses with study data. If you receive a 401 on the first call, it usually means the credentials are wrong or the OAuth token endpoint URL has changed — check UserTesting's API documentation for the current token endpoint. If you receive a 403, your plan likely does not include API access. A 404 response often means the API endpoint path has changed — UserTesting's API versioning (v1, v2) can shift with platform updates, so verify the current endpoint paths in their developer documentation. After confirming local testing works, push to GitHub to trigger a Vercel deployment and test the production environment as well.

1# .env.local (local development only — never commit)
2USERTESTING_CLIENT_ID=your_client_id_here
3USERTESTING_CLIENT_SECRET=your_client_secret_here