Connect your app to Snowflake

Connect Snowflake to your Lovable app using Snowflake OAuth. Run SQL, use the SQL REST API, and work with warehouses and data from your Snowflake account through Lovable’s connector gateway.

Snowflake is a cloud data platform for analytics, data engineering, and AI/ML workloads. The Snowflake app + chat connector uses Snowflake’s native OAuth (custom security integration) so your app can call Snowflake through Lovable’s connector gateway without embedding long-lived passwords in your project.

Use	If you want to
App + chat connector (this page)	Work with a shared Snowflake connection in the chat and in your published apps
App user connector	Let each user of your published app connect their own Snowflake account and work with their own data

With Snowflake connected, your app can:

• Run SQL and use the SQL REST API (for example submitting statements and checking status)
• Work with warehouses, databases, and schemas your role can access
• Build internal tools, dashboards, and data workflows backed by Snowflake

Snowflake fits when your organization already centralizes data in Snowflake and you want Lovable apps to query or orchestrate that data securely.

Common use cases and example apps

Example app	Example prompt	Description
SQL explorer	Build an internal tool that runs read-only SQL against our analytics schema and shows results in a table.	Ad-hoc querying with guardrails you define in app logic.
Metric dashboard	Show daily revenue and signups from Snowflake summary tables with date filters.	Operational dashboards fed by modeled tables in Snowflake.
Pipeline status	After a user uploads a file, poll Snowflake for load completion and show pass/fail.	Orchestration-style UX on top of warehouse data.
Support lookup	Given an account ID, load key fields from our Snowflake customers view for the support UI.	Enrich product UIs with trusted warehouse data.
Data validation	Run lightweight row counts and null checks on staging tables after our ETL runs.	Quality checks using SQL against Snowflake.

How Snowflake connections work

• OAuth 2.0 (authorization code): You register a custom OAuth integration in Snowflake and enter the Account URL, Client ID, Client Secret, and Role in Lovable. You (or your admin) then complete sign-in with Snowflake to authorize the connection. Lovable stores the OAuth tokens and refreshes them automatically, so credentials never live in your app’s code.
• Role: The connection runs under a single Snowflake role that you configure. Administrator roles cannot be used; create a dedicated, least-privilege role instead (Step 2 below shows how).
• Gateway: API requests are proxied through Lovable’s connector gateway, which manages tokens. See Gateway-based connectors for limits.

Snowflake compute and storage costs are billed by Snowflake / your cloud agreement, not by Lovable.

How to connect Snowflake

Who can create Snowflake connections depends on your plan and workspace settings. On Enterprise plans, app + chat connectors are effectively disabled at first: Who can create connections and clients defaults to No one until an admin changes it. You can create multiple Snowflake connections using different accounts or roles, which is useful for separating development and production data.

When the connection is created, you can link it to the projects where you want to use it. Anyone building in a project can ask Lovable in chat to link their project to it.

The steps below can create everything from scratch, but you do not have to start from a blank slate: each step opens with the criteria an existing piece must meet, so verify and skip the creation SQL where yours already passes.

Prerequisites

Before connecting Snowflake, make sure you have:

• A Snowflake account, and a user with the ACCOUNTADMIN role (or the global CREATE INTEGRATION privilege) to create the OAuth security integration and read its client secret
• Privileges to create a role and grant it access to your data (USERADMIN or SECURITYADMIN for the role, plus ownership of the objects you grant)
• A Snowflake user who will authorize the connection. This user must hold the dedicated role. Prefer a dedicated, non-personal user so the connection does not break when an employee leaves
• Permission to create connections in your Lovable workspace (see Who can create connections and clients)

By the end of Step 4 you have the four values the Lovable connection form asks for:

Field	Where it comes from	Already have it?
Account URL	Step 1	It has the form https://<orgname>-<account_name>.snowflakecomputing.com, no path
Client ID	Step 4	DESC SECURITY INTEGRATION <name> passes the Step 3 criteria
Client Secret	Step 4	SYSTEM$SHOW_OAUTH_CLIENT_SECRETS re-reads it any time
Role	Step 2	SHOW GRANTS TO ROLE <role> covers warehouse and data; role passes the Step 2 criteria

Step 1: Find your account URL

Lovable needs your account URL in the form https://<orgname>-<account_name>.snowflakecomputing.com, with no trailing slash or path.

The easiest way to get it: in Snowsight, open the account selector in the bottom-left corner, hover over your account, and click View account details. Copy the value under Account/Server URL.

See Account identifiers in the Snowflake docs for details.

Step 2: Create a least-privilege role

Snowflake blocks ACCOUNTADMIN, SECURITYADMIN, ORGADMIN, and GLOBALORGADMIN from OAuth sessions by default, and Lovable additionally rejects ACCOUNTADMIN and SECURITYADMIN in the connection form. This is a feature, not a limitation: create a dedicated role that can see only the data your app needs.

Reuse an existing role instead?

Reuse an existing role only if all of these hold:

• It is none of the blocked roles above, not on your integration’s BLOCKED_ROLES_LIST, and present in its ALLOWED_ROLES_LIST if one is set (DESC SECURITY INTEGRATION).
• It is granted to the user who will authorize the connection (SHOW GRANTS TO USER <user>).
• It has USAGE on a warehouse plus the data grants your app needs (SHOW GRANTS TO ROLE <role>).

A broad existing role (a general analyst role, say) passes these checks but hands the app everything that role can see, so a dedicated role stays the recommendation. If you do reuse one, substitute its name below and skip ahead to the final grant in this step.

USE ROLE USERADMIN;
CREATE ROLE IF NOT EXISTS LOVABLE_ROLE
  COMMENT = 'Least-privilege role for the Lovable connector';

Give the role a warehouse to run queries on. In most cases this is one of your existing warehouses:

GRANT USAGE ON WAREHOUSE MY_WH TO ROLE LOVABLE_ROLE;

Recommended for production apps: a dedicated warehouse instead. Query volume is driven by your app’s end users, so it is unpredictable and outside your control. A dedicated warehouse isolates that load from your other workloads, makes the app’s spend its own line item, and can be capped with a resource monitor. Skip this block if you granted an existing warehouse above.

USE ROLE SYSADMIN;
CREATE WAREHOUSE IF NOT EXISTS LOVABLE_WH
  WAREHOUSE_SIZE = XSMALL
  AUTO_SUSPEND = 60
  AUTO_RESUME = TRUE
  INITIALLY_SUSPENDED = TRUE;
GRANT USAGE ON WAREHOUSE LOVABLE_WH TO ROLE LOVABLE_ROLE;

Grant access to exactly the data the app needs. Read-only example:

GRANT USAGE ON DATABASE MY_DB TO ROLE LOVABLE_ROLE;
GRANT USAGE ON SCHEMA MY_DB.MY_SCHEMA TO ROLE LOVABLE_ROLE;
GRANT SELECT ON ALL TABLES IN SCHEMA MY_DB.MY_SCHEMA TO ROLE LOVABLE_ROLE;
GRANT SELECT ON ALL VIEWS  IN SCHEMA MY_DB.MY_SCHEMA TO ROLE LOVABLE_ROLE;
-- Cover tables and views created later:
GRANT SELECT ON FUTURE TABLES IN SCHEMA MY_DB.MY_SCHEMA TO ROLE LOVABLE_ROLE;
GRANT SELECT ON FUTURE VIEWS  IN SCHEMA MY_DB.MY_SCHEMA TO ROLE LOVABLE_ROLE;

Add INSERT, UPDATE, or DELETE grants only if your app writes data.

Finally, grant the role to the user who will click through the OAuth authorization in Step 5. The grant target is the Snowflake username, which is not always the email used to log in; the authorizing person can get theirs by running SELECT CURRENT_USER();. If it contains special characters such as @, quote it and match the case exactly (GRANT ROLE LOVABLE_ROLE TO USER "[e-mail]";).

GRANT ROLE LOVABLE_ROLE TO USER MY_AUTHORIZING_USER;

Step 3: Create the OAuth security integration

This is the OAuth client Lovable authenticates against. Creating it requires ACCOUNTADMIN or the global CREATE INTEGRATION privilege. See Configure Snowflake OAuth for custom clients in the Snowflake docs. Already have an integration? Jump to the reuse checks at the end of this step.

USE ROLE ACCOUNTADMIN;
CREATE SECURITY INTEGRATION LOVABLE_OAUTH
  TYPE = OAUTH
  ENABLED = TRUE
  OAUTH_CLIENT = CUSTOM
  OAUTH_CLIENT_TYPE = 'CONFIDENTIAL'
  OAUTH_REDIRECT_URI = 'https://api.lovable.dev/workspaces/connectors/standard/oauth/callback'
  OAUTH_ISSUE_REFRESH_TOKENS = TRUE
  OAUTH_REFRESH_TOKEN_VALIDITY = 7776000
  OAUTH_ENFORCE_PKCE = TRUE
  ALLOWED_ROLES_LIST = ('LOVABLE_ROLE')
  COMMENT = 'OAuth client for the Lovable Snowflake connector';

Why these values:

• OAUTH_CLIENT_TYPE = 'CONFIDENTIAL': Lovable stores the client secret server-side and can use a confidential client, which is stronger than a public one.
• OAUTH_REDIRECT_URI: must exactly match the callback Lovable uses. The Lovable connection form shows this value under Redirect URI with a copy button, so you can copy it from there.
• OAUTH_ISSUE_REFRESH_TOKENS = TRUE and OAUTH_REFRESH_TOKEN_VALIDITY = 7776000: Snowflake access tokens are short-lived, so Lovable refreshes them in the background. 7776000 seconds (90 days) is the maximum; when the refresh token expires you reconnect in Lovable, so the maximum keeps reconnects to at most once per quarter.
• OAUTH_ENFORCE_PKCE = TRUE: Lovable always sends a PKCE code challenge, so you can enforce it. This protects the flow against authorization code interception.
• ALLOWED_ROLES_LIST = ('LOVABLE_ROLE'): every role not listed is implicitly blocked, so this integration can only ever mint sessions for the connector role. Leaked client credentials cannot be parlayed into a broader session, and repointing the Lovable connection at a more privileged role fails at the authorize step until whoever controls the integration updates this list first.

Leave OAUTH_USE_SECONDARY_ROLES at its default (NONE) so sessions are limited to the single role you configured and cannot pick up extra privileges from the authorizing user’s secondary roles.

Already have an OAuth integration?

Inspect it first:

DESC SECURITY INTEGRATION MY_INTEGRATION;

Reuse it only if it is a custom OAuth integration (OAUTH_CLIENT = CUSTOM) with OAUTH_CLIENT_TYPE = CONFIDENTIAL, it is enabled, and its OAUTH_REDIRECT_URI is exactly Lovable’s callback. Two hard limits:

• A custom OAuth integration holds a single redirect URI, so an integration already serving another tool (Tableau, a BI client) cannot also serve Lovable. Create a separate integration per application; separate secrets also keep rotation and revocation independent.
• OAUTH_CLIENT_TYPE cannot be changed after creation. An existing PUBLIC client must be recreated as CONFIDENTIAL.

Everything else is fixable in place on an integration dedicated to Lovable:

ALTER SECURITY INTEGRATION MY_INTEGRATION SET
  OAUTH_REDIRECT_URI = 'https://api.lovable.dev/workspaces/connectors/standard/oauth/callback'
  OAUTH_ISSUE_REFRESH_TOKENS = TRUE
  OAUTH_REFRESH_TOKEN_VALIDITY = 7776000
  OAUTH_ENFORCE_PKCE = TRUE
  ALLOWED_ROLES_LIST = ('LOVABLE_ROLE');

Step 4: Retrieve the client ID and secret

Still as ACCOUNTADMIN, read the generated credentials:

SELECT SYSTEM$SHOW_OAUTH_CLIENT_SECRETS('LOVABLE_OAUTH');

The result is a JSON object containing OAUTH_CLIENT_ID, OAUTH_CLIENT_SECRET, and OAUTH_CLIENT_SECRET_2. Copy OAUTH_CLIENT_ID and OAUTH_CLIENT_SECRET (either secret works; two exist so you can rotate them without downtime). The function can be re-run at any time, so a lost secret never requires recreating the integration.

Treat both values like passwords. Paste them directly into Lovable in the next step rather than storing them in documents or chat.

Step 5: Connect Snowflake in Lovable

1. Open Snowflake in Connectors

   Go to Connectors and select Snowflake.

2. Add a connection

   Click Add connection.

3. Name the connection

   In Display name, name the connection (for example, Snowflake Prod). This name is only used inside Lovable to identify the connection.

4. Enter the connection details

   • Account URL: the URL from Step 1.
   • Client ID and Client Secret: the values from Step 4.
   • Role: LOVABLE_ROLE. Enter it in uppercase, exactly as it appears in SHOW ROLES. The role name is passed to Snowflake case-sensitively as the OAuth scope.
5. Choose who can use this connection

   Under Who can use this connection, decide who in your workspace can use the connection. You start as the only person with access:

   • Only you (default): leave the access list as is; only you can use the connection and its associated data.
   • Invite specific people: add workspace members by email; only you and the people you add can use the connection and its associated data.
   • Invite entire workspace: click Invite entire workspace to make the connection available to everyone in your Lovable workspace.

   See Who can manage connections for more information.

6. Connect to Snowflake and authorize

   Click Connect. The Snowflake authorization window opens, so make sure your browser doesn’t block pop-ups. If it does, Lovable redirects you instead.

   Sign in as the user that holds LOVABLE_ROLE (from Step 2), review the requested role, and click Allow.

   Lovable verifies the connection by running SELECT CURRENT_USER() through Snowflake’s SQL REST API. When it succeeds, you are redirected back to Lovable with a confirmation.

When connected, anyone building in a project can ask Lovable in chat to link their project to Snowflake (based on configured connection-level access). Your Lovable apps can then run SQL against your Snowflake data while you build and after you publish.

Verify and use the connection

Link the connection to a project and ask Lovable in chat to query your data, for example:

Use Snowflake and show the ten most recent rows from MY_SCHEMA.MY_TABLE.

Two things to know when building:

• Queries that need compute must run on a warehouse. Tell Lovable which warehouse to use (the SQL API accepts a warehouse parameter per statement), or set a default warehouse on the authorizing user.
• You can audit everything the app runs in Snowsight under Monitoring → Query History, filtered by user or warehouse.

Best practices

• One connection per environment: create separate integrations, roles, and connections for development and production data.
• Keep the role read-only unless the app genuinely writes data, and scope grants to specific schemas rather than whole databases.
• For production apps, use a dedicated warehouse with a resource monitor to cap unexpected spend.
• Authorize with a dedicated user rather than a personal login. If the authorizing user is disabled, the connection stops working until someone reconnects.
• Rotate the client secret periodically using the second secret slot, then update the connection in Lovable.
• Changing the connection’s role later? Add the new role to the integration’s ALLOWED_ROLES_LIST before reconnecting.
• Expect to reconnect when the refresh token expires (at most every 90 days with the settings above).

Limitations

• Scopes and roles are determined by your Snowflake OAuth integration and the role you configure; the app cannot exceed those permissions.
• Per-user Snowflake login is not provided by this connector. Each connection represents a shared authorization for the workspace connection. If you need each end user to sign in with their own Snowflake account and query under their own role, use the Snowflake app user connector.
• Gateway limits apply as described in Gateway-based connectors.

Manage your connection

Connections are managed from Connectors: select , then open the connection.

• Unlink projects to remove access from specific projects while keeping the connection available for others. See Unlink projects from a connection for the steps.
• Delete the connection to remove it from the workspace entirely. Deleting is permanent. It removes the credentials from all linked projects, and app features that use stop working until a new connection is added. See Delete a connection for the steps and who can delete.

Troubleshooting

Error during Snowflake authorization

The signing-in user does not have the role granted, the role is blocked or missing from the integration’s ALLOWED_ROLES_LIST (check both lists with DESC SECURITY INTEGRATION), or the role name case does not match. Re-check Step 2 and re-enter the role in uppercase.

If the connection fails with “role cannot be ACCOUNTADMIN or SECURITYADMIN”, enter the dedicated role from Step 2 instead.

Redirect URI mismatch

OAUTH_REDIRECT_URI in the security integration must exactly match the Redirect URI shown in the Lovable connection form. A common cause is reusing an integration created for another tool; create a Lovable-dedicated one instead. Otherwise fix it with ALTER SECURITY INTEGRATION LOVABLE_OAUTH SET OAUTH_REDIRECT_URI = '...';.

Authorization window never completes

The authorizing user cannot sign in interactively (SSO-only or key-pair-only service users, or an MFA policy blocking the login). Authorize with a user that can complete a browser login.

The connection works, but queries fail

Usually a missing warehouse (pass warehouse in the statement or set a user default) or a missing grant on the queried object.

Reconnecting every day

OAUTH_REFRESH_TOKEN_VALIDITY is at or near the minimum (86400). Raise it with ALTER SECURITY INTEGRATION LOVABLE_OAUTH SET OAUTH_REFRESH_TOKEN_VALIDITY = 7776000; and reconnect once more.

The connection stopped working after weeks

The refresh token expired or the authorizing user was disabled. Reconnect the integration in Lovable.