Hunter · OAuth Scopes

Hunter OAuth Scopes

OAuth 2.0 probed

Hunter publishes 2 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 Hunter API on a user’s behalf.

Tokens are issued from https://hunter.io/oauth/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.

Contact DiscoveryEmailEmail VerificationLead GenerationProspectingSales Intelligence

Scopes: 2 Flows: authorizationCode, clientCredentials, refreshToken Method: probed

OAuth endpoints

Authorization URL
https://hunter.io/oauth/authorize

Token URL
https://hunter.io/oauth/token

Flows
authorizationCodeclientCredentialsrefreshToken

Scopes (2)

Scope	Description	Flows
read	Read access. Granularity is not documented; Hunter publishes no scope reference page, so the mapping from this scope to individual endpoints or MCP tools is not stated anywhere public.	authorizationCode, clientCredentials, refreshToken
write	Write access. Same caveat: no published scope-to-operation mapping, so a client cannot tell which of the 100 MCP tools or 25 REST operations a "write" grant actually unlocks.	authorizationCode, clientCredentials, refreshToken

📄 Provider scope reference: https://hunter.io/api-documentation/v2#authentication

Source

OAuth Scopes

generated: '2026-08-13'
method: probed
source: https://hunter.io/.well-known/oauth-authorization-server
docs: https://hunter.io/api-documentation/v2#authentication
description: >-
  Hunter's OAuth surface is not described in the OpenAPI (which declares only API-key and bearer
  schemes) and is not written up in the API reference. It was discovered by probing RFC 8414
  authorization-server metadata on hunter.io, which advertises exactly two coarse scopes.
  The remote MCP server at mcp.hunter.io publishes RFC 9728 protected-resource metadata naming
  the same two scopes and hunter.io as its authorization server.
schemes:
- name: OAuth2
  source: https://hunter.io/.well-known/oauth-authorization-server
  issuer: https://hunter.io
  registration_endpoint: https://hunter.io/oauth/register
  code_challenge_methods_supported: [S256]
  token_endpoint_auth_methods_supported: [client_secret_basic, client_secret_post, none]
  flows:
  - flow: authorizationCode
    authorizationUrl: https://hunter.io/oauth/authorize
    tokenUrl: https://hunter.io/oauth/token
  - flow: clientCredentials
    tokenUrl: https://hunter.io/oauth/token
  - flow: refreshToken
    tokenUrl: https://hunter.io/oauth/token
scopes:
- scope: read
  description: >-
    Read access. Granularity is not documented; Hunter publishes no scope reference page, so the
    mapping from this scope to individual endpoints or MCP tools is not stated anywhere public.
  flows: [authorizationCode, clientCredentials, refreshToken]
  sources: [https://hunter.io/.well-known/oauth-authorization-server, https://mcp.hunter.io/.well-known/oauth-protected-resource]
- scope: write
  description: >-
    Write access. Same caveat: no published scope-to-operation mapping, so a client cannot tell
    which of the 100 MCP tools or 25 REST operations a "write" grant actually unlocks.
  flows: [authorizationCode, clientCredentials, refreshToken]
  sources: [https://hunter.io/.well-known/oauth-authorization-server, https://mcp.hunter.io/.well-known/oauth-protected-resource]
gaps:
- id: no-scope-reference-page
  detail: Hunter publishes no scopes/permissions reference page; the two scopes are only discoverable from the discovery documents.
- id: coarse-granularity
  detail: >-
    Two scopes cover an API surface that includes destructive bulk deletes, CRM push and sending
    email sequences. A "write" grant is effectively full account control.