View Categories

How to Expose a Microsoft Access Database as a Secure REST API

13 min read

Microsoft Access logo MICROSOFT ACCESS REST API

Turn a Microsoft Access query into a secure REST API — no exports, no shared file.

Microsoft Access is a desktop, file-based database with no network API and no real way to share data safely with outsiders. Save a query against your .accdb file, mint a per-recipient API key, and hand a partner a live JSON endpoint — no Excel export to email, no .accdb file to copy onto a shared drive. Just a governed, read-only Microsoft Access REST API in minutes.

No file to share Per-recipient keys Read-only enforced Nothing to deploy

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

Why expose a Microsoft Access database as a REST API?

Plenty of real businesses still run on a Microsoft Access database — an inventory list, a job tracker, a customer ledger that has quietly done its job for years. It works, but it was never built to share data with the outside world. There is no network endpoint, no proper user accounts, and no safe way for a client, accountant, or vendor to read just the data they need. So the data goes out the only ways Access allows: someone exports an Excel file and emails it (stale the moment it sends), or the whole .accdb file gets dropped on a shared drive (now everyone can see everything, forever). A Microsoft Access REST API is the clean version of this — the partner gets a URL and a token for one specific query, not a copy of your database. Query Streams makes it a saved query plus a key, with nothing to code.

No file to email or share

Stop sending Excel exports and copies of the .accdb. The Network Agent reads your Access file locally and serves a live result — no copy of your data ever leaves your network.

Per-recipient API keys

Every recipient gets their own qsapi_* key. Revoke one without touching the others — no file to claw back, no shared password to change.

Read-only by design

The Agent opens Access read-only and a validator rejects any non-SELECT statement. There is no way for a recipient to edit, append to, or delete your records through the API.

Your data and file stay private

The recipient sees the endpoint URL, the JSON response, and any filters you exposed — never your other tables, your forms, or the .accdb file itself.

Nothing to build or patch

No VBA web service, no .NET middleware, no IIS site. The endpoint runs as a managed feature, so there is no code to write and no server to keep secure.

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 share Access data — and why they hurt

Most Access shops share data one of three ways, and each one gives away more than it should. Here is how those approaches compare to a Query Streams shared endpoint when the goal is simply “let a specific partner read a specific result set.”

Concern Email an Excel / CSV export Share the .accdb on a drive DIY VBA / .NET service Query Streams
Is the data live? No — stale the moment you send it Yes, but the whole file is exposed Yes Live on every call
What the recipient holds A full copy of the exported data A copy of your entire database A URL into your service A single-purpose key for one query
Data / schema exposure Whatever you exported Every table, query, and form Whatever you hand-code One saved query, nothing else
Per-recipient keys + revoke Impossible once sent Impossible once copied Build it yourself Built in
Audit log of every call None None Add it yourself Built in
Code / servers to maintain None None Yes, forever Managed for you

Keep using Access exactly as you do today

Nothing about your Access database changes. Your forms, reports, and macros stay put, and your team keeps working in Access as always. Query Streams simply adds a secure, read-only way for outside parties to pull a specific query — it sits beside your database, it does not replace it.

How Query Streams turns an Access query into a REST API

Once the Network Agent is installed on a Windows machine that can reach your Access file, 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

Point the Agent at your Access file

Install the Network Agent on a Windows machine that can reach your .accdb or .mdb file and add a Microsoft Access connector. The Agent uses the Access Database Engine to read the file and dials out over TLS — nothing is exposed to the internet.

2

Save a SQL query

Write the SELECT in the Query Builder against your Access connection — joins across tables, totals queries, 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 Access 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 file to share, no code to write

The security model is the reason teams reach for this instead of emailing a spreadsheet or sharing the database file. Your Access file never leaves its machine, and the path to it lives only inside the Agent’s configuration 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 dials out to agent.querystreams.com on port 443 — normal outgoing HTTPS, no inbound ports or VPN. how the outbound-only connection works →

Read-only enforcement

Access is opened read-only and a validator runs on your network before any statement executes. 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 Microsoft Access 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 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 Access-backed endpoint curl -H “Authorization: Bearer qsapi_K7…ZmQ” \ “https://api.querystreams.com/v1/endpoints/open-invoices?status=unpaid&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 plan and draws from the same monthly byte allowance as Excel, Google Sheets, and the MCP Server — Accept-Encoding: lz4 calls bill on the compressed bytes that moved. how byte-based billing works across surfaces →

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 Access data directly, with nothing to install on their side. 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 .accdb, .mdb, and network shares

It does not matter how old your Access database is or where it lives. The Agent connects the same way to a modern .accdb file or a legacy .mdb, whether it sits on a local disk, a shared network drive, or as the back-end of a split front-end/back-end setup. The Agent runs on Windows and uses the Microsoft Access Database Engine to read the file. For the lowest latency, run the Agent on or near the machine that holds the database; one Query Streams account can run multiple Agents across sites.

Outgrowing Access?

The same workflow promotes a saved query from PostgreSQL, Microsoft SQL Server, MySQL, MariaDB, SQLite, DuckDB, Snowflake, Oracle, or BigQuery to a REST endpoint. If you ever migrate your Access data to one of those, your endpoints move with it — the recipient’s URL and key stay the same. Browse the Connector Setup guides for the current list.

Frequently Asked Questions

Do I need to change my Access database or open a port? +
No. Your Access database stays exactly as it is — same forms, reports, and tables — and the Network Agent runs on a Windows machine that can reach the file, opens it read-only, and dials out to agent.querystreams.com on port 443 with no inbound port to open. why no firewall change is needed →
Does it work with both .accdb and older .mdb files? +
Yes. The Agent uses the Microsoft Access Database Engine to read modern .accdb files as well as legacy .mdb databases, whether on a local disk, a shared network drive, or as the back-end of a split application. It runs on Windows, where the Access Database Engine is available.
Can the recipient see my whole database or just the query? +
Just the one query. The recipient sees the endpoint URL, the response body, and any parameters you exposed as filters — never your other tables, your forms, or the .accdb file itself. Unlike sharing the file, no copy of your database ever lands on the recipient’s machine.
Can a recipient change or delete my Access data? +
No. The Agent opens Access read-only and a validator rejects any statement that is not a SELECT, so there is no way to edit, append to, or delete your records through the API. Your team keeps full edit access in Access as normal; the API is strictly read-only.
What output formats can the API return? +
JSON (default), CSV, and — on a streaming endpoint — NDJSON, chosen per call with the Accept header or a ?format= parameter, with optional LZ4 payload compression. the four wire formats and static vs streaming modes →
Can an endpoint expire or self-destruct? +
Yes. An endpoint can be permanent, set to expire on a date, or given a fixed call budget that stops working after a set number of requests — useful for a one-time data handoff to a client or auditor. You can also revoke any recipient’s key instantly from the Portal without affecting the others.
Does the recipient need a Query Streams account? +
No — a recipient invited by email gets a magic-link claim and an auto-created Free-tier key, or you can issue a service key for unattended machine-to-machine access. per-recipient keys vs service keys →

Get Started

Publish your first Microsoft Access REST API for free.

Sign up, install the Network Agent on a Windows machine that can reach your Access file, 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 | Expose SQLite as a REST API | Database REST API platform | Connector Setup guides

Category: API Platform

Tags: microsoft-access-rest-api, ms-access-api, access-database-api, rest-api, expose-access-as-api, share-access-data, accdb, per-recipient-keys, no-code-api, database-rest-api

Meta Description: Turn a Microsoft Access query into a secure, read-only REST API with per-recipient keys — no exports, no shared .accdb file, no code.

Updated on June 16, 2026

Powered by BetterDocs