Concept

Role-based access control

Multi-tenant authorization with hierarchical roles — admin, reseller, merchant, and user.

Overview

Every API token carries a role that determines which resources the caller can access. Breeze Buddy enforces RBAC on all endpoints automatically — list queries are filtered, and mutation requests are validated against the caller’s scope.

Role hierarchy

RoleScopeDescription
adminGlobalFull access to all resources across all resellers and merchants.
resellerResellerAccess to all merchants and templates under the reseller.
merchantMerchantAccess limited to the merchant’s own templates and leads.
userUserRead-only access to assigned resources.

How RBAC works

When a request comes in, the API:

  1. Decodes the JWT and extracts the role, reseller_id, and merchant_id
  2. For list endpoints: automatically filters results to only show resources the caller owns or has access to
  3. For create/update/delete: validates that the target resource falls within the caller’s scope

Transparent Filtering

List endpoints automatically filter results based on the caller’s role. An admin sees all records; a merchant sees only their own. No extra query parameters needed.

Resource scoping

Resourceadminresellermerchantuser
TemplatesAllOwn resellerOwn merchantRead-only
LeadsAllOwn resellerOwn merchantRead-only
ConfigurationsAllOwn resellerRead-only
NumbersAllOwn reseller
MerchantsAllOwn reseller
AnalyticsAllOwn resellerOwn merchantRead-only
S2S TokensCreate anyCreate for own

S2S token roles

When creating a server-to-server token, you assign it a role. The token inherits the same access rules as that role. Most backend integrations use the merchant role for least-privilege access.

json
{
  "name": "my-backend",
  "role": "merchant",
  "reseller_id": "res_001",
  "merchant_id": "mer_abc"
}

Principle of Least Privilege

Always assign the most restrictive role that satisfies the integration’s needs. Avoid using admin tokens in production services.

Was this helpful?