A bot can be emailed. Mail arrives at an address belonging to the bot, the bot replies in the thread, and the thread keeps its own history the way a chat does.
How email is set up
Email is configured once for the whole deployment, not once per bot. The mail credentials — the mail provider's API key and sending domain — live in the deployment's environment, and an individual bot's email integration carries only its address prefix, which defaults to the bot's id.
That has two practical consequences:
- You do not paste an API key when adding an email integration to a bot. If there is a field asking for one, it is not what makes email work.
- If email fails for every bot at once, it is a deployment-level problem — the API key or the domain — not something to fix bot by bot.
Threads belong to a group
The complication email has and chat does not: anyone can be added to a thread, and a thread has no obvious owner. Mesa resolves this by tying each thread to exactly one authorization group.
When a new thread arrives:
- If the thread is already associated with a group, that association is reused.
- Otherwise Mesa looks at who is on the thread and which groups they are authorized in.
- Exactly one match — the thread is associated automatically.
- Several matches — Mesa emails the person who started the thread with a link asking them to choose. The thread waits until they do.
Only the original sender can make that choice. Someone else following the link is refused. An administrator can reassign a thread afterwards from the admin console.
This is what the web app's thread-assignment page is for; it is reached from that email, not from the navigation.
Participants who are not authorized
A thread can include people who are not authorized to use the bot. Mesa detects this and can be configured to send an authorization request rather than answering into a thread where some recipients should not see the reply. Whether that request is sent automatically is a per-bot setting.
The conservative behaviour is the default worth keeping: an unauthorized participant on a thread is a reason to pause, because a reply goes to everyone on the thread, not just the person who asked.
Identity across channels
An email address can be linked to the same person as a Telegram account, so a bot recognises you on both. Linking is confirmed with a verification code rather than assumed from a matching name. Administrators can review links in the admin console under Identity links.
Limits worth knowing
- Attachments are not read. Inbound mail is reduced to its plain-text body before anything else happens; an attachment is not summarised or placeholdered, it is simply absent. The bot cannot tell you what was in the file you sent, and will answer as though you sent none.
- Email is slower by nature. Delivery, threading and any disambiguation step all add latency; a thread awaiting group selection produces no reply at all until someone picks.