Key Takeaways
- A marketplace is several contact ledgers: buyers in checkout, sellers on duty, and a promotional audience that must be able to STOP.
- Consent metadata lives with the number. A CSV dump of “everyone who ever messaged a listing” is not a sendable list.
- Free is 1 device, 300 SMS lifetime, and 300 contacts. Platform price is devices plus send volume; carrier credit is yours.
- Seller “new bid” alerts are operational. Weekend feature blasts are promotional. They do not share a SIM.
- Import validation is cheaper than transmitting junk rows that still decrement operator balance.
Summary
Marketplaces fail SMS in a distinctive way: they treat “users” as one blob. Buyers need checkout OTP. Sellers need bid, order, and payout pings while they are on a job site. Growth wants a weekend blast about a new category. Those are three lists, three templates, and usually three device stories. Service pricing is devices plus SMS send volume. You supply the Android and the operator credit. Free is 1 device, 300 SMS lifetime, and 300 contacts.
Professional caps at 5 devices — enough to isolate OTP, seller-ops, and a paced promo SIM if you actually pair and charge all five. Platform “Unlimited SMS” on paid catalog rows means uncapped platform send volume, not free carrier traffic. Confirm list APIs in Developer Center.
buyer · seller · promo ledgers
scan rejects rows without consent source
Three ledgers, not one mega-list
Buyer ledger: E.164 numbers collected at checkout or login, hashed OTP codes, short TTL, no promo footer. Seller ledger: numbers the seller verified when they enabled SMS alerts, with quiet hours for non-payout events. Promo ledger: explicit opt-in, campaign id, and STOP processing that does not unsubscribe the seller from “buyer paid you.”
Cross-link contacts, lists, and segments and consent-minded bulk SMS. Do not import marketplace chat exports into the promo ledger because someone “already talked.”
If a seller replies STOP to a feature announcement, that must not mute the “you sold the sofa” message. Store suppression per purpose, not per phone number as a global death flag — unless the seller asked to leave SMS entirely.
Marketplace list matrix
| Ledger | Who is on it | Radio failure |
|---|---|---|
| Buyer auth | Checkout / login OTP only | Seller blast queued on the same device |
| Seller ops | Bid, order, payout, dispute | Quiet-hour logic missing; 02:00 bid spam |
| Promo | Category launches, coupons | CSV without consent source; STOP ignored |
| Support bridge | Two-way inbox for open tickets | Auto-reply bot talks over a live dispute |
Consent rides with the number
Every import row needs a source (checkout checkbox, seller settings toggle, paper form, inbound JOIN) and a timestamp. Rows missing source stay in quarantine. Country format mistakes — local numbers without country code — should fail closed. See number format hygiene.
Retention is a product decision. A deleted seller account should leave the promo ledger immediately. Buyer OTP numbers are not a remarketing list unless they opted into that purpose. Google’s SMS/MMS advertising rules are a starting point, not your only statute.
Seller fan-out without starving OTP
A popular listing can page fifty sellers. That is volume you pay twice: platform send meter and carrier airtime. Pace the fan-out. Prefer a digest when the seller is offline. Never let a category-wide “new listing nearby” job sit on the OTP device.
Webhooks from the marketplace core should be signed the same way as any other automation. Conceptual shapes only — live fields in Developer Center. DLR tells you the radio finished, not that the seller acted.
Devices, volume, and airtime
Model cost as connected Androids + platform SMS volume + operator balance. Failed validation should not hit the radio. Failed radio retries should. Free (1/300/300) is for a staging marketplace, not a national classifieds site.
List hygiene operations
Weekly: bounce and DLR-fail rates per ledger, STOP volume on promo, seller numbers that changed SIMs, and pairing health on each pool. After an OEM update, re-canary buyer OTP and one seller-ops template on staff accounts. Name who owns list imports so a growth intern cannot paste a scraped file.
Setup: device setup, Downloads, pricing.
Decision guide
Ship when ledgers, purpose-level STOP, import quarantine, and OTP isolation exist. Delay if “the user table” is your only list. If you will not operate phones, rent aggregator traffic instead — and stop comparing that invoice to a device-plus-volume service fee on your own SIMs.
List-launch checklist
- Buyer / seller / promo ledgers created with owners.
- Consent source required on import; quarantine otherwise.
- Purpose-level STOP, not a single global mute unless requested.
- OTP device pool isolated from seller fan-out and promo.
- Staff canary on both buyer login and seller payout templates.
- Airtime and platform volume budgeted separately.
- Developer Center checked; samples treated as conceptual.
Next steps
Read how the Android SMS gateway works, the Android SMS gateway app hub, and FAQ.
Related product pages
Jump to the live product docs for this topic—not another long-form article.
- contacts, lists, and segmentsAudience hygiene
- bulk SMS from Excel and CSVSpreadsheet campaigns
- bulk SMS with consent best practicesHigh-volume outreach
- SMS API documentationLive endpoint reference
