Happyrobot · Authentication Profile
Happyrobot Authentication
Authentication
Happyrobot secures its APIs with http, apiKey, oauth2, and openIdConnect across 3 declared security schemes, as derived from its OpenAPI definitions. OAuth 2.0 is offered via the authorizationCode, clientCredentials, and refreshToken flow(s).
ai-agentsagent-orchestrationvoice-aiconversational-ailogisticsfreightsupply-chainworkflow-automationcontact-centertelephonymcpagent-nativeagent-governanceenterprise-automation
Methods: http, apiKey, oauth2, openIdConnect
Schemes: 3
OAuth flows: authorizationCode, clientCredentials, refreshToken
API key in: header
Security Schemes
bearerAuth http
scheme: bearer
authorization apiKey
· in: header (authorization)
x-organization-id apiKey
· in: header (x-organization-id)
Source
Authentication Profile
generated: '2026-08-01'
method: searched
source: openapi/happyrobot-public-api-openapi.json
docs: https://docs.happyrobot.ai/api-reference
notes: >-
Derived from both OpenAPI documents, then upgraded with the three discovery documents probed live on
2026-08-01: the Auth0 OIDC configuration on auth.happyrobot.ai, the RFC 8414 OAuth authorization server
metadata on platform.happyrobot.ai (MCP), and the RFC 8414 metadata on docs.happyrobot.ai (docs MCP).
Happyrobot runs three distinct authentication planes: a bearer API key for machine access to the Public
API, an Auth0 OIDC tenant for human sign-in to the console, and OAuth 2.0 authorization servers fronting
its two MCP surfaces.
summary:
types:
- http
- apiKey
- oauth2
- openIdConnect
api_key_in:
- header
oauth2_flows:
- authorizationCode
- clientCredentials
- refreshToken
planes:
- plane: public-api
audience: machine / server-to-server
mechanism: Bearer API key
header: 'Authorization: Bearer <api_key>'
applied: >-
every operation in the v2 OpenAPI carries security [{bearerAuth: []}] and there is a matching
top-level security requirement, so the scheme is both defined and applied
scoping: >-
An API key is bound to one organization and one environment. GET /api-key/describe returns the key's
id, orgId, org_slug, org_name, name, prefix, lastFour, createdAt, lastUsedAt and revokedAt — so keys
carry a visible prefix + last-four for identification and support explicit revocation.
introspection_operation: GET /api-key/describe
example_prefix_observed: sk_live_
example_prefix_source: https://github.com/happyrobot-ai/chatbot-sdk-example
- plane: legacy-v1
audience: machine / server-to-server
mechanism: opaque token in an `authorization` header plus an explicit `x-organization-id` header
headers:
- authorization
- x-organization-id
applied: >-
every one of the ten v1 operations declares both headers as required parameters; the v1 document
defines no components.securitySchemes, so auth is expressed as bare header parameters
source: openapi/happyrobot-platform-v1-openapi.json
- plane: console-sign-in
audience: human
mechanism: OpenID Connect (Auth0 tenant)
issuer: https://auth.happyrobot.ai/
discovery: https://auth.happyrobot.ai/.well-known/openid-configuration
observed:
authorization_endpoint: https://auth.happyrobot.ai/authorize
token_endpoint: https://auth.happyrobot.ai/oauth/token
userinfo_endpoint: https://auth.happyrobot.ai/userinfo
jwks_uri: https://auth.happyrobot.ai/.well-known/jwks.json
registration_endpoint: https://auth.happyrobot.ai/oidc/register
end_session_endpoint: https://auth.happyrobot.ai/oidc/logout
revocation_endpoint: https://auth.happyrobot.ai/oauth/revoke
device_authorization_endpoint: https://auth.happyrobot.ai/oauth/device/code
mfa_challenge_endpoint: https://auth.happyrobot.ai/mfa/challenge
backchannel_logout_supported: true
id_token_signing_alg_values_supported:
- HS256
- RS256
- PS256
code_challenge_methods_supported:
- S256
- plain
client_flow_observed: >-
app.happyrobot.ai/login and /signup both 302 to auth.happyrobot.ai/authorize with
response_type=code, code_challenge_method=S256 and scope "openid profile email offline_access",
redirecting back to https://platform.happyrobot.ai/auth/callback — authorization code + PKCE.
- plane: platform-mcp
audience: agent / MCP client
mechanism: OAuth 2.0 with dynamic client registration
issuer: https://platform.happyrobot.ai
discovery: https://platform.happyrobot.ai/.well-known/oauth-authorization-server
observed:
authorization_endpoint: https://platform.happyrobot.ai/mcp/authorize
token_endpoint: https://platform.happyrobot.ai/api/mcp/token
registration_endpoint: https://platform.happyrobot.ai/api/mcp/register
grant_types_supported:
- authorization_code
- refresh_token
- client_credentials
code_challenge_methods_supported:
- S256
token_endpoint_auth_methods_supported:
- none
scopes_supported:
- mcp:full
- plane: docs-mcp
audience: agent / MCP client
mechanism: OAuth 2.0 with dynamic client registration
issuer: https://docs.happyrobot.ai/mcp/oauth
discovery: https://docs.happyrobot.ai/.well-known/oauth-authorization-server
protected_resource_metadata: https://docs.happyrobot.ai/.well-known/oauth-protected-resource
observed:
authorization_endpoint: https://docs.happyrobot.ai/mcp/oauth/authorize
token_endpoint: https://docs.happyrobot.ai/mcp/oauth/token
registration_endpoint: https://docs.happyrobot.ai/mcp/oauth/register
grant_types_supported:
- authorization_code
- client_credentials
- refresh_token
code_challenge_methods_supported:
- S256
token_endpoint_auth_methods_supported:
- none
- client_secret_post
- client_secret_basic
scopes_supported:
- mcp:search
challenge_observed: >-
POST tools/list without a token returns HTTP 401 with
'WWW-Authenticate: Bearer error="invalid_token", error_description="No authorization provided",
resource_metadata="https://docs.happyrobot.ai/.well-known/oauth-protected-resource"' — a correct
RFC 9728 challenge.
schemes:
- name: bearerAuth
type: http
scheme: bearer
bearerFormat: Opaque
applied_to_operations: 205
sources:
- openapi/happyrobot-public-api-openapi.json
- name: authorization
type: apiKey
in: header
parameter: authorization
sources:
- openapi/happyrobot-platform-v1-openapi.json
- name: x-organization-id
type: apiKey
in: header
parameter: x-organization-id
note: tenant selector, required alongside `authorization` on every v1 operation
sources:
- openapi/happyrobot-platform-v1-openapi.json
delegated_tokens:
note: >-
The Public API issues short-lived, scoped client tokens so browser code never sees the API key.
This two-tier model is documented in Happyrobot's own public SDK examples.
operations:
- operation: POST /chat/tokens/
returns: '{ token, expires_at }'
used_by: browser chat clients connecting to POST /chat/sessions/ and the session WebSocket
- operation: POST /voice/tokens/
returns: '{ url, token, room_name, run_id }'
used_by: browser WebRTC voice clients connecting to LiveKit
- operation: POST /realtime/tokens
returns: realtime session token
sources:
- https://github.com/happyrobot-ai/chatbot-sdk-example
- https://github.com/happyrobot-ai/voice-sdk-example
x-evidence:
fetched: '2026-08-01'
probes:
- url: https://platform.happyrobot.ai/api/v2/docs/json
http_status: 200
- url: https://platform.happyrobot.ai/api/v1/openapi.json
http_status: 200
- url: https://auth.happyrobot.ai/.well-known/openid-configuration
http_status: 200
- url: https://platform.happyrobot.ai/.well-known/oauth-authorization-server
http_status: 200
- url: https://docs.happyrobot.ai/.well-known/oauth-authorization-server
http_status: 200
- url: https://docs.happyrobot.ai/.well-known/oauth-protected-resource
http_status: 200