Uptake · OAuth Scopes

Uptake OAuth Scopes

OAuth 2.0 probed

Uptake 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.

CompanyIndustrial AIPredictive MaintenanceAsset Performance ManagementFleet ManagementTelematicsMachine LearningIndustrial IoT
Scopes: 0 Flows: Method: probed

Scopes (0)

Uptake 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.

📄 Provider scope reference:

Source

OAuth Scopes

uptake-scopes.yml Raw ↑ 
generated: '2026-08-05'
method: probed
source: https://start.uptake.com/.well-known/openid-configuration
docs: null
summary: >-
  Uptake publishes no OpenAPI and no scope reference page, so these scopes come
  from the only anonymous, machine-readable auth metadata the estate serves: the
  OIDC discovery and RFC 8414 authorization-server metadata documents on Uptake's
  Okta tenant at start.uptake.com. IMPORTANT — these are IDENTITY scopes, not
  Uptake product-API scopes. The okta.* set is Okta's own org-management scope
  vocabulary, present because the tenant fronts the Okta management API; it does
  not describe access to Uptake Fleet, Radar, Compass, Fusion or Scout data. No
  Uptake product scope vocabulary is published anywhere we could reach.
issuer: https://start.uptake.com
scope_sets:
- id: oidc-standard
  origin: OpenID Connect discovery document
  applies_to: Sign-in to the Uptake platform (fleet.uptake.com) via Uptake's Okta tenant
  source_url: https://start.uptake.com/.well-known/openid-configuration
  http_status: 200
  scopes:
  - name: openid
    description: Required OIDC scope; requests an ID token.
  - name: email
    description: Release the user's email address and email_verified claim.
  - name: profile
    description: Release standard profile claims (name, given_name, family_name, locale, zoneinfo, updated_at).
  - name: address
    description: Release the user's address claim.
  - name: phone
    description: Release phone_number and phone_number_verified claims.
  - name: offline_access
    description: Issue a refresh token.
  - name: groups
    description: Release the user's Okta group memberships — the claim Uptake tenancy/role mapping is most likely to key on.
- id: okta-management
  origin: RFC 8414 authorization-server metadata
  applies_to: >-
    The Okta management API on Uptake's tenant, NOT the Uptake product API.
    Recorded for completeness and for the auth-clarity signal; do not read this
    as an Uptake data-access scope vocabulary.
  source_url: https://start.uptake.com/.well-known/oauth-authorization-server
  http_status: 200
  scope_count: 80
  vendor_vocabulary: okta
  scopes_sample:
  - okta.users.read
  - okta.users.manage
  - okta.groups.read
  - okta.groups.manage
  - okta.apps.read
  - okta.apps.manage
  - okta.clients.register
  - okta.policies.read
  - okta.logs.read
  - okta.events.read
  - okta.sessions.manage
  - okta.trustedOrigins.manage
  - okta.rateLimits.read
  - okta.apiTokens.manage
  full_list_file: well-known/uptake-oauth-authorization-server.json
product_api_scopes:
  published: false
  note: >-
    api.uptake.com and api.common.uptake.com return 403 ForbiddenException to every
    anonymous request with no WWW-Authenticate challenge, so no scope, realm or
    audience is advertised. The retired developer portal (developer.uptake.com)
    now 404s. Nothing to record without credentials.
gaps_for_provider:
- Publish the Uptake Platform API scope/permission reference at a public URL.
- Return a WWW-Authenticate challenge on the gateway so the auth model is discoverable without a support ticket.
checked: '2026-08-05'