Bot accounts access the Mattermost RESTful API on behalf of a bot through the use of the personal access tokens feature. Bot accounts are just like user accounts, except they:
Additional benefits include:
BOT
tag is used throughout Mattermost where bot accounts are referenced, including messages and user lists.Note that currently:
If you would like to see improvements to bot accounts, let us know in the Feature Proposal Forum.
By default, plugins can create and manage bot accounts. To enable bot account creation through the user interface or the RESTful API:
Once set, System Admin can create bot accounts for integrations using the Integrations > Bot Accounts link in the description provided.
Below are different ways to create bot accounts. After the bot account is created, make sure to:
Use the RESTful API POST /bots
to create a bot. You must have permissions to create bots.
See our API documentation to learn more about creating and managing bots through the API.
To authorize your bot via RESTful API use curl -i -H 'authorization: Bearer <Access Token>' http://localhost:8065/api/v4/users/me
. Access Token is not the Token ID
and won’t be visible again once created.
You can use the following CLI command to convert an existing user account to a bot:
user convert user@example.com --bot
In addition to email, you can identify the user by its username or user ID.
Bot accounts which were converted from user accounts will have their authentication data cleared if they were email/password accounts. Those synchronized from LDAP/SAML will not have their authentication data cleared so that LDAP/SAML synchronization performs correctly.
Plugins can create bot accounts through an EnsureBot
helper function. For an example, see the Demo Plugin.
Bots created by a plugin use the plugin’s ID as the creator, unless otherwise specified by the plugin.
Each bot account has a row in the Users table and the Bots table. The entries are tied together by User.Id = Bot.UserId
.
The Bots table schema is described as follows:
Field | Description | Type | Required |
---|---|---|---|
UserId | User ID of the bot user | string | Y |
Username | Username of the bot account | string | Y |
DisplayName | Display name of the bot account | string | N |
Description | Description of the bot account | string | N |
OwnerId | User ID of the owner of the bot | string | Y |
CreateAt | Unix timestamp of creation time | int64 | Y |
UpdateAt | Unix timestamp of update time | int64 | Y |
DeleteAt | Unix timestamp of deletion time | int64 | Y |
For your integrations using RESTful API and plugins, yes. To do so, you can either convert an existing account to a bot, or create a new bot account using the steps outlined above.
Once you create a bot account, use the generated token to access the RESTful API on behalf of a bot and interact in the Mattermost server.
For your webhook and slash command integrations, you cannot migrate them to use bot accounts, as they require a user account at this time. However, an option is to migrate the webhooks or slash commands to a plugin, which in turn can use bot accounts.
For a concrete example, suppose you enable the Mattermost GitHub plugin, which uses a github
bot account, while an existing github
user account was created for webhook integrations.
Once the plugin is enabled, the plugin posts as the github
account but without a BOT
tag. An error message is logged to the server logs recommending the System Admin to convert the github
user to a bot account by running mattermost user convert <username> --bot
in the CLI.
If the user is an existing user account you want to preserve, change its username and restart the Mattermost server, after which the plugin will create a bot account with the name github
.
Use the following CLI command to convert an existing user account to a bot:
user convert user@example.com --bot
In addition to email, you may identify the user by its username or user ID.
Bot accounts which were converted from user accounts will have their authentication data cleared if they were email/password accounts. Those synchronized from LDAP/SAML will not have their authentication data cleared so that LDAP/SAML synchronization performs correctly.
Add the bot to a team and channel you belong to, then use the following curl command to post with the bot:
curl -i -X POST -H 'Content-Type: application/json' -d '{"channel_id":"<channel-id>", "message":"This is a message from a bot", "props":{"attachments": [{"pretext": "Look some text","text": "This is text"}]}}' -H 'Authorization: Bearer <bot-access-token>' <mattermost-url>/api/v4/posts
Replace the following parameters:
<channel-id>
with the channel you added the bot to<bot-access-token>
with the bot access token generated when you created the bot account<mattermost-url>
with your Mattermost domain, e.g. https://example.mattermost.com
No, but you can automate your integration to cycle its token through the REST API:
bot
user.token
value from step 1.token_id
.For more information about access tokens, see the personal access tokens documentation.
Possibly yes. Currently a System Admin can disable overriding the profile picture and the username from integrations to help prevent impersonation, but this is not the case for bot accounts.
Mitigations:
BOT
tag is used everywhere in the UI where bot accounts are referenced, including messages and user lists.BOT
tag.By default, bot accounts managed by the deactivated user are disabled for enhanced security. Those with permissions to manage bot accounts can re-enable them via the Product menu > Integrations > Bot Accounts.
We strongly recommend creating new tokens for the bot, to ensure the user who was deactivated no longer has access to read or write data in the system via the bot access token.
If you prefer to have bot accounts remain enabled after user deactivation, set DisableBotsWhenOwnerIsDeactivated
to false
in your config.json
file.
Yes. By default, bot accounts can update their own posts.
If you find yourself unable to edit posts as a bot, check the following:
If neither of the above help resolve your issue, you also have the option to choose what role the bot account has. If System Admin is chosen, then the bot can update any posts in the system. Note that giving the System Admin role to a bot account enables the bot with other System Admin privileges so this should be done with care.
When AD/LDAP or SAML synchronization is enabled, you can create bot accounts using the steps outlined above. These bot accounts won’t require an email address.
If you need to sync service accounts from AD/LDAP or SAML to Mattermost and use them as bot accounts, please reach out to us to discuss in detail. You may not need to sync service accounts and use them as bot accounts to meet your use case.
As of v5.14, a field named UserType
is added to Compliance Exports, including Global Relay, Actiance, and CSV. The field identifies whether a message was posted by a user
or by a bot
account.
Did you find what you were looking for?