Team Members

Invite collaborators to a tenant or project, assign roles, and manage who can do what. Team members are the people on your team — engineers, editors, agency partners — who sign in to the admin app or use the CLI. They are not the end-users of your storefront; for end-user accounts see Customer Authentication.

Overview

A tenant is the top-level workspace that owns one or more projects. Every team member is invited to a tenant and granted a role; that role determines what they can see and change inside each project under the tenant.

A single user can hold different roles in different projects under the same tenant — invite an agency partner as Editor on one project and Viewer on another.

In the admin

Inviting a member

1. Navigate to Workspace → Members.
2. Click Invite member.
3. Enter their email and pick a role (Tenant Owner / Project Admin / Project Editor / Project Viewer).
4. Click Send invite. The invitee receives an email with an accept link.

Invitations expire after seven days. Pending invites appear in the Members list with a Pending badge — you can resend, copy the accept link, or revoke from there.

Managing existing members

From Workspace → Members:

• Change a role — click the role dropdown next to a member. The new role applies immediately.
• Revoke access — click Remove. The member loses access on the next request; their existing API tokens are not invalidated (they’re personal-use tokens issued at signin, not portable).
• Transfer ownership — Tenant Owners can promote another member to Tenant Owner. There can be more than one owner; demote yourself only after promoting someone else.

Reviewing invitations

Pending invites are listed under Workspace → Members → Pending. Each shows:

• Email
• Role
• Sent date
• Status (Pending, Expired, Revoked, Accepted)

Use Resend to re-send the email (useful if it landed in spam) or Revoke to cancel an outstanding invitation.

Via the API

Member management is exposed via GraphQL — usable from CI scripts, automation, or your own internal tools. All mutations require an admin Bearer token (a Tenant Owner or Project Admin session, depending on the action) — API keys cannot manage members.

List members

query Members {
  members {
    items {
      id
      email
      role
      acceptedAt
    }
    total
  }
}

List pending invitations

query Invitations {
  invitations(status: PENDING) {
    items {
      id
      email
      role
      status
      expiresAt
      createdAt
    }
  }
}

Create an invitation

mutation Invite {
  createInvitation(input: {
    email: "new-editor@bobscountrybunker.com"
    role: PROJECT_EDITOR
  }) {
    invitation {
      id
      email
      acceptUrl
    }
  }
}

The response includes acceptUrl — useful when you want to deliver the invite through your own email pipeline instead of the platform’s. Otherwise the platform mails the invite for you.

Resend, revoke, change role

mutation Resend  { resendInvitation(id: "inv_abc")  { invitation { id } } }
mutation Revoke  { revokeInvitation(id: "inv_abc")  { ok } }
mutation Demote  { updateMemberRole(id: "mem_abc", role: PROJECT_VIEWER) { member { id role } } }
mutation Remove  { removeMember(id: "mem_abc") { ok } }

Roles in practice

Some rules of thumb when deciding which role to grant:

• Outside agencies / freelancers doing content work: Project Editor on the project they’re working on. Drop them to Viewer or remove when the engagement ends.
• Internal developers who edit models and operations: Project Admin on staging projects, Project Editor on production projects (so they push schema changes via foir push from CI, not by hand).
• Read-only stakeholders (PMs, analysts): Project Viewer. They can browse content and reports without risk of accidental edits.
• Owners / founders: Tenant Owner. Keep this list short — Tenant Owners can change billing and add new owners.

Limits

• One pending invitation per email address per tenant. Revoke and re-invite to change role.
• Invitation links are single-use and expire after seven days. After expiry, send a new one.
• A tenant must always have at least one Tenant Owner. The platform refuses to demote or remove the last owner.

Related

• Customer Authentication — for your storefront’s end-users, which is a separate system.
• API Keys — programmatic credentials, distinct from member sessions.
• Billing & Usage — Tenant-level concern, managed by Tenant Owners.