Permissions

Cloud checks the credential type, API-key scopes, and the caller's account membership or role to decide whether an operation is allowed. Authentication establishes the caller's identity.

Operations

Operation	Requirement
Read public service documentation, listings, templates, catalog or deployment metadata	No credential; private service information requires authorized access
Read GET /user, GET /users/{user} or GET /orgs/{org}	A valid session
Create or change API keys and permissions; manage personal identity or security; create an organization; approve requests; perform interactive payment actions	A valid session and the operation's account role
Read or change resources through a key	The matching management scope and account role; write includes read for that resource
Create or rotate secret resources, or change their service grants	A valid session and the operation's account role
Delete resources, remove memberships or revoke invitations	A valid session and the operation's account role
Call a tool over REST or MCP	A session or API key; the service's visibility, tool access and any priced-service grant must allow it
Call a tool through an app	The registered app and its user identity, or anonymous access when both app and tool allow it
Deliver a webhook	Its signing secret and a valid signature; no user session

Organization operations require the appropriate membership role. A key bound to an organization cannot use its permissions on a different account. Direct deployment has additional requirements described in Deploying.

Named account profiles require a session, including fields other signed-in people can read. Organization profiles include private plan and membership fields only for members; another person's profile contains no email address. See Account profiles and IDs for the endpoints and response fields.

Management scopes

Each write scope includes read access for its resource. A read scope never grants writes. Scopes do not replace account membership and role checks, or permit an API key to perform session-only actions. A key's creator must still hold the required organization role on each request.

Resource	Read scope	Write scope
Services	services:read	services:write
Deployments	deployments:read	deployments:write
Calls	calls:read	—
Logs	logs:read	—
Usage	usage:read	—
Billing	billing:read	—
Earnings	earnings:read	—
Apps	apps:read	apps:write
Organization	orgs:read	orgs:write
Members	members:read	members:write
Invitations	invites:read	invites:write
Teams	teams:read	teams:write
API keys	keys:read	—
Secret resource metadata and grants	secrets:read	—
Alerts	alerts:read	alerts:write

A tool call needs no management scope. Keys issued to MCP connectors have no management scopes and can call tools. Calling another account's priced tool requires the key's service grant.

Apps and tool access

An app request must come from one of its registered origins and name one of its registered services. The app's account must be allowed to reach that service. Anonymous calls require both an app that admits anonymous users and a tool with access = "anonymous".

Service visibility and each tool's access setting determine which callers can reach it. These rules also apply to the service's owners. See Access.

Public access and request codes

Login initiation, OAuth discovery and token exchange do not require an existing session. Public reads return only information visible to that caller.

A request code permits only the actions recorded for it. Signing in a device or approving a deployment still requires a person signed in. Public endpoints also have request limits.

Denied access

A valid credential that lacks the required scope, role or credential type receives 403. An API key on a session-only profile endpoint receives this response.

A private service is hidden from callers who cannot access it and receives 404, as does a service that does not exist.