FOR THE PEOPLE WHO HAND OUT ACCESS
Your workspace is already an API.
Every OpenX workspace has its own API from the day you connect data. The API Manager is where you decide who may call it and what each caller can reach.
New to OpenX? Key terms →
ONE API · THREE WAYS IN
- Team
- People's own keys
- App Identity
- Tokens from your own sign-in directory
- Hybrid
- Both, side by side
- access/me
- Any caller can ask what it is allowed
See what a key can reach before you make it.
ONE DOOR FOR EVERY CAPABILITY
Every capability, one API, your rules.
Three access modes, one switch
Team for people's keys, App Identity for tokens from your own directory, or Hybrid for both, once App Identity is set up.
Your directory, your rules
Apps call with a token from the workspace's own Microsoft Entra or Azure AD B2C directory, set up in App Identity.
Rights checked on the server
For people and jobs signing in through your directory, the rules you set in the API Manager decide what they reach, judged on the rights their access cards give and checked by the server on each call.
See the reach before you mint
Pick rights for a new key and see how many routes those rights reach before the key exists.
Every capability shows up
Saved warm queries appear under their own paths. Data stores appear by store and database. Routes for the licences you sell join as you set them up.
App secrets in your vault
App keys, relay passwords and Stripe keys are kept as references into your own Azure Key Vault.
IF AN ALL-ACCESS KEY IS YOUR CURRENT ANSWER
For teams that need to share data without sharing everything.
Platform and IT leads
Let apps and partners read plant, lab or business data without handing out a key that reaches all of it.
App teams
Know what a key can call while you are making it, not when the first call fails.
Security reviewers
App access tied to your own directory, rights from your own access cards, app secrets in your own vault.
Teams building with AI
An agent reads the same API as a person, through the OpenX MCP Server, within the rights it is given.
INSTEAD OF A GATEWAY PROJECT
Nothing to build before the first call.
Gateways, key services and spec tools each do part of this well. In OpenX the API is already there: every capability you turn on publishes its routes through the same door, under the same access modes.
- A warm query built today is an API route today, readable by Power BI, Grafana, your app or an AI.
- An AI connected through the OpenX MCP Server is a caller like any other.
- Access is set per caller across every OpenX capability, not per database.
INSTEAD OF A GATEWAY PROJECT
A gateway, a key service and a spec tool, already in one place.
| THE JOB | USUALLY DONE WITH | IN OPENX |
|---|---|---|
| Publish the API | An API gateway, such as Azure API Management or Kong | The workspace API exists from day one. Each capability publishes its routes into it. |
| Sign apps in | A directory, such as Microsoft Entra ID, Auth0 or Okta | Your own Entra or B2C directory, set up step by step in App Identity. |
| Issue and scope keys | A key or token service, set up for each product | Keys with expiry presets, and the routes their rights cover shown before you make one. |
| See what a caller can reach | A separate policy tool, or the request log after a call fails | The reach shows while the key is being made, and access/me answers at any time. |
| Keep app secrets | A secrets vault you wire in | Your own Azure Key Vault, kept by reference. |
| Let AI call it | An MCP server you add and govern separately | The OpenX MCP Server, reading the same API within the same rights. |
Each of these tools does its job well. Products named are examples from our research, not a feature-by-feature comparison.
FROM QUERY TO CALLER
Three ways teams open their data up.
Query to API to AI
- 01Build a warm query over live data.
- 02It appears under its own API path.
- 03Power BI and an AI assistant both read it.
Partner access without a shared key
- 01App Identity sets up your sign-in directory.
- 02The partner's app gets a token from it.
- 03Your API Manager rules, judged on its access card, decide what it reaches.
An agent with the right reach
- 01An AI connects through the OpenX MCP Server.
- 02It asks the API what it is allowed.
- 03It reads only the routes its rights cover.
WHO CALLS IT IN PRACTICE
The same answers, served to every caller.
MANUFACTURING
OEE and downtime queries served to MES dashboards and AI assistants.
LIFE SCIENCES
Lab and QA apps read only the routes your API Manager rules allow them.
ENERGY AND BUILDINGS
Meter and building cost-allocation queries over REST and MCP.
Open your data up. On your terms.
Connect data, save a query, and decide who may call it, all in one workspace.
GO DEEPER
MORE OF OPENX
AI governance →
Over MCP, AI proposes and a person accepts. Only a person deploys.
OpenX MCP Server →
A few tools let any MCP-capable AI read your workspace and propose changes to it.
Warm queries →
Save a question over live data and serve the answer to dashboards, apps and AI.
Provenance →
A record you can prove, kept in your own cloud, with corrections and signatures.
Your cloud →
Connect your Azure, build the landing zone, and the rest of OpenX runs inside it.
Databases →
A Cosmos DB store in your subscription, with a governed API for each container.
App Identity →
Your own sign-in directory, identities for your jobs, and access in one window.
Licenses →
Sell what you build on your own Stripe, and turn a subscription into a plan's rights.
IoT →
IoT Hub and Data Explorer in your Azure, feeding queries, APIs and AI.
Communications →
Send mail through your own relay, with the password in your vault and sends on record.
App building →
Data, sign-in, access, an API and billing: your app's backend, already there.