Managing API/WebUI Permissions Within a Team
In the NocodilySuite console, you can set per-member permissions for each API and WebUI you build.
By assigning permissions to match your team or department structure, you can appropriately control who can view specifications and who can make changes.
Two Permission Levels
| Permission | What It Allows |
|---|---|
| Edit | Create APIs/WebUIs, modify schemas and settings, run upgrades and rollbacks |
| View | Read-only access to API/WebUI specs, settings, and OpenAPI documents. No write operations |
Why Separate Permissions
In the NocodilySuite console, you can view the specs, schemas, and OpenAPI documents of built APIs.
Sharing this information across teams lets the teams that consume APIs look up specs themselves.
On the other hand, if everyone is granted edit access, unintended schema changes or misconfigurations can affect production.
Separating "view the spec" from "change the app" is the foundation of safe operations.
Applying This to Department and Team Structure
Designing permissions around your organization's structure keeps order even when multiple teams are involved.
Example: Separating Dev and Business Teams
Dev team → Edit (responsible for schema design, API building, and upgrades)
Business team → View (use for spec review, OpenAPI reference, and integration planning)
- The business team can check API specs themselves, reducing questions to the dev team
- Only the dev team can make changes, preventing unintended configuration edits
Example: Per-Department App Management
Team A → Edit on Team A's APIs/WebUIs
Team B → View on Team A's APIs/WebUIs (to check specs for integration planning)
- Each team can reference other teams' specs for integration design
- Each team manages its own apps; changes from other teams are not permitted
Use Cases
| Scenario | How to Apply |
|---|---|
| Sharing internal API specs | Grant View permission to non-developer team members to use as specification documentation |
| Integration with external partners | Grant View to the partner team so they can check the OpenAPI spec themselves |
| API reuse across departments | Reference another department's API spec and connect it to your team's WebUI |
| Governance through access restriction | Limit production-impacting operations to designated owners, reducing the risk of accidental changes |