SDK reference

Every Telybot SDK — Android, iOS, React Native, Flutter, Ionic — implements the same small contract. If you have used one, you have used all of them.

The API

Open with a question. Pass a question to show and it is put in the chat's message box; the customer reads it and taps send. It travels in the link's #fragment, so it never reaches a server log. Up to 500 characters, as one line.

The chat inside your own screen. Android KeydaBotView, iOS KeydaBot.makeChatViewController or SwiftUI KeydaBotView, React Native <KeydaBotChat />, Flutter KeydaBotChat, and the Ionic package's embedWidget(). It has no close button — your screen's navigation is the way out. On Android, back closes an open item or cart first: React Native and Flutter do this for you while the chat is the screen in front, and with the native KeydaBotView your back handling calls its goBack().

Your signed-in customer. Give the SDK your customer's name, phone number or email and the chat fills in what your app already knows. The details are offered, never sent: they appear in the "talk to a person" form, an order, a booking and a welcome question for a name, phone or email, and the customer submits them. They travel in the link's #fragment and are your app's word, not a verified identity. A value the chat would refuse is left out: a name longer than 80 characters, a phone number without 8 to 15 digits, an email address without a proper domain. Ionic's full-screen chat opens in the system browser, which keeps addresses in its history, so it does not take them; its embedded widget does.

A reply while the chat is closed. When a customer asks for a person and closes the chat, your answer from the dashboard waits in the conversation. The SDKs for Android, iOS, React Native and Flutter check for it when your app comes to the foreground and tell your app, so you can show a dot on your chat button until the customer opens the chat. They ask only about chats in which the customer asked for a person in the last 14 days. A chat your app keeps loaded out of sight, such as a Help tab in the background, does not count as read: the dot stays until the customer looks. This is not a push notification: a reply is noticed when the app is opened.

There is deliberately nothing else. No message-sending API and no user identity call — because neither works end to end yet, and a method that does not work is worse than a missing one.

The URL every SDK opens

{baseUrl}/chat/{clientId}

baseUrl defaults to https://telybot.com and is overridable on every platform, for staging or a self-hosted install.

Why a web view, and what it costs you

There is one chat interface, served by the platform, and every surface loads it.

What you get: a change an owner makes in the dashboard — accent colour, welcome message, bot name, going live — reaches every app immediately, with no release. A fix lands everywhere at once. The chat is identical across platforms.

What it costs: the chat needs a connection. There is no offline mode, and there are no push notifications yet.

We would rather you know this before you ship than discover it afterwards.

Guarantees each SDK makes

1. Navigation escapes. A link to any other origin opens in the system browser instead of replacing the chat. Without this, one tap on a footer link ends a customer's conversation with no way back.
2. Conversation continuity. DOM storage is on, so a customer who closes the app and comes back finds their thread where they left it (for 24 hours).
3. The keyboard never covers the input.
4. Safe areas are respected — no chat drawn under a notch or a home indicator.
5. No crash reaches your app. A failed load shows a retry.
6. No analytics, no device identifiers, no third-party dependencies. Adding a Telybot SDK does not add a tracker to your app.
7. Back closes what the customer is looking at first. On Android, back over an open item, cart or booking closes that, and only then the chat (SDK 0.2.0 and later).

Inside the chat

All of this comes from the hosted page, so it reaches every app without an SDK update:

• A welcome message with suggestion buttons, in the language the bot is set to.
• The conversation is kept on the device for 24 hours, and the chat makes no visitor id. On a website a conversation lasts one browser tab. (The Ionic SDK's full-screen chat needs 0.2.0 for this.)
• Orders and bookings, when the business takes them: a cart, booking dates and times, a link to call the business when an order or booking has waited too long, and "Add to calendar" for a confirmed booking.
• Attachments: photos (JPEG, PNG, WebP, GIF) and PDF, DOCX, TXT, CSV and MD files. The Android and Flutter SDKs need 0.1.4 or later for the attach button, and Flutter needs 0.2.0 for documents.
• "Add to calendar" is a link to an .ics file. iOS opens it in Calendar as a calendar to subscribe to. Android offers the phone's calendar app when it imports .ics files — current Google Calendar does — and otherwise the browser downloads the file.

Client id format

kb_live_ followed by 8-48 hexadecimal characters

Anything else is rejected at init rather than opening a 404 in front of a customer. The client id is public by design — it is visible in any website that embeds the widget — and carries no ability to read or change your account. See limits and security.

Source

Public, MIT-licensed: github.com/telybotai/telybot-Sdks. The shared contract every package is held to is in CONTRACT.md at the top of that repo.