Standard connector vs. App user connector
Both are app connectors and both route through the gateway. The difference is whose account the app uses.When to reach for which. If every visitor should act as the same account (for example, notifications from one company Slack), use a standard connector. If every visitor should act as themselves (for example, viewing their own calendar events or their own CRM records), use an app user connector.
How it works
An app user connector has two parts: a client you configure once as the builder, and the individual sign-ins your end users complete when they use the app.1. You configure the client once
As the builder, you set up a client for the connector once for your workspace. Depending on the provider, this means registering an OAuth application with that provider (for example a Salesforce External Client App, a Databricks OAuth app, or a Snowflake OAuth security integration) and adding its details to the client. This configuration is stored securely and reused for every user who connects, and it never contains any individual user’s data.2. Each user connects their own account
The first time one of your users needs the integration, your published app sends them through the provider’s standard OAuth consent screen. The user signs in with their own account and approves the requested permissions (scopes). Lovable exchanges the authorization for tokens and stores them encrypted in the connector gateway, linked to that individual user.3. Your app calls the provider through the gateway
When your app makes a request, it goes to the connector gateway rather than directly to the provider. The gateway:- Resolves the right user’s account for the request and confirms it belongs to that user, in this workspace and project.
- Refreshes expiring tokens automatically in the background, so users don’t have to re-authorize on every session. If a refresh token is no longer valid, the gateway returns a clear “reconnect” signal so your app can prompt the user to authorize again.
- Injects the credentials and forwards the request to the provider. The third-party tokens never touch your app code.
- Keeps users isolated: one user’s access can never be used to act as another user.
Because tokens live in the gateway and not in your project, they are not visible in project settings, to workspace admins, or to the Lovable Agent. See Integration security for how credentials are stored, rotated, and deleted.
Available app user connectors
The following providers are available as app user connectors. For Google and Microsoft, each product is its own connector but shares the same sign-in. The OAuth app setup column links to each provider’s own documentation for creating the OAuth application you configure the client with.Set up an app user connector
Setup happens in two steps: configure the client in the workspace, then wire the connect experience into your app.Register and approve your OAuth app with the provider
Before you can configure the client, you (or your organization’s admin) register an OAuth application on the provider’s side and get it approved for use. This process differs from provider to provider, and each has its own requirements. For example, you might create a Salesforce External Client App, a Databricks OAuth app, a Snowflake security integration, a Google OAuth consent screen, or a Microsoft app registration. Approval can also involve extra steps such as admin consent for a tenant, app verification for sensitive scopes, or installation approval in a workspace. Because the exact steps and any review process are owned by the provider, the authoritative instructions live in that provider’s own documentation. The OAuth app setup links in Available app user connectors point you to each provider’s guide.When you register the OAuth app, add Lovable’s connector gateway callback URL to the app’s allowed redirect URIs so authorization can complete:Lovable also shows this value in the connector setup screen so you can copy it directly.
Configure the client
- Open Connectors in your workspace and select the provider you want (for example Salesforce or Gmail).
- Add a client and provide the provider’s OAuth application details for App User access (for example client ID and secret, and any account or workspace URL the provider requires).
- Link the client to the project that should use it.
Let Lovable use your account while building
Builder access lets Lovable use your own provider account while it works on a project. This helps Lovable inspect live schemas, test queries, and validate provider calls before it writes the integration. Builder access is available on all plans.1
Ask Lovable to inspect your provider data
After you link the client to the project, describe what Lovable should inspect or test. For example:
2
Connect your account
When the Allow Lovable to access Snowflake card appears, select Connect and complete the provider’s OAuth flow. The connection uses your provider permissions and applies only to this project.
3
Revoke access when you no longer need it
Ask Lovable in chat to stop using the connection. For example:Revoking builder access does not unlink the client from the project or disconnect anyone who uses the published app.
Builder access is separate from the connections used by your published app. Other project members and app users cannot use your builder connection, and generated app code cannot access it. However, data that Lovable returns can appear in the project’s shared chat.
Offline access
When you set up a client, Allow offline access is on by default. It lets the gateway refresh each user’s tokens in the background so they stay connected without reauthorizing every session. Turning Allow offline access on or off is available on Business and Enterprise plans. On Free and Pro plans it stays on. The setting is fixed once the client is linked to a project, so choose it before linking. To change it later, unlink the client from all projects first.Control over Allow offline access is rolling out gradually, so it may not be available in every workspace yet.
Add the connect experience to your app
Once the client is configured and linked, tell the Lovable Agent what you want, and it builds the in-app “Connect” flow for you. For example:App user connectors need to know who the current user is, so each sign-in can be tied to that person. Use built-in authentication (Cloud) (or your own auth) so each visitor is signed in before they connect.For enterprise accounts that publish a project to their own workspace, Lovable derives the signed-in user’s identity automatically through Lovable Auth, so you don’t need to add your own authentication.
Managing clients
- Users can disconnect their own account at any time, which revokes the stored tokens for that user.
- Deleting the client removes access for every user of that connector in the linked projects.
FAQ
What is an app user connector?
What is an app user connector?
An app user connector lets each end user of your published app connect their own third-party account, so your app acts on their behalf with their own permissions. It differs from a standard app connector, where you connect a single account once and every visitor shares it.
Can a user only see their own data?
Can a user only see their own data?
Yes. Each user’s access is isolated. The gateway forwards requests using that user’s credentials and their granted scopes, so one user’s access can never be used to act as another user.
Do I need authentication in my app to use this?
Do I need authentication in my app to use this?
Usually yes. Each sign-in is tied to a specific user, so your app needs to know who the current user is. Use built-in authentication (Cloud) or your own auth before prompting a user to connect. The exception is enterprise accounts that publish a project to their own workspace: Lovable derives the user’s identity through Lovable Auth, so no extra authentication is needed.
Are the user's tokens ever exposed to me or my app?
Are the user's tokens ever exposed to me or my app?
No. Tokens are stored encrypted in the connector gateway and are never visible in your project, to workspace admins, or to the Lovable Agent. Your app calls the connector through the gateway, which injects credentials behind the scenes and refreshes them automatically.