> ## Documentation Index > Fetch the complete documentation index at: https://docs.lovable.dev/llms.txt > Use this file to discover all available pages before exploring further. # App user connectors: let your users connect their own accounts > App user connectors let each end user of your published Lovable app connect their own third-party account, so your app acts on their behalf with their own permissions. Authentication is handled securely through Lovable's connector gateway. **App user connectors** let **each end user of your published app** connect **their own** third-party account. Your app then acts **on their behalf**, with their own permissions and only their data. Authentication runs through Lovable's [connector gateway](/integrations/security#gateway-connectors), so user tokens are stored securely and never exposed in your project. Use an app user connector when the app is multi-tenant by nature: a signed-in user should see **their** inbox, **their** calendar, or **their** CRM records, not a single shared account. ## Standard connector vs. App user connector Both are [app connectors](/integrations/introduction#app-connectors-add-capabilities-to-your-published-app) 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](/integrations/security#credentials) 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 | | :------------- | :------------------------------------------------------------------------------ | :----------------------------------------------------------------------------------------------------------------------------------- | | **Google** | Gmail, Google Calendar, Google Drive, Google Docs, Google Sheets, Google Slides | [Create OAuth credentials](https://developers.google.com/workspace/guides/create-credentials) | | **Microsoft** | Outlook, OneDrive, SharePoint, Teams, OneNote, Word, Excel, PowerPoint | [Register an application](https://learn.microsoft.com/en-us/entra/identity-platform/quickstart-register-app) | | **Slack** | Slack | [Installing with OAuth](https://api.slack.com/authentication/oauth-v2) | | **Salesforce** | Salesforce | [External Client Apps](https://help.salesforce.com/s/articleView?id=xcloud.external_client_apps.htm) | | **HubSpot** | HubSpot | [Working with OAuth](https://developers.hubspot.com/docs/apps/developer-platform/build-apps/authentication/oauth/working-with-oauth) | | **Linear** | Linear | [OAuth 2.0 authentication](https://linear.app/developers/oauth-2-0-authentication) | | **Databricks** | Databricks | [Authorize user access with OAuth](https://docs.databricks.com/aws/en/dev-tools/auth/oauth-u2m) | | **Snowflake** | Snowflake | [OAuth for custom clients](https://docs.snowflake.com/en/user-guide/oauth-custom) | The list of app user connectors grows over time. Open **Connectors** in your workspace to see what's currently available. ## 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](#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: ```text theme={null} https://connector-gateway.lovable.dev/api/v1/app-users/oauth2/callback ``` Lovable also shows this value in the connector setup screen so you can copy it directly. ### Configure the client 1. Open **Connectors** in your workspace and select the provider you want (for example **Salesforce** or **Gmail**). 2. 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). 3. Link the client to the project that should use it. Who can configure a connector follows the standard [app connector access rules](/integrations/introduction#who-can-create-connections): on Free and Pro plans any editor can, and on Business and Enterprise plans workspace admins and owners govern availability. ### 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: ```text wrap theme={null} Let my users connect their own Gmail so the dashboard shows their inbox. ``` ```text wrap theme={null} Add a "Connect Salesforce" button so each signed-in user links their own account, then show their own open opportunities and let them log a call. ``` There are multiple entry points. You can start from the UI or drive the whole thing from chat, but the pattern is the same: **configure the client in the UI, then ask the agent to connect it** in your app. From there, each of your users connects their own account the first time they use the feature. App user connectors need to know **who** the current user is, so each sign-in can be tied to that person. Use [Lovable Cloud](/integrations/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. See [Integration security](/integrations/security) for credential storage, rotation, outbound IP ranges, and data retention that apply to all gateway connectors. ## FAQ 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. 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. 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](/integrations/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. 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.