Now with AI-powered page building via MCP Server

Account

What your plan grants, which limits are enforced, and how roles decide who can do what.

A workspace has its own members and roles; its plan and limits come from the organization it belongs to. All three are readable programmatically, which makes them worth understanding rather than discovering at the wrong moment.

Plan and limits

The plan sits on the organization, never on a single workspace, and usage is pooled across every workspace that organization owns - adding a workspace does not add a quota. get_workspace_info reports the plan and ceilings that apply to a workspace, which is to say its organization's:

{
  "name": "Acme",
  "slug": "acme",
  "plan": "enterprise",
  "limits": {
    "maxPages": 999999,
    "maxMembers": 999999,
    "maxWorkspaces": 999999,
    "maxStorageMb": 999999,
    "maxAiTokensMonth": 999999,
    "maxApiRequestsMonth": 999999999,
    "maxBandwidthGbMonth": 999999,
    "canRemoveBranding": true,
    "canUseCart": true
  }
}

Those numbers come from an enterprise organization, where the ceilings are set high enough to be effectively unlimited. Smaller plans return real figures - which is the point of reading them rather than hard-coding an assumption. Read them as shared: a second workspace draws on the same allowance, not on a fresh one.

Two kinds of thing live in there. Ceilings - pages, members, storage, AI tokens, API requests, bandwidth - are quantities you can exhaust. Capability flags - canRemoveBranding, canUseCart - are features that are either on or off.

Read them rather than assuming. A build step that creates pages, or a script that uploads media in bulk, should know the ceiling it is working under.

The delivery limit fails in a confusing way

Exceed the monthly delivery allowance and public.siteConfig stops answering. Your site then behaves exactly as if the workspace slug were wrong or the network were down.

This is why cmssy link's preflight distinguishes the three cases instead of reporting one "cannot reach workspace". If your site suddenly cannot fetch anything and nothing changed in your config, check usage before you check DNS.

Roles

Permissions are namespaced resource:action - pages:view, media:upload, forms:submissions:manage, workspace:billing. A role is a named bundle of them.

Roles carry two flags worth knowing:

  • isSystem - built in and not editable. Owner is the system role, and it holds *: every permission, including future ones. That wildcard is the point - a new feature does not need the owner's role updated.
  • isDefault - the role new members receive. Set it deliberately; whatever it holds is what an invitation grants before anyone reviews it.

Staff roles and member roles are different things

A workspace can hold a role with no permissions at all - typically named something like Customer. That is not a misconfiguration.

Site members who sign in to your public site are separate from the people who edit it. A member role exists to label and group those visitors; it grants nothing in the workspace because a customer of your shop has no business in your CMS. Staff roles grant workspace permissions; member roles identify audiences.

Confusing the two is how a customer role quietly acquires pages:edit.

Granularity is deliberate

The permission list separates things you might expect together. pages:edit and pages:publish are distinct - you can let someone write without letting them ship. forms:view and forms:submissions:view are distinct - building a contact form does not require reading what people submitted through it.

Take the split seriously when composing roles. The default temptation is to hand out whole namespaces, and the moment you do, "can edit copy" and "can read customer messages" become the same grant.

Next steps