KonbiniAPI · OAuth Scopes
KonbiniAPI OAuth Scopes
OAuth 2.0
probed
KonbiniAPI 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.
Social-MediaInstagramTikTokXRedditLinkedInActivityStreams 2.0ScrapingData ExtractionPublic DataInfluencer MarketingSocial ListeningCreator ToolsMCPAgent SkillsAgents
Scopes: 0
Flows:
Method: probed
Scopes (0)
KonbiniAPI 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.
These scopes govern the hosted MCP server only. The REST API at api.konbiniapi.com uses a static Bearer API key with NO scopes at all — one key carries the whole surface, all 67 operations, with no way to issue a read-only or platform-restricted credential. The OpenAPI declares no oauth2 securityScheme, so `derive-oauth-scopes.py` correctly found nothing; every scope below was read from live authorization-server metadata instead.
These scopes govern the hosted MCP server only. The REST API at api.konbiniapi.com uses a static Bearer API key with NO scopes at all — one key carries the whole surface, all 67 operations, with no way to issue a read-only or platform-restricted credential. The OpenAPI declares no oauth2 securityScheme, so `derive-oauth-scopes.py` correctly found nothing; every scope below was read from live authorization-server metadata instead.
📄 Provider scope reference: https://docs.konbiniapi.com/reference/mcp/overview