Act as one of your users to reproduce a problem or fix it with them. A reason every time, a short time limit, permissions support never gets, an audit trail, and the user is told.
Reproduce a bug the way the user sees it, instead of asking for screenshots.
Every session has a reason, an actor and an end, on the user's timeline in the dashboard.
No home-made impersonation endpoint that skips your checks: the SDK's guards know it is support.
Free text, a ticket or a support conversation, in the audit log, the tokens, the webhooks and the user's notice.
30 minutes by default, and never more than the project allows. No refresh extends it.
Permissions support access never uses, whatever the user's roles, and the actions your code marks destructive.
An email, an entry on their account page, and with consent mode the user approves each access first.
Off until the project turns it on. Members need the permission and a recent second factor.
Who, what, when and why, on the user's timeline. Your API reports its own changes there too.
When a user signs in, their token carries who they are, their organisation and role, their plan and payment status, and what your flags target. Your API checks it in one guard, offline, and your UI reads the same answers.
sub · amrorg.rolebilling.planflag()The browser client exchanges the one-time launch code on page load; no token is ever in a URL. On your API the token verifies like the user's own, and the guards deny what the ceiling and your destructive list name.
// access.ts: what support access never does, whatever the user's own roles
export const access = defineAccess({
roles: { admin: ['projects:*', 'invoices:*'] },
destructive: ['projects:delete', 'invoices:refund'],
});
// In the browser: show who is acting, and let the user end it
await auth.ready();
const imp = auth.impersonation(); // null for the user's own sign-in
if (imp) banner.show(imp.actor.email, imp.reason, imp.expiresAt, () => auth.endImpersonation());
// In your API (the server SDK): the guards deny the ceiling; changes go to the user's timeline
app.use('/api/*', api.middleware(), api.impersonationAudit());Prices in euros, excluding VAT. Test environments include every feature on every plan.
Included
Included
Included
Included
Included
Included
No. The user is emailed by default and sees each access on their account page; with consent mode they approve it before it starts.
Yes. An API that must never accept it turns support access off in its createAuth options, and those tokens are rejected.
The project owner and the members they give support access, after a recent sign-in with a second factor. Server keys never can.
Turn on support access in the test environment, add a start URL to your app and try it on a test user.
Hosted sign-in, organisations, roles and enterprise SSO.
Teams, invites, custom roles and org switching, with the role in the token.
Plans, checkout, invoices and EU VAT, with the plan in the token.
Targeting and rollouts, evaluated offline from the token.
Talk to your users beside their plan, roles and flags.
Chat with visitors, and keep them when they sign up.