Core concepts
Organizations, apps, and the two planes — the model the rest of the documentation assumes.
Four ideas explain most of how Authoric is arranged. They are worth ten minutes now because every other page assumes them.
Organizations
An organization is who you are as a customer. It owns apps, holds the subscription, and has members — the people who sign in to the console.
Organizations appear twice, at two different levels, and keeping them apart matters:
- Your organization, in Authoric, containing your team.
- Your app's organizations, inside your app's own database, if your product has that concept for its own users.
They are unrelated. The second is just a table in your app that Authoric happens to provide because most multi-tenant products need one.
Apps
An app is one isolated database, with its own users, tables, policies, roles, handlers, storage, and agents.
Isolation is physical, not a filter on a shared table. Two apps cannot see each other's data because they are not in the same database. Deleting one has no effect on any other.
An app exists in two stages. It is created — a row, a name, an id — and later provisioned, which is when its database is actually built. Console sections that need the database stay disabled until provisioning finishes.
The two planes
This is the distinction that explains the shape of the API.
The control plane is how you configure Authoric: creating apps, defining tables, writing policies, setting up agents. You drive it through the console. Its API exists, but it is the console's own, and it is not part of the published contract.
The data plane is what your application calls at runtime: signing users in, reading and writing rows, uploading files, invoking agents. This is the API documented in the API Reference, and it is the one your code talks to.
Why the split matters
Configuration is a deliberate act by an administrator. Runtime is a high-volume path used by your software. Keeping them apart means a runtime credential can never reconfigure the system — an app token cannot create a table, no matter what it asks for.
Each capability in these docs is written in that order: what it is, how you set it up in the console, then how you use it from your application.
Principals
A principal is whoever is making a request. Authoric recognises several kinds:
| Principal | Signs in as | Typical use |
|---|---|---|
| App user | Your app's own end user | Your product's runtime traffic |
| Member | A person on your team | The console |
| Agent | An api key bound 1:1 to one agent | Automation and AI |
They differ in origin, not in treatment. Every one of them is authorized the same way, by policy, at the moment of the request. There is no path that skips the check because the caller is trusted — which is precisely what makes it safe to let an agent use the same API your application does.