Standard connector vs. App user connector
Both are app connectors and both route through the gateway. The difference is whose account the app uses.| Standard app connector | App user connector | |
|---|---|---|
| Whose account | One account you connect once | Each end user’s own account |
| Who authorizes | The builder (or a workspace admin) | Every user, the first time they use it |
| Data the app sees | The single connected account’s data, shared by all visitors | Only the signed-in user’s data, per their granted scopes |
| Typical use | Send from a company inbox, post to one Slack workspace, query one warehouse | ”Connect your Gmail”, “Connect your Salesforce”, per-user dashboards |
| Credentials | Stored once, reused for every request | Stored per user, isolated from other users |
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.| Provider | App user connectors | OAuth app setup |
|---|---|---|
| Gmail, Google Calendar, Google Drive, Google Docs, Google Sheets, Google Slides | Create OAuth credentials | |
| Microsoft | Outlook, OneDrive, SharePoint, Teams, OneNote, Word, Excel, PowerPoint | Register an application |
| Slack | Slack | Installing with OAuth |
| Salesforce | Salesforce | External Client Apps |
| HubSpot | HubSpot | Working with OAuth |
| Linear | Linear | OAuth 2.0 authentication |
| Databricks | Databricks | Authorize user access with OAuth |
| Snowflake | Snowflake | OAuth for custom clients |
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.
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 Lovable Cloud authentication (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 Lovable Cloud authentication 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.