Documentation

Security and access

Blobify access control is organization-based and space-aware.

Every member and API key is scoped by:

• role
• spaces

The permission model is intentionally simple so teams and automation use the same mental model.

Members

Members are scoped by:

• role
• spaces

API keys

An API key is created one of two ways:

• a role plus spaces, exactly like a member
• a scope: capability grants plus the spaces, models, and locales the key may touch

A scoped key is the safer choice for an integration, because each capability (read, write, publish, archive, delete, asset access, schema read) is granted independently and none of them implies another. Routes that carry no grant are refused for scoped keys whatever their grants say, which covers all schema and taxonomy writes, rebuilds, routing, webhooks, administration, and the danger routes. For the grant list, see Automation API.

High-level rules

Admin-only

• org settings
• S3 config
• invites
• member management
• dangerous org actions

Editor-or-higher

• content create, update, publish, unpublish, archive, restore, and permanent delete from the archive
• asset create, update, delete

Developer-or-admin required

• model and block changes
• schema import
• rebuild operations
• routing publish
• API key management
• webhook management

Notes

• Space-scoped routes validate the requested spaceId.
• API keys and members follow the same role and space model.
• Schema management is role-based through developer and admin.
• Viewer access is read-only. Content and asset mutations require editor or higher.
• The MCP server enforces the same scope as the REST API. A scoped key used as an MCP bearer has its grants, spaces, models, and locales checked on every tool call, and any tool whose REST equivalent carries no grant is denied. Only the two organization-discovery tools, listOrgs and listLocales, are always allowed, and for a scoped key listOrgs reports grants instead of a role. See MCP server.