Bring your own account
The platform has no provider account of its own. That one design decision changes who owns the numbers, who holds the quota, and who appears on the invoice.
Read the guide →SMS is billed per segment, not per message. Whether your text fits in one segment depends on the character set it needs — and on the encoding you set on the connection.
The GSM-7 alphabet covers the letters, digits and punctuation needed for most Western European languages. Anything outside it — Chinese, Cyrillic, Arabic, emoji, curly quotes — forces the message into UCS-2, which has far less room per segment.
| Encoding | Single segment | Per segment in a long message |
|---|---|---|
| GSM-7 | 160 characters | 153 characters |
| UCS-2 | 70 characters | 67 characters |
| Byte-counted gateway (GBK / UTF-8) | 140 bytes | 134 bytes |
The per-segment figure is lower than the single figure because a long message is split across several parts, and each part carries a small header so the handset can reassemble them in order. That header is charged as part of the segment.
A handful of characters — the euro sign, curly braces, backslash, tilde, caret — live in the GSM-7 extended table. They are representable in GSM-7, but each one occupies two septets instead of one, because it is sent as an escape sequence. A single one of them can be the character that pushes a 160-character message into a second segment.
Segments are computed before the message is handed to the provider, and the count is kept on the record. That is the number your provider will bill you for, so you can reconcile the two without guessing.
Each connection carries an encoding setting. On the default, the platform inspects the text and picks GSM-7 if every character fits, otherwise UCS-2 — which is what the major providers do on their own side. You can also pin it: forcing GSM-7 makes a message containing a non-GSM-7 character fail outright rather than silently being transmitted as question marks or silently billed at double the segments.
The platform has no provider account of its own. That one design decision changes who owns the numbers, who holds the quota, and who appears on the invoice.
Read the guide →Opt-out is two halves: the suppression record, and the check that runs before a marketing message is handed to the provider. Both run through one shared normalisation, which is the part that usually breaks.
Read the guide →A receipt is a sequence of states, not a verdict. Treating an intermediate one as final is the most common way a sending dashboard ends up lying to you.
Read the guide →Every connection carries a send rate. The platform queues to that rate instead of firing as fast as a provider will accept, because the fastest way to get throttled is to send at the speed that causes it.
Read the guide →Routes are ordered by priority and weighted within a connection. The point of the arrangement is that a provider rejecting sends degrades into slower sending, not into silence.
Read the guide →The platform asks you to declare what kind of message you are sending instead of inferring it from the text. That one field decides whether the opt-out gate applies — and the honesty of the declaration is yours.
Read the guide →Sending is accepted asynchronously and there is no de-duplication key. Retrying a request you are unsure about sends a second message and bills for it.
Read the guide →Delivery receipts and inbound replies are different endpoints, configured in different places in your provider’s console. Configure only the receipt URL and opt-out handling stops — silently, with no error anywhere.
Read the guide →A recipient who opted out can opt back in. The platform deactivates the suppression record rather than deleting it, so the consent trail survives.
Read the guide →Terminal outcomes are pushed to a URL you control, with a small bounded retry. Your handler has to tolerate a repeat, and it should not expect a call for every message.
Read the guide →There are two throttles in front of a send: the one your plan sets, and a much higher one at the network edge. Both answer with the same status code, so the message text is what tells them apart.
Read the guide →If you do not name a sender, the platform picks one from the connection that carries the message. Naming one explicitly takes priority everywhere.
Read the guide →Message content is not archived. What is kept is metadata — and among that metadata two fields are load-bearing, because without them a bill could not be reconciled.
Read the guide →