Skip to main content

​
Let SMPP bind traffic open Inbox conversations

By default, traffic that arrives on your SMPP bind (submit_sm from your ESME client) is recorded purely as machine traffic: every submit gets a per-channel Messages row, but it does not open an Inbox conversation and does not fire the inbox_new_conversation notification. If your team genuinely answers bind-received free-text in the Inbox — a two-way aggregator workflow where agents reply to inbound SMS — turn the SMPP Inbox toggle on and pass-through bind submits open a conversation per send again, exactly as they did before the default flipped. Everything on this page is a tenant-owned setting. The toggle flips one flag, inbox_conversations, on your organization’s smpp settings; it sends nothing and routes nothing.

​
1. What the toggle does

The flag gates the conversation creation step of bind ingest, and nothing else:
  • ON — a pass-through submit_sm received on your bind upserts an Inbox conversation per send and mints the inbox_new_conversation notification on a fresh thread. Agents see and can answer the message in the Inbox.
  • OFF (the default) — the same submit records a full Messages row with its normal status trail, but no conversation is created and no new-conversation bell or email fires. Bind ingest stays machine-side.
Either way, the Messages list shows every row — the toggle removes the conversation object, not the message record. And inbound replies to a bind-sent message still thread on the normal inbound path regardless of this flag — only the conversation creation tied to the bind submit_sm itself is gated.

​
2. Enable or disable it

​
In the dashboard

Go to Settings → Channels → SMPP Inbox. Read the current state and flip the toggle; the change takes effect on the next bind submit.

​
Over the API

Read the current state with GET /messages/smpp-bind-inbox:
Set it with PUT /messages/smpp-bind-inbox — send true to let bind traffic open conversations, false to keep bind ingest machine-side:
The body accepts only inbox_conversations — anything other than a literal boolean is rejected.

​
3. When to turn it on — and when to leave it off

Turn it ON when bind-received free-text is genuinely answered by humans in the Inbox. Two-way aggregator workflows are the canonical case: recipients text the aggregator’s short code, and your agents reply from the Inbox. Leave it OFF when your bind carries OTP, notification, or other one-way traffic. A bind that mostly submits one-time codes would otherwise open one conversation per code and ring one bell per destination — queue noise, not engagement. If you also terminate OTP submits from an absorbed bind onto a delivery channel, keep this toggle on false and pin the no-inbox behaviour on the termination rule instead — see transactional no-inbox mode. Most tenants leave it off. The setting exists because the previous default (on) flooded the queue with synthetic conversations for anyone running high-volume bind traffic.

​
4. How it interacts with the other inbox gates

Three separate mechanisms decide whether a send touches the Inbox. They are independent and compose:
  • This flag — the tenant-wide default for messages received on your SMPP bind. It says, for all bind submits at once, whether the conversation step runs.
  • inbox stamps on termination-rule hops — per-hop, per-send overrides on the outbound side. A deliver hop declaring inbox: 'none' or inbox: 'thread' pins the behaviour for traffic the rule matches, whatever the bind default is. See transactional no-inbox mode.
  • Template-category inference — a WhatsApp template of category AUTHENTICATION (Meta’s OTP category) is treated as transactional and skips the conversation upsert even with no rule saying so.
When signals disagree, the explicit hop stamp wins over inference, and either pins behaviour that the bind default merely guesses. If you expect a conversation but the hop says inbox: 'none', the hop wins — flip the hop, not this toggle.

​
5. Troubleshooting

“Replies on my bind do not appear in the Inbox.” Check the toggle first — with it on the default false, pass-through bind submits record Messages rows only, so there is nothing for an agent to open. Flip Settings → Channels → SMPP Inbox on, or PUT inbox_conversations: true. Note the toggle only affects new submits; it does not retro-open conversations for traffic recorded while it was off. “A conversation opens but no new-conversation notification fires.” Conversation creation and the notification are two steps; once the conversation exists, the inbox_new_conversation notification still depends on your notification routing — check that your role/team rules route Inbox events to the agents you expect (Settings → Team → notifications). “I turned it on but OTP traffic now floods the queue.” That is the toggle doing exactly what it says. Flip it back off and pin no-inbox on the termination rule for your OTP binds instead (see the transactional no-inbox guide); the per-hop route keeps machine traffic out while leaving two-way paths free to thread.

​
See also