Framing the project this way from the start avoids building something that gets your bot token revoked or your server IP flagged.

Bot API vs. User Account Automation

There are two fundamentally different ways people build “adder” tools, and they have very different risk profiles:

1. Bot API automation — Uses python-telegram-bot, telegraf, aiogram, or a direct HTTPS call to the Telegram Bot API. This is the sanctioned path. Bots can manage invite links, approve join requests, and message users who’ve started a conversation, but cannot add users who haven’t interacted with the bot.
2. MTProto user-session automation (via libraries like Telethon or Pyrogram running as a user, not a bot) — Technically capable of calling methods that add contacts to a chat, but doing so at scale for outreach the recipients didn’t request is exactly the pattern Telegram’s anti-spam systems are built to detect, and it violates the platform’s terms.

For a production telegram member adder bot intended for a real product or community, stick to Bot API primitives. If your use case genuinely requires user-account automation (e.g., migrating members of a group you own, with their consent, between two chats you control), treat it as a manual, low-volume, rate-limited operation — not something you industrialize.

Core Architecture of a Compliant Telegram Member Adder Bot

A well-structured telegram member adder bot separates concerns the same way any event-driven service does: an inbound webhook or polling loop, a queue for pending actions, and a persistence layer for tracking invite state.

Telegram update (join request / /start / callback)
  → webhook handler (validates update, chat_id, request signature)
    → writes intent to a queue (approve, deny, send invite link)
      → worker processes queue item
        → calls Bot API (approveChatJoinRequest, createChatInviteLink, sendMessage)
          → persists result (member_id, invite_link, source, timestamp)

This mirrors patterns used elsewhere in infrastructure automation — see our guide on building resilient job queues for the general pattern, and how we structure Telegram bot deployments on systemd for the process-management side.

Handling Join Requests

If a group has “Approve new members” enabled, users who tap an invite link land in a pending state instead of joining immediately. Your telegram member adder bot receives a chat_join_request update and decides whether to approve it.

from telegram import Update
from telegram.ext import Application, ChatJoinRequestHandler, ContextTypes

async def handle_join_request(update: Update, context: ContextTypes.DEFAULT_TYPE):
    request = update.chat_join_request
    user = request.from_user

    # Example rule: reject accounts created very recently (proxy: no username set)
    if user.username is None:
        await context.bot.decline_chat_join_request(
            chat_id=request.chat.id, user_id=user.id
        )
        return

    await context.bot.approve_chat_join_request(
        chat_id=request.chat.id, user_id=user.id
    )
    await context.bot.send_message(
        chat_id=user.id,
        text=f"Welcome to {request.chat.title}! Read the pinned rules first."
    )

app = Application.builder().token("YOUR_BOT_TOKEN").build()
app.add_handler(ChatJoinRequestHandler(handle_join_request))
app.run_polling()

This is the safest and most useful version of a telegram member adder bot: it doesn’t add anyone who didn’t request to join, it just automates the approval decision and the welcome flow.

Invite Link Generation and Attribution

A common ask for a telegram member adder bot is knowing which campaign, ad, or referral drove a join. Telegram supports creating named, revocable invite links per source.

async def create_campaign_link(bot, chat_id: int, campaign_name: str):
    link = await bot.create_chat_invite_link(
        chat_id=chat_id,
        name=campaign_name,
        creates_join_request=True,
        member_limit=None,
    )
    # persist link.invite_link alongside campaign_name in your database
    return link.invite_link

When a join request comes in on that link, update.chat_join_request.invite_link.name tells you which campaign it came from — no scraping or guessing required.

Deep Links for Opt-In Invites

If you want to invite users who already have a relationship with your product (they’ve used a related bot, signed up on your site, etc.), the correct pattern is a deep link that the user clicks themselves, which then triggers a /start conversation your telegram member adder bot can respond to with a group invite:

https://t.me/YourBotUsername?start=invite_source123

The bot reads the start payload, logs the source, and replies with the relevant invite link. This keeps every addition opt-in and auditable.

Deployment and Reliability

Once the logic is right, running it reliably is mostly standard service-hosting practice.

# docker-compose.yml (excerpt)
services:
  member-adder-bot:
    build: .
    restart: unless-stopped
    environment:
      - BOT_TOKEN=${BOT_TOKEN}
      - DATABASE_URL=${DATABASE_URL}
    depends_on:
      - postgres

For container orchestration at larger scale, see our walkthrough of deploying stateful bots on Kubernetes, and the official Docker documentation and Kubernetes documentation for the underlying primitives.

Persistence Schema

A minimal schema for tracking membership actions taken by your telegram member adder bot looks like this:

Keeping this in a relational store (Postgres is a common choice) makes it straightforward to build attribution reports later without touching Telegram’s API again.

Moderation and Anti-Abuse Considerations

Any bot that touches group membership becomes an attractive target for abuse, so a production-grade telegram member adder bot needs its own defenses:

None of this is exotic — it’s the same defense-in-depth thinking you’d apply to any public-facing webhook, discussed further in our piece on securing public webhook endpoints.

FAQ

Can a telegram member adder bot add users to a group without their consent?
No. The Bot API does not expose a method for a bot to add an arbitrary user to a chat. Users must either interact with the bot directly, click an invite link, or send a join request. Any tool claiming otherwise is either misusing a user account (against Telegram’s terms) or misrepresenting what it does.

What’s the difference between createChatInviteLink and just sharing a static group link?
createChatInviteLink lets you generate multiple named, individually revocable links for the same chat, which is what enables per-campaign attribution. A single static link gives you no way to distinguish where members came from.

Will Telegram ban my bot for using join-request automation?
Not if you stay within documented Bot API behavior — approving/declining requests, sending messages to users who’ve started a conversation, and managing invite links are all supported operations. Bans typically follow from spam-like messaging patterns, not from using these endpoints as designed.

Do I need a database for a simple telegram member adder bot?
For a small single-group bot with one invite link, you can get away with in-memory state or a flat file. Once you need attribution across multiple campaigns or want history to survive a restart, a proper database is worth the setup time.

Conclusion

A telegram member adder bot is most useful — and safest to operate — when it automates the membership actions Telegram’s API explicitly supports: approving join requests, managing named invite links, and messaging users who’ve opted in. Building it on the Bot API rather than a scripted user account keeps you compliant with Telegram’s terms, avoids account bans, and gives you clean attribution data as a side benefit. Start with the join-request and invite-link patterns shown above, add logging and rate limits before you add scale, and treat any request to bypass consent-based joining as a sign the design needs rethinking, not a feature to build.