Tetracom logo — tetrahedron mark

SMS gateway

Let senders you have named turn a Tetracom message into a real text message — off unless you switch it on.

Back to user help index

The SMS gateway is an optional extra. It is for people who are setting up a dedicated handset whose job is to send text messages on request. When it is switched on, a message that is marked as an SMS command, and that came from a sender on your allowed list, is not shown to you as a message at all — Tetracom hands it straight to a companion app on the same phone, which sends it on as a normal text message (SMS) from that phone’s SIM. Tetracom then quietly tells the sender whether it worked.

Most people never need this page. The SMS gateway is a separate app that you have to go and install on purpose. If you have not installed it, nothing on this page is running on your phone, nothing can be sent from your number, and you can safely stop reading here.
Read this before you turn it on. Switching the SMS gateway on lets that sender make your phone send real text messages — to numbers you did not choose, charged to your phone plan, and appearing to come from your number. Only turn it on if you set this up on purpose and you trust the senders you name completely. If you did not deliberately install an SMS gateway app, leave this off.

On this page

What it is and who needs it

Normally, when someone sends you a Tetracom message, you see it. The SMS gateway changes that for one special kind of message: a message that is marked, in the message itself, as an SMS command. Messages of that kind are treated as instructions, not as messages for you to read.

Each instruction says: send this text, to this phone number. Tetracom passes it to the SMS gateway app running on the same phone, and that app sends the text using the phone’s own SIM.

It is the message that is special, not the sender. Only messages marked as an SMS command are treated this way. If the same account also sends you an ordinary message — a voice message, a text, a question with buttons — that one arrives in your History and notifies you exactly like any other, because it is not an SMS command. Marking is not something a sender can fake: it is sealed into the message along with who it is from and who it is for, so it cannot be added, removed or changed on the way.

Two apps, one phone

This is the part that surprises people, so it is worth being plain about it. There are two separate apps, and the phone needs both:

They are deliberately split. The app that can send texts from your number is kept as small and as boring as possible, and it does not decide anything — it only takes orders from Tetracom on the same phone, over the phone’s own internal connection at 127.0.0.1:8769. That address means “this phone, and nothing else”: it is not reachable from the internet, from your Wi-Fi, or from any other device.

The gateway listens on both of the phone’s internal addresses on that one port — 127.0.0.1 and [::1], the older and newer ways of writing “this phone” — because handsets do not agree on which of the two localhost means. 127.0.0.1 is the one Tetracom always asks for, so that is the one that has to work; [::1] is a courtesy, and is skipped quietly on a phone that has no use for it. Neither of them makes the gateway reachable from anywhere but the handset itself.

Who this is for. A dedicated handset — one phone, plugged in, left alone, whose whole purpose is to send texts on request. A typical use is delivering a sign-in code to someone who can only receive it by text. If that is not what you are building, you do not want this.
It is off by default. A brand-new install never forwards anything. Nothing anyone sends you can turn it on — only you can, in Settings. Installing the gateway app changes nothing on its own.

Setting it up, in order

The order matters. Each step produces something the next step needs, and the gateway app refuses to start until it has been told which Tetracom account it belongs to.

Download the SMS Gateway APK → Download the Tetracom app →

Tap these on the phone that will send the texts — both apps go on that same handset, and the messages leave on its SIM. The Gateway download is small (about 2 MB); the Tetracom app is much larger (about 23 MB). If you only wanted the Gateway and a 23 MB download starts, you tapped the wrong one.
  1. Install both apps on the same phone. Go to the install page on the phone that will send the texts. Download and install the Android APK (tetracom.apk) if it is not there already, then download and install the SMS Gateway APK (tetracom-sms-gateway.apk). The texts go out on this phone’s SIM and are charged to this phone’s plan.
  2. Sign in to Tetracom on that phone as the identity that will receive the instructions, and note its userid. You will need it in the next step.
  3. Open the SMS Gateway app and grant the SMS permission when Android asks. Without it the app cannot send anything. If you tapped “Deny” by accident, grant it from Settings → Apps → Tetracom SMS Gateway → Permissions → SMS.
  4. Type the Tetracom userid into Relay userid and tap Save. This is the account from step 2. The gateway will not listen at all until this is filled in and saved — that is deliberate, so a freshly installed gateway is never sitting there accepting work from anything.
  5. Tap Start. The Status block at the top of the screen should change to “Running — listening on 127.0.0.1:8769, [::1]:8769”; if it says anything else, it tells you what to do next. A permanent notification also appears, naming the same addresses. That notification is not clutter — it is what keeps the gateway alive, and it is your at-a-glance reminder that the service is still up. Do not swipe the app away in the task switcher.
  6. Copy the two pairing values from the Gateway screen. There are two, and you need both:
    • Bearer token — tap Copy. This is a password; treat it like one.
    • Relay binding ID — tap Copy binding. This is a code the gateway made for itself, which ties that token to this particular gateway.
  7. Switch to Tetracom on the same phone and open Settings → SMS gateway.
  8. Paste them in. Put the token in Gateway bearer token (it shows as dots, like a password) and the binding code in Gateway relay binding ID. Leave Gateway host at 127.0.0.1 and Port at 8769 unless the gateway app is showing you a different port.
  9. Add your sender under Allowed SMS senders. Type the userid of the sender you are authorising — for example sendsms1 — and tap Add. You can add more than one; each gets its own row with a Remove button. This step is not optional. While the list is empty, nothing at all is forwarded, no matter who sends it and no matter how the switch below is set.
  10. Last, switch on Forward SMS commands. This is the master switch. Until you flip it, everything above is just saved settings and nothing is forwarded.
Fill in the details before you flip the switch. Turning forwarding on with a missing or mistyped token will not send any texts — the requests will simply fail, and the sender will be told the gateway could not be reached.
The token is a password. Anything on that phone that knows it can ask the gateway app to send texts. Do not paste it into a chat, a screenshot, or a support email. If you think it has leaked, tap Regenerate in the gateway app — but note that this also creates a new relay binding ID, so you must copy both values across to Tetracom again.
It stays off until you turn it on. Two things ship in the safe position and stay there until you change them: Forward SMS commands starts off, and Allowed SMS senders starts empty — which means nobody is allowed. Nothing you receive, and nothing either app does on its own, can change either one.

Is it working? Look at the top of the app

Open the Tetracom SMS Gateway app on the handset. Above every setting — above the token, above the pairing boxes, above Start and Stop — there is a section headed Status. It is there to answer one question, in one line, without you having to work anything out: is this thing working? Everything below it is setup you did once. This part is live.

New in gateway 0.1.4. Earlier versions opened straight onto the setup fields, and the permanent notification was the only place to look. That notification is still there and still does its job — but the app’s own screen now gives the fuller answer, and it is the one to check first.

The headline

The first line is in bold, and it is the whole answer. There are five of them, and a plain-language line underneath telling you what to do next.

The addresses are read back, not printed from a setting. Whatever the headline names is where the gateway actually managed to listen. So if it says 127.0.0.1:8769, that really is live — and if it cannot report an address at all it says “no listening address” rather than guessing, which means the service is up but nothing can reach it.
“Running, but it cannot send” is the one that fools people. From any distance it looks alive: the app is started, the notification is showing, the port is open. Every text will still fail. If you only ever glance at the notification you will not catch this one — the app’s own screen is where it is spelled out.

Permission and SIM

Under the headline is the familiar readiness line, unchanged:

SEND_SMS permission: yes  ·  SIM ready: yes

Both need to read yes. A no here is the same fault the headline is describing when it says it cannot send; this line just tells you which of the two it is.

The counters

Next comes a running tally of what this gateway has done:

Sent 12  ·  Failed 1  ·  Sending now 0  ·  Unresolved 0

These are totals over the last 30 days — that is how long the gateway keeps its record of jobs before it prunes itself. They are not lifetime figures, and they are not since-you-opened-the-app figures. A Sending now that never comes down, or an Unresolved that keeps climbing, is worth looking into.

Send allowance

Last in the status block is how much headroom is left in the rate limit:

Send allowance: 58 of 60 left this minute

The second number is the one you set yourself, under Send limit (messages per minute) — see How many texts it will send in a minute. The first is what is left of it right now.

When the allowance drops below a quarter of your limit, the line adds a warning: further submissions will be refused with rate_limited, and a refused security code is a failed sign-in for someone. When the gateway is stopped there is nothing to count, so it reads Send allowance: 60 per minute. Counted only while the gateway is running.

This is how you know whether to raise the limit. Guessing at a number is guesswork; watching this line during your busiest few minutes is not. If it regularly runs down near zero, your real traffic is close to the cap and you should raise it. If it barely moves, leave it alone.

What it is doing right now

Below the status block is a section headed What it is doing: a list of the recent jobs, newest first, up to 20 of them. It refreshes every couple of seconds while the screen is open, so a text that is going out right now is visibly going out right now — you can stand there and watch it change. Before anything has ever been sent it simply reads “Nothing sent yet.”

Each entry is two lines: how long ago it happened and what state it is in, then the sending client’s own reference for the job, indented underneath. Times are relative and deliberately rough — just now, 5 min ago, 2 h ago, 3 d ago.

The five states

The differences between the first four are the operationally useful part of this whole page, so it is worth being exact about them.

  1. Sending now means the gateway has taken the job, and the radio has not got it yet. Nothing has left the phone.
  2. Sent means the phone has let go of every part of the message. This is the one that means the text left the phone.
  3. Delivered is stronger, and it is never assumed: it appears only when the carrier actually confirmed the message arrived. Plenty of carriers never report this, so its absence does not mean anything went wrong.
  4. Unresolved means the confirmations never came back, so the gateway genuinely cannot tell you whether it went out. It is reporting honestly rather than guessing.
Nothing is ever resent automatically — least of all an “Unresolved”. A duplicate security code is not free: it confuses the person waiting on it, it costs you a text, and it can invalidate the code they already had. If something genuinely needs sending again, a person decides that.

The failure explanations

A failure names its cause in brackets and then explains it. These are the ones you may see:

An unfamiliar code is shown on its own. If the app does not recognise a code it prints it bare, with no explanation after it, rather than inventing a plausible-sounding one. If you see that, the code itself is what to quote to whoever is helping you.

What the list never shows

No message text. No phone numbers. Ever. The activity list shows the state, the timing, and the reference the sender chose for the job — and nothing else. The text of the message and the destination number are not just hidden from this screen; they are never written to disk at all, so there is nothing there to leak, screenshot, or recover later.

This is deliberate, and it is worth understanding why, because it is the main reason the screen is worth leaving on. These texts routinely carry one-time security codes. A gateway handset lies face-up on a desk all day. A screen that listed the codes it had just sent would hand them to anyone walking past — which would defeat the entire point of sending a code in the first place.

The secrets stay in their own sections. The Bearer token and the Relay binding ID appear only in their own parts of the screen, further down. Neither is ever shown in the status block or the activity list, so the top of the screen is safe to leave visible and safe to photograph.
These are the app’s words, not the sender’s. The person who sent the instruction sees the same journey described slightly differently — accepted, device sent, carrier delivered, unknown. They mean the same things in the same order; see What “sent” actually means if you are comparing the two side by side.

Who is allowed to send

In Settings → SMS gateway there is a list called Allowed SMS senders. It is the guest list for your phone’s SIM: only the userids on it can ever make this phone send a text.

Add one by typing the userid and tapping Add. Remove one by tapping Remove on its row. Userids are saved in lower case with spaces removed, so it does not matter how you type them.

An empty list means nobody is allowed. This is not the same as “no restriction”. With an empty list, nothing is ever forwarded — not even from an approved, verified contact, and not even with the master switch on. If you have set everything else up and no texts are going out, this is the first thing to check.

The list is also a perfectly good way to turn the feature off for one sender without turning it off for everybody: remove just that row. Emptying the list altogether stops all forwarding, which is a second, equally effective way of switching the whole feature off.

Being on the list is not enough on its own. A listed sender still has to be an approved, unblocked contact and still has to prove who they are — see below.

The three things that must all be true

Tetracom will only forward an instruction when all three of these hold. If any one of them fails, the instruction is thrown away and the sender is told nothing at all.

  1. The sender must be on your Allowed SMS senders list, and must be one of your approved contacts. A stranger cannot do this, and neither can an approved contact you have not added to the list. If you have blocked them, it also stops here. While the list is empty, everyone fails this check.
  2. The instruction must be cryptographically signed. Tetracom checks the sender’s digital signature and proves the message really came from them. Anyone can claim to be one of your allowed senders — only the real one can produce the signature. An unsigned or unverified instruction is discarded, every time.
  3. The “Forward SMS commands” switch must be on in your Settings. This is the master switch, and it starts off.
The signature check is not something you can turn off, and it is not a warning you can tap past. It is the reason someone cannot just claim to be one of your allowed senders and start sending texts on your bill.

Keeping it running

A gateway that is not running is not a gateway. This is the part of the job that actually takes attention, because Android works quite hard to shut down apps it thinks you are not using — and a phone sitting in a cupboard sending the occasional text looks exactly like an app you are not using.

Three things keep it alive.

  1. The permanent notification. The gateway runs as a foreground service, which is Android’s way of saying “this app is doing something on purpose.” The “Listening on 127.0.0.1:8769, [::1]:8769” notification is the visible half of that. It cannot be dismissed while the gateway is running, and that is the point. If it disappears, the gateway has stopped. It is a good reminder that the service is alive, but it is not the full picture — a gateway that is listening and still cannot send a thing looks perfectly healthy from the notification shade. When you actually want to know, open the app and read the status block at the top.
  2. The battery-optimisation exemption. On the gateway app’s Staying up 24/7 section you will see Battery-optimisation exemption granted: no and a Grant exemption button. Tap it and accept the Android prompt, so the line reads yes. The app will never request this silently — you have to grant it by hand, during setup.
  3. Mains power. Leave the handset plugged in. Battery savers of every kind get more aggressive as the battery drops, and a gateway phone has no reason to ever be on battery.
Skipping the battery exemption is the most common way this quietly stops working. Without it, vendor power management typically kills the service within a day or two — and it does so silently. Nothing tells you. You find out when a text that should have arrived did not.

Samsung phones need more than the exemption

Samsung’s One UI has its own power management on top of Android’s, and it will override the exemption. On a Samsung gateway handset you also need to:

The step-by-step screens are in the Samsung guide — it is written for the Tetracom app, but apply the same steps to Tetracom SMS Gateway as well, since both have to stay awake. There are equivalent guides for Google Pixel, OnePlus, Motorola, Xiaomi, and other Android phones.

After a reboot: it waits for the first unlock

This is the single most important limitation on this page. When the phone reboots, the SMS gateway does not come back at power-on. It comes back only after somebody has unlocked the phone at least once. A handset that reboots overnight and sits at the lock screen is not a working gateway, and nothing will tell you.

The reason is straightforward. The gateway’s token is kept in the part of Android’s storage that stays encrypted until the phone is unlocked for the first time after a restart. Before that unlock the app genuinely cannot read its own credentials, so it does not start. This is a deliberate trade: the alternative would be storing the token somewhere readable before first unlock, which is worse.

What this means in practice, for a handset you are not standing next to:

It also fails closed on purpose. After a reboot the gateway restarts only if you had it running when the phone went down. If you had tapped Stop, or the relay userid was never saved, it stays off and stays quiet. Restarting the phone never turns the gateway on for you.

Forwarded commands never appear in your inbox

A message marked as an SMS command is never shown to you. It does not land in History, it does not raise a notification, it does not make a sound, and it does not pop anything up on screen. This is deliberate: those instructions are machine traffic, not conversation, and mixing them into your messages would just be noise.

This applies to SMS commands and to nothing else. An ordinary message from the very same account — a voice message, a text, a question with buttons — behaves completely normally: it appears in your History and notifies you like any other message. So an account that usually sends instructions can still send you a plain message when it needs to.

There are two places you will see any sign of this feature working, and neither of them is your inbox. In the gateway app, the “What it is doing” list shows the recent jobs by state and time. In Tetracom, the “Last SMS gateway event” line in Settings shows how the most recent instruction was handled — see Checking that it is working. Neither shows a phone number or a word of any message.

This holds even when an instruction is broken or rejected, and it holds whether or not the sender is on your allowed list. An instruction from a sender you never allowed is still hidden first and refused second — it is never put on your screen as raw gibberish. There is no path by which an SMS command can get text of the sender’s choosing displayed to you.

What “sent” actually means

A text does not succeed or fail in one step, so the sender does not get one answer. They get a short run of updates as the text makes its way out, and the words are not interchangeable.

  1. Accepted — the gateway app has written the job down safely. That is all it means.
  2. Device sent — Android has confirmed that every part of the text was handed to the mobile network. This is the one that means the text left the phone.
  3. Carrier delivered — the network later confirmed delivery to the recipient. This is a bonus: not every carrier reports it, so its absence does not mean anything went wrong.
  4. Failed — it did not go, and it is not going to. This is final.
“Accepted” does not mean the text was sent. It means the request was written down. If you read accepted as done you will tell someone their code is on the way when it may not be. Wait for “device sent” — that is the real signal, and it is the one to build any check or alarm on.

There is a fifth word you will occasionally see. Unknown means the answer is genuinely ambiguous — the phone restarted, or a callback never came back, at a moment when the text may or may not have gone out. When that happens the gateway does not try again by itself. That is on purpose: a duplicate text is a real cost and a real annoyance, and guessing wrong in the other direction is worse than reporting honestly that nobody knows.

Nothing is retried automatically anywhere on this path — not the connection between the two apps, and not the text itself. If something has to be sent again, a person decides that.
The gateway app words it slightly differently. This section is about what the sender is told. On the gateway’s own screen the same four steps read Sending now, Sent, Delivered and Failed, and unknown appears as Unresolved — see What it is doing right now. Same journey, same meanings; only the wording differs.

How many texts it will send in a minute

The SMS gateway app has a setting called “Send limit (messages per minute)”. It is a safety cap: it stops a runaway or misbehaving sender from quietly working through your whole texting plan. Anything over the limit is refused rather than queued — the sender is told rate_limited, and that text is simply never sent.

The limit is a burst allowance that refills, not a counter that resets on the clock. Think of it as a small bucket of tokens: the bucket starts full, each text takes one token out, and tokens trickle back in steadily so the bucket is full again about a minute later. So you can send a whole minute’s worth in one go if you need to, and after that you can keep going at a steady pace. It is not a rule like “10 per clock-minute, then nothing until the next minute starts.”

The default is 60 per minute — roughly one per second, steadily, with a burst of up to 60 available at any moment. It used to be 10, which turned out to be inside the range of ordinary traffic: several people can genuinely ask for a security code in the same minute, such as at a shift change or when a support agent calls someone back.

You can set it anywhere from 1 to 600.

You can watch the headroom instead of guessing. The Status block at the top of the gateway app shows Send allowance: 58 of 60 left this minute — how much of this limit is still available right now. Watching that line during your busiest few minutes is the honest way to pick a number; see Is it working? Look at the top of the app.
If real texts are being refused, raise this. Seeing legitimate security codes turned away with rate_limited is the one clear sign the limit is set too low. A refused security code is not a delay — it is a failed sign-in for the person waiting on it, because these codes expire in minutes and there is nothing to retry.
Do not simply set it to the maximum. The limit is what stands between a faulty or hostile sender and your phone bill. Raise it to comfortably cover your real traffic, not far beyond it.

Checking that it is working

Under the same Settings section there is a “Last SMS gateway event” line. It shows a short note about the most recent instruction Tetracom handled — enough to tell whether things are working, and no more.

This is the Tetracom half of the picture. It tells you what Tetracom did with an instruction — whether it forwarded it, and what the gateway said back. For what the gateway is doing — whether it is running, whether it can send at all, and how the last twenty texts got on — open the gateway app itself and read the top of the screen. The two answer different questions, and between them they cover the whole path.
For your privacy, this line never shows the phone number or the text that was sent — only who the instruction came from and what happened.

The sender is now told the same detail

When an instruction fails, the reply Tetracom sends back to the sender now carries the same technical detail that the Test connection button shows you — the phase the check reached, the cause, and so on. So whoever sent the instruction can see for themselves why it did not go — that the gateway app was not running, say, or that the token did not match — without needing to get hold of your phone or ask you to read anything out. That is usually the fastest way to get it fixed, because the person who noticed the problem is the person who can act on it.

The same privacy rule covers that reply. It says only whether the bearer token and the relay binding ID have been filled in — never what they are. It never contains a phone number, and it never contains the text of any message. And it still goes only to a sender who has already passed every one of the checks; a rejected sender is told nothing at all.
It looks like it is running, but every text fails. If the gateway seems alive — notification showing, app started — and yet everything comes back “Service unavailable”, open the gateway app and read the headline at the top. Check that 127.0.0.1:8769 is one of the addresses it names: that is the address Tetracom asks for, and a gateway not listening on it will turn away every request. Check too that the headline is not “Running, but it cannot send”, which looks identical from the notification shade and fails every text. Gateway 0.1.0 and earlier printed 127.0.0.1 whether or not it had actually got it, and on some handsets ended up listening on [::1] alone; versions before 0.1.4 had no status screen to check at all. If that is what you have, update the gateway app.

The quick check-in before every text

Just before it hands over any text, Tetracom asks the gateway app one very short question: are you there and ready? Only if the app answers does the request go across.

This matters because of what these texts usually are. A typical one is a security code that stops working after about ten minutes. If the gateway app is not running, whoever sent the instruction needs to know straight away so they can reach you another way — by email, for example — while the code is still good. Waiting the better part of a minute to find out would waste time nobody has.

So when the check-in fails, it fails immediately — not after a pause — and the reply says “Service unavailable”.

Nothing is sent when the check-in fails. That is a guarantee, not a likelihood, and it is the useful part: whoever sent the instruction can safely try a different route without any risk that you also receive the original text. There is nothing for you to do differently — if you see this, start the gateway app (and check the token matches), and the next instruction will go through.

You do not need to turn this on, and there is no setting for it. The check-in happens on its own, before every single text, so the answer is never out of date.

Testing the connection yourself

You do not have to wait for somebody to send a text to find out whether the gateway is ready. In Settings → SMS gateway, just under Gateway relay binding ID, there is a Test connection button. Tapping it asks the gateway app the very same question Tetracom asks automatically before every text — are you there and ready? — and shows you the answer straight away.

It is worth being precise about that: it is the same check, not a similar one. If the button tells you the gateway is ready, that is exactly what the next real instruction will find. If it tells you something is wrong, that is exactly what the next real instruction would have run into.

It is safe to press at any time, as often as you like. No text message is sent, nothing is charged to your plan, and nobody is contacted. The test stays on the phone: Tetracom’s servers are not involved, and the person who sends you instructions is not told that you pressed it.

Reading the answer

The first line is written in plain language, and it tells you what to do. These are the answers you may see.

The detail lines underneath

Below that sentence you will see a short technical list — the phase the check reached, the cause, the host, the port, and so on. You are not expected to make sense of it, and you do not need to. It is there so you can read it out over the phone, or send a screenshot of it, to whoever is helping you: from those few lines they can tell exactly where the check stopped, without guessing.

The detail is safe to share. It deliberately shows only whether the bearer token and the relay binding ID have been filled in — never what they are. There is no way to read a token off that screen, or out of a photograph of it. It also never shows a phone number, and never shows the text of any message.

If you do not have the gateway app

Most phones do not have the companion SMS gateway app, and that is completely normal — it is a separate app for people who deliberately set this up. If an instruction arrives on a phone without it, no text is ever sent, and nothing is shown to you.

What the sender hears is a short “not supported” answer, meaning: this phone cannot send text messages this way — do not keep trying. Otherwise they would simply get silence, wait for a reply that was never coming, and have no way to tell a wrong phone from a slow one.

This matters most for security codes. A code that expires in ten minutes is no use to anyone if the person sending it spends most of that time waiting. Told straight away, they can reach you another way — by email, for example — while the code still works.

Only an approved contact ever gets this reply. The sender still has to pass every one of the checks first: on your Allowed SMS senders list, an approved and unblocked contact, and a valid digital signature. A stranger, or anyone who fails any check, gets silence, exactly as before. Nobody can use this to find out whether you use Tetracom, or what you have set up.
“Not supported” is not the same as “Service unavailable”. “Not supported” means the gateway app is not on the phone at all, so there is no point trying again. “Service unavailable” means it is there but did not answer just now — starting it will usually fix that, and the next instruction will go through.

You do not need to do anything about this, and there is no setting for it. If you never wanted this feature, you can safely ignore it: without the gateway app, nothing is ever sent from your phone.

Rejected SMS commands

In the same Settings section, whenever it applies, you will also see a line like “Rejected SMS commands: 3 — last: …”. It counts the instructions Tetracom received and refused since you last started the app, with a short note about the most recent one.

An instruction is counted here for one of two reasons: it came from a sender that did not pass the checks in The three things that must all be true, or the instruction itself could not be used — it was incomplete, malformed, or missing something Tetracom needs.

Seeing a small number here is normal, and nothing is wrong. A count that keeps climbing usually means one of three things: your Allowed SMS senders list is empty or does not contain the userid that is actually sending, the sender is not the account you think it is, or that sender was never added and approved as one of your contacts. All three are worth checking if texts you expected are not arriving.

The sender is told nothing. A rejected instruction gets no reply at all — that is deliberate, so someone who should not be doing this cannot work out which check they failed and fix it. The consequence is that this line in your Settings is the only place a rejection is ever visible. Nothing is added to your History, nothing notifies you, and nothing appears on screen.

Why most failures are silent

It is worth understanding the difference, because it changes what you should expect to see when something is wrong.

The short version. Capability is answerable; policy is not. A trusted sender may be told what this phone is able to do. Nobody is ever told how you have chosen to set it up — including whether the switch is on.

Recipient opt-outs

The gateway app keeps a list of numbers it must never text. Enter the number in international form — for example +15551234567 — and choose Add opt-out or Remove opt-out. Once a number is on the list, requests to text it are refused, and no retry overrides that.

The audit list shows only a short keyed tag, what was done, and when. It never displays or stores the number itself or any message text.

Permission is your responsibility. Whoever operates the sending account must have the recipient’s consent for the kind of texts being sent, and must honour opt-outs. Check that what you are doing is allowed where you are.

Turning it off

Open Settings → SMS gateway and switch “Forward SMS commands” off. That takes effect immediately: from that moment nothing is forwarded, no matter who sends it or how it is signed. Your host, port, token, binding ID and allowed-senders list stay saved, so you can switch it back on later without typing them again.

Removing every row from Allowed SMS senders has the same practical effect, and is the right tool when you want to stop one sender rather than all of them: remove just their row and leave the switch alone.

Switching it off is silent: senders are simply ignored, and nobody is told you turned it off. The single exception is a phone that does not have the gateway app at all — there, an approved sender is still told “not supported”, because that is about the phone rather than about your setting.

To stop the gateway app itself as well, open it and tap Stop. The headline at the top changes to “Not running”, the notification disappears, and the app will not come back after a reboot until you start it again. If you want a specific sender to stop trying entirely, block them like any other contact, or remove them from your contacts.

Privacy & control

Text messages cost money and carry your name. Every text sent this way comes from your number and counts against your plan. Before you switch this on, be sure you know who is on your allowed-senders list and what they will be sending — and check that using it this way is allowed where you are.

Still stuck?

If something here does not match what you see, or you hit a problem this page does not cover, email help@tetracom.me. Please include your phone make and model, your Android version, and the Tetracom app version so we can help faster. Do not include your gateway token.