SNOWFLAKE
REST API
Turn a Snowflake query into a secure REST API — no SQL API to wire up, no account seats to share.
Save a SQL query against your Snowflake warehouse, mint a per-recipient API key, and hand a partner a live JSON endpoint. No Snowflake SQL API integration to build, no key-pair OAuth, no warehouse seat to give away — just a governed, read-only Snowflake REST API in minutes.
Ask Nova, get SQL + charts
Meet Nova
One key per partner. No credentials shared.
Build an API
+more
Scheduled sync to 6+ platforms
Explore
+more
Query APIs with SQL, no code
Explore
+more
Claude, Cursor, ChatGPT & Grok talk to your data
Connect AIQuery Streams is a secure, real-time database integration platform that turns any saved Snowflake query into a partner-ready REST API endpoint — with per-recipient keys, read-only enforcement, and a full audit trail. You get a live Snowflake REST API without building against the Snowflake SQL API, handing out account credentials, or hosting a gateway. Learn more at QueryStreams.com and sign up for free to publish your first Snowflake endpoint in minutes.
Why expose a Snowflake database as a REST API?
Your curated data lives in Snowflake, and sooner or later someone outside your team needs a slice of it — a client wants their numbers in a dashboard, a vendor wants a live feed instead of a nightly export, a partner’s app needs to read one well-shaped result set. The native options all cost you something you would rather not spend. Snowflake’s own SQL API is powerful but means standing up key-pair or OAuth auth, a running warehouse, and pagination handling on the consumer side. Giving a partner a Snowflake login (or a reader account) hands them far more reach than one report, and every seat has a cost. Reverse-ETL pipelines move the data somewhere else entirely. A Snowflake REST API is the clean version: the partner gets a URL and a token, not your account. Query Streams makes it a saved query plus a key.
No account seats to give away
Recipients never get a Snowflake login, a reader account, or OAuth client. The Network Agent runs the query under your own read-only role; the partner only ever holds an API key.
Per-recipient API keys
Every recipient gets their own qsapi_* key. Revoke one without touching the others, and without rotating your Snowflake credentials.
Read-only by design
A read-only validator rejects any non-SELECT statement before it reaches Snowflake. There is no accidental UPDATE, MERGE, or DROP path through the API.
Your SQL stays private
The recipient sees the endpoint URL, the JSON response, and any filters you exposed — never your SQL, your warehouse, your account identifier, or your schema.
Nothing to host or patch
No SQL API integration, no OAuth server, no reverse-ETL pipeline. The endpoint runs as a managed feature, so there is no deploy pipeline or token-refresh code to own.
Permanent, expiring, or self-destructing
Make an endpoint permanent, set it to expire on a date, or give it a fixed call budget that self-destructs after a set number of requests.
Snowflake SQL via REST API — the usual ways, and why they hurt
There are real ways to put an HTTP surface on Snowflake, and they are good at what they do. The catch is that every one of them leaves you owning auth, infrastructure, or a second copy of the data. Here is how the common approaches compare to a Query Streams shared endpoint when the goal is simply “let a specific partner read a specific result set.”
| Concern | Snowflake SQL API (native) | Reverse ETL / DIY service | Query Streams |
|---|---|---|---|
| What the recipient holds | Account-level key-pair or OAuth client | A copy of your data in another tool | A single-purpose key for one query |
| Surface exposed | Any SQL the role can run | Whatever the pipeline syncs | One saved query, nothing else |
| Auth you set up | Key-pair JWT / OAuth + warehouse | Pipeline credentials both ends | Outbound-only Agent, read-only role |
| Per-recipient keys + revoke | Build it yourself | Build it yourself | Built in |
| Audit log of every call | Via ACCOUNT_USAGE, self-assemble | Add it yourself | Built in |
| You operate / patch / rotate auth | Yes, forever | Yes, forever | Managed for you |
| Time to first endpoint | Hours to days | Days | Minutes |
Looking for an alternative to Snowflake’s SQL API for partner sharing?
Snowflake’s SQL API is excellent when you control both ends and want full programmatic access to your account. If instead you want to hand a named partner one governed, read-only result set — with its own key, an audit trail, and no auth integration to build — that is exactly the gap Query Streams fills. The two can coexist: the SQL API for your own apps, Query Streams for outbound sharing.
How Query Streams turns a Snowflake query into a REST API
Once the Network Agent is installed and your Snowflake connector is configured, promoting a saved query to a shared REST endpoint takes about three steps. If you already use Query Streams for Excel, Google Sheets, or the MCP Server, your Agent and connector are already in place — you start at step two.
Connect Snowflake through the Agent
Install the Network Agent and add a Snowflake connector with a dedicated read-only role and a small warehouse. The Agent makes an outbound TLS connection to Query Streams — no account credentials ever reach a recipient.
Save a SQL query
Write the SELECT in the Query Builder against your Snowflake connection — JOINs, CTEs, window functions, and parameters all welcome. Name it and save. Anything you can SELECT can become an endpoint.
Promote it and share a key
Open the Install tab, choose the endpoint type (permanent, expiring, or call-budget) and output format, then invite a recipient by email. They get a magic-link claim and their own qsapi_* key.
Keep warehouse credits low
Every API call runs your saved query on the warehouse you assigned the connector. Point it at a small, auto-suspending warehouse so it spins down between calls, and Snowflake’s result cache serves repeated identical calls cheaply. A tightly-scoped saved query keeps both the bytes scanned and the credits burned predictable.
No shared account, no exposed warehouse
The security model is the reason teams reach for this instead of a Snowflake login or a public SQL API integration. Your Snowflake credentials live only inside the Agent’s encrypted credential store on your network; they are never transmitted to our cloud and never visible to a recipient. On top of that, every endpoint gives you per-recipient controls you can tighten before you share.
Outbound-only Agent
The Agent reaches agent.querystreams.com on port 443, so your network sees only normal outgoing HTTPS — no inbound ports, no VPN, no tunnel. how the outbound-only connection works →
Read-only enforcement
A validator runs in the Agent, on your network, before any statement reaches Snowflake. Non-SELECT statements are rejected with READONLY_VIOLATION.
IP + CORS allowlists
Pin a recipient’s key to specific IPs or CIDR ranges, and restrict which browser origins may call each endpoint. Off-list calls are refused before any SQL runs.
Rate limits + byte quotas
Two-tier rate limits (per key and per endpoint) plus an optional monthly byte cap keep a noisy recipient inside a safe blast radius — and your warehouse credits predictable.
Call your Snowflake REST API
Recipients call the endpoint like any other REST API: a bearer token and a URL. Any saved-query parameter you exposed can be set per call — on the querystring for GET or in a JSON body for POST. The Agent binds those values as proper bound parameters, never string concatenation, so a recipient cannot break out of a filter to inject SQL.
Pick the output format per call with the Accept header (or a ?format= query parameter): JSON for a single array, CSV for spreadsheets and pandas, or, on a streaming endpoint, NDJSON (one JSON row per line) for parse-as-you-go pipelines — a good fit for the large result sets Snowflake produces. For bandwidth-sensitive consumers, opt into LZ4 payload compression with Accept-Encoding: lz4; uncompressed responses also get standard gzip on the wire automatically. For the full breakdown of static vs streaming modes, the four wire combinations, and OpenAPI 3.1 generation, see the Instant REST API for SQL databases guide.
How usage is billed
The API Platform is included in every plan and draws on the same monthly byte allowance as Excel, Sheets, and MCP — with Snowflake compute credits for the query still running on your own warehouse, as usual. how the byte allowance and compression billing work →
Plug it into Power BI, Tableau, and anything that reads JSON
Because every endpoint returns standard JSON — with CSV and streaming NDJSON on tap — any tool that can read a REST feed consumes your Snowflake data directly, with nothing to install on their side and no Snowflake driver required. Power Query is the easiest bridge into the Microsoft BI stack: in Power BI choose Get Data → From Web, paste the endpoint URL, add your Authorization header, and Power Query parses the JSON into a refreshable table that feeds your data model. (For live data inside a spreadsheet, the native Query Streams Excel add-on is the simpler path — Power Query is there when you want the data in the Power BI model itself.)
Power Query
Get Data → From Web, paste the URL and bearer token, expand the JSON to a refreshable table
Power BI
Same Power Query engine — load the endpoint straight into your model and schedule refresh
Tableau
Point a Web Data Connector or JSON source at the endpoint for live dashboards
Postman
Import the OpenAPI 3.1 spec, then send, inspect, and share requests in one click
It also feeds n8n, Qlik, curl, Python (requests or pandas.read_json), Insomnia, Hoppscotch — or any script or workflow that can send an HTTP request and read JSON.
Works on AWS, Azure, and Google Cloud
It does not matter which cloud your Snowflake account runs on. The Agent connects the same way whether your account is hosted on AWS, Azure, or Google Cloud, and across any region. For the lowest latency, deploy the Agent in the same cloud region as your Snowflake account; one Query Streams account can run multiple Agents across regions and clouds, and a single endpoint behaves identically regardless of which Agent serves it.
More than Snowflake
The same workflow promotes a saved query from PostgreSQL, Microsoft SQL Server, MySQL, MariaDB, SQLite, Microsoft Access, Oracle, BigQuery, or DuckDB to a REST endpoint. Snowflake is simply one of the most popular starting points. Browse the Connector Setup guides for the current list.
Frequently Asked Questions
Do I need to set up Snowflake’s SQL API or hand out account access? +
agent.querystreams.com on port 443. The recipient only ever holds a Query Streams API key scoped to one saved query.Can the recipient see my SQL or my Snowflake credentials? +
Is this the same as Snowflake’s HTTP API or SQL API? +
What output formats can the API return? +
Accept header or ?format=. output formats, compression, and streaming explained →Will this run up my Snowflake credits? +
Can an endpoint expire or self-destruct? +
Does the recipient need a Query Streams account? +
Get Started
Publish your first Snowflake REST API for free.
Sign up, install the Network Agent, connect Snowflake with a read-only role, save a SQL query, and email a recipient a magic-link claim. Per-recipient keys, read-only enforcement, and a full audit trail are on from the first call.
Related guides: Instant REST API for SQL databases | Database REST API platform | Expose BigQuery as a REST API | Connector Setup guides
Category: API Platform
Tags: snowflake-rest-api, snowflake, snowflake-sql-rest-api, rest-api, expose-snowflake-as-api, snowflake-api-integration, share-snowflake-data, per-recipient-keys, no-code-api, database-rest-api
Meta Description: Turn a Snowflake query into a secure, read-only REST API with per-recipient keys — no SQL API setup, no shared account, no code.
English 
Spanish 
German 
French 
Portuguese 
Japanese 
Korean 
Chinese 
Italian 
Dutch 
Indonesian 
Polish