Authentication

Every authenticated request carries a bearer token in the Authorization header:

GET /api/v1/tracks HTTP/1.1
Host: www.aden.space
Authorization: Bearer <token>

The backend looks at the prefix to decide how to validate:

• Starts with aden_ → treated as a team API key.
• Anything else → treated as a Supabase JWT.

Team API keys

• Format: aden_live_<random>.
• Created from Team → Settings → API Keys in the web app.
• Hashed with SHA-256 at rest; the raw key is shown once at creation.
• Scoped to the team they were created in — the server binds requests to that team automatically.
• Rate-limited per team based on the team's plan.

curl https://www.aden.space/api/v1/tracks \
  -H "Authorization: Bearer aden_live_xxxxxxxxxxxxxxxxxxxxxxxx"

Scopes

Each key stores a list of scopes. Read endpoints are always allowed; write endpoints check against the key's scopes and return 403 if the scope is missing.

Supabase session tokens

User-facing apps authenticate with the same Supabase JWT the Aden web app uses. This keeps Row Level Security policies in force and ties requests to the real user.

const {
    data: { session },
} = await supabase.auth.getSession()

const res = await fetch('https://www.aden.space/api/v1/auth/me', {
    headers: { Authorization: `Bearer ${session?.access_token}` },
})

• Token expires and refreshes on Supabase's normal schedule — the SDK's getToken callback is the right integration point.
• Requests run under the user's identity; they can only see and mutate teams they're a member of.
• auth.me, user.*, and team-management routes require a session token (not an API key).

Choosing a mode

Anonymous access

A small set of endpoints don't need auth:

• GET /api/v1/health
• GET /api/v1/testimonials (public testimonials used on the landing page)

Everything else returns 401 { "error": "Unauthorized" } without a valid bearer token.