Turn Governed Data into Governed APIs.
A native Databricks application. No code. Runs inside your workspace. Unity Catalog permissions are enforced for every caller, not just the builder.
Built on the Databricks ecosystem and open standards
One8Data is an independent product built on these platforms and open standards. Logos and names are used to describe compatibility only and do not imply partnership or endorsement.
Your governance disappears the moment data becomes an API.
Unity Catalog decides who can see what, down to the row and column. That decision doesn't survive the trip to a REST endpoint, unless you rebuild it by hand.
Without One8Data
- A developer hand-writes the API, endpoint by endpoint
- Permissions get duplicated into a second system
- A new backend service to deploy and patch
- A separate authentication layer to build and audit
- Ongoing maintenance nobody signed up for
- Access rules drift from Unity Catalog over time
With One8Data
- A dataset is metadata: tables, joins, columns
- Publishing is instant, with no redeploy
- The same Unity Catalog governance, carried through
- No backend service to host or operate
- No second permissions system to keep in sync
- Runs natively inside your own workspace
Unity Catalog already solved governance. APIs rebuild it from zero.
Unity Catalog governs who can query what, down to the row and column, inside Databricks. The moment that same data needs to reach something outside a notebook, that governance work starts over: a new service, a new auth layer, a new set of rules to keep in sync by hand.
Unity Catalog governs the lakehouse
Row- and column-level permissions, defined once, enforced everywhere inside Databricks.
Every table carries its own rules
Grants travel with the table. No separate permissions system to maintain.
Then an API request arrives
A partner, an app, a vendor. Something outside Databricks needs this data now.
Governance carries through, natively
One8Data extends Unity Catalog's own rules to the API layer. Nothing rebuilt.
Table to governed API. Faster than you'd guess.
We keep the exact mechanics for the call itself, but here's the shape of it: connect the tables you already govern, decide what's exposed, publish. No new service, no rebuilt permissions.
Connect
Point at the Unity Catalog tables you already govern. Nothing is copied out.
Configure
Choose what's exposed, filterable, and joined.
Publish
Live in minutes, governed exactly the way it always was.
What the dataset builder actually looks like
Tables, joins, columns, toggles, live preview. A real enterprise application, not a form wizard.
customers_360
regions
Join condition
Runs entirely inside your workspace
One8Data, Unity Catalog, the SQL Warehouse, and Lakebase all stay inside your Databricks workspace boundary. Nothing crosses out except the API response.
Why it is different
Other instant-API tools are either not native to Databricks, or native to a single database, and none carry Unity Catalog's own governance model through to the API.
| Competitive Positioning | Other Instant-API Tools | One8Data Databricks APIs |
|---|---|---|
| Native to Databricks / UC | No | Yes |
| Per-caller UC permissions | No (Postgres RLS only, at best) | Yes (OBO) |
| Runs in customer's own environment | Rarely - usually hosted | Yes |
| New Unity Catalog object to publish | N/A | None required |
One engine. Every capability.
No-Code Builder
Multi-table datasets, structured joins, per-column controls. No SQL editor, anywhere in the flow.
On-Behalf-Of Execution
Queries run as the caller's own identity.
API Keys
SHA-256 hashed at rest, shown once.
Generated SQL, Visible
Every response can include the exact SQL and bound parameters that ran. Nothing about the engine is a black box, ever.
Aggregation
Count, sum, avg, min, max, group-by.
Instant Publishing
Zero downtime. No redeploy, ever.
Metadata Driven
Publishing is a status flip, not a deploy.
Live Preview
A real, permissioned query against your warehouse, visible before anything is published.
Multi-Table Datasets
Join across tables with structured input.
Structural Security
Identifier whitelisting, bound parameters.
Postgres Support
Lakebase by default, or any external Postgres for the control plane.
Every request runs as the caller. Not a service account.
Most instant-API tools run every query as a single service identity, which means every caller sees the same data regardless of who they are. One8Data does something structurally different: when a caller's own Databricks token is present, the query executes as that caller, through the Statement Execution API, so Unity Catalog's row- and column-level grants apply exactly as they would inside Databricks itself.
Built to survive a security review
Identifier whitelisting
Every catalog, schema, table, column, and alias is validated against a strict regex before it's ever quoted into a query.
Bound parameters, always
Every user-supplied value, including inside dynamically built IN() clauses, is a native bound parameter. Never a string-interpolated value.
SHA-256 hashed keys
API keys are hashed at rest. The raw value is shown exactly once, at creation, and never again.
No SQL injection surface
Joins are built from structured input, never freeform SQL, even in the trusted builder UI.
Workspace isolation
Runs entirely inside your own Databricks workspace. One8Data is never a third party holding your data.
From backend project to published endpoint
Built for regulated, governance-heavy industries
Financial Services
Publish governed data to partners and internal risk systems without loosening Unity Catalog controls.
Healthcare
Row-level access follows the patient record wherever the API sends it.
Insurance
Underwriting and claims data exposed to partners under the same grants used internally.
Retail & E-commerce
Inventory and order data available to storefronts and vendors, without warehouse credentials handed out.
Technology
Product and usage data published as a stable contract for internal and partner integrations.
Manufacturing
Plant and supply-chain data reaches ERP and operational systems through one governed contract.
Every place governed data needs to go
Partner APIs
External partners consume a key-secured endpoint. No Databricks account required.
Internal Applications
Build against a stable REST contract instead of raw warehouse queries.
Customer Portals
Show each customer only their own governed slice of the data.
AI Agents
Give an agent a bounded, governed tool instead of open warehouse access.
BI Tools
Point dashboards at a governed endpoint instead of duplicating access rules.
Operational Systems
ERP and workflow tools call live data without a batch export step.
Embedded Analytics
Ship governed data views inside your own product's UI.
System-to-System
Two internal systems exchange governed data with an audit trail on every call.
The same endpoint, four ways to look at it
GET /api/v1/customers_360?region=APAC&sort=-lifetime_value&limit=2
Host: your-workspace.databricksapps.com
X-Api-Key: o8d_live_••••••••••••••
Authorization: Bearer {
"data": [
{
"customer_id": "C-10432",
"region": "APAC",
"tier": "Enterprise",
"lifetime_value": 184320.50
}
],
"count": 1284
}SELECT c.customer_id, c.region, c.tier, c.lifetime_value
FROM sales.gold.customers_360 c
LEFT JOIN sales.gold.regions r ON c.region_id = r.id
WHERE c.region = :region
ORDER BY c.lifetime_value DESC
LIMIT :limit
-- parameters: { region: "APAC", limit: 2 }$ curl "https://your-workspace.databricksapps.com/api/v1/customers_360?region=APAC&limit=2" \
-H "X-Api-Key: o8d_live_xxxxxxxxxxxx" \
-H "Authorization: Bearer $(databricks auth token)"Nothing here bypasses your platform team
Runs inside Databricks
A Databricks App, not a third-party host.
Governance preserved
Unity Catalog's own grants, per caller.
No duplicated auth
One permission model, not two to maintain.
No backend services
Nothing new to host, patch, or take down.
No deployment
Publishing is a metadata change, not a release.
Native architecture
Built for Databricks primitives specifically.
Questions platform teams actually ask
What is One8Data Databricks APIs?
A native Databricks application that turns Unity Catalog tables into no-code, governed REST APIs, published and consumed from inside your own workspace.
Is this a hosted SaaS product?
No. It installs and runs as a Databricks App inside your own workspace. One8Data never holds your data.
Do I need to write any code to publish an API?
No. Dataset creation, joins, filters, and publishing are all handled through the in-app builder.
Does this replace our API gateway?
No. It replaces the hand-written backend your gateway currently points at. Most customers keep their existing gateway in front of it.
Can I edit a dataset after publishing?
Yes. Editing replaces the dataset's tables and columns in one transaction, and the published API reflects the change immediately.
Does our data ever leave our Databricks workspace?
No. Every query runs live against your SQL Warehouse. Nothing is copied or cached outside your workspace.
Who can see what through a published API?
With on-behalf-of-user execution active, the query runs as the caller's own Databricks identity, so Unity Catalog's grants apply exactly as they would inside Databricks.
What happens if a caller has no Databricks identity?
The query falls back to the app's own service identity rather than failing the call, matching how the builder's own preview queries work.
Is the SQL query visible to anyone?
Only on request. Passing include_sql=true adds the exact SQL and bound parameters to the response.
How are API keys stored?
SHA-256 hashed at rest. The raw key is shown exactly once, at creation.
Is the query engine vulnerable to SQL injection?
Identifiers are whitelisted against a strict regex and every value is a native bound parameter. There is no string-built SQL anywhere in the engine.
Does publishing create a new Unity Catalog object?
No. Publishing flips a status flag and mints a key. No CREATE VIEW, no catalog-create privilege required.
Does a new API require an app restart?
No. A single dynamic route resolves and executes every published API at request time. Publishing is instant.
Can I join more than two tables?
Yes. Datasets support multiple tables with structured, alias-based join conditions.
Does it support aggregation, not just row-serving?
Yes. A parallel aggregate endpoint supports count, sum, avg, min, max, and group-by, sharing the same filters as the row endpoint.
Where does the control-plane metadata live?
Lakebase by default, or any external Postgres instance you already run.
Does it support writes or only reads?
Today's engine is read-only. Write and mutation support is on the roadmap.
Is there API versioning?
The route namespace reserves /api/v1/. Running multiple versions of one API side by side is on the roadmap.
Does this work on Databricks Free Edition?
Yes. The architecture was built and validated against Free Edition's constraints specifically.
What does installation involve?
A one-time bootstrap (Terraform apply, scope registration, a Databricks Apps stop/start cycle) followed by routine code-only deploys after that.
Can we run this across multiple workspaces?
Yes, each workspace runs its own instance. Multi-workspace rollout support is part of the Enterprise plan.
What does pricing look like?
Every plan runs natively inside your own workspace. Book a 30-minute architecture review and we'll recommend the right plan for your environment.
Is usage logged for audit purposes?
Yes. Every call, successful or not, is recorded in a usage log visible on the API's detail page.
Stop rebuilding APIs. Start publishing them.
A 30-minute architecture review. We'll look at your Unity Catalog setup and show you exactly what a published API would look like.