--- title: "Snowflake Integration" description: "Connect AI agents to Snowflake through the SQL API v2. Agents run parameterized SQL, load results into tables, poll long-running statements, and discover databases, schemas, and tables." url: https://flowrunner.ai/integrations/snowflake date_modified: 2026-08-01T02:40:32-07:00 --- # Snowflake [Database](https://flowrunner.ai/integrations/category/databases-warehouses) Connect AI agents to Snowflake through the SQL API v2. Agents run parameterized SQL, load results into tables, poll long-running statements, and discover databases, schemas, and tables. [Verified](https://flowrunner.ai/integrations/verified "What does verified mean?") · 8 actions · API key · available [Snowflake website](https://snowflake.com/) · [Platform Documentation](https://docs.snowflake.com/en/developer-guide/sql-api/intro) · Capability data verified 2026-07-14 1. A scheduled flow needs the latest figures from the warehouse 2. Agent runs Execute SQL with bound parameters to compute the metric 3. If the statement outruns the synchronous window, agent polls Get Statement Results by handle 4. Agent reads the returned rows as plain objects keyed by column name 5. Agent posts the computed figures to the metrics channel via Slack 6. Agent loads the reconciled results back into a reporting table with Execute SQL 7. Any INSERT, MERGE, or DDL that writes to a production database pauses for approval ## What This Integration Enables Agents read analytics out of Snowflake and use the rows directly in flow logic, load records produced by other steps into warehouse tables with INSERT or MERGE, and discover the account structure before touching it. Statements are submitted synchronously; when one does not finish inside the API's synchronous window, Execute SQL returns a statement handle and the agent polls Get Statement Results until the rows arrive, or calls Cancel Statement to stop it. Large result sets are split into partitions the agent can page through, so a wide analytical query does not have to fit in a single response. ### Without FlowRunner **Warehouse locked behind BI**: Numbers live in dashboards but cannot drive an automated workflow **Ad hoc export scripts**: Analysts export query results to spreadsheets to feed the next step by hand **Long queries block runs**: A slow statement stalls the whole automation with no way to poll or cancel ### With FlowRunner **Warehouse in the flow**: Query results feed flow logic directly as a governed step **Results move themselves**: The agent computes a metric and routes it onward with no manual export **Async by design**: Long-running statements are polled by handle, and can be cancelled cleanly ## Use Case Scenarios ### Warehouse-to-channel reporting On a schedule, an agent runs Execute SQL to compute the day's key figures against a virtual warehouse, reads the returned rows, and posts a formatted summary to a metrics channel with Slack. The team gets the numbers where they already work, and the figures come straight from the governed warehouse rather than a hand-built export. ### Cross-system load into the warehouse An agent pulls fresh records from an operational connector, then calls Execute SQL with an INSERT or MERGE to stage them into a Snowflake table. Because parameters are bound rather than interpolated, the load is safe against malformed values, and MERGE keeps the target table idempotent when the flow re-runs. ### Anomaly detection with a human gate An agent runs a query that surfaces an anomaly, such as a metric that crossed a control threshold. Before it writes a correction back into a production database, it does not act on its own. It routes the finding and the proposed write for review, and only runs the MERGE after a person confirms the change. ## Human-in-Loop Highlight Reading from a warehouse is safe. Writing to one, especially a MERGE or a DDL statement against a production database, is where a mistake becomes expensive and hard to reverse. FlowRunner's answer is human-in-the-loop, an execution pattern where the agent pauses on its own, assembles the context and the choices, routes to a human on their preferred channel, and resumes the moment they respond. When an Execute SQL statement would INSERT, MERGE, or run DDL against a database flagged as production, the agent pauses before submitting and asks through Slack: "Ready to MERGE 1,240 rows into `ANALYTICS.PROD.REVENUE`. Here is the statement and the source. Approve or cancel?" The write runs only after a person confirms, and the approver and timestamp are captured in the run log. A connector can run any SQL; an orchestration layer knows which statements should stop and ask first. Agent processes routinely Detects exception requiring judgment Clear match Continues automatically Ambiguous Routes to human via Slack Human decides Agent resumes with decision ## Agent Capabilities 8 actions ### SQL 3 - **Execute SQL** Runs any SQL statement (SELECT, INSERT, UPDATE, DELETE, MERGE, DDL, CALL, SHOW) with \`?\` placeholders bound via the Parameters array, and returns rows as plain objects plus the total row count and a statement handle. Use it for every read and write against the warehouse. - **Get Statement Results** Retrieves the status and results of a statement by handle, including individual partitions of a large result set. Use it to poll a long-running query that Execute SQL returned as in-progress. - **Cancel Statement** Cancels a running statement by handle, so an agent can abort a query that is taking too long or was started in error. ### Metadata 5 - **List Databases** Runs \`SHOW DATABASES\` for the databases visible to the configured role, for discovery before reading or writing. - **List Schemas** Runs \`SHOW SCHEMAS IN DATABASE\` for a database, listing the schemas an agent can query. - **List Tables** Runs \`SHOW TABLES IN SCHEMA\` with row counts and sizes, so an agent can find the right table before a query. - **List Warehouses** Runs \`SHOW WAREHOUSES\` with state and size, so an agent can confirm which virtual warehouse is available to provide compute. - **Get Table Schema** Runs \`DESCRIBE TABLE\` and returns column names, types, nullability, defaults, and key flags for a table. ## Frequently Asked Questions ### What can FlowRunner do with Snowflake? FlowRunner agents can run Execute SQL, Get Statement Results, and Cancel Statement in Snowflake, plus 5 more actions. ### Does connecting Snowflake to FlowRunner require OAuth? No. Snowflake connects to FlowRunner with an API key, no OAuth flow required. ### Can Snowflake trigger a FlowRunner workflow automatically? Snowflake doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger. **Work at Snowflake?** This integration exposes Snowflake to AI agents on every FlowRunner plan, including through MCP, at no cost to you. [See what FlowRunner offers integration partners](https://flowrunner.ai/integrations/partners), including how to keep this page current. --- Markdown version of https://flowrunner.ai/integrations/snowflake. Site index: https://flowrunner.ai/llms.txt