Android SMS Gateway contact lists: Best practices

Featured illustration for Android SMS Gateway contact lists: Best practices

Android SMS Gateway contact lists — best practices. Feature deep dive on contact lists (best practices). Unique examples and failure modes; link matching /features path when exists. Priced by devices and SMS send volume; BYO phone and operator credit.

Written by the SMS Gateway team for operators who run phones and airtime themselves — not for theoretical cloud SMS demos.

InformationAndroid SMS GatewayFeaturesOperations
Article
Published
June 23, 2026
Updated
July 24, 2026
Reading time
16 minute read

Key Takeaways

  • Store people, not spreadsheets. Consent, opted_out, locale, and message class live on the contact so the next import cannot wipe them.
  • Never delete a STOP record to “make room” under the contact cap. Archive with the flag intact.
  • Free includes 300 contacts and 300 SMS lifetime. That is burn-in, not a license to keep a dirty CRM dump.
  • OTP recipients can sit in the same directory. They must not sit on the same send list or the same SIM as campaigns.
  • Priced by devices and SMS send volume. You use your own phone and operator SMS credit. Bad numbers still cost airtime when you send them.

A directory is not a blast list

Best practice for Android SMS gateway contacts is boring on purpose. You keep one record per MSISDN, you attach facts that survive the next intern’s Excel, and you send from lists that are slices — not from “Sheet1.” The pillar is contacts, lists, and segments. How to cut slices in the app is how to segment contact lists. This page is the hygiene that makes those slices mean something.

If deleting STOP records is how you stay under the contact cap, you do not have a list problem. You have a compliance problem you are optimizing for.
A contact record with consent checked and STOP stamped so imports cannot clear it+15551234567source: checkout · 2026-03-12consentedOPTED OUT
Best practice is a sticky flag, not a tab named “do not mail”

Fields you actually need

E.164, consent source, consent time, opted_out, language, timezone, message class, last inbound, last DLR. Nickname is optional. “VIP” as a boolean with no owner is how someone blasts the CEO’s personal number from the promotional SIM.

Practice vs anti-practice

TopicDoDo not
IdentityOne E.164 keyMatch on “name + last four digits”
STOPSticky flag, all devicesA separate spreadsheet tab
OTP vs promoSame person, different lists/SIMsOne “all customers” send
ImportsSkip counts on dry-runReplace-all from CRM
Cap pressureArchive with flagDelete opted-out to free slots
BodiesTemplate id + DLRFull OTP plaintext in CRM

Name an owner

Marketing may request a list. Engineering owns device mapping. Someone with a spine owns consent. When those three are “the intern this month,” STOP will leak. Write names in the runbook next to STOP handling.

CRM sync without resurrection

Nightly HubSpot or Salesforce dumps are the usual murder weapon. Map on E.164. Refuse to set opted_out=false from the CRM unless the CRM itself recorded a documented START. Prefer CSV import dry-runs even when the pipe is an API — the rule is the same.

How to keep lists honest

  1. Define the record. E.164, consent source + time, opted_out, language, timezone, message class, last DLR.
  2. Ban mystery columns. If nobody can say why a field exists, drop it. Extra PII is extra incident surface.
  3. Make opted_out sticky. Imports and CRM sync cannot clear it from a spreadsheet.
  4. Split send lists, not the person. One contact, many lists. OTP list ≠ campaign list. Device map is required.
  5. Review stale reachability. No successful DLR in 90 days is a review, not another blast.
  6. Name the human. Who may import, who may export, who is paged when STOP is ignored.

Two-way replies that update the record (STOP, new mobile number in free text) need the two-way inbox plus a human for anything that is not a token.

What not to store

Government IDs, full card numbers, health detail, and plaintext OTP do not belong next to an MSISDN in a messaging directory. GDPR-minded handling is a separate how-to; the practice here is: if a field is not required to send or to honor STOP, leave it out.

Directory cost

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. Contacts are not a second billing dimension we invent — Free’s 300 cap is a plan limit, not a per-contact fee. Sending still meters volume plus your carrier bill. Paid from $19/month. Device and SMS volume pricing.

Next steps

Start at contacts and lists, import only on plans that include Excel/CSV, and keep promotional keywords on auto-reply and STOP.

Jump to the live product docs for this topic—not another long-form article.

FAQ

Frequently asked questions

Direct answers about android sms gateway contacts.

How many contacts does Free include?

300 contacts on Free, with 300 SMS lifetime and one device. Paid plans raise device and volume caps; operator airtime stays yours.

Should I keep separate databases for marketing and OTP?

Separate send paths and SIMs, yes. Separate source-of-truth directories, usually no — you want one opted_out flag. Two CRMs is how STOP dies.

Is a “do not contact” Excel tab good enough?

No. Tabs get forgotten. The flag has to live on the person and be checked at send time, including scheduled campaigns.

Can I store full SMS bodies on the contact timeline forever?

Prefer metadata (template id, timestamp, DLR). Full OTP bodies in a shared CRM are a security incident. Retention follows your policy, not “the panel still has space.”

Where is the feature pillar?

Contacts, lists, and segments. This page is operating practice. Segmentation how-to for the Android app is a Hub D sibling — do not clone it here.
Keep learning

Topically related guides—chosen by subject overlap, not a fixed sitewide footer.

Information
android sms gateway auto reply

Android SMS Gateway auto-reply and STOP: Best practices

Android SMS Gateway auto reply and stop — reply and STOP-best practices. Feature deep dive on auto-reply and STOP (best practices). Unique examples and failure modes; link matching /features path when exists. Priced by devices and SMS send volume; BYO phone and operator credit.

Jul 9, 202516 min
Read article
Information
android sms gateway bulk csv

Android SMS Gateway bulk CSV import: Best practices

Android SMS Gateway bulk csv import — best practices. Feature deep dive on bulk CSV import (best practices). Unique examples and failure modes; link matching /features path when exists. Priced by devices and SMS send volume; BYO phone and operator credit.

Oct 29, 202516 min
Read article
Information
android sms gateway delivery reports

Android SMS Gateway delivery reports: Best practices

Android SMS Gateway delivery reports — best practices. Feature deep dive on delivery reports (best practices). Unique examples and failure modes; link matching /features path when exists. Priced by devices and SMS send volume; BYO phone and operator credit.

Feb 8, 202516 min
Read article
Information
android sms gateway dual sim

Android SMS Gateway dual SIM routing: Best practices

Android SMS Gateway dual sim routing — best practices. Feature deep dive on dual SIM routing (best practices). Unique examples and failure modes; link matching /features path when exists. Priced by devices and SMS send volume; BYO phone and operator credit.

Mar 17, 202516 min
Read article

Browse the full Android SMS gateway knowledge base or return to how an Android SMS gateway works.

Get started

Test the gateway on your own Android phone

Install the app, pair one device, and validate your API flow before choosing a paid plan.

You supply the phone, SIM, and operator SMS credit.