# Broadcasts

## Overview

Broadcasts are bulk sends built around a single template, with detailed delivery tracking for each recipient. Find them under More → Broadcasts. Because every broadcast goes out from one approved template, it's the right tool for clean, trackable outreach at scale — promotions, notifications, and re-engagement.

For each broadcast, every recipient is tracked through the full WhatsApp delivery journey — queued, sent, delivered, read, or failed — plus per-recipient link-click analytics when the template includes tracked links. You can retry just the recipients who failed without re-sending to everyone, and split a broadcast across multiple connected numbers to spread the sending load.

> Access: Broadcasts require the Admin workspace role and a plan that includes the Broadcast feature. Your plan also sets a limit on how many broadcasts the workspace can create.

## Engines & Template Pre-Flight

A broadcast sends through the workspace's active engine, and the template picker only lists approved templates:

Engine | How the template is sent
--- | ---
Unofficial API | The template's header, body, footer, and buttons are sent like a normal message.
Business API (Meta Cloud) | For a Meta-approved template, WaDesk builds the full rich message for each recipient — buttons, carousel cards, media headers, and per-recipient tracked links — and sends it to Meta exactly as approved.
Twilio | A template registered with Twilio sends as a proper Twilio template; one that isn't sends as plain text.

Before a broadcast goes out, WaDesk checks the template first so you never waste your sending allowance on a send that's bound to fail:

- Authentication (OTP) templates are blocked — each recipient needs a unique verifiable code, which a broadcast can't provide. Send those one at a time from your own system.
- Media headers must be reachable over a public HTTPS link. This check runs on all engines whenever the template has a media header: plain `http://` links, private or internal addresses, and `localhost` / `.local` / `.test` / `.internal` hosts are rejected, because the recipient's phone (and Meta) can't download from them.
- On the Business API, a template that isn't approved by Meta, is paused for quality, or has fallen below your minimum quality setting is refused with a clear reason.

## Creating a Broadcast

Click Add Broadcast on the broadcasts list to open the composer, then work top to bottom:

1. Name it. Enter a broadcast name for your own reference in reports.
2. Pick the template. Choose an approved template from the dropdown. A live preview shows the header, body, footer, buttons, and any media so you can check exactly what will go out.
3. Choose the audience. Select one or more contacts and/or contact groups. Group members are pulled in and merged into one list with duplicates removed. You must select at least one contact or group, or the form asks you to.
4. Pick the connected number(s). Choose one number, or tick several for a multi-device send (see Multi-Device Sending).
5. Choose when to send. Pick Send now to send immediately, or Schedule for later and set a date, time, and time zone (your workspace time zone is pre-selected).

When you submit, WaDesk creates the broadcast (status processing for an immediate send, or scheduled for later), records which engine it's using, adds every recipient to the list as pending, and starts the send. Scheduled sends carry the exact time and time zone so they always fire at the right local moment.

## Per-Recipient Funnel

The broadcast detail page centers on the recipient grid. As WhatsApp reports back, each recipient moves through the delivery journey and the summary tiles (Sent, Delivered, Read, Failed, Queued, Clicked) update live. The stages build on each other: read means the message was also delivered and sent, so the tiles always stay consistent.

Status | Meaning
--- | ---
pending (Queued) | The recipient is in the list, waiting their turn to be sent to.
sent | The message was handed to WhatsApp and accepted.
delivered | WhatsApp confirmed the message reached the recipient's device.
read | The recipient opened the message (when read receipts are available).
failed | The send didn't succeed; the reason is shown (e.g. "Not on WhatsApp", out of sending allowance, or a media download problem).

Status updates are de-duplicated, so repeated reports from WhatsApp never double-count. The detail page also charts deliveries over time, a status donut, and a breakdown of failure reasons (top 8, with the rest grouped under "Other") so you can spot recurring problems — such as a batch of invalid numbers — at a glance.

> Always consistent: The per-recipient grid and the summary tiles are recalculated together on every update, so the headline numbers always match the individual rows.

## Link-Click Tracking

When a template contains link buttons (or links in the body), WaDesk replaces each one with a unique tracked link for every recipient. Tracked links expire after a set period (90 days by default, minimum 7 days). When a recipient taps the link, the click is recorded against that exact contact and they're sent on to the real destination immediately.

- The recipient grid shows a click count and last-click time for each contact.
- The Clicked tile counts how many unique contacts tapped any tracked link, with a click-through rate compared to messages delivered.
- Re-sending the same link to the same contact reuses the same tracked link, so retries never inflate your numbers.
- Link-preview crawlers and bots are sent through but not counted, so your numbers reflect real people. An admin can turn link tracking off platform-wide, in which case the original links are used as-is.

> Related: WaDesk's separate WhatsApp link generator creates shareable chat links that open WhatsApp with a pre-typed message and count their own clicks. That's for public, shareable links — different from the per-recipient tracking described here.

## Retrying Failed Recipients

Failures are common after a temporary glitch — an out-of-date media link, a connection drop mid-run, or a batch of invalid numbers. Rather than re-send to your whole audience, use Retry failed on the detail page:

1. Fix the cause first (reconnect the number, correct the media link, etc.).
2. Click Retry failed. WaDesk resets every failed recipient back to pending, clears their old error, sets the broadcast back to processing, and sends again only to those recipients.
3. Watch the grid — the retried recipients move back through the stages, while everyone who already succeeded is left untouched.

If there are no failed recipients, you'll see "No failed recipients to retry."

> Note: Retry sends only to recipients who failed before, so a contact who already received the message is never messaged — or charged — twice.

## Multi-Device Sending

Selecting two or more connected numbers splits the broadcast into one broadcast per number and divides the audience between them. By default the split is even; you can set share weights per number (for example 7/3) to send more through one number than another.

The split always adds up exactly to your audience size and lands as close as possible to the weights you set. Each contact goes to exactly one number, so no one ever receives a duplicate, and any empty share (e.g. 1 contact across 2 numbers) is skipped. Spreading volume across numbers lowers how fast each number sends — a useful safety measure against bans on the Unofficial API.

## Broadcast Statuses

The list page groups broadcasts by their overall lifecycle status:

Status | Meaning
--- | ---
scheduled | Saved for a future date/time and waiting to fire.
processing | Actively sending to recipients right now.
completed | The run finished and every recipient succeeded.
completed_with_errors | The run finished but some recipients failed — a good moment to use Retry failed.
failed | The broadcast couldn't run at all — e.g. no usable sender number, every contact had an empty phone number, or the sending service was unreachable.

The final status is confirmed once at the end of the run, as a safety net in case any individual delivery updates were missed.

> Delete rules: Only scheduled or failed broadcasts can be deleted — any other state shows "Only scheduled or failed broadcasts can be deleted." Deleting first cancels any in-progress send so it's never left half-finished, then removes the broadcast. Completed broadcasts are kept for their reporting history (and can be re-used later as a "queue" from Scheduled Messages).

## Ban-Safety & Pacing

Broadcasts are paced by the same safety controls the rest of WaDesk uses, set by your admin under Admin → Settings → System Message → Sender pacing:

Control | Default | Effect
--- | --- | ---
Message gap | 3 seconds | Delay between one message and the next, varied randomly by ±20%.
Batch size | 50 recipients | How many messages go out before a pause (when batching is on).
Batch gap | 5 minutes | Cooldown between batches, varied randomly by ±20%.
Daily cap (Unofficial API) | 4000 / day / number | Maximum messages a single number can send per day (resets daily).

If a connection drops mid-run on the Unofficial API, the broadcast is paused instead of sending into a dead connection and wrongly marking the remaining recipients as failed.

> Send responsibly. Broadcast only to contacts who opted in, keep templates relevant and personalized, warm up new numbers gradually, and split very large audiences across multiple numbers. Blasting unsolicited templates to cold lists is the quickest route to a quality downgrade or a banned number. On the Business API, watch template quality: a broadcast on a paused or low-quality template is refused before it sends, because pushing volume through a struggling template makes it worse and can trigger a Meta block — let the quality score recover, or switch to a healthier template, before broadcasting again.