Stedi · OAuth Scopes

Stedi OAuth Scopes

OAuth 2.0 probed

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

EDIElectronic Data InterchangeHealthcareClearinghouseX12ClaimsEligibilityHIPAARevenue Cycle ManagementB2B Integration
Scopes: 0 Flows: Method: probed

Scopes (0)

Stedi 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: https://www.stedi.com/docs/healthcare/mcp-server

Source

OAuth Scopes

Raw ↑ 
generated: '2026-08-15'
method: probed
source: https://mcp.us.stedi.com/.well-known/oauth-authorization-server
docs: https://www.stedi.com/docs/healthcare/mcp-server
summary: >
  Stedi's REST APIs do NOT use OAuth — every published OpenAPI declares a single apiKey scheme
  (Authorization header) and no securityScheme of type oauth2, so there are no REST scopes to
  enumerate. The only OAuth surface Stedi operates is the MCP server, and its RFC 8414
  authorization-server metadata advertises exactly one scope. Access beyond that single scope is
  governed by Stedi's account ROLE model in the portal, not by OAuth scopes.
oauth:
  present: true
  surface: mcp
  rest: false
  metadata_url: https://mcp.us.stedi.com/.well-known/oauth-authorization-server
  metadata_http_status: 200
  metadata_file: ../well-known/stedi-mcp-oauth-authorization-server.json
  issuer: https://tokens.prod.saas.stedi.com/v1
  authorization_endpoint: https://portal.stedi.com/auth/oauth/authorize
  token_endpoint: https://oauth.us.stedi.com/oauth2/token
  jwks_uri: https://tokens.prod.saas.stedi.com/v1/.well-known/jwks.json
  grant_types_supported: [authorization_code, refresh_token]
  response_types_supported: [code]
  code_challenge_methods_supported: [S256]
  token_endpoint_auth_methods_supported: [none]
  client_id_metadata_document_supported: true
  dynamic_client_registration: false
  dynamic_client_registration_note: >
    No registration_endpoint is advertised. Stedi instead sets
    client_id_metadata_document_supported: true, so a client identifies itself with a hosted
    client-ID metadata document rather than by registering.
scopes:
- name: mcp:operator
  description: >
    The single scope advertised in scopes_supported. Grants an OAuth-authenticated MCP client the
    two tools the Stedi MCP server exposes (search_for_payer, eligibility_check) at the
    permission level of the authorizing account member.
  source: scopes_supported
  surface: https://mcp.us.stedi.com/mcp2
scope_count: 1
access_controls_outside_oauth:
  model: account roles
  note: >
    Stedi documents that OAuth MCP access requires the Operator role or above and a plan that
    includes healthcare eligibility, that SSO is not supported on the OAuth endpoint (email +
    password only), and that sessions expire after 30 days. REST API keys inherit the
    permissions of the account member who created them and keep those permissions even if that
    member's role later changes. None of this is expressed as OAuth scopes.
  docs: https://www.stedi.com/docs/healthcare/mcp-server
related:
  authentication: authentication/stedi-authentication.yml
  mcp: mcp/stedi-mcp.yml
  conformance: conformance/stedi-conformance.yml