Auth pattern
Two different audiences, two different credentials. Do not send a Supabase user JWT to Event, and do not put EVENT_API_KEY in a browser bundle.
UIs: Supabase JWT
eventlinx-patron, eventlinx-promoter, and eventlinx-go authenticate people with Supabase. Session JWT stays on the client (or Expo secure storage) and is sent to that product’s BFF, not to Event.
eventlinx-api-authentication is the identity service used alongside that model. Exact IdP wiring beyond “UIs use Supabase JWT; identity service exists” is not duplicated here.
APIs: service keys
BFFs and Event talk to each other with service credentials, not end-user sessions.
| Hop | Auth |
|---|---|
| Browser / Expo → BFF | Supabase JWT (user). |
| BFF → Event | X-API-Key / EVENT_API_KEY. No end-user session on Event. |
| BFF → api-stripe / seating-detect / others | Service credentials from Worker secrets. Names only in docs. |
Event does not authorize “this patron” or “this scanner” by itself. The BFF authenticates the user, then calls Event as a trusted worker.
What to never publish
- API key values, “example” keys, or Petstore-style
special-key - Supabase service role or anon keys
- Connection strings
- Wrangler / Cloudflare tokens
Document the header name (X-API-Key) and the env var name (EVENT_API_KEY). Values live in Wrangler secrets per environment.
Client vs this site
Auth policy, PCI, and incident response live on client docs. This page is only the engineering split: Supabase on UIs, service keys between APIs.