Three Codes That Mean Accepted
A text message has no single moment of success. It is accepted, then queued, then handed to a network, then delivered, then perhaps read — and an API that answers immediately can only tell you about the first of those. Knowing which one you are being told about is the whole thing.
Ask most systems whether an SMS was sent and you get a yes. Ask what the yes means and things get vague, because the send is a chain of handoffs across parties nobody in the conversation controls — an aggregator, a mobile operator, a handset that may be switched off in a drawer. The API answer arrives in a fraction of a second, long before any of that. It is a receipt for the first handoff.
Three codes, all meaning accepted
This provider answers with a per-recipient status code, and three distinct values all mean the message is on its way. The connector treats all three as success and everything else as failure.
| Status | What it means | Why it counts as accepted |
|---|---|---|
| Processed | The request was understood and taken | It is in the system |
| Sent | Handed to the mobile operator | Further along the same chain |
| Queued | Held, waiting to go out | Delayed, not refused |
The distinctions between them are about how far along a message is at the instant the reply is written, and none of them is a rejection. A connector that accepted only the middle one would report failures for messages that arrive perfectly, and would do it most often under load — which is when a queue exists at all.
Treating queued as a failure means reporting the most errors exactly when the system is busiest, which is precisely backwards.
Everything outside those three is a real refusal — an invalid number, no credit, a sender identity not permitted — and those come back with a summary line the provider writes, which is passed through as given.
What the answer does not tell you
Worth saying plainly, because it is the same distinction the chat connectors make between accepted and delivered.
None of the three codes means the message reached a handset. They mean the aggregator has it. Between there and a phone sit the mobile operator, coverage, whether the device is on, and in some markets a filtering layer with opinions about commercial traffic.
The honest reading of a successful send is: it was accepted for delivery, by a party that does this for a living, and nothing about it was refused. That is a genuinely useful thing to know and it is not a delivery confirmation, and a product that blurred the two would be inventing a number.
One call, a list of numbers
This provider takes several recipients in a single request — the numbers are joined into one list and sent together. That is a real efficiency: one message to twelve people is one call rather than twelve.
It also produces a nuance worth stating rather than glossing, because these posts are written off the code. The response carries a status per recipient, and the connector reads the first one to decide the overall result.
For the case this connector actually serves — an operational alert to a small, stable list of your own staff numbers — the recipients share every property that determines acceptance: the same account, the same credit, the same sender identity, the same country. They succeed together or fail together, and the first is representative.
Where that reasoning would not hold is a large list of unverified numbers of mixed quality, which is a bulk messaging job rather than an operational alert, and is not what this connector is for.
The refusals that happen before the network
Two checks sit ahead of the provider, and both exist because the alternative is a confusing error from somebody else's API.
-
The recipient list is cleaned first
Numbers arrive as text — separated by commas or line breaks, with stray spaces. They are split, trimmed, and empties dropped, so a trailing comma does not become an attempt to message nothing.
-
An empty list is refused here
Rather than sending a request with no destinations and receiving a puzzled provider error, the connector says the list is empty. The reason names the actual problem.
-
A missing credential is refused before the call
An incomplete configuration returns a reason instead of a network round trip, so a half-set-up connector reads as unconfigured.
-
Everything else is the provider's answer
Past those, the reason reported is theirs — the summary line they write, passed through, because it names the condition better than any paraphrase.
Why text messages are still worth wiring up
It is easy to treat SMS as the legacy option in a list that includes six chat platforms and mobile push. In a lot of the markets this system serves, that is exactly backwards.
A text message needs no application installed, no account, no data connection and no smartphone. It reaches a store supervisor on a feature phone in a warehouse with no signal for anything else. It arrives on the device somebody actually carries rather than the one with the work applications on it.
The trade is that it costs money per message and has no formatting, no link preview and no button. That combination makes it the right channel for a specific class of event — the ones where somebody needs to act and the cost of them not knowing is larger than the cost of the message — and the wrong channel for anything routine.
Which is why the per-type routing controls matter more here than anywhere else. Text messages are the one channel where over-sending has an invoice attached, and that is a useful discipline rather than a drawback.
What is in place, layer by layer
The Africa's Talking connector as it stands
Your own account and credit
Your username, your key, your sender identity. Messages are billed to your account and the relationship with the provider is yours.
Three accepted statuses
Processed, sent and queued are all treated as success, because none of them is a refusal and the third is most common under load.
One request for the whole list
Recipients are sent together rather than one at a time, which is what this provider's interface is designed for.
Recipient lists cleaned before use
Split on commas and line breaks, trimmed, empties dropped — so a trailing comma is not an attempt to message nobody.
An empty list refused with a reason
Named here rather than sent to the provider and returned as a confusing error about a malformed request.
The provider's summary passed through
A refusal reports the sentence the provider writes, which names the cause — credit, a number, a sender identity — better than any paraphrase.
Credentials encrypted at rest
Stored on the row for one workspace and never written into a log line or an error message.
Failures logged, never thrown outward
A send that fails records its reason and returns it. The operation that raised the alert is not affected.
A successful send means the message was accepted for delivery, not that it reached a handset. No immediate API answer can mean the second, and treating it as though it did would be inventing a number.
Three positions held on purpose
- Accepted is reported as accepted. A product that presented an acceptance receipt as a delivery confirmation would be making a claim its provider never made, on the channel where people are most likely to rely on it.
- Queued counts as success. Reading a delay as a failure produces the most errors exactly when the system is busiest, and trains people to ignore the errors that matter.
- This is a channel for alerts to your own people, not for bulk messaging. The design assumes a small stable list of known numbers, and it is worth saying so rather than letting somebody discover the assumption with a customer list.
Five questions about an SMS integration
What does a successful send mean?
A good answer sounds like
Accepted, and they say so.
What ours actually is
The aggregator took it. Not that a handset received it — no immediate answer can mean that.
Is a queued message a failure?
A good answer sounds like
No.
What ours actually is
Queued, processed and sent are all treated as accepted, because none is a refusal.
Whose account pays for it?
A good answer sounds like
Yours.
What ours actually is
Your credentials, your credit, your sender identity. The relationship with the provider is yours.
What happens with a malformed recipient list?
A good answer sounds like
Cleaned, or refused clearly.
What ours actually is
Split and trimmed before use; an empty list is refused with a reason naming it.
What do I see on a refusal?
A good answer sounds like
The provider's words.
What ours actually is
Their summary line, passed through, which names credit, a number or a sender identity.
Our take
The most common defect in messaging integrations is not a bug, it is a word. Somebody writes "sent" on a screen where the API said "accepted", and everyone downstream treats a queue receipt as proof a person was told. That gap is where the awkward conversations live — the supervisor who never got the alert, the approval that sat for a day, the honest disagreement about whether the system worked. The fix costs nothing except a willingness to use a slightly less satisfying word, and it is worth it the first time somebody asks the question in a room.
The channel that reaches people without an app
No installation, no account, no data connection. For the alerts where somebody genuinely needs to know, it is still the one that arrives.
Talk through SMS alertsFrequently asked questions
Does a successful send mean the message was delivered?
It means the aggregator accepted it for delivery. Between there and a handset sit the mobile operator, coverage and whether the device is switched on. No immediate API answer can report the last step, and a product that presented one as though it could would be inventing it.
Who pays for the messages?
You do, on your own provider account, with your own credit. The connector uses your credentials, so pricing, credit and sender identity are your relationship with the provider rather than something mediated by us.
What happens if we run out of credit?
The provider refuses the message and says so, and that sentence is passed through as the reason. It is one of the more useful cases for surfacing the provider's own wording, because the fix is unambiguous.
Should we route everything to SMS?
Almost certainly not. It is the one channel with a cost per message and no formatting, which makes it right for events where somebody must act and wrong for anything routine. Per-type routing controls exist precisely so this channel can be narrow while the chat ones are broad.
Can we send to customers rather than staff?
The connector is built for operational alerts to a configured list of your own numbers. Sending to a large list of customer numbers is bulk messaging, which has different regulatory, consent and deliverability considerations in every market — and is not what this is.
