Three nouns carry most of the model: an org, a workspace (tenant), and the two tiers every feature has — define and run.

Org

An org is your account on nostackai. It owns your API definitions, settings, members, and billing plan. Every API path is scoped to your org code, e.g. /app/{orgCode}/.... When you sign up you become the org's first org_admin.

Workspace (tenant)

Your deployed app's end-users are partitioned into workspaces (called *tenants* internally) — isolated data spaces. You choose a tenancy model for your app:

  • single — all app users share one default workspace. No workspace UI needed.
  • multi — users are invited to a workspace, or create/join one after signup. Full isolation per workspace.

Data isolation

Entity records live under a partition key of org#{orgCode}-{tenantCode}. One org's two workspaces never see each other's data — the runtime scopes every query to the caller's workspace automatically.

The define tier — API Studio

As a developer you work in API Studio (the apistudio gateway). Here you author entities, logic blocks, events, and settings. These are management APIs guarded by your org role (org_admin or developer).

http 
POST   /api/create-{entity}     define an entity
GET    /api/entities            list your entities
POST   /api/event               attach an automation
PUT    /org/settings            org configuration

The run tier — the app gateway

Your app's users hit the app gateway at /app/{orgCode}/.... These are the live data APIs — CRUD, list, and your custom logic blocks — guarded by tenant ACL.

http 
POST   /app/{orgCode}/create/{entity}
GET    /app/{orgCode}/list/{entity}
POST   /app/{orgCode}/logicblocks/{apiname}

They never mix

The define tier and run tier use different gateways, authorizers, and tables. Org-role checks guard what you can *build*; tenant ACL guards what your app users can *access*.

Test and production

Each org gets a test environment at signup and a production environment on demand. You build and iterate in test, then publish your config (entities, logic blocks, events, settings) to prod. App data is never deployed — only configuration moves.

1Build and test everything in the test environment.
2Open the Deploy view to diff test against prod.
3Publish selected items — they land as staged, then activate to go live.
4Roll back in one step if needed.

Production is read-only in the console

When you switch the console to the prod environment you can inspect what's live but not edit it. Changes are made in test and deployed — this keeps prod changes intentional and reviewable.