An organization is the security, billing, credential, wallet, database, and workflow boundary in B3OS. Most resources belong to an organization and are evaluated against organization permissions.

Organization Resources

ResourceDescription
WorkflowsDrafts, live versions, runs, execution state, visibility, and templates
MembersHuman users with organization roles
API keysScoped machine credentials for REST API access
Service accountsNon-human identities for automation and backend access
ConnectorsEncrypted provider credentials and masked metadata
WalletsOrganization signing surfaces for EVM, Solana, and wallet-backed actions
DatabasesOrganization-scoped tables for workflow queries
KnowledgeOrganization context used by Caddie
RestrictionsOrganization policy and usage controls

Roles

RoleTypical access
ownerFull organization control, member management, billing-sensitive controls, workflow publishing, wallet withdrawal, restrictions, and all developer capabilities
developerBuild and operate workflows, read organization resources, use connectors and runs, manage many workflow resources, and execute most non-owner operations

API routes and app flows check permissions such as workflow read/update/execute/publish, connector read/create/update/delete, run read/cancel/stream, execution read/stream, database read/update, API key management, Caddie chat, and organization operations.

API Key Scopes

API keys are intended for backend services and automation.

ScopeUse
readRead organization, workflow, connector, run, execution, restriction, API key, and database state
read-writeCreate and update workflows, execute and publish workflows, manage connectors, cancel runs, use execution streams, send Caddie chat, manage API keys and service accounts, and update organization databases

Store newly created API keys in your secret manager. B3OS stores hashes and cannot show the raw key again.

Service Accounts

Use service accounts when a system, backend, or scheduled external job needs an identity distinct from a human user. Pair service accounts with narrow API key scopes and clear ownership.

Workflow Visibility

VisibilityUse
privateIndividual or restricted workflow authoring
orgTeam-visible workflows
public_viewPublic portfolio, demo, or reference workflow
public_executePublic workflow execution surface with constrained inputs

Operational Checklist

1

Create roles before inviting broadly

Keep initial access small until workflows, connectors, wallet policy, and API scopes are understood.

2

Use API keys for servers

Do not use personal browser sessions from backend services.

3

Review connector ownership

Rotate or remove connector credentials when provider access changes.

4

Separate public workflows

Keep public execution workflows narrow, validated, and isolated from broad internal automations.

5

Audit failed runs

Repeated failures can pause workflows and may indicate provider, schema, wallet, or CU issues.