Settings, team, and access

The Settings section brings together everything that applies to the bot as a whole: its parameters and behavior, team member access, API tokens, and templates. The header shows the bot's status, user count, requests today, and remaining request balance.

General

• Salutation: how the bot addresses the user.
• Position in list: the bot's sort order among others.
• User display mode: "Show all" / "Active only" / "Paid only."
• Interface language: Russian / English.

Behavior

Bot operation flags:

• Request consent for personal data processing.
• Send the user an error message.
• Support HTML entities in messages.
• Combine media groups into a single message.

Project access

The "Project access" card in the bot settings opens one bot to other people: each of them signs in with their own email and sees the project in their own cabinet. To give someone every bot in the cabinet at once, including future ones, use cabinet access.

The card is visible to the bot owner and to members with the "Access" right. The list has three kinds of rows:

• Member: an account that accepted the invitation and already works with the project. A badge shows whether they have 2FA on.
• Invited: the invitation is sent but not accepted yet. The row shows the date the link is valid until. Such a row grants nothing.
• Legacy row: a row from the old version of the screen, where people were typed in by name. It grants nothing and can only be deleted.

The owner carries the "Owner" badge: they hold every right and cannot be edited or removed.

Roles

A role is a preset set of rights:

• Admin: every project right, including access management.
• Manager: chats, analytics, viewing support tickets and replying in support.
• Operator: chats, viewing support tickets and replying in support. This lets you onboard Chats operators without opening the bot builder to them.

Changing a row's role replaces its rights with the new role's preset. A member who does not own the bot can only assign a role whose rights they all hold themselves. Nobody can change their own role or rights.

Permissions

The "Permissions" button opens fine-grained settings. The effective permissions are listed at the top, followed by checkboxes in groups: Data, Content, Automation, Support, Analytics, Integrations, AI, Security. Each change is saved immediately, and the role then stays as a label.

• You can only grant or remove a right you hold yourself (the owner holds all of them). Other checkboxes are disabled, and the server rejects such a change.
• Sensitive rights: Export profiles, Revenue in analytics, Integration secrets, and Enforce two-factor. If you do not hold one, the dialog says explicitly that you cannot grant it.
• If a right has no effect without another one (for example, "Edit profiles" without "View profiles"), a warning appears under it.

Project invitation

1. Click "Invite", enter the email and the role ("Operator" by default), and click "Grant access".
2. The address receives a one-time link of the form /invite?token=…, valid for 72 hours. Only the recipient sees the link; it is not shown in the interface.
3. The person opens the link and signs in with the account on that email (or registers one). Once accepted, the project appears in their list right away.

The invitation can only be accepted from the account with that verified email:

• if the link is opened under another account, the page offers to sign in with the right one (the "Add account" button), and the invitation stays valid;
• if the email is not verified, the page offers to resend the verification email; once verified, click "Email confirmed — accept";
• a used, expired, or unknown link is invalid: ask for a new invitation.

Inviting the same address again replaces the previous invitation: a new 72-hour link is sent and the old one stops working. The bot owner's own email cannot be invited, the server answers 409.

Editing and revoking

Change the role in the row's dropdown and the rights in the "Permissions" dialog. An invited person's role and rights can be adjusted before they accept. The trash button revokes a member's access, cancels an invitation (the emailed link stops working), or deletes a legacy row.

Inviting and changing roles or rights requires the bot owner's plan to include roles. Otherwise the list stays visible, a plan hint replaces the "Invite" button, and the server answers 402. Revoking access works on any plan.

Cabinet access

Project access opens a single bot. To give someone every bot in the cabinet (your account), including future ones, plus the cabinet's own rights (billing, creating bots, team), open Account → the "Cabinet access" card.

Roles:

• Administrator: all rights.
• Manager: chats, reactions, analytics, profiles, events, segments, content, and campaigns (view and edit), viewing support tickets and replying in support.
• Operator: chats, viewing profiles, viewing support tickets and replying in support.
• Finance: viewing the balance and payments only, no bot rights.

The cabinet owner is listed separately and cannot be edited or removed. You can fine-tune a role's rights with the "Rights" button; the role then stays as a label. Cabinet rights:

• View balance and payments (billing.read);
• Payments and top-ups (billing.write);
• Manage the cabinet team (team.manage);
• Create bots (bots.create);
• Delete bots (bots.delete);
• Security (security.manage);
• Audit log (audit.read).

The "Rights" dialog also sets bot rights, which apply to every bot in the cabinet.

Access can be granted by the owner or by a member with "Manage the cabinet team"; nobody can grant a right they do not hold. The feature requires a plan with roles, otherwise the server answers 402.

Invitation

Access is granted by email: click "Invite", enter the address and the role. The invitee receives a one-time link valid for 72 hours. The invitation can only be accepted from the account with that verified email:

• if the link is opened under another account, the page offers to sign in with the right one, and the invitation stays valid;
• if the email is not verified, verify it first using the email link;
• a used, expired, or unknown link is invalid: ask for a new invitation.

Cabinet access is managed from the web session only: these operations are not available with an API token or via MCP. How cabinet rights apply to API tokens: see The token's account.

API tokens

The "API tokens" block creates keys for accessing the bot via the REST API. A token is shown once at creation time: copy it immediately; only a masked version is visible afterward. See REST API and tokens for details.

Templates

A template is a snapshot of the bot's settings and all its reactions that can be reused:

• Create template: saves the current bot (its settings and reactions) as a named template.
• Apply template: copies the template to another bot: settings are replaced with the template's values, while reactions are added to the existing ones (they are not overwritten).

Convenient for rolling out a standard bot across multiple projects. See also Projects and channels.

Bot maintenance

• Synchronize: update the bot name from Telegram.
• Change token: update the token after regenerating it in @BotFather.

Bot health

The "Bot health" card shows the observed state: whether the bot is online, the current incident with its cause, the automatic-restart counter, the time of the next attempt and the last error, the restart journal for that incident, and the list of past incidents with duration, cause and the same restart details, when the incident recorded any. A bot that is turned off is shown as turned off rather than offline, and the incident history stays in place. How an incident is opened and closed: see Projects and channels.

The same card holds the notification settings:

• Notify the bot owner when the bot is offline: the bot's owner gets the notification (in the bell and by email), and the bot messages the same chats as the wallet-exhausted notice.
• Threshold, minutes without a heartbeat: a whole number 1–1440, 5 by default. An empty, fractional or out-of-range value is not saved and is not silently adjusted: the form shows an error.

Only the bot owner or a member with the "Reactions" right can change these two settings; everyone else sees the state but does not edit it.

• Change owner: transfer the bot to another account (irreversible).

What's next

• REST API and tokens: programmatic access.
• Projects and channels: token, transfer, templates.
• Chats and operators: the Operator role in action.
• Two-factor authentication: enrolment, recovery codes, and trusted devices.

Support operations and security

Support settings define the timezone, weekly coverage, breaks, overnight intervals, holidays, overflow group, and published auto-replies for working and non-working time. Use the availability preview before saving a schedule. A routing rule never substitutes an unavailable arbitrary member: it uses an eligible least-loaded candidate, configured overflow, or leaves the dialog unassigned.

Only the bot owner can require two-factor authentication for bot members. Review the affected-member count and the enrolment remediation path before enforcing the policy. Roles control access to bot configuration, support data, analytics and security policy; neither a role nor support staff can view an account's authenticator secret, recovery codes, or trusted-device token.