Traccar SMS Gateway turns an Android phone into an SMS modem with an HTTP API

One feature separates it from every other messaging app

Traccar SMS Gateway is an Android messaging app, and the documentation is clear that this is the whole difference: an option to expose an HTTP API for sending SMS messages through the phone.

That option changes what the device is. Normally a phone is a client, it asks a network to deliver a message. With the API enabled, the phone is a server. Something on your network can send a request to the handset, and the handset hands that request to the radio stack as an outgoing SMS. The phone becomes the modem, and the API is the interface to it.

The project is written in Kotlin and lives in the Traccar organisation, with a single named contributor listed in the team section, Anton Tananaev. The homepage of the wider Traccar project is traccar.org, and the README links a dedicated page for the SMS gateway, which is where the operational documentation lives.

The use case that follows from the design is a tracking server that needs to reach a user by SMS. GPS trackers and other hardware platforms often need a way to send a command or an alert to a phone number, and instead of provisioning a hosted SMS provider with its own account, the operator can use a phone that is already on the desk. The phone keeps the cost and the carrier relationship, and the tracking server keeps the API.

Fossify Messages is the foundation, not a rewrite

The README states that the project is based on another open source project, Fossify Messages, and links that project directly. Nothing here suggests a fork that has diverged into a different application, so the reasonable assumption is that the messaging features, the conversation list and the Android messaging integration come from that codebase.

That has two consequences for anyone considering this. The first is scope: the project is an SMS gateway with a messaging app around it, not a bare API service, and the inherited code brings the maintenance obligations of a general messaging application with it. The second is licensing and provenance, and here the news is good. Fossify Messages is an open source project and the result is distributed under the GNU General Public License version 3, with the full notice included in the README. A derivative work built on an open source messaging app and published as GPL-3.0 keeps the chain intact, and the licence text in the repository says the software comes with no warranty, which is the usual framing for a project of this kind.

For a project that will run on a phone people use every day, being a recognisable open source codebase rather than a purpose built script is a genuine advantage. Auditing an API server is one thing. Auditing a messaging app that has been open sourced and forked is a different proposition, because the behaviour of the application around the new feature is already public.

A Kotlin Gradle project with the quality tooling checked in

The repository layout is a standard modern Android project, and it is worth reading as a set of signals about how the project is maintained.

The build uses the Kotlin DSL, with build.gradle.kts and settings.gradle.kts at the root, and a buildSrc/ directory for custom build logic that does not belong in a module. There is a Gradle wrapper checked in, gradlew and gradlew.bat, so a build does not depend on the version of Gradle installed on the machine. gradle.properties holds shared properties, and the application module is the app/ directory.

Two static analysis configurations are present, which is more than many small Android projects carry. detekt.yml configures Detekt, a Kotlin static analyser, and lint.xml configures the Android lint tool with project specific exclusions. A .editorconfig file sets formatting rules for anyone who edits the code, including the detekt configuration file itself.

There is a .github/ directory for the workflows, which is where the build and release automation lives, given that the application is also distributed on Google Play. The combined picture is a project with continuous integration, linting and a static analyser, which is what you would expect from something maintained by the person behind the Traccar server and published under their name.

A sample keystore file tells you who builds a release

One entry at the top of the repository says more about the distribution model than the README does: keystore.properties_sample.

Android release builds are signed, and the signing key cannot be published. A project that ships a sample of the signing properties file is a project where at some point somebody assembles a signed build from the source, and where the file has been kept out of the repository so that the real credentials stay out of it too. The .gitignore sits alongside it for the same reason.

There are two ways to run this application, and they are quite different. The first is to install the published build from Google Play, which is the route the README promotes with its store badge, and which needs no build step at all. The second is to build from source, which means supplying your own signing key and accepting responsibility for a distribution channel update when the Play version moves ahead of yours.

That second route is the interesting one for anyone who wants to modify the app, since the point of an open source SMS gateway is often to add a small behaviour change. The tooling in the repository supports it, but the README gives no build command and no configuration walkthrough, so the details have to come from the project page and from the build files themselves.

The version numbers and the gap to the last commit

The release history is short and regular. Version 7.0.2 was published on 2026-06-25, and versions 7.0.3 and 7.0.4 both appeared on 2026-07-05, an hour and fifty minutes apart.

Two patch releases on the same afternoon is the pattern of a fix that had to be shipped twice, or of a release process that publishes an artefact and then republishes it. Either way it is worth knowing that a patch release in this project does not necessarily mean a behaviour change.

The last push to the master branch was on 2026-08-03, which is nearly three months before the most recent tag, so the branch has moved since 7.0.4 was published. Since the README does not state a version and the branch is the default, the source tree and the shipped application are on different points of the history.

The licence is GPL-3.0, and for a project you intend to modify and redistribute that matters in a specific way. The copyleft obligation follows the derived work, and a modified SMS gateway that you operate as a service still carries the obligation to offer its source. That is the usual bargain, and it is a reasonable one for infrastructure, but it is a decision rather than a detail.

What the HTTP API option asks of your network

The most consequential consequence of the feature is not visible in the code layout, and the README does not discuss it, so it is worth spelling out as a question to answer before deployment.

An HTTP API on a phone is a listening service on a device that is designed to roam between networks. A server that can send SMS through it has to be able to reach it, which means either exposing the phone to the internet, or placing it on a network segment where the tracking server can talk to it. Both options have consequences for the device, and the documentation for the gateway is the place to look for how the project expects people to handle it.

The project being open source and single maintainer run also shapes the security conversation. There is no formal security process visible in the repository, no SECURITY.md and no separate security contact, so an issue is a GitHub issue. For an application whose entire purpose includes receiving commands over a network, that is a fair thing to weigh.

The comparison to the obvious alternative is instructive. A hosted SMS provider gives you an API, a provider handles the carrier relationship, and you get credentials and a service level rather than a phone on your desk. Reusing a phone you already own removes the provider and its per-message cost, and adds the operational burden of a device, a network and a listening HTTP service. Which side of that trade you should be on depends on whether the phone is at the same place as the server.

Editorial conclusion

Traccar SMS Gateway suits a self-hosted tracking setup that needs to send SMS through a handset the user already owns, and it does not suit a deployment that needs a carrier grade sending service with delivery receipts and throughput guarantees. Before adopting it, read the SMS gateway page on the Traccar site, because the README does not document the API endpoints, the authentication scheme or the network exposure model, and confirm what the HTTP API option does to the phone's attack surface before you put it on a mobile network.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. traccar/traccar-sms-gateway on GitHub