Reuse Lovable workspace identity in your app

Let apps you build for your team recognize the signed-in Lovable user automatically, without a separate login flow.

When you build an internal tool in Lovable, the people who use it are usually your own teammates, and they already sign in to Lovable every day. Workspace identity reuse lets your app treat that existing sign-in as its login: the app knows who is visiting (their name, email, and Lovable user ID) without showing a login page or asking anyone to create another account.

It works no matter how someone signs in to Lovable: workspace SSO, Google, or email. The feature is available on Business and Enterprise plans.

Workspace identity reuse is rolling out gradually, so it may not be available for every workspace yet.

Which identity feature do you need?

Lovable has three features that sound alike but do different jobs. If you are not sure this page is the right one, start here:

Feature	What it controls	Who it affects
Lovable workspace identity reuse (this page)	Whether apps you build can recognize the workspace member who is already signed in to Lovable	Your workspace members using apps your team builds
Workspace SSO	How your team signs in to Lovable itself, through your identity provider	Workspace members signing in to Lovable
SAML SSO for apps	How external end users of a published app on the built-in backend (Cloud) sign in with their own company credentials	Your app’s outside users

A simple way to keep them apart: the Identity settings decide how people get into Lovable. Workspace identity reuse decides what your apps can know about people who are already in. Neither requires the other: identity reuse works even if your team signs in to Lovable with Google or email, and you do not need workspace SSO configured.

Why use workspace identity reuse

Identity reuse fits when everyone who uses your app is already in your Lovable workspace. Without it, you would need to build and maintain a second login system, and your teammates would sign in twice: once to Lovable, and once to your app. With it, the app already knows the current user.

Use case	Example	Why identity reuse fits
Internal admin tool	A billing review dashboard for your operations team	Team members already sign in to Lovable, so the app can identify them without another login page
Employee portal	A workspace-only PTO request app	The app can show each user their own requests and route approvals by Lovable identity
Workspace reporting	A dashboard that filters activity by the signed-in team member	The app can personalize views based on the current Lovable user
Per-user data apps	A notes or tasks app where each member sees only their own rows	Your app can use the Lovable identity to personalize data access

For customer-facing apps, public signup flows, or apps where users do not have Lovable accounts, use traditional app authentication instead.

How workspace identity reuse works

When a signed-in user opens the preview or the published app, Lovable creates a short-lived identity token for that project and user, and passes it along with the app request. Helper code that Lovable generates in your app verifies the token and exposes the current user to the rest of your app code.

Lovable strips any identity information that visitors send themselves before attaching its own signed token, so a visitor cannot impersonate someone else by faking an identity.

Who gets recognized

The app recognizes people who are signed in to Lovable and have access to the project. Everyone else, including anonymous visitors and people who can only view the published app, gets no identity: the helper returns no user, and your app decides what they see, such as a guest view or an access-denied message.

What your app can read

• The signed-in user’s Lovable user ID.
• The user’s display name, when available.
• The user’s email address, when available.

Do you need the built-in backend?

No. Workspace identity reuse works in any eligible project, with or without the built-in backend (Cloud). Reading the current user’s name or email needs no backend at all.

You need the backend when the app should store per-user data: for example, a task tracker where each member sees only their own tasks. Lovable passes the signed-in identity to your Cloud backend so the database can enforce per-user access.

Do not mix workspace identity reuse with a traditional app sign-in flow unless you intentionally design a hybrid app. For most apps, choose one auth model: Lovable identity for workspace-member apps, or traditional app authentication for public and customer-facing apps.

Prerequisites

• A Business or Enterprise workspace.
• A newer Lovable project that uses TanStack Start. Some older projects are not eligible.
• Lovable workspace identity allowed in your workspace’s App login methods policy. It is allowed by default.

If you are not sure which stack your project uses, ask Lovable:

What stack is this project on?

Set up workspace identity reuse

Setup happens at two levels, usually by two different people:

• Workspace level: a workspace admin or owner decides whether apps in the workspace may use workspace identity at all. This is a one-time policy decision, and it is allowed by default.
• App level: the project editor asks Lovable to use the signed-in user in a specific app. Nothing uses the identity until you ask for it. There is no per-project setting to turn on or off.

Workspace setup (admins and owners)

Workspace identity is allowed by default, so in most workspaces there is nothing to do here. To confirm or change the policy:

1. Open App login methods

   Open Privacy & security (Settings → Security → Privacy & security), then select Configure under App login methods.

2. Check Lovable workspace identity

   The Lovable workspace identity entry should show Allowed.

   Blocking a method locks it for every project in the workspace. The change takes effect immediately. This policy only affects apps your team builds. It does not change how workspace members sign in to Lovable.

App setup (project editors)

1. Ask Lovable to use the signed-in user

   In your project, describe the identity behavior you want. Lovable makes the app changes needed to use the signed-in identity. For example:

   Use Lovable workspace identity to show the signed-in user's name and email in the header. If no user is available, show a signed-out state.
   

   Build an internal task tracker where each signed-in workspace member only sees tasks assigned to them. Use Lovable Cloud for per-user data access.
   

   Be explicit about which login model you want. If you only say “add login”, Lovable may build a traditional sign-up flow with email or Google instead. Say that you want to use the signed-in Lovable user, like the prompts above do.

2. Test it in preview

   Open the preview while signed in to Lovable. Wherever your app displays the current user, you should see your own details. With the header prompt above, the header greets you with your own name and email instead of showing a login button.

   To test what other people see, ask a teammate with access to the project to open the app. They see their own name, not yours. To test the signed-out experience, open the published app in a private browser window. Without a Lovable session, the app shows the guest or signed-out state you asked for.

Identity works in preview. You do not need to publish the app to test it.

Turning workspace identity reuse off

• For the whole workspace: a workspace admin or owner blocks Lovable workspace identity in Privacy & security (Settings → Security → Privacy & security → App login methods). This applies to every project immediately and cannot be changed from a project.
• For a single app: ask Lovable to remove it, for example: Stop using workspace identity in this app and show a public landing page instead.

When to use traditional app authentication instead

Use traditional app authentication when:

• Your app is customer-facing or public.
• Users should create accounts inside the app.
• Users may not have Lovable accounts.
• You need app-specific login methods such as email/password, magic links, Google sign-in, or SAML SSO for Cloud app users.
• You need app-owned user accounts, signup flows, or user management that is separate from Lovable workspace membership.

In those cases, ask Lovable to add the sign-in method you need, such as Google authentication, email sign-in, or SAML SSO for Cloud app users.

FAQ

Is workspace identity reuse the same as workspace SSO?

No. Workspace SSO controls how your team signs in to Lovable. Workspace identity reuse lets an app you build read the Lovable user who is already signed in. See Which identity feature do you need?

Do I need workspace SSO configured to use this?

No. The identity is the signed-in Lovable account, regardless of whether the user signed in with workspace SSO, Google, email, or another supported method.

Do I need the built-in backend?

No. Reading the current user works in any eligible project. You only need the built-in backend (Cloud) when the app stores per-user data.

Can people without access to my project use this identity?

No. Only signed-in Lovable users with access to the project get an identity. Everyone else is treated as anonymous, including public visitors and workspace members without access to the project. Use traditional app authentication if public or customer users need accounts.

Does this consume extra credits?

No, workspace identity reuse has no separate cost. Any built-in database, storage, hosting, or AI usage in the app follows normal credits and usage rules.

Troubleshooting

I do not see Lovable workspace identity in App login methods

The App login methods dialog shows the entry when the feature is available for your workspace. Confirm your workspace is on a Business or Enterprise plan. The feature is rolling out gradually, so it may not be available for your workspace yet.

My project cannot use workspace identity

Workspace identity reuse needs all three of the following. Check each one:

• Your project runs on TanStack Start. Some older projects use an earlier stack and are not eligible. If you are not sure, ask Lovable: What stack is this project on?
• Lovable workspace identity is allowed in Privacy & security (Settings → Security → Privacy & security → App login methods).
• Your workspace is on a Business or Enterprise plan.

The app shows no signed-in user

Open the preview while signed in to Lovable, and make sure your account has access to the project itself, not only to the published app. If your app supports anonymous visits, make sure it handles the no-user state clearly.

Lovable added a login page instead of using my identity

Ask Lovable to use the signed-in Lovable user as the app identity. For example:

Use Lovable workspace identity for this internal app. Do not add a separate email or Google login flow.

My Cloud data does not recognize the user

Ask Lovable to connect the signed-in identity to your Cloud data access. Avoid mixing this setup with a separate app sign-in flow unless you are intentionally building a hybrid auth model.