Android Sms Gateway Api Multi Device: In-Depth Guide

Why the API cares about more than one phone

One Android radio is a queue with a battery. Peak OTP, a shipping spike, and a consented campaign cannot share that queue without stealing latency from each other. The multi-device API exists so your backend names the handset. Hub C’s overview is the Android SMS gateway API guide; this spoke is routing.

Throughput scales with device count, not with a louder retry loop against a single modem. If the phone is busy, retrying faster just rearranges the wreckage.

deviceIds on POST /messages

Authenticate with Authorization: Bearer. Body is JSON. to and text are the minimum. deviceIds is how you pin the radio. OpenAPI at docs.sms-gateway.app wins over any older query-string sample. A shape like this is the idea — not a substitute for the live schema:

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":"Your login code is 481920. It expires in 5 minutes.","type":"sms","deviceIds":[3]}'

PHP and C# language samples on the site are REST recipes, not a NuGet or Composer “complete SDK.” Keep keys on the server.

Routing strategies that survive contact

Feature context: multi-device and dual SIM routing.

Failover is not round-robin

When a paired phone drops, other devices on the account can keep claiming jobs that were not nailed to the dead id. That is queue continuity. It is not load-balancing in the cloud-LB sense. If your code hard-codes device 3 and device 3 is in an elevator, those OTPs wait. Keep a spare charged, funded, and already paired — then change the id in config, not in a tweet to support.

Dual SIM is not a second device

Two SIMs in one chassis share power, OEM policy, and a single pairing session. Useful for operator diversity on one nightstand. Useless as a second battery. After reboot, confirm which slot the app still thinks is “slot 1.” Multi-device API routing will not save a slot-map lie.

How to wire multi-device sends

1. Pair every phone and write the map. Panel nickname, device id integer, SIM MSISDN, message class (OTP vs bulk). Tape it to the rack.
2. Send a canary with deviceIds set. POST /api/v1/messages with Bearer auth. Confirm the SMS leaves that SIM, not the primary.
3. Send a canary with deviceIds omitted. Prove you know where “default” goes. If default is OTP, never let bulk omit the field.
4. Pull one phone off Wi-Fi. Watch queue depth and whether unpinned jobs move. Document the actual behaviour for on-call.
5. Isolate OTP. Application code always sets the OTP device id. Feature-flag bulk onto the other pool.
6. Re-test after OEM update. Reboots reshuffle dual-SIM slots and battery exemptions. The API still trusts last week’s map until you check.

Pairing walkthrough: device setup guide. DLR per device: delivery reports guide. Inbound still belongs on SMS webhooks.

Ops: maps, reboots, canaries

Nickname every phone in the panel with the message class, not “Lenovo-left.” On-call should not decode serial numbers at 03:00. After any OEM update, send one canary per deviceId before you declare the fleet healthy. Queue depth climbing on one id while others idle is a routing bug in your app, not “Android being slow.”

Capacity math you can defend

Start from peak, not from monthly totals. If login OTP peaks at 400 sends in ten minutes, a single consumer SIM that crawls at 15–20 SMS/minute will queue. Two OTP phones at 15/minute is not 800 in ten minutes if they share an operator account already under fair-use review. Measure on the SIMs you will actually use, in the room they will live, after a reboot.

A workable planning sheet has four columns: message class, peak per minute, devices assigned, measured sustainable rate on that SIM. If peak divided by rate is greater than the device count, you do not have a routing problem yet — you have a hardware problem. Buy or pair the missing phone before you write a smarter retry. Retries on a saturated radio duplicate OTP and look like abuse to the operator.

Webhooks should carry enough identity to know which device sent. When DLR failure rates spike on one id, pin that class to the spare and page the human who owns that handset. A fleet-wide retry storm is how a single bad SIM takes down login for everyone.

Plan device caps

Service pricing is based on device count and total SMS sent through the gateway. You need a working Android phone with a SIM and SMS credit from your mobile operator. Operator message costs are yours—we do not sell carrier SMS balance. Caps: Free 1 device; Starter 2; Professional 5; Business 15. Starter starts at $19/month. Free includes 300 SMS lifetime so you can prove deviceIds on one phone before you buy a second. Full table: device and SMS volume pricing.

Failure modes

• Bulk jobs omit deviceIds and starve OTP on the primary.
• Copied device id from staging into production.
• Assuming dual SIM equals two independent gateways.
• No spare paired when the OTP phone hits 1% and OEM kills the app.
• Inventing a /api/send-bulk-sms path — bulk is to[] or campaigns, per OpenAPI.

Next steps

Return to the API guide, then pin classes with multi-device routing. Keep OTP semantics on OTP and 2FA SMS on Android.