Key Takeaways
- OTP priority-queue setup is a backend + device-pool design: login SMS never waits behind a CSV blast on the same radio.
- Do not invent priority=high on POST /messages unless OpenAPI says so. Live fields live in the docs.
- Pin OTP with deviceIds to a dedicated SIM. Promo uses other ids.
- Idempotency-Key = userId+challenge so retries do not double-send codes.
- 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.
Android SMS gateway OTP priority queue setup is for teams whose login codes sit in the same worker as “weekend sale.” The radio does not care that finance labeled one transactional. A dedicated device pool plus a dedicated consumer in your app is the setup. This is not a packaged SDK and not an invented priority flag.
Service pricing is based on device count and total SMS sent through the gateway. Pillar: OTP verification. Contract: API docs.
A priority queue that still writes to one SIM is a sorted list of delays.
Priority is your queue, not a fake API field
Your auth service already creates a challenge. Put OTP jobs on a high-priority worker. Put campaigns on another. Both may call the same POST /messages with Bearer JSON — different deviceIds. Do not copy undocumented fields from a blog.
curl -X POST "https://app.sms-gateway.app/api/v1/messages" \
-H "Authorization: Bearer $SMS_GATEWAY_API_KEY" \
-H "Content-Type: application/json" \
-H "Idempotency-Key: 3f1b0c8a-9d2e-4c77-9f5a-2b6d1e0f4a83" \
-d '{"to":["+14155552671"],"text":"Your verification code is 481920","type":"sms"}'Lane table
| Lane | Worker | Devices | Idempotency |
|---|---|---|---|
| Login / 2FA | OTP consumer, short timeout | Pinned OTP SIM(s) | userId + challenge id |
| Receipts / alerts | Transactional worker | Ops SIM | orderId + event |
| Promo / CSV | Slow, paced | Promo SIM only | campaign + recipient |
Worker design
Bound OTP concurrency to what that SIM can land (OEM ceilings + carrier fair-use). Retry with backoff on 5xx/timeouts; never retry-storm the same challenge without the same Idempotency-Key. DLR webhooks update the challenge row — the SPA polls you, not the gateway. Webhooks.
Pin OTP with deviceIds
Spare charged OTP phone is failover, not a place to dump the newsletter. Multi-device. 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.
How promo starves login
Concatenated UCS-2 campaigns occupy the radio for seconds each. A hundred of those in front of a 30-second OTP SLO is the incident. STOP and consent still apply on the promo worker — bulk consent.
Checklist
- Two workers, two device pools.
- OTP Idempotency-Key stable per challenge.
- No priority field invented off-docs.
- p95 DLR on a cold OTP handset.
- Promo cannot enqueue on the OTP id.
- Codes not logged in Slack.
Next steps
Pair an OTP-only phone via downloads, fire a staff canary during a dummy CSV, and confirm login still lands first.
Related product pages
Jump to the live product docs for this topic—not another long-form article.
- OTP and 2FA SMS on AndroidAuthentication flows
- SMS API documentationLive endpoint reference
- device and SMS volume pricingPlans and allowances
- device setup guidePair and go live
