Guides

Serving many users

Your app has many people and one FactQL key. Tell FactQL who is asking, and each person gets their own private chats.

Send X-End-User-Id

On every conversation call, set X-End-User-Id to a stable id for the signed-in person, set by your server.

curl -N -X POST "https://api.factql.ai/clients/$CLIENT_ID/ask/stream" \
  -H "X-API-Key: $FACTQL_API_KEY" \
  -H "X-End-User-Id: user-4821" \
  -H "Content-Type: application/json" \
  -d '{"query": "Top 5 customers by spend", "new_session": true}'

What it changes

Private chats. Chats started with an end-user id belong to that person. Another id gets 404 for them.
Separate memory.One person's earlier questions never shape another person's answers.
Same limits.Rate limits and spend still count against your account, and workspace access doesn't change.

Always send the header when a person is behind the call.A request without it acts for your whole account: every question shares one default chat, so one person's questions can shape another's answers, and it can open and continue any end user's chat by its session_id. Keep header-less calls for your own server jobs.

Choosing the id

Use your own user id, or a hash of it. Don't use an email address.
1 to 128 characters: letters, digits and . _ : @ + -. Anything else returns 400.
Keep it stable. A new id means a new person with no chats.

The header isn't authentication. Anyone holding your key can send any value, which is one more reason the key stays on your server. If your app calls FactQL straight from the browser, use an ask-only key: it can't manage your account or change data, and it requires the header on every chat call.

Chats in your UI

Start each new chat with new_session: true and store the session_id FactQL returns against the chat in your app. Send it with every follow-up. Your app never makes up session ids; one it invents returns 404.