Microsoft Graph API in SPFx: Calling the Graph Without a Backend

Using MSGraphClientV3 in Your Web Part

With permissions approved, using the Graph API in your web part is straightforward. The MSGraphClientV3 wraps the official @microsoft/microsoft-graph-client SDK with automatic token injection. You never write a single line of token acquisition code.

import { MSGraphClientV3 } from '@microsoft/sp-http';
import { User } from '@microsoft/microsoft-graph-types';

private async fetchUserAndCalendar(): Promise<void> {
  const client: MSGraphClientV3 = await this.context.msGraphClientFactory
    .getClient('3');

  // Fetch current user profile
  const me: User = await client
    .api('/me')
    .select('id,displayName,mail,jobTitle,department')
    .get();

  // Fetch today's calendar events
  const now = new Date().toISOString();
  const endOfDay = new Date();
  endOfDay.setHours(23, 59, 59);

  const events = await client
    .api('/me/calendarView')
    .query({
      startDateTime: now,
      endDateTime: endOfDay.toISOString(),
    })
    .select('subject,start,end,location')
    .orderby('start/dateTime')
    .top(5)
    .get();

  // Update component state...
}

Calling Users, Calendar, and Mail APIs

The three most commonly used Graph endpoints in SPFx web parts are the user profile, calendar, and mail APIs. Each serves different intranet use cases and requires different permission scopes.

• User profile (/me, /users/{id}): Requires User.Read for the current user. Requires User.ReadBasic.All to look up other users in the directory. Used for employee directories, people pickers, and profile cards.
• Calendar (/me/events, /me/calendarView): Requires Calendars.Read. calendarView is preferred over events as it expands recurring events into individual instances within a date range — critical for accurate "Today's meetings" widgets.
• Mail (/me/messages, /me/mailFolders): Requires Mail.Read. Useful for unread mail count badges and preview widgets. Treat email access carefully — it's sensitive data and should be used only when it provides clear user value.

Handling Delegated vs. Application Permissions

SPFx web parts always use delegated permissions — they call the Graph as the logged-in user, with the user's own access rights. This is the correct security posture for client-side code: a user can only see data they're already authorised to see. Application permissions (which let a service access data for any user) are not available to SPFx web parts and require a backend service.

This distinction has practical implications. A web part with User.ReadBasic.All (delegated) can read profile information for all users in the directory — but only if the logged-in user has permission to view that information, which is true for most corporate directories by default. However, if you need to read another user's calendar or email, you typically cannot do this with delegated permissions unless the target user has explicitly shared their calendar. Don't try to use SPFx for admin-level data access scenarios — build a proper Azure Function or Logic App with managed identity for those cases.

Caching Graph Responses for Performance

Graph API calls add latency to your web part's render time. User profile data, org chart information, and configuration data don't change frequently — caching them significantly improves perceived performance without sacrificing data freshness.

async function getCachedGraphData<T>(
  cacheKey: string,
  fetcher: () => Promise<T>,
  ttlMinutes: number = 15
): Promise<T> {
  const cached = sessionStorage.getItem(cacheKey);
  if (cached) {
    const { data, expiry } = JSON.parse(cached);
    if (Date.now() < expiry) return data as T;
  }
  const data = await fetcher();
  sessionStorage.setItem(cacheKey, JSON.stringify({
    data,
    expiry: Date.now() + ttlMinutes * 60_000
  }));
  return data;
}