Connect your app to Snowflake

• 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

​

Common use cases and example apps

​

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.

​

How to connect Snowflake

​

Prerequisites

• 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 to create the role, and SECURITYADMIN to run the grants (its global MANAGE GRANTS privilege covers objects it does not own, and the future grants in Step 2 require it)
• A dedicated, non-personal Snowflake user to authorize the connection. Using a dedicated user rather than someone’s own account means the connection stays active if the person who set it up leaves the company. This user must hold the dedicated role and must be able to complete a browser sign-in, so keep it at TYPE = PERSON. A TYPE = SERVICE user cannot authorize the connection: it can sign in with neither a password nor SAML SSO, and Snowflake OAuth only offers the authorization code flow, which needs an interactive login
• Permission to create connections in your Lovable workspace (see Who can create connections and clients)

​

Step 1: Find your account URL

​

Step 2: Create a least-privilege role

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

USE ROLE SECURITYADMIN;
GRANT USAGE ON WAREHOUSE MY_WH TO ROLE LOVABLE_ROLE;

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;

USE ROLE SECURITYADMIN;
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;

USE ROLE USERADMIN;
GRANT ROLE LOVABLE_ROLE TO USER MY_AUTHORIZING_USER;

​

Step 3: Create the OAuth security integration

DESC SECURITY INTEGRATION MY_INTEGRATION;

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');

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';

• 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. Both values are already Snowflake’s defaults for a custom client, so these two lines change nothing on a fresh integration; set them explicitly anyway so the connector does not silently inherit a shorter validity from an integration someone edited earlier. 7776000 seconds (90 days) is also the maximum, and you reconnect in Lovable when the refresh token expires, so this 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.

​

Step 4: Retrieve the client ID and secret

SELECT SYSTEM$SHOW_OAUTH_CLIENT_SECRETS('LOVABLE_OAUTH');

​

Step 5: Connect Snowflake in Lovable

​

Verify and use the connection

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

• 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.
• If the query fails, the connection itself is fine and the role is missing a warehouse or a grant. Go back to Step 2 and check SHOW GRANTS TO ROLE LOVABLE_ROLE;.

​

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

• 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