Sending policy

Your workspace sends over session-based WhatsApp numbers — the same connection the WhatsApp app uses, not the official Business (Cloud) API. That is what lets you send from an ordinary number, but it also means WhatsApp's spam detection is watching: a sudden burst of messages from one number is the clearest signal of automation, and it can get the number banned.

The sending policy is how MessageVia keeps each number sending at a human pace. You configure it under Settings → Sending policy (changing it needs the Manage sending policy permission; anyone with settings access can view it).

What it governs

Every automated send is released within the policy:

• Campaigns
• API sends (POST /messages)
• Scheduled messages
• Automations

One-to-one replies you send from the Inbox are never paced. A reply to a live conversation is expected within seconds, so it always leaves immediately.

The controls, per number

Control	What it does
Messages per hour / per day	The most a single number may send in a rolling hour and in a calendar day. 0 means no limit. When a cap is reached, the remaining messages are carried into the next hour or day rather than forced out.
Minimum / maximum gap	A small, randomised pause between two sends on the same number. A fixed "one every 5 seconds" is as recognisable to a provider as no gap at all, so the gap varies within the range you set.
Most queued ahead	How far ahead a large campaign may line this number up. On reaching it, the campaign pauses claiming new recipients and resumes as the queue drains. It bounds how many sends are waiting at once — it does not limit how many are sent in total.

Workspace default and per-number overrides

The values you set at the top are the workspace default — every number follows them. Below that, any individual number can take its own override: give a new, fragile, or high-value number a tighter policy, or a well-warmed number a looser one. A number with no override always follows the workspace default, and removing an override hands it straight back.

Number health — automatic slow-down

The sending policy sets the pace you want; number health adjusts it to the pace a number can currently sustain. Each number is scored continuously from signals MessageVia already has — how many of its recent sends failed or came back unconfirmed, how much of what it sent was delivered, and how often its connection dropped — and lands in one of five states:

State	What it means	Effect on sending
Healthy	Recent activity looks normal.	Full configured rate.
Watch	An early warning sign.	A gentle slow-down.
Risky	Several signs, or one strong one.	The rate is cut noticeably.
Critical	Corroborated bad signals.	Cut hard — a fraction of the rate.
Logged out	The number was unlinked from the phone.	Paced sending is paused until it reconnects.

The slow-down is automatic and self-correcting: as the signals settle, a number eases back toward its full rate on its own (recovery is deliberately gradual so the pace doesn't flip back and forth). Delivery is treated as a soft, supporting signal only — a number is never cut to Critical on low delivery alone, because delivery receipts are naturally patchy on session numbers. A paused number is never dropped: its sends wait and are released once it comes back.

You will see each number's current state on the Settings → Sending policy screen, and every threshold, the slow-down for each state, and the fallback limits for an unlimited number are all editable there (same Manage sending policy permission). Turn the whole behaviour off if you would rather every number always run at its configured rate.

Tuning number health, setting by setting

The defaults are already conservative — you do not need to touch any of this. But if you want to, here is what each setting does, and which way to move it. One rule runs through all of them: want to play it safer? make the thresholds smaller and the slow-down bigger. Want more speed? do the opposite.

Measurement window — what the score is based on.

• Window (hours) — how far back a number's signals are read. Longer makes the score calmer (one bad spell fades slowly, and recovery is slower too); shorter makes it react faster in both directions.
• Minimum sends to judge — below this many sends in the window there isn't enough to judge, so the number stays Healthy. Higher means low-volume numbers are almost never scored; lower lets small numbers be judged, at the cost of the odd false alarm.
• Delivery settle (minutes) — a just-sent message hasn't had time to get a delivery receipt, so delivery ignores sends newer than this. Raise it if your receipts arrive slowly.

Signal thresholds — the four things that can flag a number, each with a Watch / Risky / Critical step. For every one of them, smaller numbers = stricter (flags sooner), larger numbers = more lenient.

• Failed sends (%) — share of attempted sends that failed.
• Uncertain sends (%) — share the gateway couldn't confirm either way.
• Delivery floor (%) — this one is a floor, so low is bad: below the given delivered share the number is flagged. Higher floor = stricter. (Delivery is advisory — on its own it never pushes a number all the way to Critical.)
• Connection drops — a count, not a percent: how many disconnect/degrade events in the window reach each step.

How much to slow down — the share of its configured rate a number keeps in each state (e.g. at 40/hour, Watch 80% = 32/hour, Risky 50% = 20/hour, Critical 10% = 4/hour). Lower percentages throttle a struggling number harder (safer, but its messages leave later); higher keeps it faster (riskier). Leave Healthy at 100% so a well number runs at full rate.

Fallback caps for unlimited numbers — a number with no rate limit set can't be "slowed by a percentage" (a share of unlimited is still unlimited), so when such a number turns unhealthy it falls back to these real per-hour and per-day caps. Raise them for more speed, lower them to be safer.

Recovery

• Clean checks before easing up — a number doesn't jump back to full speed the instant it looks better; it must look clean this many checks in a row first (each check is one recompute, a few minutes apart). Higher is safer and recovers more slowly; lower recovers quickly but can let the rate flip back and forth.
• Pause backoff (seconds) — when a number is logged out its sends wait this long before trying again, repeating until it reconnects. Its messages are never dropped — they simply wait.

What you will see

A send is accepted as queued and then released when its turn comes up, so on a busy number or a large batch it can leave a little later than the moment it was queued — see Sending messages, "'Accepted' is not 'delivered'". A big campaign therefore stays in running for a while: it is pacing itself on purpose.

It reduces risk, it does not remove it

Session-based bulk sending can never be perfectly safe. The policy lowers the chance of a ban and degrades gracefully when a number is under pressure — it is not a guarantee. The strongest protection is still the ordinary one: send to people who asked to hear from you, keep the content relevant, and don't push a number harder than it can sustain.