Sending six thousand WhatsApp messages is easy. Sending six thousand WhatsApp messages without damaging the number you will need next month is the actual problem, and it is mostly a queue design problem rather than an API one.
What you are protecting
WhatsApp assigns each business number a quality rating, derived largely from how recipients react — blocks and reports push it down. Fall far enough and the number's messaging limit drops, which means the next campaign reaches fewer people. Keep falling and the number is restricted.
So the constraint is not "how fast can the API accept messages." It is "how fast can we send without the responses degrading the asset we are sending from." Those are different, and only the first is documented.
Four rules we build into every broadcast
One. Spread the send, do not burst it. A campaign that lands in six thousand phones inside two minutes produces a concentrated spike of blocks from the people who did not want it, which is the worst possible signal shape. We spread over hours rather than minutes. The recipient who was going to reply replies either way; the one who was going to block does so more diffusely.
Two. Respect quiet hours in the recipient's timezone. We pause sends between 21:00 and 09:00 by default. A marketing message at 11pm earns blocks that the same message at 11am does not, and the cost lands on every future campaign, not just this one. Queued messages resume the next morning.
Three. Segment before you throttle. The most effective rate control is sending to fewer, better-chosen people. An audience filtered to recent, relevant contacts outperforms a full-list blast on every metric that matters, including the quality rating. A throttle applied to a bad list just spreads the damage over a longer period.
Four. Watch the rating during the send, not after. We poll quality and delivery failure rates as the campaign runs and pause automatically on a sharp change. A campaign that has to be stopped at 20% delivered is a bad morning; one discovered the next day is a bad quarter.
The queue
The design that survives contact with reality:
Persist every intended send before sending any of them. The queue is a table, not an in-memory list. A deploy, a crash or a rate-limit pause in the middle of a campaign must not lose the remainder or, worse, restart it.
Make each send idempotent. A key per recipient per campaign, checked before dispatch. Retries are inevitable; duplicates to a customer are not acceptable.
Separate transactional from marketing. A payment link or a booking confirmation must never sit behind four thousand promotional messages. Different queues, different priority, and transactional always wins.
Treat the failure taxonomy seriously. A template rejection, an invalid number, a rate limit and a transient network error need different handling — respectively: stop the campaign, mark and skip, back off and resume, retry. Collapsing them into "failed" means retrying things that will never succeed and abandoning things that would have.
What the operator sees
One number that matters — delivered against total — and a plain statement of what the system is doing: throttled, sends pause 21:00–09:00 IST. When a campaign is deliberately slow, the person who launched it needs to know it is working as intended rather than stuck, or they will launch it again from a second number and solve nothing.
That is most of what we learned building WhatsApp Suite: the API is the easy part, the queue is the real product, and the thing you are actually managing is a reputation that takes months to build and one bad Tuesday to lose.