Inbox thread

Two-Way SMS: Replies on the Number You Sent From

Two-way SMS means customers reply to the same mobile number that messaged them, and those replies land in your SMS inbox or on a webhook — using the Android SIM and operator credit you already run.

Thread+880 1712 345678
  1. You · SIM · 10:02

    Your appointment is Thursday 10:00. Reply YES to confirm.

  2. Customer · 10:04

    Yes, please reschedule to Thursday.

  3. You · SIM · 10:05

    Done — Thursday 10:00 confirmed. Reply STOP to opt out.

Thread

How a reply reaches your application

From outbound send to webhook delivery, the path is short and physical — which is why it is easy to reason about when something fails.

  1. 01

    You send from a connected device

    Your application posts an outbound message through the gateway. The Android phone that holds the SIM transmits it with the operator plan attached to that subscription.
  2. 02

    The recipient replies to that number

    They tap Reply in their messaging app. The response goes to the same mobile number that appeared on their screen — an ordinary local number, not a short code or a no-reply sender.
  3. 03

    The device receives the inbound SMS

    The SIM that sent the original message receives the reply. Android surfaces it to the gateway app the same way any other inbox message arrives on the handset.
  4. 04

    The gateway records it in the SMS inbox

    The inbound message is stored against the conversation thread for that device and remote number, so you can read history in the panel without writing code first.
  5. 05

    A webhook posts it to your endpoint

    If you configured a receive SMS webhook, the gateway POSTs the payload — from, to, message body, timestamps, device and message identifiers — to your HTTPS URL.
  6. 06

    Your application responds or assigns it

    Your code can auto-acknowledge, open a ticket, or hand the thread to a person. Outbound follow-ups go back through the same device so the conversation stays on one number.

Delivery status for the outbound leg still arrives through delivery reports. Inbound replies are a separate event stream: same device, different direction. Wire both if you need to know that the original message landed and that the customer answered.

Comparison

Shared short codes and no-reply senders versus your own number

The difference is not branding polish — it is whether a reply can exist at all, and whether you can see it.

Rented short codes, alphanumeric IDs, no-reply gateways

  • Replies are dropped or routed somewhere the customer cannot follow
  • Alphanumeric sender IDs cannot receive SMS at all
  • Short-code rental and monthly fees sit on top of per-message costs
  • Approval and provisioning delays before you can even test a conversation
  • Conversation history is split across vendor portals the customer never sees

Your own SIM on a connected Android device

  • Replies come back to the same number that sent the original message
  • Conversation history stays in one thread on that device
  • No short-code rental — you use the SIM and operator plan you already have
  • Works with the phone you control; add devices when volume needs a second path
  • Inbox and webhook give your team and your code the same inbound events

If you also run several phones for capacity, read multi-device and dual SIM routing. Throughput and conversation stability pull in opposite directions: bulk pools spread load; two-way threads need a stable number.

Definition

What two-way SMS actually is

Two-way SMS is messaging on a real mobile number that can both send and receive. You send from an Android device connected to the gateway. The customer replies to the message they received. That reply lands on the same SIM, then reaches your systems through the SMS inbox or a receive SMS webhook. No separate reply channel, no "text this other number" instruction — the conversation stays where it started.

The practical advantage is ordinary behaviour. Recipients treat a local mobile number the way they treat any other contact: they tap Reply. That is harder to achieve with rented short codes, alphanumeric sender IDs, or no-reply gateways. With an Android SMS gateway you already own the send path; two-way SMS simply means you also keep the inbound path on that same handset and feed it into your application.

  1. 01

    Two-way SMS uses a real mobile number that both sends and receives, so the customer replies in the same thread they received.

  2. 02

    Replies return to the SIM that sent the original message; pin conversational traffic to a stable device.

  3. 03

    Inbound messages appear in the SMS inbox and can be posted to your application through a receive SMS webhook.

  4. 04

    Alphanumeric sender IDs and many short-code setups cannot receive replies; your own SIM can.

  5. 05

    You supply the phone and operator SMS credit; service pricing follows device count and total SMS sent.

Event log

Receiving replies in code

A two way SMS API is mostly an inbound webhook plus the same outbound send you already use. Your endpoint receives a JSON body when the device gets a reply; you respond on the REST SMS API with the same device_id so the thread stays intact. Full webhook setup lives on the webhook documentation.

Inbound webhook payload and outbound replybash
# Inbound webhook (message.received). Signing: X-SmsGateway-Signature.
{
  "id": "evt_01K2F8QW3N4RXB7M",
  "type": "message.received",
  "createdAt": "2026-08-12T14:04:09Z",
  "apiVersion": "2026-08-12",
  "data": {
    "message": {
      "id": 41822,
      "number": "+14155552671",
      "text": "Yes, please reschedule to Thursday.",
      "status": "Received",
      "deviceId": 3,
      "receivedAt": "2026-08-12T14:04:09Z"
    }
  }
}

# Reply on the same number via POST /api/v1/messages
curl -X POST "https://app.sms-gateway.app/api/v1/messages" \
  -H "Authorization: Bearer $SMS_GATEWAY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"to":["+14155552671"],"text":"Done — Thursday 10:00 confirmed. Reply STOP to opt out.","type":"sms","campaign":false}'
Store message_id and treat duplicate deliveries as no-ops — providers retry, and your handler must be idempotent.

Engineering realities matter more than the sample. Verify the request (shared secret or signature) before you trust the body. Return a 2xx quickly and process asynchronously so a slow database write does not cause the gateway to retry forever. Expect retries anyway: store the provider message_id and deduplicate. Android's Telephony provider documentation is useful background for how SMS lands on the handset before the gateway reads it.

Keyword replies such as STOP belong next to this flow. Pair the inbox with auto-reply and STOP handling so opt-outs are recorded as they arrive, then keep the suppression list on your contacts and lists rather than in a spreadsheet someone forgets to check.

Operations

Practical answers before you wire production

Four questions that come up once the first test reply works and you start thinking about real traffic.

Q01

Do replies work if I send from several devices?

Yes, but each reply lands on the SIM that sent the original message. Pin conversational traffic to a stable device rather than round-robining it across a pool, or you will split the same customer across different inbox threads.

Q02

What happens to a reply that arrives while the app is offline?

The carrier still delivers the SMS to the SIM. Once the gateway app reconnects, it reads the inbox and syncs pending inbound messages, then fires any configured webhook. Keep the phone charged and online if you need near-real-time delivery.

Q03

How do I route a conversation to a human?

Use the webhook to open a ticket or push the thread into your helpdesk, keyed by the remote number and device_id. Agents then reply through the API on the same device so the customer sees one continuous conversation.

Q04

How are STOP replies handled?

Inbound STOP (and common variants) can be matched automatically, recorded as an opt-out, and suppressed from future campaigns. Pair two-way inbox routing with auto-reply rules so compliance does not depend on someone noticing the keyword by hand.

Transactional codes and login flows are usually one-way by design, but the same device fleet can host both OTP sends and a support number. Keep them on separate SIMs — see OTP verification — so a busy inbox never sits in front of a login code.

Structure

What stays on the same number

These are structural facts about two-way SMS on your own SIM — not throughput claims.

Send and receive on one SIM
Same number
Its own inbox thread
Per device
Inbound delivered as it arrives
Webhook
Geography

Regional notes on two-way SMS

Local numbers are trusted in some markets; alphanumeric senders and short codes behave differently in others.

Bangladesh

Customers expect to reply to a local mobile number. Two-way SMS on your own SIM matches how people already text shops and banks; branded alphanumeric senders used elsewhere cannot receive those replies at all.

India

Transactional templates often go out under alphanumeric sender IDs that cannot accept inbound SMS. If you need a conversation — confirmations, reschedules, support — send from a registered mobile SIM that can both send and receive.

Philippines

SMS remains a primary channel and replies are common. A local number builds trust faster than a short code most recipients have never saved, and the inbox thread stays on the SIM you already operate.

USA

US carriers treat consumer lines differently from short codes and toll-free numbers. Volume filtering and consent rules still apply; ramp carefully and keep content consistent. Short-code rental is a separate path with its own approval timeline.

More markets sit on the SMS gateway by region hub. Wherever you operate, honour local consent rules and process STOP replies promptly. Support for account questions is available within 24-48 hours through the contact channels on the site.

FAQ

Common questions about Two-way SMS inbox

Straight answers for teams evaluating this feature for production OTP, bulk, or two-way traffic.

Get started

Run two-way sms inbox on your own SIM

Install the Android app, pair a device with operator SMS credit, and test this feature in the panel or over the API. Paid plans are metered by devices and SMS send volume.