Sending slower on purpose, to send more overall

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.

5 min read · updated 2026-10-12

What the setting means

A connection has a send rate, expressed as messages per second. When a batch is running, the platform releases messages to the provider at that rate rather than submitting everything at once.

The default per provider is deliberately conservative. It is a starting point, not a statement about your account — your real ceiling is set by your provider, based on your account level, the number type and the destination country.

Where the limit actually lives

This is the part worth getting right: providers generally rate-limit per sending number, not per account or per connection. If a connection has several sender numbers bound to it, the effective capacity is roughly the per-number rate multiplied by the number of numbers.

So the value on a connection has to be set with the number count in mind. Leaving it at the default when you have bound five numbers is not cautious, it is slow for no reason.

Throttling is not a failure

When a provider pushes back because a request arrived too fast, that is a pacing signal, not a broken send. The platform backs off and retries the message rather than marking it failed and moving on. Marking a throttled message as failed would produce a retry storm against an already-congested provider, which is exactly the situation that escalated the throttling in the first place.

Two rates, and the lower one wins

There are two separate rates in play. The subscription tier sets a submit rate — how fast you may hand messages to the platform. The connection sets a send rate — how fast the platform calls your provider.

Whichever is lower governs. Raising the plan submit rate does not raise your provider quota, and raising the connection rate does not bypass the plan.

What is on your side

  • Knowing your actual provider quota, including whether it is per number or per account.
  • Any destination-specific registration your provider requires before it will carry traffic to that country.
  • Choosing how many sender numbers to bind to a connection, which is what actually sets the ceiling.

Keep reading

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 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 →

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 →

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 →