Threads that live on the graph.

Minting vs continuing

• Omit conversation: each request mints a fresh conversation. The id comes back in webel.conversation.
• Pass conversation: the request appends to that thread server-side, with its full history in context.

Continuing is also cheaper: you send only the newest user message while the model still sees everything before it. There is no separate "fetch history" call — the room is the source of truth.

{
  "model": "auto",
  "conversation": "1834708065435648",
  "messages": [{ "role": "user", "content": "Go on." }]
}

What the server remembers

• The full transcript of every turn in the thread — yours and the assistant's — in order, automatically included as context.
• Room memory. The engine's durable memory of your room (decisions, preferences, facts it has learned) informs replies the same way it does in the product.
• The room persona acts as the system prompt; your room's configured instructions apply to API turns too.

Because threads are ordinary Webel conversations, your team can open one in the app, read exactly what the integration said, and even step in. API work is never a black box.

Where API threads live

API conversations are stamped flavor: "api". They appear in your room's conversation picker under a dedicated filter, so integrations never pollute the human thread list by accident. The default view hides them; switch the filter to see API traffic alongside everything else.

Notes for multi-turn design

• The messages array must contain at least one user message; its last user message becomes the new turn. Earlier entries in the array do not replace the stored history — the thread's own history always wins.
• A conversation id from another room is rejected — keys act only inside their own room.
• Thread ids are stable; store them against your users or jobs to resume weeks later at full fidelity.