Reference
Roles
What each role can see and change — admin, reseller, merchant, user.
Breeze Buddy has four roles. Each role grants a scope — which data the user can see — and a set of permissions — what they can change.
Role summary
| Role | Scope | When to use |
|---|---|---|
admin | All resellers, all merchants | Breeze Buddy platform operators only. |
reseller | All merchants under the reseller | Agency or parent organisation managing multiple merchant accounts. |
merchant | One merchant’s data | The default role for everyone at a merchant business. |
user | Read-only subset | Analysts, support staff, anyone who shouldn’t make changes. |
Permission matrix
| Resource | admin | reseller | merchant | user |
|---|---|---|---|---|
| Templates | All | Own reseller | Own merchant | Read-only |
| Leads | All | Own reseller | Own merchant | Read-only |
| Call execution configs | All | Own reseller | Read-only | — |
| Numbers | All | Own reseller | — | — |
| Merchants (the accounts) | All | Own reseller | — | — |
| Analytics | All | Own reseller | Own merchant | Read-only |
| Server-to-server tokens | Create any | Create for own reseller | — | — |
Picking a role
- Someone running a campaign →
merchant. Can create and edit templates, push leads, read analytics. - A support analyst who needs to review calls →
user. Read-only — no accidental edits. - An agency account manager handling multiple clients →
reseller. Can switch between merchants. - A platform operator →
admin. Typically only a handful of people hold this globally.
Server-to-server tokens
Backend integrations (cron jobs pushing leads, CRM sync, CI) use S2S tokens, not user logins. Give an S2S token the narrowest role it needs — usually merchant scoped to a single merchant — rather than admin. Details in Authentication (developer docs).
Principle of least privilege
Grant the smallest role that gets the job done. Most people should be user or merchant. reseller and admin are the leak-blast-radius roles — use them sparingly.
Was this helpful?