The limit that stops your traffic is not your application’s quota — it is the rate your provider applies per sender number. One number, one limit, and a batch that ignores it fails partway through.
A platform-wide “messages per second” setting tells you nothing about whether a specific number can absorb a batch. Because the provider’s limit is attached to the number, pacing is configured and applied at that same granularity — add a number, and you genuinely add throughput.
When a batch exceeds what a number can absorb, the platform paces it out rather than sending into the wall. That turns a partial failure into a longer send, which is a trade you can plan for — and the pace is visible in the logs while it runs.
Pacing at the per-number limit ships on the SMS channel, where the provider applies its rate to the sender number itself. Email and WhatsApp carry their own limits, handled by those channels rather than through this pipeline.
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 →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 →You keep the provider relationship you already have, connect it once, and the platform treats that account as a send path it can route through, pace against and read receipts from.
Open →One provider account is a single point of failure that you cannot see failing until customers tell you. Routing across several accounts turns that into a failover you configure once.
Open →Two providers describe the same outcome with two different words, and neither word means what the reader assumes. Normalising receipts into one status is what makes a receipt usable in code rather than as a screenshot.
Open →Suppression is the part of messaging that is easy to get almost right and expensive to get wrong: honour it too broadly and confirmations stop arriving; honour it too narrowly and you are ignoring a customer who asked you to stop. Getting it right is the whole feature.
Open →The sender is the first thing a recipient sees and the thing that decides whether a message is trusted. Because that identity sits on your own account, it stays with you however you choose to send.
Open →Product messaging is emitted by code, not typed by a person. The API exists so the service that knows an event happened is the service that sends the message about it.
Open →Polling for status works until the volume makes it wasteful. A callback lets the system that cares about an event be told about it, which also means the record lands in your own database at the same time.
Open →The first question after any messaging incident is “what did we actually send?”. That answer should come from a log with a filter on it, not from a reconstruction.
Open →Isolation is the feature that nobody asks about until it is missing. Holding connections, keys and records per tenant means a shared platform does not become a shared inbox.
Open →Not every message comes from an API. Testing a new sender, resending after a fix, or simply looking up what a customer received — those are console jobs, and they should not require writing code.
Open →