View Categories

How to Expose a MySQL Database as a Secure REST API

11 min read

MySQL logo MYSQL REST API

Turn a MySQL query into a secure REST API — no Express app, no server to host.

Save a SQL query against your MySQL database, mint a per-recipient API key, and hand a partner a live JSON endpoint. No PHP or Node service to build, no open 3306 port, no shared credentials — just a governed, read-only MySQL REST API in minutes.

No inbound ports Per-recipient keys Read-only enforced Nothing to deploy

Query Streams is a secure, real-time database integration platform that turns any saved MySQL query into a partner-ready REST API endpoint — with per-recipient keys, read-only enforcement, and a full audit trail. You get a live MySQL REST API without writing a backend, opening a database port, or hosting a gateway. Learn more at QueryStreams.com and sign up for free to publish your first MySQL endpoint in minutes.

Why expose a MySQL database as a REST API?

Sooner or later, someone outside your team needs data that lives in MySQL — a client wants their numbers in a dashboard, a vendor wants a live feed instead of a nightly CSV, a partner’s app needs to read a slice of your tables. The usual answers all leak something. You email exports that are stale on arrival, you hand out a read-only MySQL user that outlives the engagement, or you spin up a small PHP or Node service and inherit its auth, TLS, and patching forever. A MySQL REST API is the clean version — the partner gets a URL and a token, not your database. The hard part has always been building and operating that API safely. Query Streams makes it a saved query plus a key.

No open MySQL port

You never expose 3306 to the internet or poke a hole in your firewall. The Network Agent dials out; inbound calls ride back down that one outbound connection.

Per-recipient API keys

Every recipient gets their own qsapi_* key. Revoke one without touching the others, and without rotating your MySQL user’s password.

Read-only by design

A read-only validator rejects any non-SELECT statement before it reaches MySQL. There is no accidental UPDATE, DELETE, 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, schema, hostname, or connection string.

Nothing to host or patch

No Express app, no Laravel API, no reverse proxy. The endpoint runs as a managed feature, so there is no deploy pipeline or TLS rotation 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.

The usual ways to put a REST API on MySQL — and why they hurt

There are well-known ways to put an HTTP layer on MySQL, and they are fine for what they do. The catch is that every one of them leaves you owning a backend, a network exposure, or both. 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 DIY PHP / Node / Laravel API Auto-API tool (self-hosted) Query Streams
Database reachable from the API Must reach MySQL Must reach MySQL (often a public port) Outbound-only Agent — no inbound port
What the recipient holds A URL into your service A URL into your schema A single-purpose key for one query
Schema exposure Whatever you hand-code Whole schema exposed by default One saved query, nothing else
Per-recipient keys + revoke Build it yourself Build it yourself Built in
Audit log of every call Add it yourself Add it yourself Built in
You operate / patch / rotate TLS Yes, forever Yes, forever Managed for you
Time to first endpoint Days Hours to days Minutes

Don’t want to build and babysit a backend?

A hand-rolled API server is the most flexible option when you need complex business logic. But if you simply want to hand a named partner one governed, read-only result set — with its own key, an audit trail, and no service to run — that is exactly the gap Query Streams fills. Build the backend when you truly need one; use Query Streams when the job is “share this query, safely.”

How Query Streams turns a MySQL query into a REST API

Once the Network Agent is installed and your MySQL 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.

1

Connect MySQL through the Agent

Install the Network Agent next to your database and add a MySQL connector with a standard read-only user. The Agent makes an outbound TLS connection to Query Streams — your database is never exposed to the internet.

2

Save a SQL query

Write the SELECT in the Query Builder against your MySQL connection — JOINs, subqueries, and parameters all welcome. Name it and save. Anything you can SELECT can become an endpoint.

3

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.

One saved query, many surfaces

The same saved MySQL query can drive an Excel refresh, a Google Sheets sidebar, a Claude or Cursor conversation through the MCP Server, and a partner-facing REST endpoint at the same time. You build the query once; Query Streams handles the surfaces.

No open MySQL port, no shared credentials

The security model is the reason teams reach for this instead of a public database port. Your MySQL password lives only inside the Agent’s encrypted credential store on your network; it is 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 connects out to agent.querystreams.com on port 443. Your firewall sees normal outgoing HTTPS — no inbound ports, no VPN, no tunnel.

Read-only enforcement

A validator runs in the Agent, on your network, before any statement reaches MySQL. 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 or runaway recipient inside a safe blast radius.

Call your MySQL 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 prepared-statement parameters, never string concatenation, so a recipient cannot break out of a filter to inject SQL.

GET with a filter parameter
# Recipient call against your MySQL-backed endpoint curl -H “Authorization: Bearer qsapi_K7…ZmQ” \ “https://api.querystreams.com/v1/endpoints/orders-today?warehouse=US-EAST&since=2026-01-01”

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. 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 Query Streams plan — no separate subscription — and draws from the same monthly byte allowance that powers Excel, Google Sheets, and the MCP Server. how byte-based billing and LZ4 compression are counted →

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 MySQL data directly, with nothing to install on their side and no MySQL 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.)

Microsoft Power Query logo Power Query Get Data → From Web, paste the URL and bearer token, expand the JSON to a refreshable table
Microsoft Power BI logo Power BI Same Power Query engine — load the endpoint straight into your model and schedule refresh
Tableau logo Tableau Point a Web Data Connector or JSON source at the endpoint for live dashboards
Postman logo 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 with Amazon RDS, Cloud SQL, and PlanetScale too

It does not matter where your MySQL runs. The Agent connects the same way to an on-premise server or a managed service — Amazon RDS and Aurora MySQL, Azure Database for MySQL, Google Cloud SQL for MySQL, or PlanetScale. For the lowest latency, deploy the Agent in the same network or region as the database; one Query Streams account can run multiple Agents across regions and clouds, and a single endpoint behaves identically regardless of which Agent serves it.

Using MariaDB?

The same connector serves MariaDB, which shares the MySQL wire protocol. If your database is MariaDB, follow the dedicated Expose a MariaDB database as a REST API guide — the workflow is identical. The same approach also covers PostgreSQL, Microsoft SQL Server, SQLite, Microsoft Access, Snowflake, Oracle, BigQuery, and DuckDB; browse the Connector Setup guides for the current list.

Frequently Asked Questions

Do I need to open a port or expose MySQL to the internet? +
No — the Network Agent dials out over TLS on port 443, so inbound calls ride back down that one connection and your MySQL port (3306 by default) is never exposed. how the outbound-only connection works →
Can the recipient see my SQL or my database credentials? +
Never — recipients see only the endpoint URL, the response, and the filters you exposed, while your MySQL password stays in the Agent’s encrypted credential store on your network. what stays private vs. what a recipient sees →
Do I have to build a backend to get a MySQL REST API? +
No — instead of writing and hosting a PHP, Node, or Laravel service, you save a SQL query and promote it to an endpoint, and Query Streams supplies the auth, TLS, rate limiting, audit log, and per-recipient keys. why there’s no backend to build or patch →
What output formats can the API return? +
JSON (a single array, the default), CSV (RFC 4180), and — on a streaming endpoint — NDJSON, chosen per call with the Accept header or a ?format= parameter, with optional LZ4 payload compression. the wire formats and compression options →
Can recipients filter the results, or do they get a fixed query? +
You decide — any parameter you expose becomes a per-call filter (GET querystring or POST JSON body) that the Agent binds as a prepared-statement parameter, so filters can’t be used to inject SQL. how exposed parameters and SQL-injection safety work →
Can an endpoint expire or self-destruct? +
Yes — an endpoint can be permanent, expire on a date, or carry a fixed call budget that self-destructs after a set number of requests, and you can revoke any recipient’s key instantly without rotating your database password. endpoint lifetimes and per-recipient key controls →
Does it work with Amazon RDS, Cloud SQL, or PlanetScale? +
Yes. The Agent connects to any reachable MySQL, whether on-premise or managed — Amazon RDS and Aurora MySQL, Azure Database for MySQL, Google Cloud SQL for MySQL, and PlanetScale all work. For best latency, run the Agent in the same region as the database; one account can run multiple Agents across clouds and regions.
Does the recipient need a Query Streams account? +
Sharing by email is recommended — the recipient gets a magic-link claim and a Free-tier org is auto-created when they accept — or you can issue a service key for unattended machine-to-machine access. recipient claims vs. service keys →

Get Started

Publish your first MySQL REST API for free.

Sign up, install the Network Agent next to your MySQL database, 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 MariaDB as a REST API | Connector Setup guides

Category: API Platform

Tags: mysql-rest-api, mysql, rest-api, expose-mysql-as-api, mysql-api-no-code, share-mysql-data, per-recipient-keys, no-code-api, database-rest-api

Meta Description: Turn a MySQL query into a secure, read-only REST API with per-recipient keys — no Express app, no open port, no code.

Updated on June 16, 2026

Powered by BetterDocs