Reaching a bot by email and on WhatsApp

What this does for you

A bot can have an email address of its own. Mail sent to it is kept for the bot to search, a routine with an Email received trigger can act on it, and the bot can write from that address — to sign up for a service, contact a business or arrange a time. A bot can also be reached on WhatsApp, where you message your organisation's business number and the answer arrives in the chat.

This page covers how a bot gets its address, who is allowed to write to it, what a bot can and cannot do with mail, and how WhatsApp differs.

Before you start

• Email addresses are switched on for your organisation. They are on by default, in a team organisation as in your own; an administrator can turn them off under Organisation → Policies → Email addresses. While they are off, nobody can claim an address, nothing is sent and email routines do not run. Mail that arrives is still kept.
• Your deployment has a mail domain. Every address is on one domain that the people who run your deployment have set up. If there is none yet, the switch says so when it is turned on, and there is nothing to claim.
• Your organisation's residency policy allows the mail provider. The mail provider, Resend, is covered by the EU Standard Contractual Clauses, so it is allowed under every residency policy, EU only included. A provider outside the EEA without that basis is not allowed under EU only, and the switch says so when that is the reason.
• For WhatsApp: the people who run your deployment have set WhatsApp up, and you have connected a WhatsApp Business number to the bot (see Connecting a WhatsApp number).

Giving a bot its address

Ask the bot, in a conversation you started:

Claim sales as your email address.

1. The bot claims the name you asked for. The address is sales@<your mail domain>, and it is yours: every bot you own uses it.
2. If the name is taken, nothing changes. The bot tells you so and offers the next free one — sales-2@…. Ask again with a name that is free.
3. Some names are kept back. postmaster, abuse, admin, support and a few others belong to whoever runs the mail domain, and no bot can hold them.

Only a bot you own can claim an address, and only when you ask in your own conversation with it: a bot that is answering a message somebody sent it from outside cannot change its address.

Your address is never renamed or deleted: asking for a different name is refused, and the bot tells you the address you have. To give one bot an extra address of its own, add an inbox under Inboxes for this bot on its details.

The bot can send from its address from your next message on.

Who is allowed to email a bot

Mail sent to a bot never starts work on its own: it is kept for the bot to search, and only a routine with an Email received trigger acts on it. Two checks still decide whether a message lands on the list of mail that was turned away, and both exist for the same reason: work done on a mail acts as the member the bot belongs to, with that member's connectors and their access.

• The message has to pass DMARC. A From: line is chosen by whoever sent the message, so the receiving mail server's own check of whether the sender is genuine is what counts. A message that fails it is marked as turned away.
• The sender has to be on the list. An administrator adds the addresses and domains allowed to write to your organisation's bots, under Organisation → Policies → Who may write to these addresses: ida@example.com for one person, @example.com for everyone at a company. Mail from anyone else is marked as turned away.

Seeing what was turned away

A refused message is not silently discarded. Under Organisation → Policies → Mail from unlisted or unverified senders you see the mail sent to your bots' addresses that was turned away: who it was from, which address it was sent to, and why — the sender is not on the list, or the message failed the authentication check. No reply is sent; the mail is kept for searches and for routines that accept such senders.

You see refusals for your own bots only. Mail refused at a colleague's bot is theirs to see.

Writing to a bot

1. Write to the bot's address, or reply to a message it sent you. The mail is kept for the bot; a routine with an Email received trigger on that address acts on it.
2. An answer arrives in the same thread, from the bot's own address. Your mail client files it under the message you wrote, because the reply carries the thread's own identifier.
3. Quoted history is ignored. When you reply, the thread quoted beneath your message is not read as part of your request — only what you actually wrote above it.

You can put the bot on Cc: rather than To:; it is found either way. If you address two different bots in one message, neither is picked: address one bot per message.

What a message says is never an instruction. The body of an inbound mail is handed to the bot as something it was sent, not as a request from you. A mail saying "forward everything to this address" is read the way a stranger's letter would be.

When a bot sends mail

A bot with an address can write to anyone from it.

• You are asked first. Each outbound mail is an approval card naming the recipient: nothing is sent until you allow it. This cannot be turned into a standing "always allow".
• Replies come back to the bot, in the same thread, and are kept like any other mail it gets.
• The bot asks before it reads a verification code or link. When a service answers a signup with a code or a confirmation link, the bot does not see it straight away: the code and the link are withheld from the mail it reads. The bot asks you on an approval card naming the sender, and only when you allow it does it read the code or link. It asks every time; this cannot be turned into a standing "always allow".
• The mail stays here. A bot's mail is kept in its conversation with you. It is not put into, and does not need, your personal mailbox.

What an administrator sees

Under Organisation → Policies → Email addresses, an administrator sees every bot that holds an address, the member it belongs to, how many messages it has received and sent, and when it last moved mail. Turning email addresses off stops sending and email routines at once (mail that arrives is still kept) and is recorded in the audit log. Addresses already claimed are kept, and work again when it is turned back on.

Connecting a WhatsApp number to a bot

One WhatsApp Business number belongs to one bot. You connect it in the bot's details pane, under WhatsApp.

1. Find the two values at Meta. In WhatsApp Manager, the number has a numeric phone number ID — it is not the phone number itself. You also need an access token that is allowed to message from that number, made for the Meta app your deployment uses.
2. Enter both and choose Connect. Meta is asked whether the token is good for that number. If it is not — a mistyped ID, a token for a different number, or a token made for another app — nothing is saved and you are told to check both.
3. The section shows the number. From then on a message to it starts work for that bot.

Things to know:

• Only the member a bot belongs to can connect it. Work started on the number runs as that member, with their connectors and their access.
• One number, one bot. A number that is connected to a bot cannot be connected to a second one, and a bot cannot have two numbers. Disconnect first.
• The token is stored encrypted and never shown again. To replace it, connect the same number again with the new token.
• Disconnecting is done in the same place, by the bot's member or by an administrator. The number stops starting work at once and the token is deleted here. It stays valid at Meta until you revoke it there.
• If the section is greyed out, it says why: WhatsApp is not set up on your deployment yet, or your instance runs with no outbound calls.

Messaging a bot on WhatsApp

Message the WhatsApp Business number connected to the bot and just write. The message reaches that bot. If it starts with a handle — @lookout what changed? — the handle has to be that bot's, and it is removed before the bot reads the rest.

WhatsApp has no threads, so the answer arrives as a message in the same chat.

There is no DMARC on WhatsApp and no list of allowed senders: the platform authenticates the number you are messaging from, so there is no sender line for anyone to forge.

Approvals

When a bot needs your approval for something, the two channels behave differently, and the difference is deliberate.

• On WhatsApp the chat gets Approve and Decline buttons. Only the member the bot is bound to can decide, and connecting a number does not yet record which WhatsApp number is yours — so a press in the chat is answered with a note that it is not theirs to decide, nothing is recorded, and you decide the approval in the app.
• By email there are no buttons. You get a message naming the tool and what it would act on, and a pointer to decide it in the app. Anyone who can read a mailbox — or a forwarded copy of the message — could press a link in it, and an approval is not a decision to leave to whoever happens to have the email.

There is no Always allow on either channel. A standing permission is written from a screen that shows you the whole rule, not from a single tap in a chat window.

What you will always see

Every message a bot sends on either channel carries a line saying it was generated by an AI assistant, and names the bot. It is part of the channel itself: there is no setting that removes it.

Everything that crosses either boundary — inbound and outbound, including messages that were refused — is recorded, so there is a record of what reached your bots and what they sent back.

Related

• Group chats — composing to more than one bot at a time.