> ## 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.

# 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.

export const connector_0 = "Snowflake"

[Snowflake](https://www.snowflake.com/) 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](/integrations/app-user-connectors) | 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](/integrations/app-connectors#gateway-based-connectors) for limits.

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

## 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](/integrations/admin-controls#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](/integrations/app-connectors#link-a-connection-to-a-project) 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](/integrations/admin-controls#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](https://docs.snowflake.com/en/user-guide/admin-account-identifier) 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.

<Accordion title="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.
</Accordion>

```sql theme={null}
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:

```sql theme={null}
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](https://docs.snowflake.com/en/user-guide/resource-monitors). Skip this block if you granted an existing warehouse above.

```sql theme={null}
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:

```sql theme={null}
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 "jane.doe@company.com";`).

```sql theme={null}
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](https://docs.snowflake.com/en/user-guide/oauth-custom) in the Snowflake docs. Already have an integration? Jump to the reuse checks at the end of this step.

```sql theme={null}
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.

<Accordion title="Already have an OAuth integration?">
  Inspect it first:

  ```sql theme={null}
  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:

  ```sql theme={null}
  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');
  ```
</Accordion>

### Step 4: Retrieve the client ID and secret

Still as `ACCOUNTADMIN`, read the generated credentials:

```sql theme={null}
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.

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

### Step 5: Connect Snowflake in Lovable

<Steps>
  <Step title="Open Snowflake in Connectors">
    Go to **Connectors** and select **Snowflake**.
  </Step>

  <Step title="Add a connection">
    Click **Add connection**.
  </Step>

  <Step title="Name the connection">
    In **Display name**, name the connection (for example, `Snowflake Prod`). This name is only used inside Lovable to identify the connection.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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](/integrations/admin-controls#who-can-use-connections-and-clients) for more information.
  </Step>

  <Step title="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**.

    <Check>
      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.
    </Check>
  </Step>
</Steps>

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:

```text wrap theme={null}
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](/integrations/app-user-connectors)**.
* **Gateway limits** apply as described in [Gateway-based connectors](/integrations/app-connectors#gateway-based-connectors).

## Manage your {connector_0} connection

Connections are managed from [**Connectors**](https://lovable.dev/dashboard?connectors): select **{connector_0}**, then open the connection.

* **Unlink projects** to remove {connector_0} access from specific projects while keeping the connection available for others. See [Unlink projects from a connection](/integrations/app-connectors#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 {connector_0} stop working until a new connection is added. See [Delete a connection](/integrations/app-connectors#delete-a-connection) for the steps and who can delete.

## Troubleshooting

<AccordionGroup>
  <Accordion title="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.
  </Accordion>

  <Accordion title="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 = '...';`.
  </Accordion>

  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>

  <Accordion title="The connection stopped working after weeks">
    The refresh token expired or the authorizing user was disabled. Reconnect the integration in Lovable.
  </Accordion>
</AccordionGroup>