Chat

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.

POST /api/chat

One turn of the loop

The house reads the message against the current draft and answers with what it said plus the mutations it applied. Every applied mutation is ALSO pushed over the job socket the moment it lands (turnId is echoed so the tab that asked does not render it twice). Free — a turn never spends tokens.

Request body — application/json (required)

{
  "message": "string",
  "draft": {},
  "history": [
    {
      "role": "director",
      "text": "string"
    }
  ],
  "screen": "string",
  "turnId": "string"
}

Responses

200 returns:

{
  "text": "string",
  "applied": [
    {}
  ],
  "mirror": {},
  "turnId": "string"
}

Call it

curl -X POST "https://api.flam.fashion/api/chat" \
  -H "Authorization: Bearer $FLAM_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"message":"string","draft":{},"history":[{"role":"director","text":"string"}],"screen":"string","turnId":"string"}'

POST /api/chat/apply

Undo, redo, and any direct edit

ONE door for both directions of the walk — undo posts the inverse, redo posts the mutation. Free by definition: a mutation never spends. A selection can only ever name pieces this house holds.

Request body — application/json (required)

{
  "draft": {},
  "mutation": {}
}

Responses

200 returns:

{
  "draft": {},
  "applied": {}
}

Call it

curl -X POST "https://api.flam.fashion/api/chat/apply" \
  -H "Authorization: Bearer $FLAM_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"draft":{},"mutation":{}}'