> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Let SMPP bind traffic open Inbox conversations: the bind → Inbox opt-in

> Decide per tenant whether messages received on your SMPP bind may open Inbox conversations and ring the new-conversation bell. Default off — turn it on only if your team works bind free-text in the Inbox.

# 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`:

```bash theme={null}
curl https://api.orbit.devotel.io/api/v1/messages/smpp-bind-inbox \
  -H "X-API-Key: dv_live_sk_your_key_here"
# -> { "data": { "inbox_conversations": false } }
```

Set it with `PUT /messages/smpp-bind-inbox` — send `true` to let bind traffic open conversations, `false` to keep bind ingest machine-side:

```bash theme={null}
curl -X PUT https://api.orbit.devotel.io/api/v1/messages/smpp-bind-inbox \
  -H "X-API-Key: dv_live_sk_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{ "inbox_conversations": true }'
```

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](/guides/transactional-inbox-no-conversation).

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](/guides/transactional-inbox-no-conversation).
* **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](/guides/transactional-inbox-no-conversation)); the per-hop route keeps machine traffic out while leaving two-way paths free to thread.

## See also

* [Connect via SMPP](/guides/smpp) — bind credentials, ports, and the wire protocol
* [Transactional no-inbox mode](/guides/transactional-inbox-no-conversation) — the per-hop alternative when only some bind traffic should skip the Inbox
* [SMPP edge model](/concepts/smpp-edge-model) — how the relay underneath your bind is organized