BIGQUERY
REST API
Turn a BigQuery query into a secure REST API — no jobs API, no service-account keys to hand out.
Save a SQL query against your BigQuery dataset, mint a per-recipient API key, and hand a partner a live JSON endpoint. No BigQuery jobs API to poll, no service-account JSON to share, no GCP IAM roles to grant — just a governed, read-only BigQuery 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 BigQuery query into a partner-ready REST API endpoint — with per-recipient keys, read-only enforcement, and a full audit trail. You get a live BigQuery REST API without wiring up the BigQuery jobs API, sharing a service-account key, or granting GCP IAM. Learn more at QueryStreams.com and sign up for free to publish your first BigQuery endpoint in minutes.
Why expose a BigQuery dataset as a REST API?
Your analytics warehouse lives in BigQuery, and eventually someone outside your team needs a slice of it — a client wants their metrics in a dashboard, a vendor wants a live feed instead of a scheduled export, a partner’s app needs to read one well-shaped result set. The native options all cost you something. BigQuery’s own REST API works, but it means an OAuth2 service account, submitting jobs and polling for results, handling pagination, and managing GCP IAM. Granting a partner project access (or sharing a service-account JSON file) hands them far more reach than one report. A BigQuery REST API built for sharing is the clean version: the partner gets a URL and a token, not your Google Cloud project. Query Streams makes it a saved query plus a key.
No IAM or service-account JSON to share
Recipients never get a GCP role, a project invite, or a service-account key file. The Network Agent runs the query under your own read-only credentials; 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 any Google Cloud credentials.
Read-only by design
A read-only validator rejects any non-SELECT statement before it reaches BigQuery. 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 dataset, your project ID, or your table structure.
Nothing to host or patch
No jobs-API client, no Cloud Function gateway, no OAuth token-refresh code. The endpoint runs as a managed feature, so there is no deploy pipeline 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.
BigQuery data over REST — the usual ways, and why they hurt
There are real ways to put an HTTP surface on BigQuery, 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 | BigQuery jobs REST API (native) | Cloud Function / DIY gateway | Query Streams |
|---|---|---|---|
| What the recipient holds | OAuth client or service-account key | A URL into your function | A single-purpose key for one query |
| Surface exposed | Any SQL the credentials can run | Whatever you hand-code | One saved query, nothing else |
| Auth you set up | OAuth2 + IAM roles + jobs polling | Function auth + service account | Outbound-only Agent, read-only role |
| Per-recipient keys + revoke | Build it yourself | Build it yourself | Built in |
| Audit log of every call | Via Cloud Logging, 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 the BigQuery API for partner sharing?
BigQuery’s REST API is the right tool when you control both ends and want full programmatic access to your project. If instead you want to hand a named partner one governed, read-only result set — with its own key, an audit trail, and no IAM to grant — that is exactly the gap Query Streams fills. The two can coexist: the jobs API for your own pipelines, Query Streams for outbound sharing.
How Query Streams turns a BigQuery query into a REST API
Once the Network Agent is installed and your BigQuery 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 BigQuery through the Agent
Install the Network Agent and add a BigQuery connector with a read-only role (such as BigQuery Data Viewer plus Job User). The Agent makes an outbound TLS connection to Query Streams — no Google Cloud credentials ever reach a recipient.
Save a SQL query
Write the SELECT in the Query Builder against your BigQuery connection — GoogleSQL 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 bytes-scanned predictable
Because each endpoint runs one saved query, you control exactly how much data BigQuery scans per call. Select only the columns the partner needs, filter on partitioned or clustered columns, and the bytes-scanned cost stays small and predictable. Query Streams rate limits and byte quotas add a second ceiling on how often an endpoint can fire.
No shared project, no service-account keys in the wild
The security model is the reason teams reach for this instead of IAM grants or a service-account JSON. Your BigQuery 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 makes one outbound HTTPS connection to agent.querystreams.com on port 443 — 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 BigQuery. 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 bytes-scanned bill predictable.
Call your BigQuery 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 query 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 BigQuery 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 the rest of Query Streams. (BigQuery’s own bytes-scanned charges apply to the query as usual, which is why a tightly-scoped saved query matters.) how the byte allowance is metered →
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 BigQuery data directly, with nothing to install on their side and no Google Cloud SDK 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 across every BigQuery region
It does not matter which region or multi-region your BigQuery datasets live in. The Agent connects the same way whether your data is in the US, EU, or any regional location. For the lowest latency, deploy the Agent in a Google Cloud region close to your dataset; 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 BigQuery
The same workflow promotes a saved query from any connected database — PostgreSQL, SQL Server, MySQL, Snowflake, Oracle, DuckDB and more — to a REST endpoint. every database the API Platform exposes →
Frequently Asked Questions
Do I need to grant IAM or share a service-account key? +
Can the recipient see my SQL or my Google Cloud credentials? +
How is this different from BigQuery’s own REST API? +
What output formats can the API return? +
Accept header or a ?format= parameter. the wire formats and compression options →Will this run up my BigQuery bytes-scanned bill? +
Can an endpoint expire or self-destruct? +
Does the recipient need a Query Streams account? +
Get Started
Publish your first BigQuery REST API for free.
Sign up, install the Network Agent, connect BigQuery 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 Snowflake as a REST API | Connector Setup guides
Category: API Platform
Tags: bigquery-rest-api, bigquery, google-bigquery, rest-api, expose-bigquery-as-api, bigquery-api-integration, share-bigquery-data, per-recipient-keys, no-code-api, database-rest-api
Meta Description: Turn a BigQuery query into a secure, read-only REST API with per-recipient keys — no jobs API, no IAM, no service-account keys.
English 
Spanish 
German 
French 
Portuguese 
Japanese 
Korean 
Chinese 
Italian 
Dutch 
Indonesian 
Polish