WhatsApp Bulk Messaging: How to Send at Scale Without a Ban

WhatsApp bulk messaging at scale runs on one path: the official WhatsApp Business API, opted-in recipients, and Meta-approved templates pushed through a rate-aware queue. This guide from 1MSG, an official WhatsApp Business API platform, gives backend engineers and growth leads the sendTemplate call, delivery tracking, throttling, and warm-up math for a 2,500-contact list.

A new business portfolio starts at 250 unique recipients per rolling 24-hour period (Meta, 2026), so a bulk sender needs a halt switch as much as a loop. This guide builds that pipeline: approved template, throttled queue, delivery tracking, and warm-up math.

What is the only scalable way to send bulk WhatsApp messages?

Send bulk messages on WhatsApp at scale through the official WhatsApp Business API (Cloud API): explicit opt-in, a Meta-approved message template, and a rate-aware send queue. The WhatsApp Business App stops at 256 broadcast contacts; production volume belongs on official WABA, not a reverse-engineered WhatsApp Web session.

"Template messages are the only type of message that can be sent to WhatsApp users outside of a customer service window." — Meta template guidelines

Most teams' first mistake is treating bulk as a list-upload problem: blast a bought list on day one, then read the failures as a mysterious ban. Opt-in quality and template approval decide whether the send loop stays open at volume.

Business App, dashboard campaigns, or API: which send path scales?

Three send paths exist: the free WhatsApp Business App (broadcast lists capped at 256, phone-bound), dashboard campaigns on a Business API platform (CSV, no code), and direct API integration (programmatic sendTemplate calls). Past the App's 256-per-list cap, only the API-backed paths keep working.

Marketers take the dashboard for CSV upload and scheduling; engineering teams integrate the API, which this guide implements on the same tiers and template rules.

Compliance and setup before you scale: template approval and session rules

Two gates stand before any bulk send: every business-initiated message outside the 24-hour customer service window must use a Meta-approved template (marketing, utility, or authentication), and every recipient must have opted in. Clear both once and the rest of this guide is engineering.

"You may only initiate conversations using an approved Message Template." — WhatsApp Business Messaging Policy

Template approval is procedural: submit the body with numbered {{1}}, {{2}} variables and a category. An unverified portfolio holds up to 250 message templates per WABA; a verified portfolio with an approved display name holds up to 6,000. Billing bites twice: since July 1, 2025, Meta bills per delivered template message by category. Promotional-sounding utility templates can be reclassified to marketing rates while the template stays APPROVED — automatic category updates are the default, not an opt-in flag.

A customer reply opens a 24-hour session window where free-form messages need no approval; outside it, templates are the single door, so cold-list campaigns start with a template send.

Template approval and the 24-hour customer service window gate every bulk WhatsApp send.

How do you prepare a recipient list for a bulk send?

Recipient list QA prevents most first-blast failures: normalize numbers to international format without plus signs or spaces, deduplicate across sources, attach opt-in proof (source, timestamp) to each contact, and map template variables so no row ships blank; a blank {{1}} fails that row's send.

Meta's Cloud API sandbox only lets you message 5 verified recipient numbers — a wall on the first test broadcast. Production channels drop per-recipient verification, so QA moves to your list; a variable count mismatch returns a 422 for that row while the rest proceeds.

Send your first bulk batch on 1MSG: sendTemplate with params, not components

1MSG's sendTemplate call takes five keys: phone, template (the approved template name), namespace, language as an object with policy and code, and params for body variables. Meta's Graph API components array does not exist on this wire; sending it is the most common first-integration failure.

Copy-pasting a Graph API example with its components payload is the rejected first move; the call dies on schema validation. 1MSG channels run official WABA with full Cloud API compatibility: the template Meta approved is exactly what you send.

A win-back template reading Hello, {{1}}! You previously showed interest in "{{2}}". {{3}} carries three body variables (name, interest, re-engagement hook). The URL button lives in the Meta template, so params carries body values only. The official @1msg/sdk wraps the wire in Node.js (run once per recipient; Python, PHP, Go, and curl post the same JSON):

import { createClient } from '@1msg/sdk';

const client = createClient({
  baseUrl: 'https://api.1msg.io',
  instanceId: process.env.MSG_INSTANCE_ID,
  token: process.env.MSG_API_TOKEN,
});

// the wire wants `params`; Meta's `components` key fails schema validation
const res = await client.templates.sendTemplate(client.config.token, {
  phone: '14155550123',
  template: 'winback_offer_v1',
  namespace: 'your_template_namespace', // 422 without it
  language: { policy: 'deterministic', code: 'en' }, // an object, not "en"
  params: [{ type: 'body', parameters: [
    { type: 'text', text: 'Anna' },                 // {{1}} name
    { type: 'text', text: 'Pro plan for teams' },   // {{2}} interest
    { type: 'text', text: '20% off until Friday' }, // {{3}} hook
  ]}],
});
// res.sent === true means accepted, not delivered; persist res.id (the wamid)

How do you track delivery and halt before the daily limit is reached?

Every accepted send returns sent: true plus an id (the wamid); delivery lands later through webhook hooks[] events or hookInfo polling. A bulk queue runs that wamid and webhook delivery status loop: aggregate delivered/failed events, count unique recipients over a rolling 24 hours, and pause at a buffer below whatsapp_business_manager_messaging_limit.

Call the pattern the tier-aware send loop: accept, track, count, halt. sent: true is an acceptance receipt, not proof of delivery, so reconcile each wamid against webhook delivery statuses; 1MSG's delivery log and webhook verification turn that reconciliation into configuration.

Meta holds a new business portfolio to 250 unique recipients per rolling 24 hours, scaling to 2,000, 10,000, 100,000, and unlimited. Count unique recipients in your own send log; pause at a buffer, say 240 of 250 — do not wait for a hard failure to learn the cap was hit.

A tier-aware send loop persists wamids, reconciles webhook statuses, counts unique recipients, and pauses below the portfolio cap.

How fast can you send? Throughput, pair rate, and template pacing

Cloud API throughput defaults to 80 messages per second per business phone number; a pair-rate limit caps sends to the same user at 1 message every 6 seconds, returning error 131056 when exceeded. New templates face pacing on top: a bulk queue needs three throttles, one per limit.

Practical queue design: a worker pool under the throughput ceiling, a per-recipient key enforcing the 6-second pair spacing, and a scheduler that spreads a fresh template's first sends while Meta accumulates engagement data (all three limits are in Meta's docs). At 80 messages per second, pushing 1,000 WhatsApp messages at once takes about 13 seconds of API time; the daily recipient tier decides the real calendar.

Warm-up schedule: reaching 2,500 recipients from a tier-250 start

A 2,500-contact launch list does not fit a fresh portfolio's 250-recipient daily tier, so the send plan is arithmetic: 250 unique recipients per rolling 24 hours until the portfolio moves up, then the remainder. Treat the campaign as a multi-day job. Moving from 250 to 2,000 is a Meta scaling path (verification or quality and volume), not a date on a calendar.

The tier-aware send loop makes the ramp self-enforcing: the queue pauses at the buffer; unsent rows lead the next batch.

Which errors hit at volume, and how do you handle 131049 and 131056?

Three failures dominate bulk sends: error 131049 (per-user marketing cap; the recipient received too many promos recently), error 131056 (pair rate; same user messaged twice inside 6 seconds), and undeliverable US marketing (Meta paused marketing templates to +1 numbers on April 1, 2025).

Meta explains the first: "WhatsApp may limit the number of marketing template messages a WhatsApp user receives from any business in a given period of time", weighing read rate and inbox volume. Log 131049 per recipient and suppress that contact from marketing sends for the cycle; a user reply opens a service window where the cap does not apply. For 131056, requeue with pair-rate spacing instead of retrying instantly. US +1 marketing attempts surface 131049 or a provider's wrapper code; geo-segment the list first. Persistent failures are worth a support ticket with the failing wamids.

When should bulk marketing use the Marketing Messages API?

If Cloud API marketing sends keep failing with 131049 on cold segments, route that promotional traffic through Meta's Marketing Messages API. 1MSG runs it on the same official WABA channel as sendTemplate — same number, same templates — so the send loop does not change product. Utility and authentication stay on Cloud API.

Quality-based delivery on that path can lift high-engagement marketing deliveries versus Cloud API (Meta platform documentation). Use it when 131049 is the bottleneck, not as the default for every bulk job.

What does 1MSG handle so your team only builds campaign logic?

The whole guide reduces to one pipeline: approved template in, throttled sendTemplate loop out, webhook statuses back. 1MSG operates that pipeline on official WABA channels with full Cloud API compatibility (140Mn+ messages processed, 99.8% API failure-free), so your team builds campaign logic and rents the wire, tiers, and delivery log.

Bulk WhatsApp messaging that scales is official WABA plus an approved template plus a throttled, tracked send loop. Connect a channel, submit the template, point the queue at sendTemplate, register the webhook. Pricing stays flat at $39 per channel per month plus Meta usage, and a free test number lets the loop run end-to-end before any production number.

Next step: Run a 10-recipient batch on a free 1MSG test channel: same sendTemplate wire, live webhooks, production code from send one.

Browse use-case templates · Get a free test number

Sources

• Messaging limits — Meta Developer Documentation, 2026

• About the WhatsApp Business Platform (throughput and pair-rate limits) — Meta, 2026

• Per-user marketing template message limits — Meta, 2025

• WhatsApp Business Platform pricing — Meta, 2025

• Message template guidelines — Meta Developer Documentation, 2026

• WhatsApp Business Messaging Policy — Meta

• Template categorization (automatic category updates) — Meta, 2025

• Marketing Messages API for WhatsApp — Meta Developer Documentation