Organization

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.

DELETE /api/toolkit/org/seats/{userId}

Empty a seat (or leave the house yourself)

Owner or admin — and anyone may remove THEMSELVES, which is how a person leaves. Deletes exactly one member row. NOTHING ELSE MOVES: every frame, model, look and collection keys to organization_id, and created_by_user_id is attribution only, so the work stays with the house and keeps their name on it. The founder of a personal house cannot be removed from it — the house's id is derived from theirs and a lazy repair would silently re-seat them as owner.

Parameters

Responses

200 returns:

{
  "userId": "string",
  "email": "string",
  "workStaysWithHouse": true
}

Call it

curl -X DELETE "https://api.flam.fashion/api/toolkit/org/seats/{userId}" \
  -H "Authorization: Bearer $FLAM_API_KEY"

POST /api/toolkit/org/seats/accept

Take an offered seat

Auth-gated, and the session's email must match the invited one. Writes the member row and makes that house the caller's ACTIVE one, so their very next request resolves to it rather than to their personal house.

Request body — application/json

{
  "invitationId": "string"
}

Responses

200 returns:

{
  "organizationId": "string",
  "organizationName": "string",
  "role": "owner"
}

Call it

curl -X POST "https://api.flam.fashion/api/toolkit/org/seats/accept" \
  -H "Authorization: Bearer $FLAM_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"invitationId":"string"}'

POST /api/toolkit/org/seats/invite

Invite a teammate into this house

Organization-level. Owner or admin only, and only an owner may offer an owner's seat. Re-inviting the same address supersedes the pending invitation rather than stacking a second one. NOT the platform gate (/api/toolkit/admin/invite).

Request body — application/json

{
  "email": "[email protected]",
  "role": "member"
}

Responses

200 returns:

{
  "id": "string",
  "email": "string",
  "role": "owner",
  "organizationId": "string",
  "organizationName": "string",
  "expiresAt": "string",
  "url": "string"
}

Call it

curl -X POST "https://api.flam.fashion/api/toolkit/org/seats/invite" \
  -H "Authorization: Bearer $FLAM_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"email":"[email protected]","role":"member"}'

POST /api/toolkit/org/seats/role

Change what a seat may do

Owner or admin. An admin may only re-seat a member or a viewer — never an owner, never another admin. owner is NOT settable here: handing the house over is POST /api/toolkit/org/transfer, which demotes the outgoing owner in the same write so a house never has two.

Request body — application/json

{
  "userId": "usr_eli",
  "role": "admin"
}

Responses

200 returns:

{
  "userId": "string",
  "role": "owner",
  "email": "string"
}

Call it

curl -X POST "https://api.flam.fashion/api/toolkit/org/seats/role" \
  -H "Authorization: Bearer $FLAM_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"userId":"usr_eli","role":"admin"}'

POST /api/toolkit/org/transfer

Hand this house to somebody else

OWNER ONLY, and the one route that can create an owner. The outgoing owner is demoted to admin in the SAME statement that promotes the new one, so the house never has two owners and never has none. Money follows the seat: canSpendMoney is owner only, so the plan, top-ups and purchases move with it immediately.

Request body — application/json

{
  "userId": "usr_eli"
}

Responses

200 returns:

{
  "organizationId": "string",
  "userId": "string",
  "email": "string",
  "previousOwnerRole": "admin"
}

Call it

curl -X POST "https://api.flam.fashion/api/toolkit/org/transfer" \
  -H "Authorization: Bearer $FLAM_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"userId":"usr_eli"}'