Context
In apps/api/src/routes/experiences.ts, the GET /experiences endpoint accepts an optional ?email= query parameter:
- It uses
email alongside deviceId to check permissions across purchases and free_downloads.
Current Usage Analysis
- In the mobile app, 100% of
fetchExperiences() calls rely strictly on the X-Device-Id header injected by ApiClient.
- Access grants from payments and free download leads are linked to
deviceId during the initial claim/purchase flow, making deviceId sufficient for playback and download authorization on the client.
Questions for Evaluation
- Redundancy: Is the
?email= query parameter on GET /experiences redundant with the device-centric access architecture?
- Multi-device vs Simplicity: Should we retain
?email= as an extensibility hook for future user accounts/cross-device sync, or simplify the endpoint queries to only rely on X-Device-Id to reduce query branching and complexity?
- Privacy & Consistency: If
email is passed as a query param in a GET request, consider potential log leakage vs header/token-based auth if retained.
Context
In
apps/api/src/routes/experiences.ts, theGET /experiencesendpoint accepts an optional?email=query parameter:emailalongsidedeviceIdto check permissions acrosspurchasesandfree_downloads.Current Usage Analysis
fetchExperiences()calls rely strictly on theX-Device-Idheader injected byApiClient.deviceIdduring the initial claim/purchase flow, makingdeviceIdsufficient for playback and download authorization on the client.Questions for Evaluation
?email=query parameter onGET /experiencesredundant with the device-centric access architecture??email=as an extensibility hook for future user accounts/cross-device sync, or simplify the endpoint queries to only rely onX-Device-Idto reduce query branching and complexity?emailis passed as a query param in a GET request, consider potential log leakage vs header/token-based auth if retained.