Sequel · OAuth Scopes

Sequel OAuth Scopes

OAuth 2.0 probed

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

CompanyWebinarsVirtual EventsLive StreamingVideoNetworkingMarketingEventsWebhooks
Scopes: 0 Flows: Method: probed

Scopes (0)

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

The published OpenAPI declares NO oauth2 securityScheme (only http bearer + an apiKey Authorization header), so `derive-oauth-scopes.py` yields nothing for this provider. Everything below was read from the two RFC 8414 / RFC 9728 discovery documents the provider actually serves, and from the docs' authentication page. Nothing here is inferred.

Source

OAuth Scopes

Raw ↑
generated: '2026-08-13'
method: probed
source: https://api.introvoke.com/.well-known/oauth-protected-resource + https://api.introvoke.com/.well-known/oauth-authorization-server
docs: https://docs.introvoke.com/docs
note: >-
  The published OpenAPI declares NO oauth2 securityScheme (only http bearer + an apiKey
  Authorization header), so `derive-oauth-scopes.py` yields nothing for this provider.
  Everything below was read from the two RFC 8414 / RFC 9728 discovery documents the
  provider actually serves, and from the docs' authentication page. Nothing here is
  inferred.
schemes:
- name: api-client-credentials
  type: oauth2
  flow: clientCredentials
  token_url: https://api.introvoke.com/api/oauth/token
  audience: https://www.introvoke.com/api
  scopes_published: false
  scopes: []
  note: >-
    The REST API's own machine-to-machine flow is scope-free. Sequel's docs instruct
    clients to POST client_id + client_secret + audience + grant_type=client_credentials
    and use the returned JWT as a bearer token; no `scope` parameter is documented and
    no scope values are published. Authorization is therefore all-or-nothing per API
    client — an agent holding a Sequel token can reach every operation that client's
    company is entitled to, including destructive ones (deleteevent, deleteRegistrantById,
    postClearChat). There is no way to issue a read-only API credential.
- name: mcp-protected-resource
  type: oauth2
  resource: https://prod-api-elb.sequelvideo.com/api/mcp
  resource_public_endpoint: https://api.introvoke.com/api/mcp
  authorization_servers:
  - https://login.introvoke.com
  bearer_methods_supported:
  - header
  scopes:
  - scope: openid
    description: OpenID Connect — issue an ID token identifying the end user.
    source: /.well-known/oauth-protected-resource
  - scope: profile
    description: Access the end user's basic profile claims.
    source: /.well-known/oauth-protected-resource
  - scope: email
    description: Access the end user's email address claim.
    source: /.well-known/oauth-protected-resource
  - scope: offline_access
    description: Issue a refresh token so the MCP client can act without re-prompting.
    source: /.well-known/oauth-protected-resource
  note: >-
    These are the four standard OIDC scopes the Auth0 tenant advertises for the
    interactive user-login flow that fronts the MCP server. They authenticate the human;
    they do NOT describe or constrain what the MCP tools may read. There is no
    Sequel-specific scope (nothing like `transcripts:read` or `events:read`), so an MCP
    client's data access is bounded by the account's own permissions rather than by a
    consent-time grant the user can narrow.
discovery:
- path: /.well-known/oauth-protected-resource
  host: api.introvoke.com
  status: 200
  spec: RFC 9728 (OAuth 2.0 Protected Resource Metadata)
  file: well-known/sequel-oauth-protected-resource.json
- path: /.well-known/oauth-authorization-server
  host: api.introvoke.com
  status: 200
  spec: RFC 8414 (OAuth 2.0 Authorization Server Metadata)
  file: well-known/sequel-oauth-authorization-server.json
authorization_server:
  issuer: https://login.introvoke.com
  provider: Auth0
  grant_types_supported:
  - authorization_code
  - refresh_token
  code_challenge_methods_supported:
  - S256
  - plain
  token_endpoint_auth_methods_supported:
  - client_secret_post
  - client_secret_basic
cross_ref:
  authentication: authentication/sequel-authentication.yml
  mcp: mcp/sequel-mcp.yml
  well_known: well-known/sequel-well-known.yml