Members, roles & API keys

Three kinds of access exist in a project, and they never blur:

Who	What they are	How they authenticate
Members	Teammates working in the dashboard	Session sign-in on your workspace
API keys	Your servers and scripts	`Authorization: Bearer esc_…`
End users	Your site's own customers	Auth schemas — a separate system entirely

The workspace owner (the account that created the workspace) bypasses roles and always holds every permission.

Members

Invite a teammate under Members with their email and a role. They receive an invitation email (through your mail integration) with a single-use link where they set their password; from then on they sign in at your workspace's project sign-in page. Invitations expire, can be re-sent, and a member can be removed at any time.

Roles and permissions

A role is a named set of permissions. Every project starts with an Administrator role holding everything; create leaner roles for editors, reviewers or integrators. The permission vocabulary:

Group	Permissions
Content	`content.read` `.create` `.update` `.delete` `.publish`
Schemas	`schemas.read` `.create` `.update` `.delete`
Media	`media.read` `.upload` `.delete`
Forms & events	`forms.read` `.create` `.update` `.delete`
Email	`emails.read` `emails.send` `emails.manage`
Endpoints	`endpoints.read` `.create` `.update` `.delete` `.invoke`
Members	`members.manage`

Two deliberate splits worth noting: **emails.send is separate from emails.read because sending uses your SMTP identity — someone who can read delivery logs cannot necessarily send as you; and endpoints.invoke is separate from endpoint management** so a credential can be allowed to call your APIs without being able to read or rewrite their logic.

Roles can also be scoped to specific schemas, restricting content access to a subset of your content types.

API keys

Under API keys, create a key with a name and a permission list. The secret (prefixed esc_) is shown once at creation and stored only as a hash — copy it then or re-issue. Use it from servers and scripts:

curl https://<workspace>/api/projects/<project>/schemas/<schema>/records \
  -H "Authorization: Bearer esc_…"

A key's reach is exactly its permission list — a read-only key gets 403 on writes, and a key without endpoints.invoke cannot call API-key endpoints.
Keys are project-scoped by construction (they live in the project's own database) and only work on your workspace's domain.
Each key records when it was last used; deactivate or delete revokes it immediately.
Never ship a key in browser JavaScript — anything public-facing should be a public or end-user endpoint instead.

Sensitive areas stay owner-only

Integration credentials (SMTP, S3, Redis) and the database connection are readable and writable only by the workspace owner — no role and no API key can reach them.