Auth & Identity
Authentication
Every MUDBASE API request authenticates one of two ways — an API key for server-to-server calls, or a JWT for user-facing apps that need identity and RBAC. Most endpoints accept either; each one's reference page states which it requires.
API key (server-to-server, SDKs)
Create one from Console → API Keys (or POST /api/api-keys, which itself requires a JWT). Send it in the X-API-Key header:
X-API-Key: ak_live_xxxxxxxxxxxxxxxxxxxxxxxx
Content-Type: application/jsonX-API-Key: ak_live_xxxxxxxxxxxxxxxxxxxxxxxx
Content-Type: application/jsonAPI keys are project-scoped — the project comes from the endpoint's URL (e.g. /api/projects/{projectId}/...), not a header. Each key can be limited to specific permissions (database, storage, functions, auth, realtime) and has its own rate limit, default 1000 requests/hour.
JWT (user-facing apps, RBAC)
Obtained from a login/register endpoint (e.g. POST /api/auth/login). Send it in the Authorization header instead:
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Content-Type: application/jsonAuthorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Content-Type: application/jsonA JWT carries the authenticated user's identity and organization context, so it's the right choice whenever you need role-based access control or an audit trail tied to a real user — not just a project. See User Authentication for the full login flow.
X-API-Key and an Authorization: Bearer header, the JWT is tried first.Base URL
https://cloud.mudbase.devhttps://cloud.mudbase.devAuthentication Flow
Error Responses
| Status | Code | Meaning |
|---|---|---|
| 200 | ok | Request succeeded |
| 400 | bad_request | Check your request parameters |
| 401 | unauthorized | Invalid or missing API key |
| 403 | forbidden | Insufficient permissions for this action |
| 404 | not_found | Resource does not exist |
| 429 | rate_limited | Rate limit exceeded — see Retry-After header |