Key Takeaways
- Auto-reply and STOP API usage is integration around inbound: keyword match, suppression store, and a reply that only fires while the Android device is online.
- Developer Center owns live field names. This page is the state machine: who replies, who records the opt-out, who must not.
- Honor STOP on promotional lanes even if the body is messy (“stop please”). OTP threads should not get campaign auto-replies.
- A device-side keyword reply is a safety net, not a CRM. Persist opt-outs in your database from the webhook.
- Priced by devices and SMS send volume. You use your own phone and operator SMS credit. Auto-replies are SMS too — they burn operator credit and meter platform volume.
- Verify webhook signatures. Fake inbound STOP events are how attackers empty your airtime or poison your list.
Teams land on android sms gateway auto reply API usage after a STOP sits in the phone inbox and the next CSV still includes that number. This is not a second copy of the feature page. It is how your application should use inbound + send so opt-outs survive a reboot, a delayed webhook, and a well-meaning intern.
Product behavior lives on auto-reply and STOP. Pair with two-way inbox and SMS API documentation. Priced by devices and SMS send volume. You use your own phone and operator SMS credit.
STOP is a write to your suppression list that happens to travel over SMS. If the only copy of that write is a keyword rule on a phone that is asleep, you do not have an opt-out program.
What “API usage” means for STOP
Three calls, conceptually: receive inbound (webhook or poll inbox), decide (keyword / intent), send a short confirmation if policy says so, persist the MSISDN as opted out. Live JSON belongs in Developer Center. Your code should treat the MSISDN as the primary key, not the message body spelling.
Industry context still matches CTIA messaging principles for US promotional traffic: identify the sender, honor opt-out. Your SIM does not get a waiver because the originator is a handset.
Device auto-reply vs your backend
Device-side rules are fast and die with the process. Backend rules are slower and are the system of record. Production pattern: device acknowledges STOP in one SMS; webhook writes the list; your sender checks the list before every campaign row. If you only use the device, a reinstall forgets the law. If you only use the backend, a 20-second outage leaves the user thinking nobody heard them.
Keyword table: STOP, HELP, START
| Inbound (typical) | Your app should | Device auto-reply may | Do not |
|---|---|---|---|
| STOP / unsubscribe / cancel | Suppress immediately; confirm once | Send a one-line confirmation | Argue, upsell, or add a coupon |
| HELP | Identify brand + how to opt out | Short identity line | Dump a URL shortener farm |
| START / YES (if you support resubscribe) | Require a clear prior relationship | Confirm only if policy allows | Treat a random YES as consent for a cold list |
| STOP in an OTP thread | Ignore for login; do not kill 2FA | Stay silent on the OTP SIM | Unsubscribe the user from authentication |
| Garbage / empty | Log; no reply loop | No match, no send | Echo the inbound forever |
Normalize case and extra words (“Please STOP”). Do not require exact tokens unless you enjoy complaints.
Inbound path the API cannot fake
The radio has to be up, the SIM has to receive, notification access and default SMS app have to allow the agent to see the message, and the control plane has to deliver an event. If any step fails, your API never hears STOP. That is an ops problem — see notification access — not an extra header you can set.
Idempotency and double replies
Webhooks retry. Device rules may also fire. Cap confirmation SMS at one per MSISDN per day for STOP. Key the suppression row on the number, not on the inbound message id. Duplicate delivered events should not produce duplicate “you are unsubscribed” texts — those look like harassment.
Never auto-reply on the OTP SIM
Isolate devices. Promotional keywords live on the promo pool. Login SIMs stay quiet except for codes. Mixed pools are how a campaign auto-reply delays a password reset. Rotate and label: rotate devices for volume.
When the phone is offline
Pause the campaign worker when the promo device drops. Inbound STOP may arrive later and still must suppress. Do not keep blasting a list because “we will catch STOP when it comes back.” That hour is the complaint.
Webhooks and your suppression list
Verify signatures. Apply STOP before the next send, not in a nightly batch if you send all day. Export the list before you migrate vendors. The webhook in-depth guide covers the pipe; this page only insists the pipe writes a row your CSV mapper will actually read.
Cost of a missed STOP
Priced by devices and SMS send volume. You use your own phone and operator SMS credit. Confirmation SMS and the original campaign both spend operator credit. A missed STOP spends reputation. Free-tier 300 SMS is for rehearsing the keyword path on staff numbers.
Checklist
- Suppression store is durable and checked on every campaign send.
- Device keyword + backend write both exist; confirmation is idempotent.
- OTP SIMs have no promo auto-reply rules.
- Webhook signatures verified; duplicates ignored.
- Offline promo device pauses the list.
- Staff canary: text STOP, see confirm, see list row, see next send skip.
- HELP identifies the brand without spammy wording.
- No API keys in auto-reply templates.
- Developer Center checked for live inbound fields.
- Runbook names who owns the suppression export.
Next steps
Configure the product on auto-reply and STOP, keep the agent awake via the app guide, and size sending on pricing. The API is the easy half. The list is the job.
Related product pages
Jump to the live product docs for this topic—not another long-form article.
- two-way SMS inboxReplies on your SIM
- SMS auto-reply and STOP keywordsOpt-out and keywords
- SMS API documentationLive endpoint reference
- device and SMS volume pricingPlans and allowances
