CaptivateIQ · OAuth Scopes
CaptivateIQ OAuth Scopes
OAuth 2.0
probed
CaptivateIQ 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.
CompanyCloud SaasSales CommissionsIncentive Compensation ManagementSales Performance ManagementRevenue OperationsFinancePayoutsCommission PlansSales Compensation
Scopes: 0
Flows:
Method: probed
Scopes (0)
CaptivateIQ 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 were read from CaptivateIQ's own RFC 8414 authorization-server metadata document (HTTP 200, application/json), NOT from the OpenAPI and NOT from the docs. The public developer reference documents only static token auth ("Authorization: Token") and never mentions OAuth, so there is no scopes/permissions reference page to enrich this from — the OAuth surface is served but undocumented. The server advertises exactly one scope, `read`, which means the OAuth path as published is read-only and cannot authorize any of the write operations (create/update/delete/batch/import) in the ciq/v1 OpenAPI; those require a static API token. Do not infer additional scopes: the metadata document names one.
These scopes were read from CaptivateIQ's own RFC 8414 authorization-server metadata document (HTTP 200, application/json), NOT from the OpenAPI and NOT from the docs. The public developer reference documents only static token auth ("Authorization: Token
Source
OAuth Scopes
Work with this as data
Every scope set here is available over the APIs.io API and to AI agents over MCP.