Permissions & scopes

Scopes are declared in your catalog entry and granted verbatim at install — never taken from a request at runtime. If it isn’t in your listing, your app can’t read it, and adding a scope later means the listing (and what the customer agreed to) changes.

Read scopes

Scope	Grants
`projects.read`	The workspace’s projects
`photos.read`	The photos on those projects
`clients.read`	Client records
`inventory.read`	Inventory items

Writes are deliberately narrow: today an integration writes only into the destination the customer connected (their folder), plus the activity events attributed to it. A general status write-API is on the roadmap alongside community submissions.

The store spells out every scope in the customer’s words, next to the Install button — not behind a link, not only in a dialog:

Read your projects projects.read Read the photos on your projects photos.read

Both forms are shown on purpose: the sentence is for the person deciding; the raw string is for whoever pastes it into a config. Your listing also states the write behavior plainly, e.g.:

Installing connects the integration. It reads your projects and photos, and writes copies into the folder you authorize. It can also remove those copies when photos are deleted in Stageory. It never changes anything else.

Write your app’s consent copy to that standard — say exactly what it reads, exactly where it writes, and what it will never touch.

Enforcement

The UI bridge’s fetch proxy only allows endpoints scoped to your app; everything else is refused page-side.
Sync-side reads run under the installation’s granted scopes.
Uninstall revokes: destination tokens are revoked at the provider and the installation is retired — see Lifecycle.