The Studio and the Runtime
gtable has two planes. Builders define apps in the Studio; invited people use them in their suite's Runtime. Each plane has its own API, MCP server and credentials.
gtable is two products built on one definition. The Studio is where an app is designed. The Runtime is where the people invited into it use it. The app’s definition lives beside its data, so a published app keeps working without the Studio.
Organisations, suites and apps
organisation who pays and who builds builders sign in at studio.gtable.app
└── suite a set of apps with ONE login acme.gtable.app, or your own domain
└── app tables, permission rules, pages acme.gtable.app/crmA suite is a login boundary: its apps share one directory of people, one sign-in page and
one address. The same person in two suites is two accounts. An app lives under its suite’s
address at its own path, so the CRM of the suite acme is https://acme.gtable.app/crm.
The two planes
| Studio (builder plane) | Runtime (app plane) | |
|---|---|---|
| Who | builders of an organisation | people invited into a suite’s apps |
| Signs in at | studio.gtable.app | the suite’s own address |
| REST | https://studio.gtable.app/v1 | https://{suite}.gtable.app/{app}/v1 |
| OpenAPI | one public document, the same for everyone | one per app and per person, generated on request |
| MCP | https://studio.gtable.app/mcp | https://{suite}.gtable.app/mcp, plus /{app}/mcp for one app |
| Credentials | builder keys and OAuth grants | personal keys and OAuth grants, per suite |
The planes are a wall, not a filter. A key made in an app is not a weaker builder key: the
Studio does not recognise it at all (401), and the reverse is true too. An app credential can
never be granted a builder scope such as schema:write, so no consent screen can even offer an
end user’s agent the power to change an app’s structure.
A builder is not automatically a member of their own apps. The Studio reaches every record of
an app through its own routes (/v1/apps/{appId}/tables/{tableId}/records), with every write
recorded under the builder’s name. Inside the app’s Runtime, a builder is a person like any
other, and sees what their groups give them.
Why an app has an API of its own
Every app answers its own API under its own path, and that API is shaped like the person calling it:
GET /{app}/v1/openapi.jsonis generated on each request from the schema you can see: your tables, and only the fields you can read. A table you cannot open is not in the document.- The MCP tools you receive are built the same way.
tableIdis a closed list of your tables, and a record is typed with your readable fields only. - A suite on its own domain serves the same paths there, with no
gtable.appin them:https://portal.example.com/crm/v1.
That is why the App API reference on this site is a generic
contract: the operations and their shapes, with no table or field named. Your real document
is at https://{suite}.gtable.app/{app}/v1/openapi.json, behind your credential, and there is
no anonymous version of it.
The Studio’s Builder API is the opposite case: it describes the
platform, not anybody’s data, so its document is public at
https://studio.gtable.app/v1/openapi.json and is the same for every reader.
One MCP server per suite
A suite answers MCP at https://{suite}.gtable.app/mcp, one address for every app of the suite
you belong to. Its first tool, apps_list, tells an agent which apps it can reach, and every
app tool takes an appId. Adding an app to the suite does not make anybody reconfigure their
client. https://{suite}.gtable.app/{app}/mcp serves a single app, which is the right address
for an integration that must touch that app and nothing else. See
MCP servers.