ORACLE
REST API
Turn an Oracle query into a secure REST API — no ORDS to stand up, no port to open.
Save a SQL query against your Oracle database, mint a per-recipient API key, and hand a partner a live JSON endpoint. No Oracle REST Data Services to install, no open 1521 listener, no shared schema login — just a governed, read-only Oracle 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 Oracle query into a partner-ready REST API endpoint — with per-recipient keys, read-only enforcement, and a full audit trail. You get a live Oracle REST API without installing Oracle REST Data Services, opening the listener port, or hosting a gateway. Learn more at QueryStreams.com and sign up for free to publish your first Oracle endpoint in minutes.
Why expose an Oracle database as a REST API?
Mission-critical data sits in Oracle, and eventually someone outside your team needs a slice of it — a client wants their figures in a dashboard, a vendor wants a live feed instead of a nightly extract, an auditor needs a specific result set. The usual answers all leak something. You email exports that are stale on arrival, you hand out a read-only schema login that outlives the engagement, or you stand up Oracle REST Data Services (ORDS) and inherit a Java middle tier to deploy, secure, patch, and keep reachable from the database. An Oracle 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 Oracle listener
You never expose the 1521 listener 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 Oracle schema password.
Read-only by design
A read-only validator rejects any non-SELECT statement before it reaches Oracle. 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, schema, service name, or connection string.
No ORDS to host or patch
No ORDS middle tier, no WebLogic or standalone Jetty, 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 Oracle — and why they hurt
There are well-known tools for this, and they are good at what they do. The catch is that every one of them leaves you owning a middle tier, 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 | Oracle REST Data Services (ORDS) | DIY .NET / Java service | Query Streams |
|---|---|---|---|
| Database reachable from the API | Middle tier must reach the listener | Must reach Oracle | Outbound-only Agent — no inbound port |
| What the recipient holds | A URL into your ORDS-enabled schema | A URL into your service | A single-purpose key for one query |
| Schema exposure | Whatever you REST-enable, often broad | Whatever you hand-code | One saved query, nothing else |
| Per-recipient keys + revoke | OAuth roles to configure | Build it yourself | Built in |
| Audit log of every call | Configure + retain yourself | Add it yourself | Built in |
| You operate / patch / rotate TLS | Yes — the ORDS tier, forever | Yes, forever | Managed for you |
| Time to first endpoint | Hours to days (install + enable) | Days | Minutes |
Looking for an ORDS alternative for partner sharing?
Oracle REST Data Services is excellent when you want a full, self-hosted REST surface over your own schema and you are happy to run the middle tier. If instead you want to hand a named partner one governed, read-only result set — with its own key, an audit trail, and nothing to deploy — that is exactly the gap Query Streams fills. The two can coexist: ORDS for your internal apps, Query Streams for outbound sharing.
How Query Streams turns an Oracle query into a REST API
Once the Network Agent is installed and your Oracle 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 Oracle through the Agent
Install the Network Agent next to your database and add an Oracle connector with a standard read-only schema. The Agent makes an outbound TLS connection to Query Streams — your listener is never exposed to the internet.
Save a SQL query
Write the SELECT in the Query Builder against your Oracle connection — JOINs, analytic functions, and bind 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.
Great for EBS and EPM reporting data
If your reporting lives in an Oracle E-Business Suite or EPM schema, a saved query over the right views becomes a partner-ready endpoint without giving anyone access to the application. You shape exactly the columns and rows they should see, and share that — not the schema.
No open listener, no shared credentials
The security model is the reason teams reach for this instead of a public listener or a self-hosted ORDS tier. Your Oracle schema 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 dials out 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 Oracle. 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 Oracle 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 bind variables, 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. 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 part of every plan and draws from the same monthly byte allowance as Excel, Google Sheets, and the MCP Server — an lz4 call bills on compressed bytes, otherwise on uncompressed. how the shared byte allowance works →
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 Oracle data directly, with nothing to install on their side and no Oracle client 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 with Autonomous Database and managed Oracle too
It does not matter where your Oracle runs. The Agent connects the same way to an on-premise database, Oracle Real Application Clusters, Oracle Autonomous Database on OCI, or Amazon RDS for Oracle. 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.
More than Oracle
The same workflow promotes a saved query from PostgreSQL, Microsoft SQL Server, MySQL, MariaDB, SQLite, Microsoft Access, Snowflake, BigQuery, or DuckDB to a REST endpoint. Oracle 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 install ORDS or open a port to expose Oracle? +
1521 listener — the Network Agent makes an outbound TLS connection and inbound requests ride back down it, so there is no middle tier and no inbound firewall rule. the outbound-only agent model in detail →Can the recipient see my SQL or my database credentials? +
How is this different from Oracle REST Data Services (ORDS)? +
What output formats can the API return? +
Accept header or ?format=, with optional LZ4 payload compression. all the wire formats and how they bill →Can recipients filter the results, or do they get a fixed query? +
GET, JSON body on POST), bound as a bind variable so filters cannot inject SQL. how exposed filter parameters work →Can an endpoint expire or self-destruct? +
Does it work with Autonomous Database, RAC, or Amazon RDS for Oracle? +
Does the recipient need a Query Streams account? +
Get Started
Publish your first Oracle REST API for free.
Sign up, install the Network Agent next to your Oracle 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 PostgreSQL as a REST API | Connector Setup guides
Category: API Platform
Tags: oracle-rest-api, oracle, oracle-database, ords-alternative, rest-api, expose-oracle-as-api, share-oracle-data, per-recipient-keys, no-code-api, database-rest-api
Meta Description: Turn an Oracle query into a secure, read-only REST API with per-recipient keys — no ORDS, no open listener, no code.
English 
Spanish 
German 
French 
Portuguese 
Japanese 
Korean 
Chinese 
Italian 
Dutch 
Indonesian 
Polish