BotNetwork

Guide 01

Getting started with bots: platforms, architectures and first decisions

Before writing code, make four decisions: where your users are, how messages reach your code, where state lives, and how the bot behaves when things go wrong.

Guide4 min readUpdated

What a bot actually is

A bot is a program that acts on a messaging platform, a website or an API on behalf of its operator. In practice almost every bot is the same loop:

  1. Receive an event: a message, a button press, a slash command, a scheduled tick, a webhook from another service.
  2. Decide: parse the input, check permissions, look up state, maybe call an AI model or another API.
  3. Act: reply, update a record, post to a channel, open a ticket.
  4. Record: log what happened so you can debug, measure and audit.

Everything in this site is about doing those four steps reliably, securely and with the consent of the people involved.

Choosing a platform

Pick the platform your users already use, then accept its rules. Each has a different model for identity, permissions and cost.

Platform Best for Identity and consent Cost model Delivery
Telegram Communities, utilities, notifications, mini apps Users start the bot; groups add it Free API Long polling or webhook
Discord Gaming and community servers, moderation, games Server admins install with OAuth2 scopes Free API Gateway WebSocket or HTTP interactions
WhatsApp Cloud API Customer support, transactional notices Explicit opt-in, business verification Charged per template message Webhook only
Slack Internal workflows, ChatOps, approvals Workspace admins install with scopes Free API, paid workspace features Events API or Socket Mode
Web chat widget Product support, onboarding Your own site and privacy policy Your hosting plus AI costs Your own API

If you are learning, start with Telegram: you can create a bot in two minutes with BotFather and test from your phone. Then build the same bot on Discord to learn interactions and permissions.

How events reach your code

There are three delivery models, and the choice drives your hosting:

  • Polling: your process repeatedly asks the platform for new events (getUpdates on Telegram). Simple, works behind NAT, needs a process that is always running.
  • Webhooks: the platform sends an HTTPS POST to your URL for every event. Efficient and serverless-friendly, but you need a public HTTPS endpoint and must verify each request.
  • Persistent connections: a WebSocket (Discord Gateway) or Socket Mode (Slack). Low latency, receives events you cannot get otherwise (presence, voice, message content), but needs a long-lived process.

A good rule: use webhooks in production when the platform supports them, polling or sockets for local development and for features that require them.

Stateless versus stateful

Most bots need to remember something: the step of a conversation, a user's language, a subscription. Keep state outside the process so you can restart, scale and redeploy without losing it.

  • Small key-value data: Redis, Cloudflare KV, DynamoDB.
  • Relational data: PostgreSQL, SQLite or Cloudflare D1.
  • Conversation memory for AI bots: store messages with a retention limit, summarize long histories.

Design handlers so that processing the same event twice does no harm. Platforms retry deliveries, and you will see duplicates. See reliability and rate limits.

A minimal architecture

 platform  --HTTPS POST-->  edge / API gateway  -->  handler (verify, parse, ack fast)
                                                         |
                                                         v
                                                 queue / background job  -->  AI, DB, other APIs
                                                         |
                                                         v
                                                 platform API (reply)

Acknowledge quickly, do slow work in the background, and reply through the platform API. Discord and Slack both expect an answer within 3 seconds; Telegram and WhatsApp retry if you are slow or return errors.

Choosing a language and library

Use what your team knows. The mature ecosystems are:

  • JavaScript or TypeScript: grammY and Telegraf (Telegram), discord.js, Bolt for JavaScript (Slack). Runs on Node.js, Deno, Bun and Cloudflare Workers.
  • Python: python-telegram-bot and aiogram, discord.py, Bolt for Python. Great for data and AI work.
  • Go, Rust, Java, C#: solid libraries exist for every major platform; useful when you care about memory and concurrency.

Browse the directory for official SDKs and maintained libraries.

The launch checklist

Before you invite real users:

  • Token and secrets in environment variables or a secret manager, never in the repository.
  • Webhook requests verified (secret header, HMAC or Ed25519 signature).
  • Least-privilege scopes, intents and permissions.
  • A /help or about message that says what the bot does, who operates it and how to contact them.
  • A privacy notice: what you store, for how long, and how to delete it.
  • Rate limiting and backoff on outgoing API calls.
  • Structured logs with secrets and personal data redacted.
  • An alert when error rates rise or the webhook stops receiving events.
  • A stop or unsubscribe command that works.

What this site will not help with

Spam, fake engagement, account farming, evading bans, scraping behind logins, credential stuffing or anything built to deceive people or platforms. Those break laws and terms of service and harm the people on the other side. Everything here assumes you are building something users asked for.

Check your understanding

1. Which delivery model needs a public HTTPS endpoint?
2. Why should handlers tolerate processing the same event twice?