Authentication
Authenticate connector discovery and MCP calls with a CoreSpeed key or a WorkOS user session.
Every connector, MCP, memory, and account-management request is resolved inside a user and organization boundary. Two pasted credential types are accepted across three header forms, plus a browser OAuth flow for interactive MCP clients:
Long-lived CoreSpeed API key. Send it as a Bearer token or through x-api-key.
Short-lived WorkOS token. Send it through the Authorization header.
Interactive MCP clients (Claude Code, Cursor, VS Code) obtain a token through the browser — no key to paste.
| Header | Credential |
|---|---|
Authorization: Bearer <JWT> | WorkOS-issued OIDC JWT |
Authorization: Bearer <sk-cs-...> | CoreSpeed API key |
x-api-key: <sk-cs-...> | CoreSpeed API key |
Authenticate connector discovery
curl https://api.corespeed.io/connectors \
-H "Authorization: Bearer $CORESPEED_API_KEY"curl https://api.corespeed.io/connectors \
-H "x-api-key: $CORESPEED_API_KEY"The response is caller-specific: it includes visible connectors, connection status, account aliases, and whether this caller can remove an account.
Authenticate MCP
The same credentials work on the unified /mcp endpoint:
curl https://api.corespeed.io/mcp \
-H "Authorization: Bearer $CORESPEED_API_KEY" \
-H "Content-Type: application/json" \
-H "Accept: application/json, text/event-stream" \
-d '{
"jsonrpc": "2.0",
"id": 1,
"method": "initialize",
"params": {
"protocolVersion": "2024-11-05",
"capabilities": {},
"clientInfo": {"name": "my-agent", "version": "1.0.0"}
}
}'Create, rotate, cap, and revoke agent keys in Dashboard → Keys.
MCP OAuth (browser sign-in)
Interactive MCP clients can authorize /mcp with no pasted key. An
unauthenticated call returns a 401 whose WWW-Authenticate header advertises
the RFC 9728 protected-resource metadata; the client discovers CoreSpeed's
authorization server (WorkOS AuthKit), runs OAuth 2.1 + PKCE in the browser, and
retries /mcp with the issued token. The token is bound to the /mcp resource
(RFC 8707). See MCP endpoint for the client config and
the full flow.
Browser sign-in is rolling out per environment; the API key and WorkOS JWT above work everywhere today.
Requests without a bearer credential
GET /health is the only product endpoint in this documentation that needs no
caller credential. Artifact downloads use a short-lived signed URL instead of
the headers above; do not strip or reuse its signature.
Error responses
HTTP errors use a nested error object:
{
"error": {
"type": "authentication_error",
"message": "Authorization header or x-api-key is required",
"code": "missing_authorization"
}
}| Status | Code | When it fires |
|---|---|---|
| 401 | missing_authorization | No Authorization or x-api-key header |
| 401 | invalid_jwt | Bearer JWT failed verification |
| 401 | invalid_api_key | API key missing, revoked, expired, or unknown |
| 402 | payment_required | Organization is on a billing hold |
| 402 | key_spend_limit_exceeded | API key reached its monthly spend cap |
| 403 | org_suspended | Organization is administratively suspended |
| 500 | internal_error | Unhandled gateway error |
MCP tool failures can arrive inside an HTTP 200 response with isError: true.
Always inspect the JSON-RPC result in addition to the HTTP status.
visible tools can execute inside their account and budget boundaries
billable tools stop before execution; account and discovery reads remain available
adding balance does not restore access