Skip to main content
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 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. No journey is involved. A journey exists to carry a conversation you started, so it has a trigger, a first message, and a path. An inbound conversation has none of those. It starts because the customer decided to write.

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:
If no agent is configured to answer a channel, or the configured agent is disabled, an inbound message is received and stored, and nothing replies. It waits in the inbox for a person. Boom does not pick an agent on your behalf, because guessing which agent should speak for you is worse than staying quiet.
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.

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.

The agent

The agent that answers, how the knowledge base briefs it, and when it hands off to a person.

Journeys

The other direction: a flow you author to start a conversation.

WhatsApp templates

Why outreach needs an approved opener and inbound does not.

Use MCP

Read conversations and transcripts from an AI tool.