Everything you can do with MyChatBot

Get the owner's demo page — the live preview link for the sales assistant built from their website at signup. Use when the owner asks to see that demo or preview, for example 'show me my demo', 'open my demo', 'show me the demo page', 'where is my preview link' or 'show me my sales assistant'. It is the only tool that returns that link. Signup offers to build one from the owner's website, so it often already exists, and the link shows their own sales assistant answering questions about their own business. To show that demo, use this tool, not create_website_widget, which sets up or changes the website chat widget itself. Read-only.

No parameters.

Draft a customer-facing AI sales assistant for the user's own business — a shop, store, online business or service — that answers that business's customers on its website, Telegram, Instagram, Messenger or WhatsApp, and show it on an approval card. Use when the user asks to set up a sales or support assistant, a chatbot, automatic replies or 24/7 support for their own business's customers. Draft the assistant first (research the business, then write the greeting, the instructions and the starter knowledge) and pass the whole proposal here. Nothing is created until the owner approves it on the card.

Build the assistant exactly as proposed. Called only after the owner approves the card.

Put a live chat widget on the owner's website — the chat bubble visitors click to ask questions. Use for 'add chat to my site', 'a chatbot on my website', 'live chat for my store', or putting an existing sales assistant on a web page. The one channel that connects fully from here, no dashboard needed: returns a ready-to-paste embed snippet plus a hosted page URL so it can be dropped onto any site (or tried immediately on the hosted page). Calling it again with the same widget_id for the same assistant does not create a second widget: it updates that widget in place. Every setting passed here replaces the saved one (an empty pop_up_text removes the popup, ad_oriented false switches the teaser card off), settings not passed are kept, and the widget is switched back on. A widget_id owned by a different assistant is refused. Omit widget_id to use the assistant's default widget — if signup already built a demo widget for this assistant, that one is returned rather than a second one created, and any settings passed are applied to it (website_url changes the site its demo page shows). NOT for showing an existing demo: 'show me the demo page' / 'show me my sales assistant' / 'where is my preview link' are get_demo_status, which returns the page they already have. The widget has many more settings than this tool takes — which details the contact form asks for (name/email/phone), button position and size, popup timing, margins. For any of those, the result carries a config_link: it opens that widget's settings page and signs the owner in. All of it is editable there. Calling this tool again leaves those settings as they are; re-creating the widget under a new widget_id makes a second, separate widget.

Creates a Calls channel so visitors can click and TALK to the assistant instead of typing, and returns its agent_id, two embed snippets (plain HTML and npm) for putting the call button on a site, and a settings link. It needs no credentials and completes here, like the website widget. An assistant that already has a voice channel gets that channel's snippets back rather than a second one. The voice demo built during signup is a different thing: get_demo_status returns its preview page.

Get the dashboard link for connecting Telegram to an assistant. Telegram authorization can only be completed in the MyChatBot dashboard, so this returns a deep-link ({url}) for the owner to open in their browser — present it as "finish connecting in your dashboard (login required)". Read-only: this call connects and changes nothing by itself.

Get the dashboard link for connecting WhatsApp to an assistant. WhatsApp authorization can only be completed in the MyChatBot dashboard, so this returns a deep-link ({url}) for the owner to open in their browser — present it as "finish connecting in your dashboard (login required)". Read-only: this call connects and changes nothing by itself.

Get the dashboard link for connecting Instagram to an assistant. Instagram authorization can only be completed in the MyChatBot dashboard, so this returns a deep-link ({url}) for the owner to open in their browser — present it as "finish connecting in your dashboard (login required)". Read-only: this call connects and changes nothing by itself.

Get the dashboard link for connecting Messenger to an assistant. Messenger authorization can only be completed in the MyChatBot dashboard, so this returns a deep-link ({url}) for the owner to open in their browser — present it as "finish connecting in your dashboard (login required)". Read-only: this call connects and changes nothing by itself.

Get the dashboard link for connecting TikTok to an assistant. TikTok authorization can only be completed in the MyChatBot dashboard, so this returns a deep-link ({url}) for the owner to open in their browser — present it as "finish connecting in your dashboard (login required)". Read-only: this call connects and changes nothing by itself.

Let a sales assistant take orders in conversation. Until this is on the assistant can answer questions and recommend products but cannot close a sale — it has nowhere to record what the customer wants, so it hands off to a human instead. Turn it on once the catalog is imported. Safe to call again to change the settings; it will not create a second setup. Omit required_fields/item_fields to accept sensible defaults (name, phone, delivery address, optional email; quantity per item).

Stop a sales assistant from taking orders. It keeps answering questions and recommending products, but can no longer record a sale. Existing orders are kept. If no other assistant on the account takes orders, the order-form setup (fields, currency, payment rule) is removed with it — enabling again starts from defaults.

Disconnect one channel from a sales assistant: the platform stops delivering and the connection is removed. Conversations are KEPT — the assistant just stops getting new messages there. This is the right tool for 'take it off Telegram' or 'stop it answering on the website'. Use list_channels first to get the exact channel name.

Permanently delete a sales assistant. THIS ALSO DELETES EVERY CONVERSATION IT HAS HAD WITH CUSTOMERS, plus its channels, skills and tasks. There is no undo and no export. Intended for removing a sales assistant created by mistake — a duplicate from a repeated setup, say. If the assistant has any conversations this call fails and reports how many, leaving everything intact; setting delete_conversations then deletes those conversations along with the assistant, permanently and with no export. When the owner only wants the assistant to stop working, delete_channel does that instead and keeps the history. If the owner hasn't said which sales assistant and the account has more than one, list them by name and ask which before calling this.

Teach the sales assistant a business's website so it answers from the real pages — prices, products, delivery, opening hours, policies. Use for 'answer from my website', 'learn my site', 'use my shop's pages', or when the owner names a site as their source of truth. It is a LIVE source: the sales assistant searches the site and reads pages at answer time, so there is nothing to upload and no indexing wait. The knowledge_base group name links sources to assistants: pass assistant_id to attach the assistant that should use it. The reply's attached_assistants lists the assistants that answer from the group.

Create a new FAQ knowledge base integration for the owner's assistant. Optionally seed it with initial entries. Each entry needs an id, question (short title), and answer (detailed text). The knowledge_base param groups integrations — use an existing group name to add to that group, or pick a new unique name. Check list_integrations first and prefer updating an existing FAQ integration over creating a duplicate.

List all entries in a FAQ knowledge base integration. Returns the full list of FAQ items with their IDs, questions, and answers. Omit integration_id when the account has only one FAQ — it is resolved for you; with several, the error names them. Note that a 'Site link' integration is NOT an FAQ knowledge base even though list_integrations marks both as knowledge bases — passing its id here fails.

Modify entries in a FAQ knowledge base. Supports three granular operations (use any combination): add (new entries to append, or replace one with the same id), update (existing entries to change, matched by id), remove (entry IDs to delete). The backend reads the current entries, applies your changes, re-uploads, and re-indexes.

Create a Products integration — a manually-managed product catalog the assistant answers from. Optionally seed with initial products. Each product can have arbitrary attributes (name, description, price, url, image_url, category, and any custom keys). Processing is asynchronous — returns immediately while indexing happens in the background; check status with get_integration. Check list_integrations first and prefer one catalog per account over duplicates.

List the products in a catalog. Omit integration_id to be answered for the account as a whole: one catalog is opened directly, several come back as a list of catalogs with each one's live counts, and none says so. A manual Products catalog and a Product Spreadsheet (a connected Google Sheet) return a page of products — read a large one a page at a time by passing next_offset back as offset. A Product Feed is indexed for search rather than stored as a list, so it reports live counts and its source feed URL rather than items; every response says which kind it is in type, and whether it can be paged in products_listable. Note that a 'Site link' integration is NOT a product catalog even though list_integrations marks both as knowledge bases — passing its id here fails.

Modify products in a Products integration. Supports three granular operations (use any combination): add (new products to append; each must have 'name', other keys are arbitrary), update (existing products to change, matched by id, merges provided fields), remove (product IDs to delete). The backend reads current products, applies changes, re-uploads, and re-indexes.

Create a Product Feed integration that indexes products from a feed URL for semantic search. Supports JSON, XML, Google Shopping, YML, and similar feed formats. A Shopify store works too: its storefront URL (https://yourstore.com) or /products.json URL is read from the store's public catalog, with no Shopify app or API keys. Each Shopify product is indexed once with all its variants (options, price, sale price, in stock or sold out, SKU), images and link, and an assistant that uses this catalog can send shoppers a checkout link that opens the store's own Shopify checkout with the chosen items in the cart. Password-protected stores, and stores that block /products.json, cannot be read this way; a Google Shopping feed URL from a feed app works for the catalog, without checkout links. Prices and stock are as of the last sync, and autoupdate_interval_hours re-syncs on a schedule. Processing is asynchronous — returns immediately while indexing happens in the background. Use get_integration(integration_id) to check processing status.

Connect a Shopify store's catalog to the owner's sales assistants in one step. The store is checked first through its public storefront — no Shopify app or API keys — and the reply names the shop, its primary domain and currency; the catalog is then imported as a Product Feed that re-syncs on a schedule. Each product arrives with all its variants (options, price, stock), and assistants that use the knowledge base send shoppers checkout links that open the store's own Shopify checkout with the chosen items in the cart. The catalog joins the knowledge base named in knowledge_base; pass assistant_id to attach the assistant that should sell from it. Without it, the catalog is attached only when exactly one assistant has no knowledge base yet — the reply lists the assistants that answer from it, and says what to do when none was attached. Accepts the store address in any form: yourstore.com, https://yourstore.com, yourstore.myshopify.com, the Shopify admin URL, or a /products.json or collection URL (then only that collection is imported). A password-protected store, one that blocks its public catalog, or a site that is not Shopify is reported back in plain words and nothing is created. For 'sell my Shopify store', 'connect my Shopify shop', 'import my Shopify products'.

List all integrations for this account: CRMs, knowledge bases, MCPs, automations. Supports filtering by type. Shows which FAQ knowledge bases and product catalogs already exist on the account.

Get detailed info about a specific integration including metadata and configuration (sensitive fields stripped). Also the way to check async indexing status after creating or updating a catalog or feed.

Permanently delete an FAQ knowledge base and everything the sales assistant learned from it. Cannot be undone — the answers are gone and the assistant stops using them immediately. Use list_integrations first and confirm which one with the owner by name; ids are not interchangeable and this refuses anything that is not an FAQ.

Permanently delete a manually-added products catalog and everything indexed from it. Cannot be undone. This is for catalogs whose products were added by hand — for one imported from a feed URL use delete_product_feed_integration. Each refuses the other's type, so check with list_integrations first.

Permanently delete a product feed (a catalog imported from a feed URL) and everything indexed from it. Cannot be undone, and it stops the feed being re-imported. For a hand-built catalog use delete_products_integration instead — each refuses the other's type.

Business pulse for a period on the connected MyChatBot account: total orders, active chats, new clients, and LLM activity (requests + tokens). Both dates are optional — omit them for the upstream default period. Read-only. The response may include an `errors` map when a sub-source failed to load; the affected counter is unavailable rather than zero, and a narrower date range usually succeeds.

Order statistics for the connected account over an optional period: total orders, total revenue, and breakdowns by channel and by status. Revenue is in the shop's own currency and is NOT normalized — present it as a bare number without inventing a currency symbol. Read-only.

List orders on the connected account with optional filters: period, client, status (pending, awaiting_payment, paid, in_progress, completed, cancelled), source channel, order reference, assistant. Offset pagination, applied after filtering: limit ≤ 200 (default 50), and the response's `total` is the filtered count before pagination while `count` is the rows returned. Read-only.

List recent chats sorted by last_active descending (most recent first), max 100 per call. Returns {chats: [...], count, next_last_active_before, next_before_id}. To page through more chats, pass next_last_active_before as last_active_before AND next_before_id as before_id from the previous response, then call again (keyset pagination); repeat until fewer than `limit` rows come back. Paging is only exact with both cursor fields: next_last_active_before carries full sub-second precision (unlike the seconds-precision last_active shown on each chat), and next_before_id keeps paging exact when many chats share one timestamp. There is no offset parameter. Combine last_active_after and last_active_before to fetch a specific date window. Both accept RFC3339 timestamps (fractional seconds allowed) or date-only YYYY-MM-DD; a date-only value always means UTC start of day (00:00), so for the window 2026-07-25..2026-07-31 inclusive pass last_active_after=2026-07-25 and last_active_before=2026-08-01. Shows client name, channel, last active, unread count, and whether operator is needed. A chat with communication_channel="Calls" represents a phone call — its message history is the call transcript (use get_chat_messages). Every filter is optional; omit a field to include all values for it.

Get detailed info about a specific chat including metadata, follow-up state, and channel info. chat_id is the small integer `id` returned by list_chats — not page_id, not common_client_id, not any channel-specific external id. The response distinguishes three ids: `id` (the canonical chat id), `client_id` (per-channel external id), and `common_client_id` (the unified client UUID = clients.id); these are three different values.

Read the message history of a specific chat. Returns the last N messages with role, content, and timestamp. For chats with communication_channel="Calls", the message history is the call transcript — there is no separate transcript endpoint.

List clients (leads/customers) with filtering by funnel status, labels, search, and pagination.

Get detailed info about a specific client (lead/customer) including contact info, funnel status, labels, and metadata. The response includes metadata.client_context — a map of custom fields collected from the client (only populated when the assistant has 'Client Context' enabled). Cross-reference the keys with the assistant's client_context_schema to render human-readable labels.

Check which plan the account is on and how many AI replies are left. Use this when the owner asks what they are paying for, how much trial they have left, or why their sales assistant stopped answering. Read-only.

No parameters.

List all active sales assistants for this account. Returns id, name, status, language, and model. Use it to resolve the assistant_id that send_one_off_message and the outreach campaigns require.

No parameters.

List all connected channels (Telegram, WhatsApp, Instagram, Email, etc.) with their status; sensitive credentials are stripped. Shows what is connected: the communication_channel that send_one_off_message accepts and the outreach_channels a campaign accepts both come from here.

Send a single ad-hoc message to a specific lead through any connected non-Calls channel (WhatsApp, Telegram, Email, Instagram, Viber, etc.). Use for operator-style 'remind John about his appointment' situations. For multi-recipient campaigns use immediate_outreach_create. The message is written to the lead's chat history just like a normal reply, so it shows up in the chat panel. Sending is immediate and cannot be recalled or edited: the customer receives it on the named channel as soon as this returns. Channel names come from list_channels.

Preview how many clients match a campaign's filters. Read-only: it creates nothing and sends nothing. Reports the audience size immediate_outreach_create would reach with the same filters.

Create and schedule an immediate outreach campaign to many leads at once. Returns the matched audience count. Sending starts immediately and reaches every matched customer on their channel; the messages cannot be recalled. immediate_outreach_preview_audience reports the same audience count without creating or sending anything.

Pause, resume, or reset an immediate outreach campaign. Use 'user_paused' to pause, 'scheduled' to resume, 'draft' to reset (clears all progress and stats).

List follow-up automations (outreach campaigns). Supports filtering by type and status.

Get detailed info about a follow-up (outreach campaign) including steps, filters, and execution stats.

Start a test chat session with an assistant to try it from right here, before (or without) putting it in front of customers. The assistant_id is the session key — one test session per assistant — and starting clears any previous test chat history. Test chats are free: rehearsal replies do not spend the account's token balance.

Send a message in the assistant's test chat session and get its reply. Synchronous: waits for the full model response, generated from the assistant's current LIVE instructions and skills. Test replies are free — they do not spend the account's reply balance. When that balance runs low — live customer replies do spend it — a clearly-marked balance_warning line is appended below the reply.

End the assistant's test chat session and clear its history. The assistant_id is the session key. Call this when a test conversation is done — a later test_chat_start also starts clean.

Render a review card for changing an assistant's instructions (system prompt): fetches the CURRENT instructions and shows them next to your PROPOSED replacement so the owner can compare before anything happens. NOTHING is saved by this call — the card's Confirm button performs the update (via update_assistant_instructions), same rule as the setup flow: nothing changes until the owner says so. This is the recommended path for every instructions edit. The proposed text must be the COMPLETE new instructions (full replacement, not a diff).

Replace an assistant's instructions (system prompt) with new text — the WRITE behind propose_instructions_update's Confirm button. The card is the recommended path (propose first, let the owner confirm); call this directly only when the owner has already approved the exact text in conversation. Full replacement; the platform runs a moderation check before saving and rejects flagged content.