Help that knows who is asking.
An in-app AI chat SDK for SaaS and mobile apps
Put the AI support chatbot inside your product with the JavaScript or Flutter SDK. Your server vouches for the signed-in user, so Kothadesk can greet them by name, remember what they told it last time if you allow it, and look up their own orders or account through your API.
01
What changes for your users.
Before
- Help lives on a separate site, and users leave the app to find it.
- Every chat starts with “what's your email and order number?”
- A generic chatbot can explain the refund policy but cannot see the refund.
With Kothadesk
- The chatbot opens inside the screen the user is on, on web, iOS and Android.
- The user is already identified by your server, with the context you choose to share.
- Tools call your API for that user only, and ask before changing anything.
02
The building blocks of in-app chat.
- SDKs for web and mobile
- A typed JavaScript SDK and a Flutter SDK with a drop-in chat screen and launcher.
- Signed identity
- A short-lived token signed by your server. Browsers cannot claim to be someone else.
- Opt-in memory
- For signed-in users only: short, encrypted facts and preferences, which users can ask it to forget.
- Tools with confirmation
- REST tools and remote MCP servers. Reads run on their own; writes ask the user first.
03
SDKs for web, iOS and Android.
Signed-in customers download the SDKs from the Developers page of the dashboard. They are not published on npm or pub.dev.
| Package | Version | What it gives you |
|---|---|---|
| Flutter SDK (kothadesk_sdk) | 0.4.0 | A drop-in chat screen and launcher for iOS and Android, live support, and optional file and voice add-ons |
| JavaScript SDK (@kothadesk/sdk-js) | 0.4.0 | A typed client that streams tokens, citations and images for your own chat interface |
| Web widget | 0.6.0 | The one-tag widget, also as a self-hostable build |
04
Memory for signed-in users.
With memory on, a returning user does not have to repeat their plan, their store or how they like to be contacted.
- Short, stable facts
- Such as prefers email over phone calls, or is on the Pro plan. Kept per bot, encrypted, with their own retention.
- Off by default, and forgettable
- Only for users your server has signed in. Users can ask the chatbot to forget what it remembered.
05
Tools over REST or MCP.
Describe one or two API endpoints in the dashboard, or run an MCP server when you want a set of actions managed in one place.
- REST tools
- Nothing to deploy: a URL, a method, an input schema and a credential. The signed-in user's id can be part of the URL.
- Remote MCP servers
- Connect a server over Streamable HTTP; its tools are discovered and you enable them one by one. Complete Python and Node.js samples are in the guide.
06
A signed-in conversation.
- Visitor
Where's my last order?
- Checking your order
- Assistant
Your order 10482 left the warehouse yesterday and is due on Thursday.
- Visitor
Can you change it to express delivery?
- Assistant
I can upgrade order 10482 to express delivery for the listed fee. Shall I go ahead?
The second request uses a write tool, so the widget shows a confirmation card before anything changes.
07
Two pieces of code on your side.
Sign a token on your server, and describe the API calls the chatbot may make for that user.
server/identity.js
// On your server, never in the browser.
import jwt from "jsonwebtoken";
export function chatIdentityToken(user) {
return jwt.sign(
{
sub: user.id,
name: user.name,
email: user.email,
aud: "bot_01J9ZKQ3M4X8R2T6V0B1C5D7EF",
ctx: { plan: user.plan },
},
process.env.KOTHADESK_IDENTITY_SECRET,
{ algorithm: "HS256", expiresIn: "10m" },
);
}{
"name": "get_order_status",
"display_name": "Checking your order",
"description": "Look up the status of one of the signed-in customer's orders.",
"input_schema": {
"type": "object",
"properties": { "order_id": { "type": "string", "pattern": "^[0-9]{1,10}$" } },
"required": ["order_id"],
"additionalProperties": false
},
"method": "GET",
"url": "https://shop.example.com/api/customers/{{end_user.sub}}/orders/{{args.order_id}}",
"auth": { "type": "bearer", "secret": "write-only" },
"side_effect": "read",
"requires_identity": true
}08
Setup.
- 01
Add the widget or an SDK
Script tag on the web, the Flutter SDK in your apps. - 02
Generate the identity secret
Keep it on your server; sign a token per session. - 03
Register tools
Mark each as read or write, and whether it needs a signed-in user. - 04
Turn on memory if you want it
Per bot, off by default, with its own retention.
09
Questions from product teams.
How does the assistant know who the user is?
Your server signs a short-lived token with your workspace's identity secret. The widget or SDK passes it on, and Kothadesk verifies it. Nothing the browser says about identity is trusted otherwise.
Can a tool change data in our system?
Yes, if you allow it. Write tools ask the user to confirm in the chat before they run, unless you explicitly enable automatic runs for that tool.
10
Related guides.
Step-by-step setup, with worked examples by business.
Put answers where your users already are.
Start on the free plan with your own AI key. No card needed.