Your own Telegram bot

The template

A working skeleton lives in our repository under examples/partner-bot. Fork it and rework it — it is a starting point, not a library.

cp .env.example .env      # bot token + your rsk_ key
docker build -t partner-bot .
docker run -d --env-file .env -v "$PWD/data:/data" partner-bot

Out of the box: /start asks for an email and creates the account, /trial grants a trial within your budget, /my shows the state. Inside: 429 handling that honours Retry-After, human wording for an exhausted budget, and SQLite holding nothing but the "telegram id → account" mapping.

Architecture

The bot is your process, in any language. It holds three things: a Telegram token, your rsk_ key, and its own mapping of "Telegram user → Logrus account". All VPN work is delegated to our API; the bot handles UX and selling.

The minimal sign-up flow:

1. The user taps Start → the bot creates an account: POST /api/v1/reseller/accounts with email and external_ref set to their Telegram id.
2. The response carries generated_password, once. The bot hands the credentials to the user and does not store the password.
3. The user installs the app, signs in with those credentials, and gets your brand and your nodes.

Security rules

• The rsk_ key lives only on the bot's server. It creates accounts and changes your prices; it does not belong in a client app, a repository, or a log line.
• Ask for a bot key scoped to accounts:write (plus accounts:read if you need the list) — no price or payout rights.
• external_ref is your identifier for the user; it is how you reconcile your database against our customer list later.

What the bot cannot do

Take money. Payment goes through the checkout on your storefront: revshare is computed from confirmed payments, and a subscription that bypasses it earns you nothing. The config likewise reaches the customer in the app, not in the bot.

Everything else it can do: create a customer, grant a trial, suspend and restore — see Provision users.

If a bot as the point of sale is exactly your scenario, bring it to the call — it is a reasonable candidate for prioritisation.