How to add a Telegram moderation bot and check that it works
Connect a hosted moderation bot, review its requested rights, configure one rule and verify it with an ordinary member before using stronger penalties.
Adding a moderation bot has three separate stages: connect the correct account, give it the authority needed for the job, and confirm that its rules work for ordinary members. A welcome reply proves only that the bot replied. It does not prove that spam will be removed or that legitimate messages will survive.
This guide uses the hosted @defendy_bot. You do not need to create a bot in BotFather, provide a token or run a server. If you want your own bot identity and custom behavior, start with the no-code decision guide.
Before granting access
Use a private test group for the first trial. Invite a consenting person as an ordinary member, or use a separate account you control. Do not demote your only administrator to make a test work.
Write down the first problem to solve: for example, removing a particular promotional phrase. Agree who will review mistakes and who can change the configuration. If another moderation bot already operates in the live group, identify overlapping filters before adding a second one. Two bots deleting the same test message make the result hard to interpret.
Check the bot's exact username through the link above. A familiar display name or avatar is not enough. Also check the destination: this procedure is for a group. For comments under channel posts, follow the separate discussion-group guide.
Connect Defendy to the intended group
- Open the bot's private chat and press Start, or send
/start. - Open Settings beneath its reply. The current bot button may be labeled «⚙️ Настройки» even when you read this guide in English.
- In the Mini App, choose Connect a group, select your group and review Telegram's administrator-permission screen before confirming.
- Return to the Mini App, open My groups and choose the connected group.
- Check the group name and ID before changing anything. Similar names are easy to confuse; settings belong to the selected group.
You need permission in Telegram to appoint an administrator. If the group is missing from the selection, ask its owner to check your authority rather than sharing their Telegram login. If connection succeeds but the group remains absent from the Mini App, use the diagnostic guide.
Review the requested rights, not just the administrator label
Defendy's connection link currently requests a broad set of administrator rights. Its onboarding check can also warn that rights are missing “for full functionality,” including group-profile changes, invitations, pinning or adding administrators. That warning is broader than the permissions required for a single filter.
Decide what the bot is meant to do. Do not grant promotion of other administrators merely to remove a warning if you have no reason to authorize that power. Equally, do not assume a reduced permission set supports every feature: test each selected workflow and investigate its specific failure.
| Intended action | Permission to review | What to test |
|---|---|---|
| Remove a member's message | Delete messages | A new disposable message is removed; an allowed one remains. |
| Mute, ban or release a member | Restrict members | A consenting ordinary member can be restricted and restored. |
| Process join requests | Invite users | The actual invitation and approval path your group uses. |
| Pin a message | Pin messages | A disposable announcement can be pinned and unpinned. |
| Administer forum topics | Manage topics | The particular topic-management action you intend to use. |
These powers are defined by Telegram's administrator-rights reference. Choosing an existing topic as a delivery destination is not itself permission to administer topics. Telegram rights and Defendy's moderator roles are separate layers: an internal role cannot grant a Telegram permission the bot lacks.
There is no routine “disable privacy mode” step here. An administrator bot receives ordinary group messages without that change. BotFather settings belong to the bot's owner; you cannot use your BotFather account to configure a vendor's bot. See Telegram's privacy-mode explanation.
Make the first trial deliberately small
The following is a hypothetical acceptance test, not a report of a live deployment. In a private test group, use one harmless, unique marker such as trialmarker to verify a stopword filter. It makes the expected match unambiguous without posting real spam.
- Open Stopwords and enable the filter. Select Exact matching for this single-word trial.
- Create a clearly named test list and add
trialmarker. Save the entry form. - Set the member action to None. Separately enable deletion of the disposable test message.
- Reopen the list and verify both values. None means no member punishment; it does not turn message deletion off.
- Have the ordinary member send
trialmarker, then a harmless message without it. Check that only the marker message disappears and the person can still participate. - Remove the test entry or disable the test configuration when finished. Design real rules from examples relevant to your community, using the stopword guide.
Test with an ordinary member because administrator exemptions and Telegram's restrictions on acting against administrators can produce a misleading result. Do not use a warning as a supposedly harmless test: it can contribute to an existing escalation threshold. Do not use /spam as a connectivity check either; an AI-assisted check can result in deletion.
This trial tests one rule and one permission. It does not verify CAPTCHA, all types of links or every future moderation decision. Repeat the process with each workflow you actually enable.
Check saved settings and evidence separately
Ordinary switches and selectors save on change; forms with a Save button need that button. If saving fails, reopen the section and read the stored values. If the app specifically says the setting was saved but the latest data could not be loaded, use Check again rather than repeatedly submitting the change.
For an audit trail, configure Logging, verify its destination and enable the event categories you need. The logging setup uses @defendy_logs_bot for delivery. A working connection test establishes that delivery works; it does not establish that every event category is enabled. Keep a moderator-only destination when records contain member details.
Move to the live group with a recovery plan
Repeat only the tested settings in the live group's own profile. Start with the narrowest useful rule and an administrator available to review mistakes. Publish the rule and a way to contact a human if a person loses access.
If an allowed message is deleted, pause or narrow the responsible rule before testing again. Restoring permission to participate does not restore deleted content; ask the author to repost if appropriate. If a person was restricted, review and reverse that specific action using the recovery guide.
After changing the administrator roster, an administrator can run /reload in the group to refresh Defendy's administrator list. It is not a restart or a settings reset. Keep a short note of the chosen rules, granted rights and responsible moderator. Setup is complete when an allowed case, a violation and the recovery path all behave as intended.
Run several bots or replace one without conflicting actions
Give each automated action one owner. A statistics bot and a moderation bot may have different jobs; two services both restoring posting permissions need a deliberate compatibility test. Telegram's member-restriction method changes the member's permissions. Do not assume independent bots maintain a shared stack of reasons for a restriction.
Before switching, make a small handover record: active modules, relevant permissions, allowlists, current warnings and sanctions, scheduled closures, pending CAPTCHA challenges and join requests. Record enough to preserve legitimate restrictions without exporting the entire membership. A new bot does not automatically inherit another service's warning history or queued work.
Use this sequence during a staffed period:
- Assign responsibility. Choose one CAPTCHA provider, one warning/escalation system, one handler for join requests and one owner of group-wide posting schedules. Document any intentional exception.
- Prepare the replacement in a test group. Recreate only the rules you need. Compare allowed messages as well as violations, using harmless markers and consenting ordinary members.
- Switch one workflow. Pause the old service's corresponding action before enabling the replacement. If the old service has no separate switch, consider whether removing its relevant right would break another job it still owns. Keep human moderation available during the gap.
- Resolve work already in progress. Identify outstanding challenges, requests and timed sanctions. Agree who will handle each. Turning a module off is not evidence that its scheduled work was canceled.
- Verify the live outcome. Check the actual member permissions and group defaults, then the logs. Keep the old configuration record until the replacement passes the checks below.
Four tests that reveal conflicting responsibilities
These are acceptance tests for the combination of tools you use, not a claim that Defendy has these defects.
- CAPTCHA plus a disciplinary mute. With a consenting test member, verify that passing a join challenge does not remove a separate restriction the team intends to keep. Check permissions after completion, not only the success message.
- Manual recovery plus a delayed action. Restore the intended access, then check again when the original challenge or sanction was due to expire. If another service changes the state later, pause the responsible workflow and investigate before repeating the recovery.
- Two warning systems. A single harmless test violation must not increment two independent counters and produce an unexpected escalation. Do not reset real warnings simply to make the totals match. Decide how earlier cases will be reviewed during the transition; see warning history and escalation.
- Two join-request handlers. Test the exact invitation route with a consenting account. Verify who approves or declines, whether a required challenge occurred, and whether any request remains unresolved. An ordinary group-message test does not cover joining.
If a test fails, stop the new workflow and restore its last verified owner and settings. Recheck effective permissions rather than merely switching the old bot back on. For unclear sanctions, use the individual recovery procedure; removing a bot does not establish that its existing restrictions disappeared.
Once the handover works, remove unneeded rights or the retired bot and check the administrator list again. Verify a fresh allowed message, a violation, a join and the next relevant scheduled transition. Record unresolved cases explicitly. The migration is finished when responsibility and observed results agree, including the rollback path.
Sources and scope
The installation steps were reviewed on 5 October 2026 against the Defendy implementation. The multi-bot handover section and its linked Telegram documentation were checked on 7 October 2026. This is a configuration guide, not a live service-availability test. Detailed product steps are in Quick start, Bot permissions and Logging. Items labeled Coming soon are not part of the working setup.