Owner and staff
The account that signed the store up holds the owner role. It is the only role that can change the store itself — settings, domain, branding, theme, plan and the team — and it is the only role that can issue API keys. Everyone else is staff.
Every role is scoped to a single store. That scoping is applied by the server on every request, so a staff account cannot read another merchant’s orders even with a correct id, and neither can a key minted from that account.
The four permission bundles
Permissions are grouped into four bundles. Each one is self-contained — it already includes the read access its screens need, so you never have to combine two bundles just to make one page load.
| Bundle | What it allows |
|---|---|
| orders | Read and update orders; read the customers, products, payment and delivery methods behind them; read branches, which the till needs before it can open. |
| catalog | Create, read, update and delete products, variants, assets and tags. |
| marketing | Manage promotions — coupons and discount campaigns. |
| reports | Read-only across orders, customers and the catalogue. |
Templates are not bundles
When an owner invites someone they pick a template, not a bundle list. Three templates are canned and the fourth lets them mix bundles by hand. The names overlap with the bundle names, which is worth reading carefully once.
| Template | What the person gets |
|---|---|
| orders | Exactly the orders bundle. |
| catalog | The catalog bundle PLUS custom attributes, product import and product export — more than the bundle of the same name. |
| full | Everything the owner can do EXCEPT store settings and API keys. A manager, not a second owner. |
| custom | The union of whichever bundles the owner ticked. |
Roles are shared per template or per bundle-set rather than created per person, so two staff with the same template hold the same role. Removing one does not disturb the other.
Managing the team over the API
Three operations, all owner-only. `myStaff` lists the team with each member’s template. `inviteStaff` creates the account, and `removeStaff` deletes it by administrator id.
# List the team
query { myStaff { id firstName lastName emailAddress template } }
# Invite someone with the canned "orders" template
mutation {
inviteStaff(input: {
firstName: "Rana", lastName: "Haddad",
emailAddress: "[email protected]",
password: "set-by-the-owner",
template: "orders"
}) { id template }
}
# Or mix bundles by hand
mutation {
inviteStaff(input: {
firstName: "Omar", lastName: "Nasr",
emailAddress: "[email protected]",
password: "set-by-the-owner",
template: "custom", bundles: ["orders", "reports"]
}) { id template }
}
# Remove someone
mutation { removeStaff(administratorId: "42") }How many people you can add
The number of staff a store may have is capped by its plan. The limit is set per plan and can change without a release, so read it from the store’s dashboard rather than hard-coding a number — an invite past the cap fails with a plain error.
This is not the same as a customer group
Staff are people who sign in and run the shop. Customer groups are segments of the shop’s buyers, used for wholesale pricing. They are different entities with different APIs, and the similar wording has caught people out.