Authenticating requests with a Bearer hk_live_ key
The HIIE public API and MCP server use Bearer API-key authentication. You send your developer key in the Authorization header on every request.
The header
Send your key as:
Authorization: Bearer hk_live_<id>.<secret>
The base URL for the REST API is /api/v1, and the MCP server lives at /api/mcp.
What happens server-side
Every /api/v1 and /api/mcp handler authenticates the request as its first step. The server resolves your key to a tenant (your account), loads your entitlement, and then runs the underlying logic owner-scoped — the exact same code a signed-in session would run, so behavior is identical. Each request is also subject to a per-tenant rate limit, and build-scope calls are subject to the free-tier monthly programmatic spend cap.
Fail-closed behavior
Authentication is fail-closed. If required server infrastructure (the data store or the server-only key secret) is unavailable, the API returns a 503 rather than letting a request through unauthenticated.
Discovering how to authenticate
If you send an unauthenticated or invalid request, a 401 response includes a standards-based WWW-Authenticate header (RFC 9728) pointing at /.well-known/oauth-protected-resource. MCP and agent clients can follow that metadata to discover how to authenticate. Clerk is the interactive authorization server for human sign-in, while headless agents use the hk_live_ API key documented at /auth.md.
Two surfaces, one key
The same hk_live_ key works for both the REST API and the MCP server — the difference is the endpoint and protocol, not the credential.