SMS segments and what you actually pay for
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.
Read the guide →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.
The model in one paragraph
You keep your account with Twilio, Vonage, Infobip, MessageBird, Plivo or AWS. You give the platform credentials with permission to send. When a message goes out, the platform calls that provider using your credentials, from your account, against your quota, and the provider bills you at the rate you negotiated with them.
The platform never holds a provider account, never resells message volume, and never appears on the invoice you get from your provider. What you pay the platform is a flat subscription for the orchestration layer and nothing else.
What this actually buys you
- Your sender numbers stay yours. If you stop using the platform, the numbers, registrations and history with the provider do not move.
- Your negotiated rate stays your negotiated rate. There is no markup applied on top of it, because there is no message margin to apply it to.
- Your relationship with the provider stays direct. When they change a limit, run a maintenance window or need to verify your account, you deal with them as their customer, not through us.
What it does not buy you
- It does not transfer your provider account, approvals or credit line. Those remain yours to keep in good standing.
- It does not make your quota larger. Your provider grants you a rate; the platform can only queue to it, never raise it.
- It does not put us between you and your provider in a dispute. We cannot escalate on your behalf, because we are not their customer.
Why a flat subscription is the honest shape
If message volume is billed by your provider and not by us, then a per-message price on our side would be a margin on somebody else’s bill, with no corresponding cost of ours. A flat subscription keyed to the things we actually operate — how many connections you run, how fast you may submit, how long logs are kept — is the shape that matches where the work is.
Keep reading
Opt-out handling
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 →Reading a delivery receipt
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 →Pacing, quotas and why we queue
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 →Routing and failover
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 →Who decides whether a message is marketing
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 →A timeout is not a failure
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 →Two endpoints that look alike and are not
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 →Getting a number back
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 →What happens when your callback is down
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 →Which rate limit you just hit
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 →Who the recipient actually sees
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 →What the platform does not keep
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 →