Key Takeaways
- Dual SIM API usage is selecting a send path on a paired handset — android sms gateway dual sim is not a second host.
- Multi-device uses deviceIds. Slot/subscription fields belong to live OpenAPI; do not invent names in a blog.
- Omit routing flags and the account primary (and that phone’s default SIM) takes the job.
- Pin OTP with an explicit id. Round-robin conversations fracture inbound.
- Priced by devices and SMS send volume. You use your own phone and operator SMS credit. Routing flags do not include operator airtime.
- Prove with a staff canary. Free is 300 SMS lifetime.
What the API can choose
This feature spoke is dual SIM routing (API usage). Searchers still hit android sms gateway dual sim; the job is to pick a path in code without inventing hosts. Service pricing is based on device count and total SMS sent through the gateway. Pillar: dual SIM and multi-device. Practices: dual SIM routing best practices.
If a field is not in OpenAPI this week, it is not a production contract. Copy-paste from an old gist is how slot selection “mysteriously” no-ops.
deviceIds vs SIM slot
deviceIds selects which paired Android claims the job. Dual SIM inside that phone is a second axis. Many teams set the default subscription in the app and only pin device id from the API. That is valid and easier to support.
| Intent | Mechanism | Note |
|---|---|---|
| This chassis, not that one | deviceIds on POST /messages | Multi-device accounts; numeric ids from the panel |
| This SIM on a dual-SIM phone | App default slot and/or documented subscription field | Confirm OpenAPI — blogs do not freeze field names |
| OTP never shares promo | Separate deviceId (or dedicated phone) | Safer than hoping slot B is “usually quiet” |
| Look up what happened | GET /messages/{id} + webhooks | deviceId in payloads helps on-call |
Send shape (confirm OpenAPI)
Official sample uses a named device. Live field names: docs.sms-gateway.app.
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]}'Keys in env — secure API keys. PHP/C# pages are REST samples, not an SDK package.
Errors worth mapping
- Unknown device id — you deployed a nickname map that drifted.
- Device offline — queue waits; this is not a slot bug.
- Insufficient plan volume — Free/Developer pause; not silent $0.0x overage.
- Empty SIM — operator reject; switch path or top up.
DLR and inbound still per MSISDN
message.delivered / message.received carry the number that actually sent or received. STOP on slot B does not suppress slot A unless you join them in CRM. DLR · webhooks.
Canary: 300 SMS lifetime on Free is enough to prove both paths once.
Client checklist
- OpenAPI pulled this week.
- OTP uses a hardcoded device id from config, not “first healthy.”
- Logs store deviceId + message id, not the Bearer token.
- Idempotency-Key on OTP.
- Staff A/B canary after app or OS update.
Next steps
Pair the dual-SIM phone ( setup), send two labeled messages, then encode the pin in your worker. Meters: pricing.
Related product pages
Jump to the live product docs for this topic—not another long-form article.
- multi-device and dual SIM routingCapacity and failover
- SMS API documentationLive endpoint reference
- device and SMS volume pricingPlans and allowances
- Android SMS gateway product guideDefinition, product, and how to buy
