Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.scrubbe.com/llms.txt

Use this file to discover all available pages before exploring further.

Scrubbe uses role-based access control (RBAC) to define what each team member can see and do inside the platform. Every user is assigned one or more roles when they are invited to your organization. Roles range from full administrative access down to read-only observation, and a separate CUSTOMER role grants access only to the self-service customer portal. Choosing the right role for each team member keeps your incident data secure and your workflows predictable.

​
User roles

RoleOperational access
SUPER_ADMINUnrestricted access to all features, settings, and data across the platform. Reserved for platform owners and system administrators.
ADMINAdministrative access including user management, blog posts, and job listings. Appropriate for operations leads who need full organizational visibility.
MANAGERCan manage team members and incident records. Appropriate for engineering managers and team leads overseeing on-call rotations and escalations.
ENGINEERCan create, update, and resolve incidents. The standard role for engineers who actively respond to incidents and contribute to post-mortems.
RESPONDERCan acknowledge and resolve incidents that are assigned to them. A narrower version of ENGINEER suitable for on-call responders who do not need to create new tickets.
VIEWERRead-only access across all incident data and reports. Appropriate for stakeholders, product managers, or auditors who need visibility without write access.
CUSTOMERAccess only to the customer self-service portal. This role is for external users who submit and track their own incidents — not for internal team members.
A user’s roles field is an array, so a single account can hold multiple roles. In practice, most team members are assigned a single role that reflects their primary function.

​
Account types

In addition to roles, each account has a type that governs which parts of the platform are available:
Account typeDescription
DEVELOPERIndividual developer account. Suitable for solo users or developers evaluating the platform.
BUSINESSOrganization account. Required for team features including on-call scheduling, SLA policies, and multi-member incident management.

​
Inviting team members

Use POST /api/v1/business/send-invite to invite a new team member and assign their role in the same request: 
POST /api/v1/business/send-invite

{
  "email": "teammate@example.com",
  "role": "ENGINEER",
  "accessPermissions": ["incidents", "postmortems"],
  "level": "Senior"
}
FieldDescription
emailEmail address of the person being invited
roleOne of the roles listed above
accessPermissionsArray of feature areas the user can access — valid values include "incidents" and "postmortems"
levelOptional seniority label (e.g. "Senior", "Lead") used for display and escalation context
The invite recipient receives an email with a token-based link. They accept it via POST /api/v1/business/accept-invite, at which point their account is created with the assigned role and permissions.

​
Accepting an invite

To decode an invite token before accepting it (useful for pre-filling a sign-up form): 
POST /api/v1/business/decode-invite
To accept the invite and create the account: 
POST /api/v1/business/accept-invite

​
The CUSTOMER role

The CUSTOMER role is distinct from all team roles. Users with this role authenticate through the customer portal (/api/v1/customer) and can only submit incidents, view their own incident history, and read resolution summaries published to the knowledge base. They cannot access your organization’s internal incident dashboard, SLA data, or team settings. Customer portal users register separately via POST /api/v1/customer/register and log in via POST /api/v1/customer/login. They are not invited through the team invite flow.
If you want an external stakeholder to have read-only visibility into your internal incident data, use the VIEWER role and send them a standard team invite — not the customer portal. Reserve the CUSTOMER role for end-users of your product who are reporting issues they have experienced.

​
Listing your team

Retrieve all current members and their roles with: 
GET /api/v1/business/get_members
This endpoint returns each member’s ID, email, assigned roles, access permissions, and account status. Use the returned user IDs when creating on-call assignments or filtering incident analytics by assignee.