Rose Rocket uses OAuth 2.0 but publishes no discrete scopes — access is governed by the grant itself (e.g. client-credentials or role-based authorization) rather than per-scope consent.
This index is generated from the provider’s OpenAPI security definitions (and, where available, its documented scope reference) and refreshes on every APIs.io network build. Browse every provider’s scopes at scopes.apis.io.
Rose Rocket implements OAuth 2.0 but publishes no discrete scopes — access is governed by the grant itself (client-credentials or role-based authorization) rather than per-scope consent.
generated: '2026-08-26'
method: searched
source: >-
https://roserocket.readme.io/docs/rose-rocket-api-oauth-20-authentication-guide,
https://roserocket.readme.io/docs/roles-and-permissions, the
components.responses.GroupForbiddenResponse description inside
openapi/rose-rocket-platform-model-api.json, and the live discovery document at
https://a.roserocket.com/.well-known/openid-configuration (HTTP 200, probed
2026-08-26).
docs: https://roserocket.readme.io/docs/roles-and-permissions
description: >-
Rose Rocket's OAuth 2.0 layer carries NO API authorization scopes. The scopes the
Authentication Guide tells you to request — `offline_access email profile` — are
the standard OIDC identity scopes of the Auth0 authorization server at
a.roserocket.com; none of them names a Rose Rocket resource or a permission on
one. Authorization is enforced entirely server-side by the ROLE the token's user
or service account holds inside the organization, against a per-object,
per-field permission matrix administered in the product. This is a real and
reasonably granular authorization model, but it is invisible to a client: an
agent holding a token cannot read from the token, or from any documented scope
list, what it is allowed to do. It finds out by receiving a 403.
model: role-based
model_note: >-
Permissions are set per ROLE per objectKey, in three sections — Board (which
boards the role sees), Record (isCreateAllowed / isDeleteAllowed) and Data (full,
read-only, or per-field custom). They are administered at
Settings > Users, Roles, Groups > Roles, and can be written through
POST {base}/permissions/roles/{role}/objectKey/{object} — an endpoint documented
in the Roles and Permissions guide that is NOT present in the published OpenAPI.
authorization_server: https://a.roserocket.com/
audience: https://roserocket.com
oauth_scopes_requested:
- name: offline_access
purpose: Issues a refresh token. Required for any long-lived integration.
kind: oidc
- name: email
purpose: Adds the email claim to the ID token. Identity only; grants no API access.
kind: oidc
- name: profile
purpose: Adds profile claims to the ID token. Identity only; grants no API access.
kind: oidc
oauth_scopes_supported_by_authorization_server:
source: https://a.roserocket.com/.well-known/openid-configuration
note: >-
Advertised by the Auth0 tenant, not by Rose Rocket. Every entry is an OIDC
identity scope or claim; none is a Rose Rocket resource permission.
values: [openid, profile, offline_access, name, given_name, family_name, nickname,
email, email_verified, picture, created_at, identities, phone, address]
resource_permissions_note: >-
The one named permission the published contract exposes. It appears only in the
403 response description for the user-group operations, and it uses a
viewer/editor level rather than an OAuth scope string.
resource_permissions:
- name: userGroupResource
levels:
viewer: List, fetch, and view membership of user groups.
editor: Update, delete, and modify membership of user groups.
applies_to:
- GET /userGroups
- POST /userGroups
- GET /userGroups/{groupId}/members
- POST /userGroups/{groupId}/members
- POST /userGroups/search
evidence: components.responses.GroupForbiddenResponse.description
built_in_roles_source: https://roserocket.readme.io/docs/roles-and-permissions
built_in_roles:
- {name: Admin, description: Full access for account owners and system administrators.}
- {name: Manager, description: 'Almost full access, restricted from changing organizational or subscription settings. Service accounts default to this role.'}
- {name: Operations, description: Limited financial data access.}
- {name: Sales, description: Limited financial data access.}
- {name: Driver, description: Specific for company driver or owner operator.}
- {name: Customer (Guest), description: Limited access for your customers.}
- {name: Partner (Guest), description: Limited access to tracking and providing updates.}
- {name: Guest, description: Provides guests with limited access.}
- {name: External, description: For public viewing of shared information.}
- {name: Custom, description: Organizations can define additional roles; every built-in role is editable by an Admin.}
scope_count: 0
scope_count_note: >-
Zero API authorization scopes are published. Counted deliberately: the three OIDC
scopes above are identity scopes and are recorded separately so they are not
mistaken for resource permissions.
gaps:
- The OpenAPI declares no components.securitySchemes at all, so no scope list is machine-readable.
- No token introspection surface is documented, so a client cannot enumerate its own effective permissions.
- The permissions write endpoint (POST /permissions/roles/{role}/objectKey/{object}) is documented in prose but absent from the contract.