Mybots.pro · OAuth Scopes

Mybots.pro OAuth Scopes

OAuth 2.0 probed

Mybots.pro publishes 6 OAuth 2.0 scopes via the authorizationCode, clientCredentials, and password flows. Scopes are the fine-grained permissions an application requests at authorization time to act against the Mybots.pro API on a user’s behalf.

Tokens are issued from https://auth.mybots.pro/connect/token.

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.

CompanyAI AgentsConversational AIMessagingChatbotsCustomer SupportSales AutomationWhatsAppTelegramInstagramOmnichannelLead QualificationOpenID Connect

Scopes: 6 Flows: authorizationCode, clientCredentials, password Method: probed

OAuth endpoints

Authorization URL
https://auth.mybots.pro/connect/authorize

Token URL
https://auth.mybots.pro/connect/token

Flows
authorizationCodeclientCredentialspassword

Scopes (6)

Scope	Description	Flows
openid	Standard OIDC scope requesting an ID token for the authenticated subject.	authorizationCode
profile	Standard OIDC scope for the end-user's default profile claims (name, family_name, picture, updated_at, and similar).	authorizationCode
email	Standard OIDC scope for the email and email_verified claims.	authorizationCode
phone	Standard OIDC scope for the phone_number and phone_number_verified claims.	authorizationCode
offline_access	Standard OIDC scope requesting a refresh token so the client can obtain access tokens without the end-user present.	authorizationCode
roles	Role claims for the authenticated subject. Conventional in OpenIddict/ASP.NET Identity deployments; myBots publishes no enumeration of which roles exist.	authorizationCode, clientCredentials

📄 Provider scope reference:

Source

OAuth Scopes

generated: '2026-08-14'
method: probed
source: https://auth.mybots.pro/.well-known/openid-configuration
note: >-
  Scopes are taken verbatim from `scopes_supported` in the provider's live OIDC discovery
  document. myBots publishes no scopes/permissions reference page, so there are no
  descriptions to enrich with — the descriptions below are the STANDARD OIDC/OAuth
  definitions of these registered scopes (RFC 6749 / OpenID Connect Core 1.0 §5.4), not
  claims about myBots-specific behavior. Every scope advertised is a standard one; myBots
  advertises NO product-specific scopes (nothing for agents, channels, conversations,
  contacts or billing), so an OAuth client cannot request least-privilege access to any
  myBots resource — only identity.
docs: null
schemes:
- name: OAuth2
  source: well-known/mybotspro-openid-configuration.json
  flows:
  - flow: authorizationCode
    authorizationUrl: https://auth.mybots.pro/connect/authorize
    tokenUrl: https://auth.mybots.pro/connect/token
  - flow: clientCredentials
    tokenUrl: https://auth.mybots.pro/connect/token
  - flow: password
    tokenUrl: https://auth.mybots.pro/connect/token
scopes:
- scope: openid
  description: Standard OIDC scope requesting an ID token for the authenticated subject.
  standard: OpenID Connect Core 1.0
  product_specific: false
  flows: [authorizationCode]
  sources: [well-known/mybotspro-openid-configuration.json]
- scope: profile
  description: >-
    Standard OIDC scope for the end-user's default profile claims (name, family_name,
    picture, updated_at, and similar).
  standard: OpenID Connect Core 1.0 §5.4
  product_specific: false
  flows: [authorizationCode]
  sources: [well-known/mybotspro-openid-configuration.json]
- scope: email
  description: Standard OIDC scope for the email and email_verified claims.
  standard: OpenID Connect Core 1.0 §5.4
  product_specific: false
  flows: [authorizationCode]
  sources: [well-known/mybotspro-openid-configuration.json]
- scope: phone
  description: Standard OIDC scope for the phone_number and phone_number_verified claims.
  standard: OpenID Connect Core 1.0 §5.4
  product_specific: false
  flows: [authorizationCode]
  sources: [well-known/mybotspro-openid-configuration.json]
- scope: offline_access
  description: >-
    Standard OIDC scope requesting a refresh token so the client can obtain access tokens
    without the end-user present.
  standard: OpenID Connect Core 1.0 §11
  product_specific: false
  flows: [authorizationCode]
  sources: [well-known/mybotspro-openid-configuration.json]
- scope: roles
  description: >-
    Role claims for the authenticated subject. Conventional in OpenIddict/ASP.NET Identity
    deployments; myBots publishes no enumeration of which roles exist.
  standard: null
  product_specific: false
  flows: [authorizationCode, clientCredentials]
  sources: [well-known/mybotspro-openid-configuration.json]
claims_supported: [aud, exp, iat, iss, sub]
claims_note: >-
  `claims_supported` lists only the five registered JWT claims. Despite advertising the
  profile/email/phone scopes, the discovery document does not advertise the corresponding
  claims (name, email, phone_number), so a client cannot tell from discovery what the
  userinfo endpoint will actually return.
summary:
  scope_count: 6
  product_specific_scope_count: 0
  standard_oidc_scope_count: 6