Netlify Functions Can Now See Who Is Visiting a Protected Site

Netlify Functions and Edge Functions can now tell who is making a request on a protected site. The signed-in Netlify user appears as context.user, carrying an ID, an email address and an access expiry, Netlify said in an Oct. 7, 2026 changelog entry.

What changed

It applies to private projects and sites guarded by Netlify team login. Netlify’s example is a /whoami function that returns context.user.id, email and expiresAt as JSON, and answers 401 when context.user is unset.

Before this, Netlify decided who could visit a protected site, but the code behind it could not see who had gotten through. Netlify said developers who needed that had to add a second login of their own on top.

Why it holds up

Netlify verifies the visitor at the edge and hands the identity to the function. context.user comes from Netlify, not from the request. A visitor cannot impersonate a colleague by sending headers of their own, the company said.

Netlify’s suggested uses: internal dashboards that show each person their own data, audit logs of who made a change, approval workflows that record who approved what, and per-person settings or feature access inside an internal app.

Key Takeaways

• context.user works in both Netlify Functions and Edge Functions.
• It is populated on private projects and sites behind team login, and exposes ID, email and access expiry.
• Netlify sets it at the edge. Request headers cannot spoof it.

The take

This is a small API with a practical payoff. Internal tools built on Netlify no longer need their own auth layer just to learn a name. The 401-on-missing pattern in Netlify’s example is the right default for any function that assumes a signed-in user. It follows the SSO sign-in change Netlify made in August. Team login now works as an identity source for code, not only a gate in front of it.