Coresignal · OAuth Scopes

Coresignal OAuth Scopes

OAuth 2.0 probed

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

Tokens are issued from https://dashboard.coresignal.com/api/auth/oauth2/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.

Agentic SearchB2B DataCompaniesCompany DataData as a ServiceElasticsearchEmployee DataEmployeesEnrichmentFirmographicsJob PostingsJobLead GenerationPeople DataSales IntelligenceTalent IntelligenceWeb Data
Scopes: 4 Flows: authorizationCode, clientCredentials, refreshToken Method: probed

OAuth endpoints

Authorization URL
https://dashboard.coresignal.com/api/auth/oauth2/authorize
Token URL
https://dashboard.coresignal.com/api/auth/oauth2/token
Flows
authorizationCodeclientCredentialsrefreshToken

Scopes (4)

ScopeDescriptionFlows
openid Standard OIDC scope — request an ID token identifying the signed-in dashboard user. authorizationCode
profile Standard OIDC scope — name, given_name, family_name, picture claims for the dashboard user. authorizationCode
email Standard OIDC scope — email and email_verified claims for the dashboard user. authorizationCode
offline_access Standard OIDC scope — issue a refresh token so the MCP client can keep the session alive without re-prompting the user in the browser. authorizationCode

Source

OAuth Scopes

Raw ↑
generated: '2026-08-13'
method: probed
source: >-
  well-known/coresignal-oauth-authorization-server.json,
  well-known/coresignal-openid-configuration.json,
  well-known/coresignal-oauth-protected-resource.json
docs: https://docs.coresignal.com/integrations/coresignal-mcp
note: >-
  Coresignal's REST data APIs use an api-key header and have NO scope surface at all. The only OAuth
  on the estate authenticates the MCP v2 server, and it is a sign-in flow, not a permissioning model:
  the four scopes below are the standard OIDC identity set, and the protected resource itself
  advertises scopes_supported: [] — meaning once a user signs in, the server resolves their team's
  API key and the token carries the team's full data entitlement. There is no read/write split, no
  per-dataset scope, and no way for an agent to request less than everything the team can see.
schemes:
  - name: Coresignal Dashboard OAuth 2.1
    source: https://dashboard.coresignal.com/.well-known/oauth-authorization-server
    issuer: https://dashboard.coresignal.com/api/auth
    protects: https://mcp.coresignal.com/mcp/v2
    flows:
      - flow: authorizationCode
        authorizationUrl: https://dashboard.coresignal.com/api/auth/oauth2/authorize
        tokenUrl: https://dashboard.coresignal.com/api/auth/oauth2/token
        pkce: S256
      - flow: clientCredentials
        tokenUrl: https://dashboard.coresignal.com/api/auth/oauth2/token
      - flow: refreshToken
        tokenUrl: https://dashboard.coresignal.com/api/auth/oauth2/token
    jwks_uri: https://dashboard.coresignal.com/api/auth/jwks
    introspection_endpoint: https://dashboard.coresignal.com/api/auth/oauth2/introspect
    revocation_endpoint: https://dashboard.coresignal.com/api/auth/oauth2/revoke
    registration_endpoint: https://dashboard.coresignal.com/api/auth/oauth2/register
    userinfo_endpoint: https://dashboard.coresignal.com/api/auth/oauth2/userinfo
    end_session_endpoint: https://dashboard.coresignal.com/api/auth/oauth2/end-session
    token_endpoint_auth_methods: [none, client_secret_basic, client_secret_post]
    id_token_signing_alg: [RS256]
scopes:
  - scope: openid
    description: Standard OIDC scope — request an ID token identifying the signed-in dashboard user.
    flows: [authorizationCode]
    sources: [well-known/coresignal-oauth-authorization-server.json]
  - scope: profile
    description: >-
      Standard OIDC scope — name, given_name, family_name, picture claims for the dashboard user.
    flows: [authorizationCode]
    sources: [well-known/coresignal-oauth-authorization-server.json]
  - scope: email
    description: Standard OIDC scope — email and email_verified claims for the dashboard user.
    flows: [authorizationCode]
    sources: [well-known/coresignal-oauth-authorization-server.json]
  - scope: offline_access
    description: >-
      Standard OIDC scope — issue a refresh token so the MCP client can keep the session alive without
      re-prompting the user in the browser.
    flows: [authorizationCode]
    sources: [well-known/coresignal-oauth-authorization-server.json]
resource_scopes:
  resource: https://mcp.coresignal.com/mcp/v2
  scopes_supported: []
  bearer_methods_supported: [header]
  interpretation: >-
    The MCP resource declares an EMPTY scope list. Authorization is binary — a valid token for a team
    grants every tool, including the credit-spending ones (entity_search at 20 credits, entity_fetch
    at up to 20 credits per record, email_enrich at 10 credits per email). Spend control is handled by
    the server's confirmation prompt before expensive calls, not by the token.
claims_supported: [sub, iss, aud, exp, iat, sid, scope, azp, email, email_verified, name, picture, family_name, given_name]
rest_api_scopes:
  present: false
  note: >-
    api.coresignal.com authenticates with a 32-character `apikey` header. Keys have no scopes and no
    least-privilege model; entitlement is the plan attached to the account. Multiple keys per account
    can be generated and revoked, which is the only isolation mechanism available.