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 an org developer you work in API Studio. Here you define the shape of your data — your entities — and attach automations to them. Logic Blocks, Agents, Connectors and Tenant Management have their own sections in the console. What you can do is 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 — your app's endpoint

Your app's users call the endpoint nostackai provides for your app, 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 the run tier are kept completely separate. 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.