httpSMS: the SMS gateway that is already in your pocket

Built where virtual numbers cannot be bought

The origin story in the README is short and specific, the author is from Cameroon and wanted an automated way to send and receive SMS via an API, but many countries do not support buying virtual phone numbers, and no good ready-made solution existed for driving an ordinary mobile phone over an intuitive HTTP API. That gap defines the product, httpSMS lets you use your Android phone as an SMS gateway, an HTTP request triggers the phone to send a message, and messages received on the phone can be forwarded to your webhook endpoint. The license is AGPL-3.0, the repository was pushed today, and releases have arrived monthly, v1.0.0 in June 2026, v1.1.0 in July and v1.2.1 in August, the cadence of a service under active operation rather than a weekend project.

The flow: 202 first, SMS later

The documented sequence diagram is worth narrating because it explains the system's asynchronous character. Your code calls the send endpoint, the API schedules a push notification and immediately responds 202 Accepted, so the caller is never blocked on radio. The push queue delivers the notification to the Android app, which asynchronously fetches the message, sends it using the Android SMS API, and then asynchronously posts the result of the send and a delivery report back to the API. Every hop after the 202 is decoupled, which is the only sane architecture when the last mile is a phone that may be asleep, offline or out of credit, and the delivery report closing the loop gives the caller a real signal instead of hope.

Encryption with the key kept on the phone

The end-to-end encryption feature is specified precisely enough to evaluate, messages can be encrypted using AES-256, and the encryption key is stored only on the mobile phone, so even the server has no way to view the content of SMS messages sent and received through it. That is the meaningful design point, the gateway is deliberately blind, routing ciphertext it cannot parse, which addresses the obvious objection to routing personal or customer messages through a third-party relay. For a service whose hosted edition sees every transaction, blindness is the difference between an operator and a confidant, and combining it with the webhook forwarding means downstream integrations receive encrypted content that only the phone's key can open.

Back pressure and expiring messages

Two operational features show the author has run this in production. Back pressure exists because abusing the Android SMS API gets numbers flagged or blocked, so you can set a rate limit, three messages per minute in the documented example, and even if the API is asked to message one hundred people, dispatch proceeds at three per minute, protecting the SIM while the queue drains. Message expiration addresses the other failure, sometimes the phone does not receive the push notification in time and the SMS cannot be sent, so each message carries a validity timeout, and when it lapses you are notified rather than left assuming delivery. Rate limiting on the way in and expiration on the way out are exactly the two controls an SMS gateway needs before being pointed at anything that matters. Together they also shape caller expectations, a bulk send is known in advance to take as long as the limit dictates, and silence after the timeout is a definitive negative rather than an ambiguity to poll.

Two clients, one webhook surface

Integration is served by official API clients for Go, in the httpsms-go repository, and for JavaScript and TypeScript, in httpsms-node, with full API documentation hosted alongside the service. The Go shape is compact:

// Sending an SMS Message using Go
client := htpsms.New(htpsms.WithAPIKey(/* API Key from https://httpsms.com/settings */))

client.Messages.Send(context.Background(), &httpsms.MessageSendParams{
    Content: "This is a sample text message",
    From:    "+18005550199",
    To:      "+18005550100",
})

Inbound is the webhook, the platform forwards SMS messages received on the Android phone to a callback URL you provide, which is what turns the phone into a two-way endpoint for alerting, verification codes or chat-bot style flows rather than a one-way sender. The .mcp.json in the repository hints at an MCP integration as well, keeping the API reachable from agent tooling alongside conventional clients.

Self-hosting: eight steps and three external services

Self-hosting is documented as an eight-step Docker procedure, and the preamble of external dependencies deserves attention before the first command, you set up Firebase for cloud messaging and authentication, an SMTP email service, and Cloudflare Turnstile for bot protection, then download the code, configure environment variables, build and run, create the system user, and build the Android app yourself. The docker-compose stack is a conventional quartet, PostgreSQL on Alpine with a healthcheck, Redis, the API on port 8000 gated on both, and the web UI on port 3000, while the hosted production API differs by running serverless on Google Cloud Run against CockroachDB, the PostgreSQL-compatible split meaning the compose stack approximates production semantics without the distributed database.

A hosted edition riding on AGPL bones

The commercial shape is conventional open-core, a hosted edition at httpsms.com with a Nuxt and Vuetify single-page web UI served from Firebase, an API built with Go's Fiber framework, uptime monitored on a public status page, API keys managed in settings, and an Android app distributed as an APK from the project's own domain, native Kotlin with material design per the README. Community support runs through a Discord server and GitHub issues, a code of conduct and a security policy are committed, and the repository divides cleanly into android, api, web and tests directories. The AGPL license is the adoption decision point, self-hosting is fully supported and documented, but offering the service to others triggers source obligations that a team should read before building a business on it.

Editorial conclusion

Use httpSMS when you need programmatic SMS in a place where virtual numbers cannot be bought, or when the SIM you already own is the right sender identity, and self-host it when message routing must stay entirely under your control. Use a commercial virtual number provider where numbers are available and you prefer managed compliance over running an app on a phone. Verify first that the Android device can maintain battery, network and push notification delivery, since the whole chain depends on it, configure the message expiration timeout for missed pushes, and read the AGPL-3.0 terms before embedding the server into a commercial offering.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. NdoleStudio/httpsms on GitHub
3. Project website
4. README
5. Releases