Me
3 Me routes on the FLAM API: The signed-in user; GDPR erasure — delete the caller's account; GDPR access — export the caller's own user row.
Base URL https://api.flam.fashion. Send Authorization: Bearer flam_sk_… on every call; a handful of routes are session-only and say so. How keys and roles work.
GET /me
The signed-in user
The Better Auth user row for the session cookie. Identity only — no house scope.
Responses
| Status | Meaning |
|---|---|
200 | The Better Auth user |
401 | No valid session |
200 returns:
{}Call it
curl -X GET "https://api.flam.fashion/me" \
-H "Authorization: Bearer $FLAM_API_KEY"POST /me/delete
GDPR erasure — delete the caller's account
ONE transaction. Every organization the caller is the SOLE member of is deleted FIRST (that CASCADEs its imagery, wallet and ledger), then the user row. A SHARED house survives its departing seat — the house is the brand, not the person. No body.
Responses
| Status | Meaning |
|---|---|
200 | Erased |
401 | No valid session |
200 returns:
{
"deleted": true,
"userId": "string"
}Call it
curl -X POST "https://api.flam.fashion/me/delete" \
-H "Authorization: Bearer $FLAM_API_KEY"GET /me/export
GDPR access — export the caller's own user row
Sent as an attachment (Content-Disposition: attachment; filename="my-data.json"). STARTER SCOPE — the Better Auth user row only; widen it before relying on this for a real DSAR.
Responses
| Status | Meaning |
|---|---|
200 | The export document |
401 | No valid session |
200 returns:
{
"exportedAt": "2026-07-27T09:00:00.000Z",
"user": {}
}Call it
curl -X GET "https://api.flam.fashion/me/export" \
-H "Authorization: Bearer $FLAM_API_KEY"