Inbound conversations

Everything else in these docs starts with you reaching out: an audience, an initiative, a journey that sends the first message. Inbound is the other direction, and it needs none of that. When a customer messages your WhatsApp number, your SMS number or your Instagram account without being enrolled in anything, the conversation is answered by the same agent that runs your outreach. Same knowledge base, same policies, same voice. It is not a separate support bot with its own configuration to keep in sync, which is the point: an agent that already knows your business, your product and your rules can handle someone asking a question just as well as someone answering one. By default no journey is involved: the agent simply answers, using everything it knows about your business. But a journey can also start from an inbound message — see Routing by keyword — which is how you put a specific flow in front of a specific question. Those are not the only ways in. The web widget puts the same agent on your own website, and everything on this page applies to it — the answering settings, the escalation path, and the inbox.

​

Where it goes

The agent answers, and can hand off to a person at any point in the conversation, not only at a step someone designed in advance. Escalated conversations land in the shared inbox, where a person replies with the whole history in front of them. That is the difference worth internalizing. In outreach, escalation is a node you place. Inbound, escalation is a judgment the agent makes whenever the conversation calls for it.

​

What has to be configured

Answering inbound is a setting, not a default. Each channel resolves its own answering behavior, falling back to the organization when the channel says nothing: whether the agent replies at all, and which agent replies. You set both in the Boom app, not through this API. A channel can be set to reply even when the organization’s default is not to. The behavior when this is unset is deliberate, and it is worth knowing before you go looking for a bug: So “we pointed our number at Boom and the agent never answered” is almost always this: the channel has no answering agent set, or the one it has is off.

​

Routing by keyword

A journey’s entry step can listen for “a message arrives on these channels”, optionally narrowed to messages that say something in particular. When one arrives, the sender is enrolled in that journey before the agent replies, so the reply already comes from inside the journey’s instructions rather than from the default agent. Three kinds of channel can start a journey this way: a WhatsApp number, an SMS number, and a native Instagram account. The authoring is identical for all three — the picker lists whichever you have connected. You configure this on the entry step in the journey builder, in three steps: pick the channels, then choose what the journey answers — every message on them, or only messages that say a particular word — then test a message to see who answers it. Choosing Keyword gives you a list of words. Type one and press Enter — or a comma — to add it; each becomes its own rule, and any one of them enrols the sender. Once added, the word appears in the form it will actually be compared in, so you can see the folding. Several journeys can listen on one number, as long as their keywords differ. Exactly one journey answers any given message, and the most specific rule wins: a keyword beats a journey that answers everything, a narrower match mode beats a broader one, and a longer keyword beats a shorter one. The third step shows you which journey wins a message you type, against the real rules, before publishing. Two journeys cannot claim the same number and the same keyword — the second one could never fire, so publishing it is refused rather than silently accepted. Two journeys both set to answer every message on one number is the same case, and the most common one: the builder warns you as soon as you pick the number, and the way out is to give one of them a word. Two limits worth knowing before you rely on this:

• A photo or file with no caption has no text, so it can only reach a journey that answers every message on the number. If every rule on a number carries a keyword, an image enrols nobody and the agent answers normally.
• Someone already in a journey with you stays there. A keyword does not pull a customer out of a conversation they are already having — they continue in their current journey, and the agent answers them.

“Only this word” is the strictest option and rarely what you want: real customers write “Hola, quería saber el precio” far more often than “precio” on its own.

​

What you can read back

Inbound conversations are readable the same way any conversation is, through the transcripts and messages endpoints on the API and over MCP. One asymmetry to plan around: extraction schemas are defined on an initiative, so structured fields come from conversations that belong to one. A customer who writes in while enrolled in an active initiative is answered inside that conversation and is covered by its schema. A customer who writes in cold belongs to no initiative, so there are no typed fields for that conversation, only the transcript and whatever your team records from the inbox.

​

Testing with your own number

While you are integrating, the same conversation accumulates every edge case you try, and the agent’s replies get worse as it grows. Two commands reset it from WhatsApp itself. The message has to be exactly the command. /reset now or please /reset is an ordinary message and reaches the agent normally. /reset is not a full wipe. Your CDP person, its event history and your initiative participation all survive, so a journey that branches on CDP data still sees a returning customer. Both commands only work from a number on your organization’s test-number list. Add yours under Settings → Test numbers. Entries expire — renew or remove them there — and a number that is not on the list gets a normal agent reply instead.

​

Related