Custom Bots & Smart Apps | BotX API

The eXpress platform supports the creation of custom bots and SmartApps. You can create a bot or SmartApp on your own using the BotX API, or order one from the eXpress vendor.

Creating Bots & SmartApps

Can Regular Users Add Bots and SmartApps to the Server?

A user without administrator console access cannot add a bot to the server independently — to deploy a bot, they must contact their organization's support team.

Who Can Create Bots and SmartApps?

Bots and SmartApps can be created by:

• The eXpress development team. Requests for deployment and customization of such bots and SmartApps are submitted through the eXpress account manager or the sales department.
• The customer independently using the BotX API. API documentation is available via the links below.
• The customer's partners. Requests for customization of such bots and SmartApps are submitted through the partner organization's support team.

Is There a Bot Builder or an Analogue of Telegram's Bot Father?

No, bots must be created and connected to the corporate server on your own or through a custom development order.

How a Chatbot Works and Where to Start Development

A chatbot in eXpress is a separate user type backed by a web application on your organization's server. To an employee, the bot looks like a contact and a chat with it; to the platform, it is an HTTP service to which the corporate server forwards messages and from which it receives replies. There are three participants in this scheme.

Participant	What It Does
eXpress app	Shows the bot as a contact. Everything the user writes to the bot or taps in its messages goes to the corporate server as a regular message.
BotX on the corporate server CTS	The intermediary between the messenger and bots. Delivers messages to the bot via HTTP requests and receives requests from the bot to send messages, create chats, and search for users.
Bot backend	A web application on the organization's server, usually a Docker container. Receives commands from BotX, communicates with internal systems (Jira, 1C, email), and responds through BotX. Its address is specified by the administrator when creating the bot in the admin console.

This gives two APIs that are important not to confuse:

• Bot API is implemented by the bot itself: the addresses to which BotX sends user commands and system events (POST /command), message delivery results (POST /notification/callback), and a request for the list of commands for the chat menu (GET /status). The Bot API version is set in the bot card in the Protocol version field. Description — HTTP(s) Bot API v4 (in Russian).
• BotX API is provided by the platform: the methods the bot calls to act on its own behalf — send a message with buttons, create a chat, find a user, download a file. Description — HTTP(s) BotX API (in Russian); ready-made requests for typical cases — BotX API usage examples (in Russian).

What Happens When a User Writes to the Bot?

The message goes to the corporate server, and BotX delivers it to the bot with a POST /command request. The bot must respond within 5 seconds that it has accepted the command, otherwise the user sees “Failed to get a response from the bot.” After that, the bot works as long as needed and responds through the BotX API; the delivery result arrives to the bot as a separate request. The checkmarks on the user's message show these stages: one gray checkmark — sent, two gray checkmarks — BotX received it, two blue checkmarks — the bot confirmed receipt. Two blue checkmarks mean that the bot responded to the request, not that it completed the task. For details, see Development and debugging (in Russian).

Both directions are protected by the bot's secret key, which is created together with the bot in the admin console: BotX signs every request to the bot with it, and the bot uses it to obtain a token for the BotX API. Traffic between BotX and the bot goes without TLS inside the organization's network by default; encryption is enabled by uploading a certificate to the server and configuring it in the bot card — API overview (in Russian).

Where to Start Bot Development?

1. Understand the platform: what corporate and regional servers are, what the bot knows about users from other servers, and what the checkmarks mean — What chatbots and SmartApps are (in Russian).
2. Decide whether the bot needs its own user interface. If yes, it is a SmartApp — see the next subsection.
3. Prepare the server: Linux, Docker, PostgreSQL, Redis, and network access to the corporate server in both directions — Chatbot deployment (in Russian), “Prerequisites” and “System requirements” sections.
4. Register the bot in the admin console: Bots > Create bot, specify the name, APP_ID, backend URL, and protocol version, then save the ID and Secret key — Connecting a chatbot (in Russian). Who the bot is available to and what it sees in group chats is configured in the same place — Chatbot settings (in Russian).
5. Implement the Bot API and obtain a BotX API token — Bot API (in Russian), Bots API (in Russian).
6. Do not write everything from scratch: for Python there is the pybotx library, the async-box bot template, and the next-feature-bot and todo-bot examples — API overview (in Russian), “Libraries” and “Bot examples” sections; source code — GitHub ExpressApp. The language can be any: both APIs are plain HTTP with JSON.
7. Deploy the bot in Docker according to the Chatbot deployment (in Russian) instructions and update it according to Updating the application image (in Russian).

What Else the Bot Can Do

• Buttons under a message and a keyboard, widgets made of several messages — Notifications API (in Russian), Creating widgets (in Russian).
• A link or QR code that opens a chat with the bot and immediately sends it a command — Bot links with command sending (in Russian).
• Creating chats, managing participants and administrators, pinning messages, threads — Chats API (in Russian).
• Searching for users on its own server by email, login, or HUID — Users API (in Russian).
• Receiving and sending files — Files API (in Russian).
• BotX platform changelog by version — Changelog (in Russian).

How a SmartApp Works and Where to Start Development

A SmartApp is a chatbot that has its own interface: a single-page web application that opens inside eXpress. Everything said about bots in the previous subsection also applies to a SmartApp: it has the same backend bot, the same BotX, and the same two APIs. What is added is a frontend and a way to deliver it to the user.

SmartApp Part	What It Is
Frontend	A web application on any stack (React, Vue, Angular) that the eXpress app shows in an embedded window: on Web and Desktop this is an iframe, on mobile — a WebView. The frontend communicates with the messenger through the SmartApp SDK (in Russian) library: contacts, chats, files, secure storage, NFC, and Bluetooth.
Backend	A regular chatbot whose SmartApp block is filled in in the admin console. Stores the frontend static files, processes its requests, and communicates with the organization's internal systems — Backend (in Russian).
BotX on the corporate server CTS	The intermediary: the frontend never calls its backend directly. A request from the interface goes through the eXpress app to BotX, from there to the bot, and the response returns along the same path.

What Types of SmartApps Are There?

The developer chooses one of three types based on where the frontend comes from, and this determines the app's behavior without a network — Types of SmartApps (in Russian).

• Cache-based. The frontend is built into an archive (bundle) that the eXpress app downloads from the bot and stores on the device in encrypted form. It opens instantly and works offline. The most common choice for apps written from scratch.
• Non-cache-based. The frontend is requested from the bot every time, like a regular website. It does not work offline, but it can proxy files from the corporate network.
• Proxy-based. An existing internal web resource of the organization opens in the embedded window, with access through the corporate server. This is how ready-made systems are published without rewriting them. For limitations, see the What are the limitations of a Proxy SmartApp? subsection.

How Does the Frontend Communicate with the Bot?

The frontend calls an SDK method, the eXpress app passes the event to BotX, BotX delivers it to the bot as a system event in POST /command, the bot responds through the BotX API, and the response arrives in the frontend. This exchange is called SmartApp RPC — Backend (in Russian), “SmartApp frontend and backend interaction” section; frontend-side methods — Interacting with the bot (in Russian). The bot can also reach out to the user on its own: send a push notification or update the counter on the app icon — Push notifications (in Russian).

How the eXpress app displays the SmartApp — window size, docking to the panel, preloading, full-screen mode on mobile — is communicated by the bot through a manifest that it sends to BotX — SmartApp API (in Russian), “Sending the SmartApp manifest” section. A cache-based SmartApp also has a second manifest, inside the bundle: it sets the build version and the update method — Cache-based SmartApp (in Russian).

Where to Start SmartApp Development?

1. Choose the SmartApp type — Types of SmartApps (in Russian). If the goal is to show an existing system inside eXpress, a ready-made Proxy SmartApp from the collection is usually enough.
2. Design according to the plan from the documentation: the method for authenticating the bot in the external system, the specification of frontend ↔ backend requests, backend and frontend projects, build and publication — Development and debugging (in Russian).
3. Prepare the server and register the bot in the admin console in the same way as for a regular bot, additionally filling in the SmartApp block with the App ID — Chatbot/SmartApp deployment (in Russian).
4. Write the backend: a regular bot that additionally serves the frontend static files and processes SmartApp events — Backend (in Russian).
5. Write the frontend: connect the SmartApp SDK, call ready at startup, and follow the bundle build requirements — SmartApp SDK (in Russian), Cache-based SmartApp (in Russian).
6. Debug: the eXpress web app has a SmartApps debugging mode that opens a local frontend build instead of the published one; on iOS and Android, remote debugging is available through Safari and Chrome — Frontend (in Russian).
7. Send the manifest to BotX and deploy the bot; for a proxy-based SmartApp, you additionally need a subdomain of the corporate server and a certificate — Deployment and updating (in Russian).

What Else a SmartApp Can Do

• Open by a link from a chat or email and receive parameters — Deep links (in Russian).
• Appear in the contact card and in the “Send to” menu — Links in the contact card (in Russian), “Send to” menu (in Russian).
• Upload files from the device with media quality selection and open files — Files (in Russian), Working with files (in Russian).
• Store tokens and settings in secure storage on the device — Client-side data storage (in Russian).
• Read NFC tags and work with Bluetooth and geolocation on mobile — Devices (in Russian).
• Adapt to the app theme and language — Appearance (in Russian), Localization (in Russian).
• Let the user into an external system without a password through SSO — Backend (in Russian), “Authentication in integrated services” section.

BotX API

About bots in the knowledge base:

• General information about bots (in Russian)
• Bot developer guide (in Russian)

BotX API documentation:

• BotX documentation welcome page (in Russian)
• General description of BotX (in Russian)
• HTTP(s) Bot API v4 (in Russian) — the protocol for sending data from BotX to the bot (BotX → Bot). The protocol version is specified on the bot editing page in the admin panel, in the Protocol version field.
• HTTP(s) BotX API (in Russian) — the BotX service API. Allows the bot to interact with eXpress internal services.

SmartApps documentation:

• About SmartApps in the knowledge base — developer guide (in Russian)

GitHub repository with libraries and examples:

• ExpressApp (in Russian)