Authentication
HG Insights supports two authentication methods:
- API key for direct integrations you control
- OAuth 2.1 (PKCE) for third-party apps acting on behalf of a user
Which Method Should I Use?
| Use Case | Recommended Method |
|---|---|
| MCP clients you configure directly (Cursor, Claude Code, Windsurf, n8n) | API key |
| Server-to-server scripts and internal automation | API key |
| ChatGPT custom GPTs and other user-consent integrations | OAuth 2.1 |
| Multi-tenant SaaS where each user authorizes their own account | OAuth 2.1 |
Rule of thumb: Use API keys unless a third-party app needs user-delegated access.
API Key Authentication (Recommended)
API keys are the fastest way to get started.
Get Your API Key
- Log in to HG Insights at phoenix.hginsights.com
- Navigate to MCP in the sidebar
- Copy your API key from that page
Keep your API keys secure. Never commit them to version control or share them publicly.
Using API Keys
MCP endpoints (API key in URL path)
https://phoenix.hginsights.com/api/ai/{YOUR_API_KEY}/mcp
https://phoenix.hginsights.com/api/ai/{YOUR_API_KEY}/sse
MCP endpoint (Bearer token)
For enterprise API gateways (e.g., Azure APIM) and server-to-server integrations, HG Insights exposes an MCP endpoint that accepts the API key as a Bearer token instead of in the URL path:
POST https://phoenix.hginsights.com/api/mcp
Authorization: Bearer phx_your_api_key_here
Both the URL-path (/api/ai/{key}/mcp) and Bearer token (/api/mcp) approaches provide access to the same MCP tools. Use Bearer token auth when your gateway or client manages credentials separately from URLs.
REST/Agents endpoints (Bearer token)
For documented REST and Agents endpoints that accept API key auth, pass it as:
Authorization: Bearer phx_your_api_key_here
Example:
curl -H "Authorization: Bearer phx_your_api_key_here" \
https://phoenix.hginsights.com/api/agents/v1/agents
API key bearer auth is not universal for every /api/* route in the webapp. Always follow the auth requirements in each endpoint's reference doc.
Security Checklist
- Rotate keys regularly — regenerate keys periodically and after any suspected compromise
- Never commit to version control — use environment variables or secret managers
- One key per integration — use separate keys for different applications to limit blast radius
- Revoke unused keys — delete keys for decommissioned integrations
OAuth 2.1 Authentication
HG Insights supports OAuth 2.1 Authorization Code flow with PKCE (S256) for third-party integrations.
Scopes
| Scope | Description |
|---|---|
mcp:read | Read company data via MCP tools |
mcp:tools | Execute MCP tools (default scope) |
offline_access | Issue refresh tokens for long-lived access |
Endpoints
GET /.well-known/oauth-authorization-server
GET /.well-known/oauth-protected-resource
POST /oauth/register
GET /oauth/authorize
POST /oauth/token
POST /oauth/revoke
Minimal Flow
- Register a client at
/oauth/register(or let the client auto-register). - Redirect the user to
/oauth/authorizewith PKCE (code_challenge_method=S256). - Exchange the authorization code at
/oauth/tokenusingcode_verifier. - Call the OAuth MCP endpoint with bearer token:
POST https://phoenix.hginsights.com/api/ai/mcp
Authorization: Bearer <access_token>
- Refresh tokens at
/oauth/token(grant_type=refresh_token) as needed.
Token lifetimes:
- Access tokens expire after 1 hour
- Refresh tokens expire after 30 days
Full OAuth request/response examples:
Common Issues
| Symptom | What to check |
|---|---|
401 on /api/ai/{apiKey}/mcp | API key format, key rotation, revoked key |
401 on /api/ai/mcp | Missing/invalid Authorization: Bearer <access_token> |
invalid_request with PKCE message | Include code_challenge/code_verifier and code_challenge_method=S256 |
invalid_request for redirect_uri | Redirect URI must exactly match the registered URI |
invalid_grant on token exchange/refresh | Code or refresh token expired, revoked, or already used |
For protocol-level troubleshooting, see OAuth 2.1 Reference.
Admin keys
Org admins can mint a privileged admin API key that authorizes management operations (invite users, configure integrations) on the MCP, admin REST, and Power Automate surfaces. Admin keys are scoped to a single organization. Their admin tools work only while the user who minted the key still holds an admin role on at least one team in that organization — see Admin Operations → overview for the full security model, the audit log, and the available admin tools. If they lose the admin role but remain a member, the key is not revoked: over MCP and Power Automate it is treated as an ordinary user key, while the admin REST endpoints reject it. If they lose access to the organization altogether, all of their keys for it are revoked and stop authenticating.
Authorization: Bearer phx_<your-admin-key>
Admin keys use the same phx_ prefix as user keys; the distinction lives
on the server side in webapp_api_keys_registry.scope.
An admin key exposes only the admin tools while its owner remains an org admin — the org's normal tools are not available to it, and vice versa. If you need both, keep two connections.
Once the owner no longer holds an admin role on any team, the admin tools stop
working for the key: the admin REST endpoints and the Power Automate facade
return 403 forbidden_admin_scope, and over MCP they disappear from
tools/list. The key itself keeps working over MCP and Power Automate, falling
back to user scope. If the owner loses access to the organization entirely,
every key they hold for it is revoked and stops authenticating.
Next Steps
- Set up your MCP client — client-specific configuration guides
- Browse MCP tools — see what tools are available
- Admin Operations — minting admin keys, audit log, security model
- Agents API Reference — run AI agents via REST API
- OAuth 2.1 Reference — full endpoint and payload details