Authentication

Two credentials work everywhere; use the one that fits the caller.

API keys (scripts, servers, agents)

Keys are issued per user from an authenticated session (POST /api/v1/api-keys, or peer10 admin api-keys create) and carry that user’s role and org scope. Send as a header:

curl -H "x-api-key: p10_live_..." https://peer10.com/api/v1/games/upcoming

Bearer JWT (browser and mobile sessions)

Sessions authenticate with a Supabase JWT in an Authorization header. This is what the web app and the iOS app use; scripts should prefer keys.

curl -H "Authorization: Bearer eyJ..." https://peer10.com/api/v1/profile/me

What a credential can reach

Every request is tenant-scoped and role-gated server-side — repository constructors take the org id, middleware enforces route-level role minimums, and those gates are attacked in tests on every change. A key can never reach outside the org and role of the person who issued it, and access to children’s data additionally requires a real relationship — a role alone is not enough.