# Blueticks > WhatsApp business automation: scheduling, campaigns, AI support agent, and CRM-style contact management. The Blueticks blog ("The Blueticks Dispatch") covers WhatsApp business operations: scheduling, marketing campaigns, customer service workflows, platform updates, and policy news. --- # WhatsApp Business API Updates 2026: A Dated Changelog of Every Pricing & Policy Change > Meta keeps changing WhatsApp Business pricing on a rolling schedule. Here is a single dated changelog of what shifted across 2026, with every date pinned to Meta's own card. URL: https://blueticks.co/blog/whatsapp-business-api-updates-2026 Published: 2026-09-06 Author: Avi Kohen Category: industry If you run WhatsApp messaging at any scale, you already know the frustration: the rate you budgeted against in January is not the rate you are billed in September. Meta now changes WhatsApp Business pricing on a rolling, quarter-by-quarter schedule, and the announcements land on a developer changelog most teams never read. This piece is that changelog, translated into plain dates and effects, with every entry pinned to Meta's own documentation. One clarification before the timeline, because it decides which changes touch you. Everything below is Meta's WhatsApp Business Platform (the Cloud API), reached through a Business Solution Provider. It is not the free WhatsApp Business app, and it is not Blueticks. Blueticks is a separate path (your own number over WhatsApp Web) that never touches this per-message bill. Keep the three straight and the changelog reads cleanly. ## What changed in WhatsApp Business pricing and policy in 2026? Across 2026, Meta kept the per-message model it launched in July 2025 and layered rolling changes on top: local-currency billing for India (January) and Brazil (July), higher authentication-international rates in several markets, and market-by-market rate-card adjustments. Each change carries its own effective date and affects a different slice of senders. Here is the at-a-glance timeline. Every date and effect below is drawn from [Meta's pricing updates changelog](https://developers.facebook.com/docs/whatsapp/pricing) (verified 2026-09), not a third-party recap. | Effective date | What changed | Who it affects | |---|---|---| | Nov 1, 2024 | Service conversations became free for all businesses | Support-led senders | | Jul 1, 2025 | Per-message pricing replaced conversation-based billing; volume tiers added for utility and authentication | Every API sender | | Jan 1, 2026 | India INR billing localization; India marketing rate up, North America utility/authentication down | India buyers, North America senders | | Apr 1, 2026 | India authentication-international rate raised; eight new billing currencies added | Cross-border OTP senders | | Jul 1, 2026 | Brazil BRL billing launched; several markets moved to standalone rate cards | Brazil buyers, EU/UK senders | | Oct 1, 2026 (announced) | New authentication-international rates for several more markets | Cross-border OTP senders | Notice what this table does not contain: per-message price digits. That is deliberate. The rates move too often to quote reliably, and Meta publishes the live figure per country and category on its own card. For the deep model behind these dates, our [pillar guide to WhatsApp Business API pricing in 2026](https://blueticks.co/blog/whatsapp-business-api-pricing-2026) walks the full structure. ## How does the per-message pricing model work now (in effect since July 1, 2025)? Since July 1, 2025, Meta charges per delivered template message, not per 24-hour conversation window. Per Meta's documentation, "you are only charged when a template message is delivered," and the rate "varies based on the template's category and the recipient WhatsApp phone number's country calling code." Non-template messages and service replies stay free. That last clause matters more than the headline. Two variables set every charge: the template category and the recipient's country calling code. A message to a +91 number is billed at India's rate whether your business sits in Mumbai or Manchester. Category is the other lever, and it is the bigger one, because the gap between the cheapest and most expensive bands dwarfs most volume discounts. What is still free is often misunderstood. Meta's page states plainly that "all non-template messages are free" and that "utility templates delivered within an open customer service window are free." So a support reply, or a utility template sent while a customer's 24-hour window is open, carries no charge. The bill is built almost entirely from business-initiated template sends outside that window. For the mechanics with a worked example, see [the per-message pricing-change explainer](https://blueticks.co/blog/whatsapp-business-pricing-change-2026-per-message). ### Why did Meta move from conversation-based to per-message pricing? Meta moved to per-message billing to price each delivered template individually rather than bundling several under one 24-hour conversation fee. The old model let a business send multiple templates in a window for a single charge. The per-message model, effective July 1, 2025, bills each delivery, which raised costs for multi-template conversations and left one-and-done campaigns roughly flat. The change also let Meta reduce some underlying rates without losing revenue. Meta's own changelog notes that when per-message pricing launched, utility and authentication rates were reduced across several markets even as the billing unit shrank from a conversation to a single message. The net effect on your bill depends entirely on how many templates you were packing into each conversation before the switch. ## What changed with local-currency billing in January 2026? On January 1, 2026, Meta launched INR billing localization for India, so accounts whose Sold-To country is India are now quoted and settled in rupees on the rate card directly. The same date brought rate-card updates: India's marketing rate rose, while North America saw lower utility and authentication rates. Migration to INR is mandatory by December 31, 2026. The localization removes the FX guesswork Indian buyers used to carry, because the number on Meta's card is now the number you pay, before your provider's markup. But it is not optional forever. Meta's changelog states that non-migrated accounts face delivery disruption after the deadline: messages from accounts still on the old currency will no longer be delivered past the cutoff. If you send to India, confirm your WABA's billing currency well before the December 2026 line. Brazil followed the same pattern. Meta launched BRL billing on July 1, 2026, with its own mandatory migration deadline in mid-2027. The pattern is now clear: Meta is regionalizing billing currency market by market, and India was the first large one. Our [India rate-card breakdown](https://blueticks.co/blog/whatsapp-business-api-pricing-india-2026) covers the INR cut in detail. [image: currency ledger] ## What changed for authentication and international message rates in 2026? Authentication saw the most movement in 2026. On April 1, 2026, Meta raised India's authentication-international rate, the band it charges when you send a one-time passcode to a number outside your home market. Domestic authentication stayed in its cheap lane, but cross-border OTPs jumped. More markets get new authentication-international rates on October 1, 2026. This is the trap most fintech and SaaS senders miss. Authentication-international is a distinct, higher band than domestic authentication. An app verifying only local users stays cheap; the moment it sends a login code to a foreign number, that message can leap bands. Meta's April 1, 2026 update singled out India for a higher authentication-international rate, and its announced October 1, 2026 changes extend new authentication-international rates to markets including Bangladesh, Iraq, Nepal, Sri Lanka, Kazakhstan, Kuwait, Morocco, Oman, and Ukraine. > "We priced our OTP budget off the domestic authentication rate and got surprised the first month we onboarded users abroad. The international band is a different number entirely." That is a paraphrased account from a payments operator, representative of a pattern we see repeatedly. The practical read: if any of your verification traffic crosses borders, model authentication-international separately from domestic authentication, and check the specific line on Meta's card per corridor. Do not assume all OTPs cost the same. This is the single most common budgeting error in the authentication category, and the 2026 changes widened the gap. Skip the per-message metering entirely: schedule and send WhatsApp campaigns from your own number with Blueticks. [Start free at https://blueticks.co/signup](https://blueticks.co/signup) ## What changed for message categories and templates in 2026? The four categories themselves did not change in 2026. Meta still sorts every template into marketing, utility, or authentication, with service replies inside an open 24-hour window billed separately and free. What moved in 2026 was the price of each band per market, on top of the volume-tier machinery Meta introduced for utility and authentication on July 1, 2025, alongside the per-message switch. Category discipline is where the real money is. Because marketing is the most expensive band in every market and utility sits well below it, the same message re-templated from marketing into a valid utility slot can drop by a large multiple. Meta reclassifies templates at review if you get the category wrong, so this is not a loophole; it is correct categorization. Our [category deep-dive](https://blueticks.co/blog/whatsapp-business-pricing-categories-2026-utility-marketing-authentication) covers what qualifies as utility versus marketing. The tiering change quietly helps high-volume senders. Since July 1, 2025, Meta applies volume-based pricing tiers to utility and authentication templates, so per-message rates in those two categories fall as monthly volume climbs. Marketing has no such tier path. That asymmetry, combined with the 2026 market moves that raised marketing rates in Italy, Spain, and the UK, sharpens the same conclusion: control your marketing volume, and push eligible traffic into utility. ## How do I keep up as rates change again? The only reliable source is Meta's live rate card, read per country and per category on the day you budget. Meta changes rates on a rolling quarterly schedule and announces upcoming changes on its pricing page, typically one month ahead. No static blog table, including this one, stays accurate; treat every third-party figure as a pointer back to Meta's card. Here is the discipline that keeps you current. Open [Meta's rate card](https://developers.facebook.com/docs/whatsapp/pricing#rate-cards), select your recipient country, then your category, and read the figure there. Meta commits to publishing the next round of changes ahead of their effective date. For the October 1, 2026 round, for example, Meta's changelog states the rates will be announced no later than September 1, 2026. [image: analyst rate review] Three habits protect a budget against the rolling changes. First, re-check the card at the start of every quarter, since most changes land on the first of January, April, July, and October. Second, watch the currency-migration deadlines for your markets, because a missed migration stops delivery, not just billing. Third, model authentication-international separately if you send any OTPs abroad. If you want a fill-in-the-blanks estimate using the live rates, use [the WhatsApp Business API cost calculator](https://blueticks.co/blog/whatsapp-business-api-cost-calculator). ## Do these API changes affect you if you send from your own number? No. Every change in this changelog is a WhatsApp Business Platform (Cloud API) pricing event. If you send from your own WhatsApp number over WhatsApp Web instead of the Cloud API, you are not on the Platform, so there is no per-message charge for these updates to touch. The rate-card moves, currency migrations, and authentication-international bands simply do not apply. [image: owner own number] This is a genuinely different path, and it fits a specific shape of work. The Cloud API and its BSPs are the right tool when you need Meta's verified sender identity, formal template approval, and reach into large lists of new, opted-in recipients. But a large share of everyday business messaging is not that. It is the weekly update to an existing customer list, the standing reminder, the recurring broadcast you already send by hand. On the Platform, every one of those meters against a category rate. From your own number, none of them do. Blueticks sits on this path. It is not a Meta Cloud API or BSP reseller, and it does not resell or discount the API. It schedules and automates messages from the number you already use, over WhatsApp Web, so there is no per-message API bill to skip in the first place. Be square about the trade: this path gives you no Meta verification and no guaranteed protection from bans, blocks, or rate-limiting. **Consent is the sender's responsibility on every path**, and no tool can promise a no-ban outcome. Message people who expect to hear from you, pace your sends, and keep the content relevant. ## 2026 WhatsApp Business changes at a glance (recap + what to watch next) In 2026, Meta held the per-message model steady and layered rolling changes on top: INR billing for India in January, higher India authentication-international rates in April, BRL billing for Brazil in July, and more authentication-international changes announced for October. The categories stayed the same; the rates and billing currencies moved market by market. What to watch next is straightforward. The October 1, 2026 round brings new authentication-international rates to a fresh list of markets, and Meta's currency-migration deadlines (India by December 31, 2026; Brazil by mid-2027) will force account-level action, not just budget updates. The rolling cadence itself is the real story: assume January, April, July, and October each carry a rate change for at least some markets, and build your cost model to expect it. The teams that stay ahead of this do two things. They read Meta's card fresh each quarter instead of trusting a cached number, and they keep a clear-eyed view of which of their sends genuinely need the Platform versus which could run from their own number without the per-message meter at all. ## FAQ **What are the biggest WhatsApp Business API updates in 2026?** INR billing localization for India (January 1, 2026), a higher India authentication-international rate (April 1, 2026), BRL billing for Brazil (July 1, 2026), and announced authentication-international changes for several markets (October 1, 2026). All sit on top of the per-message model Meta launched July 1, 2025. Verify current figures on [Meta's card](https://developers.facebook.com/docs/whatsapp/pricing). **When did WhatsApp switch to per-message pricing?** July 1, 2025. Per [Meta's pricing documentation](https://developers.facebook.com/docs/whatsapp/pricing), conversation-based billing was deprecated and each delivered template message is now charged individually, based on category and recipient country calling code. Non-template and service messages remain free. **Did WhatsApp message categories change in 2026?** No. The categories (marketing, utility, authentication, and free service replies) stayed the same in 2026. What changed was the per-message rate within each band per market, plus the volume tiers Meta applies to utility and authentication since July 1, 2025. **What is authentication-international, and why did it get more expensive in 2026?** Authentication-international is Meta's higher band for one-time passcodes sent to numbers outside your home market. Meta raised India's authentication-international rate on April 1, 2026 and announced new rates for more markets effective October 1, 2026. Model it separately from domestic authentication if you send OTPs abroad. **Do these changes affect me if I send from my own WhatsApp number?** No. Every update here is a Cloud API pricing event. Sending from your own number over WhatsApp Web, as with Blueticks, is off the Platform, so no per-message rate change applies. There is no ban or deliverability guarantee, and consent remains the sender's responsibility. --- # WhatsApp Broadcast vs Group: Which One to Use for Mass Messaging in 2026 > Broadcast list or group for mass messaging? One is private and caps at 256, the other reaches 1,024 but exposes everyone. Here is the decisive breakdown for 2026. URL: https://blueticks.co/blog/whatsapp-broadcast-vs-group Published: 2026-09-05 Author: Maya Cohen Category: marketing You want to reach your whole customer list on WhatsApp in one send. Two options look right: a broadcast list or a group. Pick wrong and you either reach a fraction of your people, or you accidentally hand every customer's phone number to every other customer. The whatsapp broadcast vs group choice is not about which one is bigger. It is about who receives the message, who sees the replies, and who sees each other. This guide settles it: reach, privacy, the hard contact limits on both, a decision checklist, and the honest answer for when both run out of room. ## WhatsApp broadcast list vs group: the one-line difference A broadcast list sends one message as separate private chats, so recipients never see each other and replies come only to you. A WhatsApp group is one shared thread where every member sees every message, every reply, and every phone number. Broadcast is one-to-many and private. Group is many-to-many and public. That single distinction decides everything else. Everything people get confused about, reach, replies, privacy, downstream, flows from that one difference. A broadcast list is a distribution tool. A group is a conversation room. When you send to a broadcast list, WhatsApp fans your one message out into individual one-to-one threads, and each person experiences it exactly as if you messaged them directly. When you post to a group, you are speaking into a room where everyone can talk back and everyone can hear everyone. So the real broadcast list vs group question is not "which sends to more people." It is "do I want a megaphone or a meeting." Get that framing right and the rest of the decision almost makes itself. ## Who actually receives your message (and the saved contact catch) A broadcast list only reaches people who have saved your number in their contacts. You can add 256 people to the list, but only the ones who saved you actually receive the message, silently, with no error on your end. A group has no such rule. Anyone you add to a group gets every message whether or not they saved you. This is the single most expensive misunderstanding in WhatsApp messaging. Per WhatsApp's Help Center guide on broadcast lists, a broadcast is delivered only to contacts who have added your number to their address book. Add a customer who never saved you, hit send, and WhatsApp reports a clean send while that person receives nothing. The list does not warn you. It does not flag the gap. It just quietly delivers to the subset who saved you. For a typical imported customer list, that subset is often a minority. If you loaded 256 numbers from a spreadsheet and most of those people never saved your business, your real reach can be well under half the list even though the app looks like it worked. This is the number-one reason a [WhatsApp broadcast is not delivering](https://blueticks.co/blog/whatsapp-broadcast-not-delivering) to everyone you expect. A group flips this. Because a group is a shared space you place people into, membership itself delivers the message. Nobody has to have saved you first. That is genuinely useful for reach, and it is exactly why groups feel like they "work better" for cold lists. The catch is everything a group exposes in exchange, which is the next section. [image: saved contact business card] ## Who sees the replies, and who sees each other's numbers In a broadcast list, replies come back to you as a normal private one-to-one chat, and no recipient can ever see who else is on the list. In a group, every reply is visible to all members, and every member can see and save every other member's phone number. This is the privacy line, and for most business sends it is the deciding factor. Think about what a reply actually does in each channel. Send an offer to a broadcast list of 256, and if 40 people reply "how do I claim this," you get 40 separate private conversations. Clean. Send that same offer to a 256-person group and those 40 replies land in one shared thread that every single member watches scroll by. One annoyed customer can post a complaint the whole room sees. One competitor you did not vet can quietly export every number in the group. That last risk is not theoretical. A WhatsApp group is, functionally, a directory of everyone's phone number handed to everyone in it. For a promotional or announcement send, that is a data exposure you almost never want. Your customer list is an asset. A group gives it away to anyone you add. The broadcast list keeps every recipient siloed. Nobody knows who else got the message, replies stay one-to-one, and your contact list stays yours. That privacy model is the entire reason broadcast lists exist, and it is why they remain the correct default for one-directional business messaging even with the smaller cap. ## How many people can you reach with each? (contact limits compared) A WhatsApp broadcast list caps at 256 saved contacts. A WhatsApp group holds up to 1,024 participants. So a single group reaches four times more people than a single broadcast list per send, but it pays for that reach with the privacy and reply model from the section above. Neither tool was built for true mass messaging beyond these ceilings. Here is the head-to-head: | | Broadcast list | WhatsApp group | |---|---|---| | Max size | 256 contacts | 1,024 participants | | Message style | Private one-to-one | Shared thread | | Recipients see each other | No | Yes | | Replies go to | You only | Everyone | | Recipient must save your number | Yes | No | | Best for | Announcements, offers, updates | Community, discussion | ### Broadcast list contact limit The whatsapp 256 contact limit is a hard per-list cap in both the standard app and the WhatsApp Business app. Per WhatsApp's Help Center, a single broadcast list holds a maximum of 256 recipients. You can create more than one list, but each list sends separately, so three lists of 256 is three manual send actions, not one pooled campaign. There is no setting that raises the 256 ceiling. For the full picture on the cap and its workarounds, see our [WhatsApp broadcast limit guide](https://blueticks.co/blog/whatsapp-broadcast-limit). ### Group participant limit The whatsapp group message limit for membership is 1,024 participants. WhatsApp raised this from 512 when it launched Communities in November 2022, and the WhatsApp Communities announcement confirms the 1,024-per-group ceiling that still holds in 2026. Communities can bundle multiple groups up to around 2,000 total members, but any single group tops out at 1,024. So the most people you can reach in one action is 1,024 through a group, or 256 through a broadcast list. ## When to use a broadcast list vs a group: a decision checklist Use a broadcast list when the message is one-directional and privacy matters: offers, order updates, reminders, announcements to people who saved you. Use a group only when you actually want a two-way room where members talk to each other: a community, a class cohort, a team. If you need one-way reach past 256 without exposing numbers, neither native tool fits, which is the honest limit. Run your send through these questions in order: 1. **Do recipients need to reply to each other, or only to me?** Only to me, use a broadcast list. To each other, use a group. 2. **Would it be a problem if every recipient could see every other recipient's number?** Yes, use a broadcast list. Genuinely no, a group is fine. 3. **Have most of these people saved my number?** Yes, a broadcast list will reach them. No, a broadcast list will silently miss them, and a group becomes the only native option that delivers. 4. **Is this a repeating, scheduled send?** Neither native tool schedules or repeats. Note that and read the last section. 5. **Do I need to reach more than 1,024 people in one send?** Neither native tool does it. You need a different path. Here is a realistic pattern to make it concrete. Say a boutique studio, call it Marlow and Co, wants to push a flash sale to 900 customers. As a group, all 900 numbers become visible to each other and the sale thread fills with cross-talk within minutes. As broadcast lists, they split into four lists of up to 256, send privately four times, and every reply stays one-to-one, but any customer who never saved the studio's number gets nothing. That is the real tradeoff in miniature: the group delivers to everyone and exposes everyone, the lists protect everyone and reach only the savers. Outgrown broadcast lists and groups? Blueticks lets you schedule and send personalized broadcasts to unlimited contacts straight from your own WhatsApp number, with no group noise and no 256 cap. Start free at [https://blueticks.co/signup](https://blueticks.co/signup) ## What broadcasts and groups both can't do (personalization, scheduling, scale) Neither a broadcast list nor a group can personalize each message, schedule a send for later, repeat a send automatically, or reach beyond their fixed caps in one action. Both are manual, live-only tools built for personal-scale messaging. The moment you need "same message, 2,000 people, first name on each, every Sunday at 9am," you have left what native WhatsApp offers. Line up the gaps and the pattern is clear: - **Personalization.** A broadcast sends the identical text to all 256. A group sends the identical text to all members. Neither inserts a first name, an order number, or a due date per recipient. Everyone gets the exact same block. - **Scheduling.** There is no native "send this at 9am tomorrow." You are physically present, tapping send, or it does not go. - **Repetition.** A weekly update means you rebuild and resend by hand, every week, forever. - **Scale past the caps.** 256 per broadcast list and 1,024 per group are the ceilings. To [send a WhatsApp message to multiple contacts](https://blueticks.co/blog/whatsapp-broadcast-more-than-256-contacts) beyond those numbers in a managed way, you are stacking manual lists or standing up something else entirely. Personalization is not a nicety here. It is a deliverability and engagement lever. In WhatsApp campaigns, personalized sends routinely outperform identical bulk blasts on reply rate by a wide margin, and the identical-text signal is exactly what platforms watch for when flagging spam. (Reply-rate uplift from personalization is directional and varies by list and offer; treat it as illustrative, not a guaranteed figure.) So the "both can't personalize" gap costs you twice: weaker engagement and a bigger spam footprint. As one operator running weekly WhatsApp promotions put it: "The broadcast list was fine until I was managing four of them by hand every Sunday night, pasting the same message and praying half my customers had actually saved my number." (Composite quote, illustrative of the manual-scaling and saved-number frustrations this guide documents; not a single real customer.) [image: manual sunday sending] ## Sending broadcasts from your own number without the 256 cap If you need broadcast-style private sends past the 256 contact limit, without group noise and without exposing anyone's number, you can send from the WhatsApp number you already use over WhatsApp Web, with software handling the scheduling and repetition. This is a third path: not the free app's manual broadcast, not Meta's Business API, but your own account at personal-messaging scale. [image: own number scheduled send] This is the shape Blueticks takes. You connect the same WhatsApp number you send from today, and instead of stacking manual broadcast lists of 256 or dumping everyone into a group, you schedule a personalized broadcast that goes out privately to each recipient. No shared thread, so no customer sees another customer's number. No 256-per-list ceiling to rebuild around. And because each message can carry a first name or an order detail, you are not firing the identical block that both native tools force on you. Be straight about what this is and is not. It sends from your own number over WhatsApp Web, so there is no Meta verification and no per-message billing, but there is also no API-grade guarantee against a ban. It is not the Meta Cloud API and does not pretend to be, and it is not the only tool that works this way. Consent is still yours to earn. WhatsApp's anti-spam behavior still applies to your account exactly as it would if you sent by hand, so sensible pacing and a genuinely opted-in list are non-negotiable. What the software removes is the manual grind, the 256-list math, and the group-exposure problem, not your responsibility for who you message. If that is your situation, you can [connect your existing number and schedule a broadcast](https://blueticks.co/signup) in a few minutes. ## FAQ: WhatsApp broadcast vs group **What is the difference between a WhatsApp broadcast and a group?** A broadcast list sends one message to many people as separate private one-to-one chats. Recipients cannot see each other, and replies come only to you. A group is a single shared thread where every member sees every message and reply and can see each other's phone numbers. Broadcast is private and one-directional; group is public and conversational. **How many people can a WhatsApp broadcast list vs a group reach?** A broadcast list caps at 256 contacts, and a group holds up to 1,024 participants, so a group reaches four times more people per send. But a broadcast only delivers to recipients who saved your number, while a group delivers to everyone you add. Neither reaches beyond its cap in a single action. **Do people need to save my number to receive a broadcast or a group message?** For a broadcast list, yes: a recipient only gets the message if they have saved your number in their contacts, otherwise it silently fails to deliver. For a group, no: anyone you add receives every message regardless of whether they saved you. This is the biggest practical difference for cold or imported lists. **Should I use a broadcast or a group to send to multiple contacts?** Use a broadcast list for one-way announcements and offers where privacy matters and replies should come only to you. Use a group only when you want members to talk to each other. To send a WhatsApp message to multiple contacts privately beyond 256, native tools run out, and you need an own-number scheduling tool or the Business API. **Can I schedule or personalize a WhatsApp broadcast or group message?** Not natively. Both broadcast lists and groups send the identical text, live, with no scheduling and no per-recipient personalization. To schedule, repeat, and personalize sends from your own number, you need a layer on top of WhatsApp Web such as Blueticks, or Meta's Business API for true enterprise scale. *Sources: WhatsApp Help Center guide on broadcast lists (256-contact cap and the saved-number delivery rule) and the WhatsApp Communities announcement (group limit raised to 1,024 in November 2022, current in 2026). Platform limits change; verify against WhatsApp's official documentation before building around a specific figure.* --- # WhatsApp Business API vs App Pricing: What Each Actually Costs in 2026 > The honest 2026 cost breakdown: what the free WhatsApp Business app really covers, how Cloud API per-message pricing works, and the third path that skips both. URL: https://blueticks.co/blog/whatsapp-business-api-vs-app-pricing Published: 2026-09-04 Author: Maya Cohen Category: marketing You are trying to price a decision, not read a feature list. The real question behind "whatsapp business api vs app pricing" is simple: if I commit to one of these, what does it actually cost me per month at my volume? The free app has a price tag of zero and a ceiling you will hit. The Cloud API has no flat fee at all, it bills per message by category and country. Most comparisons blur that. This one pins every number to Meta's own docs and shows you the total, including the fees the rate card never prints. ## What does the free WhatsApp Business app actually cost, and where is its ceiling? The WhatsApp Business app is free. There is no subscription, no per-message fee, no Meta billing at all. You download it, verify one phone number, and send. The cost is not money, it is capability: no scheduling, no true bulk campaigns, no conditional automation, and a single-operator ceiling you hit the moment you need to reach a list at a set time. Here is what "whatsapp business app free" really buys. You get a business profile, a product catalog, labels, and three reactive automations: a greeting message, an away message, and saved quick replies. Every one of those waits for the customer to message first, or for a human to tap send. There is no "send this to 300 contacts at 9am Tuesday" button, because outbound scheduling does not exist in the app. The ceiling is where the hidden cost lives. When you outgrow reactive replying, the app forces a workaround: you copy, paste, and send by hand, or you start Googling the API. Broadcast lists exist, but they only reach contacts who have saved your number and cap the list size, so they are not real campaigns. The app is deliberately a solo tool. For the full map of what breaks first, see our [WhatsApp Business app vs API](https://blueticks.co/blog/whatsapp-business-app-vs-api) comparison. ## How does WhatsApp Cloud API pricing really work? It is per message, not a flat fee WhatsApp Cloud API pricing is not a subscription. Per [Meta's WhatsApp Business Platform pricing docs](https://developers.facebook.com/docs/whatsapp/pricing), the platform moved to a per-message model effective July 1, 2025, replacing the older conversation-based system. You pay for each delivered message, priced by two things: the message category and the recipient's country calling code. There is no single "API price" to quote. This is the mental model shift that trips up every spreadsheet. The app has a price (zero). The API has a rate card. Your monthly whatsapp business messaging cost is a function you compute, not a line item you look up: number of messages, times the per-message rate for each category, times the country mix of your audience. Send 5,000 marketing messages to one country and 5,000 utility messages to another, and those are four different math problems on the same invoice. Two structural facts make the model workable rather than punishing. Meta does not charge for service messages, the free-form replies you send inside an open conversation. And Meta runs volume tiers: send more utility and authentication templates in a market and the per-message rate drops, resetting monthly and aggregated across your business accounts. Marketing gets no such discount. Before you model anything, read [do I need the WhatsApp Business API](https://blueticks.co/blog/do-i-need-whatsapp-business-api) to confirm you are even in API territory. [image: api scale fulfillment] ## Which message categories cost money on the API: marketing, utility, authentication, and the free service window Four categories exist, and they do not cost the same. Per Meta's pricing docs, marketing, utility, and authentication are template messages that can carry a per-message charge. Service messages are free. Utility templates delivered inside an open 24-hour customer service window are also free. Marketing is the category with no free window and no volume discount, which makes it the one that reliably shows up on your bill. Think of it as a ladder from free to always-charged: - **Service messages** cost nothing. These are your free-form replies to a customer inside an open conversation. - **The 24-hour customer service window** opens when a user messages you first. Utility templates sent inside it are free, per Meta's docs. - **Utility and authentication templates** (order updates, shipping notices, OTP codes) carry a per-message rate, but qualify for Meta's volume tiers, so the rate falls as you scale. - **Marketing templates** (promos, offers, re-engagement) are charged per message with no volume discount and no free window. This is your whatsapp api cost per message at its highest. The practical read: a business whose traffic is mostly inbound support and transactional updates can keep a large share of its sends free or discounted. A business that leans on outbound marketing pays for nearly every message. Meta also runs a 72-hour free-entry window after a Click-to-WhatsApp ad, which shifts the math again if paid social is your front door. [When to use the WhatsApp Business API](https://blueticks.co/blog/when-to-use-whatsapp-business-api) walks the volume thresholds where this per-message pricing starts to pay off. ## The hidden costs of the API path: BSP fees, onboarding, and charges the rate card never shows Meta's per-message rate is not the whole bill. Most businesses reach the Cloud API through a Business Solution Provider, and the BSP adds its own layer: a monthly platform fee, a markup on each message, or both. On top of that sits the unpriced cost of onboarding, business verification, and template approval, which is time and effort the rate card does not list. Budget for all three or your estimate will be low. Here is the part comparison tables leave out. When you add up the true whatsapp cloud api pricing, you are stacking: 1. **Meta's per-message charge**, by category and country. 2. **The BSP's fee**, which can be a flat monthly plan, a per-message markup, or a per-conversation surcharge on top of Meta's rate. 3. **Onboarding cost**, meaning the days-to-weeks of business verification through Meta Business Manager and the wait for template approvals before you can send a single campaign. Consider an illustrative example, clearly labeled as illustration, not a Meta-quoted figure. Say you send 10,000 marketing templates in a month. If Meta's marketing rate for your audience's country were, hypothetically, a few US cents per message, that is a few hundred dollars to Meta before your BSP adds anything. Layer a BSP platform fee and per-message markup, and the real number climbs. The exact digits change by country and date, so pull them live from [Meta's pricing docs](https://developers.facebook.com/docs/whatsapp/pricing) rather than trusting any blog's frozen table. The pattern is common enough to state as a composite, illustrative operator view, drawn from how these migrations typically go rather than a single named source: the Meta per-message rate is the part teams predict correctly, while the BSP fee and the weeks of onboarding are the part that surprises the budget. ## App vs API pricing at a glance: which is cheaper for your monthly volume? At a glance, the free app is cheaper until you need scheduling, bulk, or automation the app cannot do. The Cloud API is cheaper than hiring people to send by hand once your volume is high and mostly transactional, because service and in-window utility messages are free and utility scales into volume discounts. The break point is not a headcount, it is whether a system or a person authors your messages. | | **WhatsApp Business app** | **WhatsApp Cloud API** | **Own-number path (e.g. Blueticks)** | |---|---|---|---| | **Pricing model** | Free | Per-message pricing since July 1, 2025 | Flat subscription, no Meta per-message fee | | **Per-message fee** | None | By category and country | None (uses your existing number) | | **Free messages** | All (no outbound scheduling) | Service messages; utility in the 24h window | N/A | | **Extra fees** | None | BSP platform fee and markup | None from Meta | | **Marketing sends** | Manual, one at a time | Charged, no volume discount | Scheduled and bulk from your number | | **Setup cost** | Download, verify number | Verification, template approval, dev or BSP work | Connect your number, start | | **Best fit** | Solo, reactive replies | High, transactional volume | Human-scale scheduling and broadcast | The honest read of the table: the app wins on raw cost and loses on capability, the API wins at transactional scale and loses to setup friction and BSP fees below it, and there is a third column most guides never draw. Reaching WhatsApp at scale without paying the Cloud API's per-message fee? Blueticks schedules and broadcasts from your own WhatsApp number. Start free at [https://blueticks.co/signup](https://blueticks.co/signup). [image: at a glance desk] ## Is there a third path that avoids per-message API fees? Sending from your own number Yes. There is a third path that is neither the free app nor the Cloud API: an own-number tool that runs on the WhatsApp number you already use, over WhatsApp Web. It adds scheduling, recurring reminders, and list campaigns without Meta business verification, without template approval, and without a per-message fee, because you are not on the Platform API at all. The trade is real and worth stating plainly. This path exists because the binary framing hides a middle. A clinic that just wants Tuesday's reminders sent does not need programmatic infrastructure, and it should not be paying a per-message rate plus a BSP fee to do something a scheduler handles from its existing number. The job is small: "send this Tuesday at 9," "follow up with non-responders in three days," "message my 150-person list." None of that requires the Cloud API. Be clear about what you take on. This is your own number over WhatsApp Web, so you inherit WhatsApp Web behavior, you pace your sending sensibly, and no tool on this path, Blueticks included, can promise you will never be restricted. Consent is the sender's responsibility: per [Meta's opt-in documentation](https://developers.facebook.com/documentation/business-messaging/whatsapp/getting-opt-in), businesses are required to obtain opt-in permission before messaging people. The [WhatsApp Business app vs API](https://blueticks.co/blog/whatsapp-business-app-vs-api) guide places this third path against the other two in full. ## Which WhatsApp option is cheapest for your job? A quick decision table by use case The cheapest option depends on who authors the message and how often. A solo operator answering incoming DMs pays nothing on the free app. A system firing thousands of transactional notifications gets the best economics from the Cloud API's free service window and utility volume tiers. A person sending human-scale, repeating campaigns from a number they already own avoids per-message fees entirely on the own-number path. | Your job | Cheapest fit | Why | |---|---|---| | Answering incoming DMs, no scheduling | Free WhatsApp Business app | Zero cost, reactive automations included | | Thousands of order or OTP notifications | WhatsApp Cloud API | Service free, utility scales into volume tiers | | A chatbot answering 24/7 | WhatsApp Cloud API | Only path with programmatic automation | | Many agents on one number | WhatsApp Cloud API | The app caps you; API is built for it | | Weekly promo to a saved-customer list | Own-number path | No marketing per-message fee, no template approval | | Recurring reminders from your own number | Own-number path | Flat cost, keeps your number and contacts | | Timed follow-ups to a pipeline you nurture | Own-number path | Human-scale, no BSP onboarding | The rule that closes it: if a human would happily type each message but has no time to, you want scheduling, not the API, and the own-number path is the cheaper answer. If a system generates the message and it must fire thousands of times with delivery tracking, the Cloud API's per-message pricing is the one that fits. Match the tool to the author. For the threshold detail, see [when to use the WhatsApp Business API](https://blueticks.co/blog/when-to-use-whatsapp-business-api). [image: decision owner notes] ## Schedule and broadcast from your own WhatsApp number with Blueticks Blueticks is the third path priced as a flat subscription instead of per message. It runs on the WhatsApp number you already use, adds scheduled sends, recurring reminders, and list broadcasts, and never charges you a Meta per-message fee, because it is not the Cloud API and not a BSP. It is built for human-scale, personalized outreach, not for million-message automated notification streams or chatbots. Where it fits is durable, repeating work. A clinic sending the same appointment reminders every week. A shop running a standing monthly offer to its saved-customer list. A consultant nurturing a pipeline with timed follow-ups. In each case a person would be comfortable authoring the message but does not have the time to send it by hand, and the work repeats. That is the shape the own-number path was built for, and it sidesteps both the app's manual ceiling and the API's per-message math. Where it does not fit, we will say so directly. If a system, not a person, must fire the message, thousands of times a day, with delivery guarantees and CRM triggers, that is a Cloud API job and no own-number tool is a substitute. And the deal on this path is honest: you send under your own discipline, you pace sensibly, and consent is yours to collect. No vendor here can promise you will never be restricted. ## FAQ: WhatsApp Business app vs API cost questions **Is the WhatsApp Business app really free?** Yes. The WhatsApp Business app has no subscription and no per-message fee. Meta does not bill you for using it. The cost is capability, not money: no outbound scheduling, no true bulk campaigns, and no conditional automation. When you need those, you move to the Cloud API or an own-number tool, and that is where costs begin. **How does WhatsApp Cloud API pricing work?** Per Meta's pricing docs, the Cloud API uses per-message pricing effective July 1, 2025. You pay for each delivered message, priced by category (marketing, utility, authentication) and the recipient's country. Service messages are free, and utility templates inside an open 24-hour service window are free. Most businesses also pay a BSP fee on top. **What is the WhatsApp API cost per message?** There is no single figure. The rate depends on the message category and the recipient's country calling code, and Meta updates its rate cards over time. Marketing is charged with no volume discount; utility and authentication qualify for volume tiers. Pull the live, date-stamped numbers from Meta's pricing documentation rather than any static blog table. **Which is cheaper, the app or the API?** The free app is cheaper until you need scheduling, bulk, or automation it cannot do. The Cloud API is cheaper than manual sending once your volume is high and mostly transactional, thanks to free service messages and utility volume tiers. Below that, the API's per-message fees plus BSP costs are overhead you will not recoup. **Can I avoid per-message fees entirely?** Yes, at human scale. An own-number tool that runs on WhatsApp Web schedules and broadcasts from a number you already use, with no Meta per-message fee and no template approval. For fully automated, high-volume notification streams, the Cloud API is still the right tool. Consent remains the sender's responsibility on every path. --- # WhatsApp Lead Nurturing: How to Turn Prospects Into Buyers With an Automated Sequence > A warm lead replies once, then goes quiet. WhatsApp lead nurturing is the fix: a planned, automated sequence that walks each prospect from first reply to first purchase without you remembering to follow up. URL: https://blueticks.co/blog/whatsapp-lead-nurturing Published: 2026-09-03 Author: Maya Cohen Category: marketing A prospect replied to your ad. They asked one question, you answered, and then they went quiet. You meant to follow up on day two. You didn't. By the time you remembered, the lead was cold and forty more were sitting in exactly the same state. That gap is where deals die, and it is what WhatsApp lead nurturing fixes. Instead of you chasing every prospect by hand at the right moment, a planned sequence of timed, personal messages carries each one from their first reply toward a first purchase. This guide covers what nurturing actually is, why leads stall at message two, a five-message nurture map you can copy, how to write messages that earn a reply, the consent rules Meta requires, and how to automate the whole thing from your own WhatsApp number. ## What is WhatsApp lead nurturing, and how is it different from onboarding or a cold blast? WhatsApp lead nurturing is guiding a pre-sale prospect toward a first purchase through a planned series of timed, personal follow-up messages. It differs from onboarding, which begins after someone has already bought and aims at activation, and from a cold blast, which fires one identical message to a whole list at once with no follow-through. The three get muddled, and the confusion costs conversions. A cold blast is a megaphone: same words, same second, everyone on the list. Onboarding is what happens once the sale is done, teaching a new customer to reach their first win. Lead nurturing sits before the sale. It is a two-way, one-to-one rhythm built around what a specific prospect just did, whether that was a form fill, an ad reply, or a price question. | | Cold blast | Lead nurturing | Onboarding | |---|---|---|---| | When it runs | Anytime, one shot | Pre-sale, after first interest | Post-sale | | Audience | Whole list at once | One prospect at a time | One new customer | | Goal | Announce or promote | Move toward first purchase | Activation, first win | | Shape | Single message | Timed sequence, stops on buy | Timed sequence, stops on activation | The distinction matters because the tactics do not transfer. If you want the post-sale playbook instead, our [WhatsApp onboarding sequence for new customers](https://blueticks.co/blog/whatsapp-onboarding-sequence-new-customers) covers that half. This article is about the pre-sale work: turning a warm reply into a paying customer with a nurture sequence that runs whether or not you remember it. ## Why do most WhatsApp leads go cold right after the second message? Most WhatsApp leads go cold because the follow-up stops, not because interest died. A prospect replies, you answer once, and then no one sends message three. Speed compounds the problem: leads contacted within five minutes are 21 times more likely to qualify than those reached at 30 minutes, per the MIT and InsideSales.com Lead Response Management study. [image: cold lead quiet phone] That study, led by Dr. James Oldroyd across more than 15,000 leads and 100,000 call attempts, found the odds of even making contact dropped roughly 100 times when the first outreach slipped from five minutes to 30. The lesson is not "be faster once." It is that responsiveness has to be systematic, because the second and third touches are where humans quietly fail. Here is the honest mechanic behind the stall. Message one is easy, someone just raised their hand. Message two is a reply to their question, still easy. Message three has no trigger. Nobody messaged you, no notification fired, and the prospect is now competing with forty other tasks for your attention. So message three does not get sent, and the lead you paid to acquire cools off on its own. A whatsapp follow up sequence removes that failure point by pre-scheduling the touches that a busy human forgets. The sequence does not get distracted, take a day off, or decide the lead "probably isn't interested." ## What does a high-converting WhatsApp nurture sequence look like? A high-converting WhatsApp nurture sequence runs about five messages from first reply to first purchase: a fast acknowledgment, a value message, a proof message, an objection-handler, and a direct offer. Each message has one job and one delay, and the entire sequence stops the moment the prospect buys, books, or clearly opts out. [image: nurture map planning] The exact copy changes by industry, but the spine below works for most pre-sale nurtures. Think of it as a lead nurturing sequence template you adapt, not a script you paste. | # | Message | Timing | Its one job | |---|---|---|---| | 1 | Acknowledge and set expectations | Within minutes of the reply | Answer their question, promise a next step | | 2 | Deliver value, no ask | Day 1 | Send the guide, tip, or example that helps whether or not they buy | | 3 | Show proof | Day 3 | One short result story from a similar customer | | 4 | Handle the obvious objection | Day 5 | Name the real blocker (price, time, risk) and answer it | | 5 | Make the direct offer | Day 8 | One clear ask: book, buy, or claim the offer, with a deadline | Two design rules hold the whole thing together. First, front-load the value and widen the gaps as you go, so you are helpful early and only direct once you have earned it. Second, build the exit before the messages: the day-8 offer should never reach someone who already bought on day 3. For the message-count and spacing logic behind this map in more depth, our guide on [how to build a WhatsApp drip sequence that converts](https://blueticks.co/blog/whatsapp-drip-sequence) breaks down the timing math. Stop losing warm leads at message two. [Schedule your entire nurture sequence from your own WhatsApp number with Blueticks](https://blueticks.co/signup), so every prospect gets the next follow-up on time without you remembering to send it. ## How do you write WhatsApp nurture messages that get a reply instead of a mute? Write nurture messages that earn replies by giving each one a single ask, opening with the prospect's name and context, keeping it short enough to read on a lock screen, and ending with a question rather than a statement. On WhatsApp, which people read like a personal thread, a message that sounds mass-produced gets muted; one that sounds like a person gets an answer. Four rules do most of the work: 1. **One ask per message.** Book the call, or answer a question, or claim a code, never all three. A message with three asks gets none of them done. 2. **Lead with context, not "Hi there."** "Hi Sara, you asked about the 6-week plan yesterday" beats "Hello, following up." Personalization variables like a first name and the thing they asked about make a nurture read one-to-one. 3. **End on a question.** Statements close a thread; questions open one. "Want me to send the pricing breakdown?" invites a reply that also reopens your messaging window. 4. **Match message length to the channel.** WhatsApp is a phone-first, glanceable medium. Three lines that get read beat three paragraphs that get scrolled past. Here is the pattern in a labeled example. Northlight Coaching, a synthetic-but-representative B2B coaching business, ran 250 ad leads a month through a single manual follow-up. Roughly 4% booked a discovery call, and the founder admitted most leads never got a second message. They rebuilt it as a five-touch automated whatsapp messages sequence: a same-minute acknowledgment with a question, a day-1 value email-equivalent sent on WhatsApp, a day-3 client result, a day-5 objection-handler on price, and a day-8 direct booking ask with a deadline. Bookings rose to 11% of leads, replies spread across all five steps, and the founder stopped losing the leads that used to vanish after message two. "The sequence sent the follow-ups I never got around to," the founder said. "Same leads, same offer, we just stopped dropping them." (Synthetic example; figures are illustrative of the pattern, not a guarantee.) ## How often should you follow up, and when should a lead exit the sequence? Follow up on a widening cadence, roughly five messages across 8 to 14 days, front-loaded early and spaced out later. A lead should exit the sequence the instant they take the goal action, reply with a real conversation, or opt out. The exit logic matters as much as the timing: nurturing someone who already bought is how you earn a block. [image: cadence exit planning] The cadence is a balance. Too tight and you crowd the thread; too loose and the lead forgets who you are. A day-0, day-1, day-3, day-5, day-8 spine keeps momentum without becoming a nag. But cadence is only half the design. These four exit conditions should end the sequence for a given contact automatically: | Exit trigger | Why it ends the sequence | |---|---| | They buy or book | The goal is met; further nurturing is noise | | They reply to talk | A human conversation should never compete with an automation | | They opt out | Required, and non-negotiable | | They finish the sequence | No message six; stop before you become spam | The second row is the one most senders get wrong. When a prospect replies to genuinely engage, the automated day-8 "still interested?" nudge should never fire into that live thread. That single mistimed message reads as spam, undoes the trust the nurture built, and is the fastest way to teach a warm lead to mute you. A good whatsapp nurture sequence treats a reply as a full stop, not a step to keep counting past. ## Do you need consent to nurture WhatsApp leads? What Meta's rules actually require Yes. Meta's WhatsApp Business Messaging Policy requires you to obtain opt-in before messaging someone, and the opt-in must clearly state your business name and that the person is agreeing to receive messages from you. The method is flexible (a website form, a checkbox, a keyword reply, in person), but consent is your responsibility as the sender, not the platform's. [image: consent optin signup] Per [Meta's official opt-in documentation](https://developers.facebook.com/documentation/business-messaging/whatsapp/getting-opt-in), businesses "must clearly state that a person is opting in to receive communication from the business" and "must clearly state the business's name that a person is opting in to receive messages from." Meta lets you determine the method as long as it meets those requirements and complies with local law. A pre-checked box buried in a footer does not clear that bar. A prospect who typed their number into your "message us on WhatsApp" form, or replied to start a conversation, generally does. This is why lead nurturing works cleanly and cold blasting does not. Nurturing follows up with people who already raised their hand, which is exactly the opted-in, existing-contact relationship the policy is built around. There is also a timing rule worth knowing: when a user messages you, [Meta opens a 24-hour customer service window](https://developers.facebook.com/documentation/business-messaging/whatsapp/messages/send-messages) during which you can reply freely, and every new reply resets it. Nurture messages that follow a prospect's inbound reply sit naturally inside that rhythm. Cold outreach to people who never opted in sits outside every rule Meta wrote, and it is how numbers get flagged. ## How do you automate the whole nurture sequence from your own WhatsApp number? Automate a nurture sequence in five steps: confirm opt-in, define one entry trigger, map your five timed messages, write each to a single action, then schedule the delays so the sequence sends itself. Done from your own WhatsApp number through a scheduling tool, this runs without the Meta Business Platform, template approvals, or per-message fees. Here is the working build: 1. **Confirm opt-in first.** Every contact entering the nurture needs recorded consent naming WhatsApp. This is a compliance step, not a growth hack, and it protects the number you send from. 2. **Pick one entry trigger.** "Replied to the September ad" or "filled the demo form" is a trigger. "When it feels right" is not. One trigger per sequence keeps the logic clean. 3. **Map the five touches before you write.** Lock the timing (day 0, 1, 3, 5, 8) and each message's single job on paper first. Mapping stops you from improvising a nine-message marathon nobody asked for. 4. **Write each message to one action.** One ask, one question, one next step per touch, using a first-name variable so it reads personal at scale. 5. **Schedule the delays.** Set the trigger and each delay once, and let the sequence fire on time for every new lead. This is the step the free WhatsApp Business app cannot do on its own, and the one a scheduling tool exists to solve. The key honesty here: a tool like Blueticks drives your existing personal WhatsApp number through WhatsApp Web or a cloud gateway. It is not the Meta Cloud API, so there are no template queues and no per-message charges, but that also means you nurture at personal-account scale and stay responsible for consent and sensible sending. It is the right fit for nurturing hundreds to a few thousand leads a month, not blasting hundreds of thousands. ## What WhatsApp can't do natively for lead nurturing, and how Blueticks fills the gap Natively, WhatsApp cannot nurture. The free Business app gives you a greeting message, an away message, and quick replies, but nothing that fires message three two days after message two on its own, and nothing that removes a contact from the sequence when they reply. Blueticks adds the missing layer: timed multi-step sequences, per-contact variables, and stop-on-reply exits, run from your own number. [image: automate own number desk] Line the gaps up against the fix and the case is clear: | What nurturing needs | Free WhatsApp Business app | Blueticks | |---|---|---| | Fire message 3 on a delay, no human action | No native sequencer | Scheduled timed sends | | Personalize per contact | Manual editing | Audience fields and variables | | Stop when a lead replies | Not available | Stop-on-reply exit | | Run from your own number | Yes | Yes, extension or cloud gateway | That last row is the honest boundary of this approach. Blueticks does not turn your personal number into an enterprise broadcast engine, and it makes no promise about deliverability or bans, because sending from your own number means your sending habits and consent hygiene decide those outcomes. What it does is close the exact gap that lets warm leads die at message two. If you are still comparing approaches, our guide to the [best WhatsApp drip campaign and sequence tools in 2026](https://blueticks.co/blog/best-whatsapp-drip-campaign-tools) lays the own-number and Business Platform models side by side so you can match one to your volume. ## WhatsApp lead nurturing FAQ **What is WhatsApp lead nurturing?** WhatsApp lead nurturing is the practice of guiding a pre-sale prospect toward a first purchase through a planned series of timed, personal follow-up messages sent on WhatsApp. Instead of one reply and then silence, a nurture sequence delivers a fast acknowledgment, a value message, proof, an objection-handler, and a direct offer, each on its own delay. It follows people who opted in, and it stops the moment they buy or reply to talk. **How many messages should a WhatsApp nurture sequence have?** For most pre-sale nurtures, about five messages spread over 8 to 14 days, front-loaded early and spaced wider later. A day-0, day-1, day-3, day-5, day-8 spine keeps momentum without crowding the thread. Fewer than three rarely overcomes inertia; more than six starts earning mutes and blocks. Always stop the sequence when the lead converts, replies to engage, or opts out. **Do I need consent to nurture leads on WhatsApp?** Yes. Meta's WhatsApp Business Messaging Policy requires opt-in before you message someone, and the opt-in must clearly name your business and state that the person agrees to receive messages. The method is flexible, but consent is the sender's responsibility. Nurturing works because it follows up with people who already raised their hand, which is the opted-in relationship the policy is built around. **Can I run an automated WhatsApp messages sequence from my own number?** Yes. Tools like Blueticks drive your existing WhatsApp number through WhatsApp Web or a cloud gateway to send timed multi-step sequences, with no Meta Cloud API, no template approval, and no per-message fees. The trade-off is that you send at personal-account scale and stay responsible for consent and sensible volume, which suits nurturing hundreds to a few thousand leads a month rather than mass sends. **Why do my WhatsApp leads keep going cold?** Usually because the follow-up stops, not because interest died. Message one and two are easy replies; message three has no trigger, so a busy human forgets it, and the lead cools. Response speed makes it worse: the Lead Response Management study found leads contacted within five minutes qualify at 21 times the rate of those reached at 30 minutes. An automated whatsapp follow up sequence sends the touches you would otherwise drop. *Source and honesty notes: the 21x qualification figure and the 100x contact-odds figure come from the MIT Sloan and InsideSales.com Lead Response Management study (Dr. James Oldroyd). Opt-in requirements and the 24-hour customer service window trace to Meta's official WhatsApp Business documentation. Northlight Coaching is a synthetic example and its figures are illustrative of the pattern, not a guarantee; your results vary by list quality, offer, and market. Blueticks sends from your own WhatsApp number over WhatsApp Web or a cloud gateway, not the Meta Cloud API, and makes no deliverability or ban-safety guarantee.* --- # Double Opt-In for WhatsApp Business: How the Confirmation Step Actually Works (2026) > Double opt-in adds one confirmation step between a raw sign-up and a real subscriber. Here is how that step works on WhatsApp, what a compliant confirmation message says, and how to record proof of each yes. URL: https://blueticks.co/blog/double-opt-in-whatsapp-business Published: 2026-08-31 Author: Maya Cohen Category: marketing Double opt-in on WhatsApp Business means you collect an initial opt-in, then send one confirmation request the person must actively answer before you count them as a subscriber. Two affirmative actions, not one. The second is what turns a phone number into consent you can defend. Most lists are single opt-in: someone ticks a box or drops their number, and you start sending. Double opt-in adds a gate. The person has to confirm, on WhatsApp, that yes, they want your messages. It costs you a step and some sign-up volume. It buys you a cleaner list and a paper trail. This piece walks the confirmation step end to end: how it works, what the confirmation message should say, whether to ask for a reply or a tap, and how to record each yes so you can prove it later. One thing up front, because it decides how you read everything below. Double opt-in is a consent method, not a piece of software. It applies to you, the sender, no matter how your messages leave the building. Blueticks runs this flow from your own WhatsApp number over WhatsApp Web, so the examples here are engine-agnostic on purpose. ## How does double opt-in work on WhatsApp Business? Double opt-in works in three moves: a person gives an initial opt-in on some channel, you send a confirmation request on WhatsApp, and they take a second affirmative action to confirm. Only after that second yes do you treat them as a confirmed subscriber. No confirmation, no subscriber. Walk the mechanism. The first opt-in is where the person volunteers their number and interest, usually off WhatsApp: a website field, a checkout page, an in-store tablet, a QR code. Meta's own [WhatsApp Business Messaging Policy](https://whatsappbusiness.com/policy/) says you may contact someone only if "they have given you their mobile phone number" and "you have received opt-in permission from the recipient confirming that they wish to receive subsequent messages or calls from you." That is the baseline for single opt-in too. Double opt-in adds the second move. You send one message to that number, on WhatsApp, asking them to confirm. They reply, tap, or click. That confirmed action is the moment your whatsapp consent collection becomes something you can stand behind: the person proved the number is theirs and that they meant to hand it over. A mistyped digit or a bored bot never completes the step, so it never lands on your list. ## Single vs double opt-in: what actually changes at the confirmation step? Single opt-in ends at the sign-up. Double opt-in adds one verification round-trip: a confirmation request and a required response. Everything before is identical. The only new thing is the second affirmative action, which proves the number is real, reachable, and genuinely willing. Here is the contrast at the step that differs: - **Single opt-in** - one action (box ticked, number given), then you send. Fast, higher volume, weaker proof. - **Double opt-in** - the same first action, plus a confirmation the person must answer. Slower, lower volume, far stronger proof. That is the whole mechanical difference. Whether double opt-in is *required* for you, how GDPR and local law treat consent, and where each method fits are separate questions this piece does not re-litigate. Read our [WhatsApp opt-in compliance requirements](https://blueticks.co/blog/whatsapp-opt-in-compliance-requirements) guide for the mandate-and-law side, and [WhatsApp opt-in best practices](https://blueticks.co/blog/whatsapp-opt-in-best-practices) for when the extra step is worth the volume you trade. Below, we stay on running the confirmation step well. ## How do you run the confirmation step, from first opt-in to confirmed subscriber? Run it in four steps: capture the first opt-in with your business name stated, send exactly one confirmation request to that number on WhatsApp, wait for the person's affirmative response, then mark them confirmed and store the timestamp. Non-responders stay unconfirmed. You never message them again. Step by step, so nothing slips: 1. **Capture the first opt-in.** On your website, checkout, storefront tablet, or QR code, collect the number and state clearly who they are opting in to. This is your entry point for how to get whatsapp opt ins at scale, and it is the same regardless of how you send later. 2. **Send one confirmation request.** Message that number on WhatsApp asking them to confirm. One message. If they do not answer, you may send a single polite reminder, then stop. Repeated nagging of someone who never confirmed is exactly the behavior that gets numbers reported. 3. **Wait for the affirmative action.** A reply, a tap, or a click. Silence is not consent. A "STOP" or no answer means they do not join. 4. **Mark confirmed and record it.** Log the yes with a timestamp and the method. That record is your defense if the consent is ever questioned. [image: customer hand phone cafe window] This is engine-agnostic. Whether you send through Meta's Cloud API or, like Blueticks, from your own number over WhatsApp Web, the sender runs these four steps. The tool changes how the message leaves; it does not change what consent requires of you. ## What does a compliant double opt-in confirmation message look like? A compliant confirmation message names your business, states plainly that the person is opting in to receive messages from you, tells them what they will get and how often, and gives a clear way to decline. Meta requires the business name and a clear opt-in statement. The rest is what keeps people from reporting you. Copy this and adapt it: > Hi [name], this is **[Business Name]**. You asked to get our weekly offers and order updates on WhatsApp. Reply **YES** to confirm you want these messages. Reply **STOP** any time to opt out. We will not message you again unless you confirm. Why those elements are not optional: Meta's [Get opt-in for WhatsApp](https://developers.facebook.com/documentation/business-messaging/whatsapp/getting-opt-in) documentation states the requirements verbatim. "Businesses must clearly state that a person is opting in to receive communication from the business." "Businesses must clearly state the business's name that a person is opting in to receive messages from." And "Businesses must comply with applicable law." Those are the whatsapp opt in language requirements in Meta's own words, not a paraphrase. **Consent is the sender's responsibility.** Obtaining and recording valid consent, in a way that complies with the laws that apply to you, is your legal responsibility as the sender, not the platform's and not your tool's. Meta's policy says you are "solely responsible for determining the method of opt-in" and that it complies with applicable law. No product removes that duty. ## Reply-YES or tap-to-confirm: which confirmation method should you use? Both work. A free-text "reply YES" proves the person typed a deliberate response and is the simplest to run from your own number. A tap-to-confirm button or a click-through link is faster for the recipient and easier to log cleanly. Use reply-YES for simplicity; use a button when you want a structured, one-tap record. What each method actually proves: - **Free-text reply (YES)** - the person read the message and typed an intentional word. High signal, and it needs no special infrastructure, which is why it is the default for a whatsapp newsletter opt in run from your own number. The cost: replies vary ("yes", "sure", "ok"), so your logging has to catch more than one spelling. - **Tap-to-confirm button or link** - one action, one clean event. Easier to record without ambiguity and lower friction for the recipient, so completion rates tend to be higher. The trade is that a stray tap is a weaker signal of intent than a typed word, so pair it with a clear label. Neither method is "more compliant" than the other. Both are an affirmative action, which is what the confirmation step is for. Pick the one you can run reliably and log without gaps. If you are still deciding where the first opt-in happens, our [WhatsApp opt-in widget](https://blueticks.co/blog/whatsapp-opt-in-widget) walkthrough covers the capture side. ## How do you record and prove each confirmation? Record three things for every confirmation: when it happened, how (reply text or the button they tapped), and the exact wording they saw. Store it against the contact so the consent is reconstructable months later. If you cannot show what someone agreed to and when, you cannot prove they agreed at all. A defensible consent record has: - **Timestamp** - the date and time the affirmative action landed. - **Method** - free-text reply (and the exact words), or the button/link they tapped. - **The wording shown** - the confirmation message text they responded to, so you can prove what "yes" meant. - **Source of the first opt-in** - where the initial number and interest came from (which form, which QR, which checkout). Keep it in your CRM, a spreadsheet, or wherever your contact records live, tied to the phone number. The point is retrievability: a year from now, for any contact, you can pull up when they confirmed and to what. This matters because, again, **Consent is the sender's responsibility.** When a recipient disputes it or a regulator asks, the record is the only thing that answers for you. ## Does double opt-in guarantee you won't get blocked or banned? No. Double opt-in reduces your risk and protects your quality signals; it does not make you immune. It filters out bad numbers and unwilling recipients, which lowers block-and-report rates, but a confirmed subscriber can still report you if you over-send or go off-topic. Treat it as risk reduction, never as a shield. Here is the honest math on why it helps. In email marketing, single opt-in lists generate roughly **75% more spam complaints** than double opt-in ones, because they collect more mistyped and fraudulent addresses (per [Stripo's 2026 opt-in benchmarks](https://stripo.email/blog/opt-in-email-marketing-statistics-benchmarks-and-what-they-mean/)). The same mechanism carries to WhatsApp: on a fully confirmed list, fewer people are surprised to hear from you, and surprise is what drives the block-and-report taps that wreck your standing. Fewer reports is a real, measurable protection. It is not a guarantee. The other honest number, from the same benchmarks: double opt-in typically cuts sign-up volume by **15% to 40%**. You lose the people who never confirm. That is the point, not a flaw. What to do with never-confirmers: leave them alone. Do not fold unconfirmed numbers into a broadcast to "give it one more shot." A person who ignored your confirmation and then gets a promotional blast is your single most likely reporter. One reminder, then silence. ## Once opt-ins are confirmed, how do you send to that consented list? Once each subscriber has confirmed, you send from your own WhatsApp number to that consented list: schedule the welcome message, then your recurring broadcasts, to the numbers that passed the confirmation step. No new consent gymnastics, no per-message API bill. You have already done the hard part. This is where Blueticks fits, and where it does not. Blueticks is not the Meta Cloud API and not the WhatsApp Business app's built-in tools. It schedules and sends from the WhatsApp number you already use, over WhatsApp Web, so once your list is confirmed you can line up the welcome message and every follow-up broadcast without touching an API console. You did the confirmation step; Blueticks handles the sending after the yes. The natural next move, after this how-to, is to put it to work: [schedule your welcome message and first broadcast to your confirmed list with Blueticks](https://blueticks.co/signup), from your own number. Send only to the people who confirmed, and keep the content close to what they opted in for. On the free tier you can have three scheduled messages running at once, which is enough to test the welcome-plus-first-broadcast sequence before you scale it. And carry the earlier warning with you: confirming a list lowers your risk, it does not remove it. Pace your sends, stay on the topic they agreed to, and honor every STOP the moment it arrives. ## FAQ **What is double opt-in on WhatsApp Business?** It is a two-step consent method: a person gives an initial opt-in, then confirms it with a second affirmative action on WhatsApp before you count them as a subscriber. Meta's [messaging policy](https://whatsappbusiness.com/policy/) requires opt-in permission before you message anyone; double opt-in verifies that permission with a confirmation step. **Is double opt-in required by WhatsApp?** Meta requires opt-in, and requires you to state your business name and that the person is opting in to receive your messages, per its [opt-in documentation](https://developers.facebook.com/documentation/business-messaging/whatsapp/getting-opt-in). Whether you must use the *double* (confirmed) version depends on the laws that apply to you, which our [compliance requirements guide](https://blueticks.co/blog/whatsapp-opt-in-compliance-requirements) covers. Consent is the sender's responsibility to determine and document. **What should a WhatsApp confirmation message say?** It should name your business, state clearly that the person is opting in to receive your messages, say what they will get, and give a clear way to opt out (for example, "Reply YES to confirm, STOP to opt out"). The business name and opt-in statement are required by [Meta's opt-in rules](https://developers.facebook.com/documentation/business-messaging/whatsapp/getting-opt-in). **Does double opt-in stop my WhatsApp number from getting banned?** No. It lowers your risk by removing bad numbers and unwilling recipients, which cuts block-and-report rates, but it is not immunity. Over-sending or off-topic messages can still get a confirmed subscriber to report you. Frame it as risk reduction, not a guarantee. **How do I prove someone opted in?** Record the timestamp, the method (their reply text or the button they tapped), the exact wording they confirmed against, and where the first opt-in came from, stored against the contact. Meta's policy makes obtaining and documenting valid consent the sender's sole responsibility, so the record is your evidence. --- # WhatsApp Business API Pricing in India 2026: INR Per-Message Rates by Category (and How to Skip the Per-Message Bill) > India is the cheapest major market for WhatsApp business messaging, but the bill has layers. Here is how Meta's per-message model works in INR, by category, with every rate pinned to Meta's own card. URL: https://blueticks.co/blog/whatsapp-business-api-pricing-india-2026 Published: 2026-08-29 Author: Avi Kohen Category: industry WhatsApp business API pricing in India in 2026 is per delivered template message, billed in INR, and set by the recipient's country. The rate depends on the category (marketing, utility, authentication), authentication-international sits in its own band, and service replies are free. That is the 30-second answer. The rest of this article does the thing most "India rate card" posts refuse to do: it pins every pricing fact to Meta's own published card instead of quoting a number from memory. If a specific INR figure below is not on Meta's live rate card, you will not find it invented here. One clarification first, because it decides everything. This pricing is Meta's WhatsApp Business Platform (the Cloud API), reached through a Business Solution Provider. It is not the free WhatsApp Business app, and it is not Blueticks. Blueticks is a third path (your own number, over WhatsApp Web) that never touches this per-message bill at all. Keep the three separate and the whole cost question gets clean. ## How does WhatsApp Business API pricing work in India in 2026? WhatsApp Cloud API pricing in India 2026 is a per-message model: Meta charges for each delivered template message, the price is set by the recipient's country calling code, and India recipients are now billed in INR. It is Meta's platform accessed through a provider, not the free app. Two facts from [Meta's WhatsApp Business Platform pricing documentation](https://developers.facebook.com/docs/whatsapp/pricing) anchor the whole model (both verified as of 2026-08). First, "effective July 1, 2025, Meta charges on a per-message basis," which ended the old 24-hour conversation-based billing. We cover that switch in [the per-message pricing-change explainer](https://blueticks.co/blog/whatsapp-business-pricing-change-2026-per-message); the one-line version is that you now pay per delivered template, not per conversation. Second, Meta states charges "are based on the country calling code of the recipient WhatsApp phone number," so an India +91 recipient is billed at India's rate regardless of where your business sits. The India-specific piece is billing localization. Per Meta's pricing page, INR billing "launched on January 1, 2026 for partners and directly-integrated clients whose Sold-To country is India." Before that, Indian buyers were effectively reading USD rates and converting. Now the meta whatsapp business platform pricing india rate card is denominated in rupees directly. To see the actual figures, you open Meta's [rate card selector](https://developers.facebook.com/docs/whatsapp/pricing#rate-cards) and choose India plus INR plus a category. That interactive card, not a third-party blog, is the only source I trust for a live number, and it is the source you should verify against too. Our own [pillar guide to WhatsApp Business API pricing in 2026](https://blueticks.co/blog/whatsapp-business-api-pricing-2026) walks the global model; this piece is the India cut. ## What are the WhatsApp Business per-message rates in India by category? WhatsApp business API pricing India per message is banded by category. Marketing is the most expensive band, utility and authentication sit far lower, authentication-international is a separate higher band, and service (customer-service) replies are free. The exact INR per-message figure for each is published on Meta's India rate card. Here is the honest structure, straight from [Meta's pricing page](https://developers.facebook.com/docs/whatsapp/pricing) (as of 2026-08). I am giving you the categories and their relative ordering, not invented digits, because the digits belong on Meta's card: - **Marketing** - promotions, offers, re-engagement. This is the priciest category on the card and drives most of the whatsapp marketing message cost in india. - **Utility** - order confirmations, shipping updates, transactional follow-ups tied to an existing action. Meta prices this well below marketing. - **Authentication** - one-time passcodes and login verification. Priced alongside utility, far under marketing. - **Authentication-International** - authentication delivered across certain international corridors, which Meta bills in its own, higher band. If you send OTPs to numbers outside your home market, check this line specifically. - **Service** - a business reply inside an open customer-service window. [Meta's platform page](https://whatsappbusiness.com/products/platform-pricing/) states these are "at no charge." Service messages are free. [image: desk ledger morning light] For the definitions behind each label (what counts as utility versus marketing, and why a mis-categorised template gets re-billed), read [the category deep-dive](https://blueticks.co/blog/whatsapp-business-pricing-categories-2026-utility-marketing-authentication) rather than trusting a one-word summary. The category you send in is the single biggest lever on your bill: the same message re-templated from marketing into a valid utility slot can drop by a large multiple. That is why category discipline, not volume alone, is where Indian teams save money. The practical read: for whatsapp cloud api pricing india 2026, marketing is your expensive lane and utility/authentication are your cheap lanes. Meta also applies volume tiers to utility and authentication, so the more you send in those categories, the lower the per-message rate can go. Confirm the live number for your category on Meta's card before you budget. ## What changed for Indian buyers in the 2025 per-message switch and authentication-international? Two shifts hit Indian buyers. First, the July 1, 2025 move to per-message billing ended the old 24-hour conversation window, so you now pay per delivered template. Second, India moved to INR billing on January 1, 2026, and authentication sent internationally is billed in its own higher band. The per-message switch is the structural one. Under the old model, Meta billed a 24-hour "conversation" that could carry several messages. Since July 1, 2025, per [Meta's pricing documentation](https://developers.facebook.com/docs/whatsapp/pricing), each delivered template is billed on its own. For a high-frequency Indian sender, that changes the math on how you batch messages. We explain the mechanics in [the per-message change piece](https://blueticks.co/blog/whatsapp-business-pricing-change-2026-per-message); no need to re-derive it here. The India-currency shift is the local one. Meta's page dates INR billing localization to January 1, 2026 for India Sold-To accounts. So whatsapp business platform pricing india 2026 is now quoted and settled in rupees on Meta's card, which removes the FX guesswork but does not, by itself, change the underlying category structure. Authentication-international is the trap worth flagging. If your OTP traffic crosses borders, Meta bills it in a distinct, higher band than domestic authentication. An Indian fintech sending login codes only to +91 numbers stays in the cheap authentication lane; the moment it verifies a user on a foreign number, that message can jump bands. Check the authentication-international line on Meta's [rate card](https://developers.facebook.com/docs/whatsapp/pricing#rate-cards) before you assume all your OTPs cost the same. ## How much does WhatsApp Business API cost per month in India? A worked INR example Monthly WhatsApp Business API cost in India is your delivered-message count multiplied by each category's INR rate on Meta's card, plus your provider's fees and applicable tax. There is no flat subscription in Meta's charge itself; the model is usage-based, so volume and category mix set the bill. Here is one illustrative scenario. Every input below is illustrative, and every rate is "as published on Meta's card (linked)," not a number I am asserting: - **Illustrative volume:** 30,000 marketing templates, 20,000 utility templates, and 10,000 authentication templates delivered in a month, all to +91 recipients. - **Illustrative service traffic:** several thousand replies inside open customer-service windows, which are free per Meta. - **Rate for each line:** taken from Meta's India INR [rate card](https://developers.facebook.com/docs/whatsapp/pricing#rate-cards) for that category, on the day you budget. To turn that into a rupee figure, multiply each delivered count by its current India category rate from Meta's card, sum the three lines, then add your provider's fees and any tax. Because I will not fabricate the per-message digits, I am not going to print a bottom-line total that would only be fiction. For a fill-in-the-blanks version where you plug in the live rates yourself, use [the WhatsApp Business API cost calculator](https://blueticks.co/blog/whatsapp-business-api-cost-calculator). The takeaway from the structure alone: your marketing line usually dominates the bill even at lower volume, because marketing is the priciest band. Shift eligible messages into utility, and the monthly cost moves more than any volume discount will. ## Where do Indian BSP markups add cost on top of Meta's rates? Meta's rate card is only the first layer. In India you almost always reach the Cloud API through a Business Solution Provider, and providers add their own platform fees, per-message markups, or monthly plans on top of Meta's per-message charge. The whatsapp business api pricing india per message you actually pay is Meta's rate plus that markup. There are two distinct layers to the bill. The first is Meta's per-delivered-message charge, set on the [official rate card](https://developers.facebook.com/docs/whatsapp/pricing). The second is your BSP's commercial model. Indian platforms in the Interakt and AiSensy class typically layer a monthly subscription, a per-message markup, or both, over Meta's raw rate. That markup is legitimate (someone has to run the integration, the template approvals, and support), but it is not Meta's money, and it is the layer that varies most between providers. The neutral, honest framing: two businesses sending identical volume through two different BSPs can pay materially different totals, purely on the provider layer, while Meta's underlying rate is the same for both. When you compare quotes, separate the Meta line from the provider line. Ask any prospective BSP to show Meta's pass-through rate and their markup as two numbers, not one blended figure. If they only quote a blend, you cannot tell whether you are paying for messaging or for margin. This is a cost point, not a throughput or API-versus-app point; keep the comparison on rupees per delivered message plus platform fee. ## When can you skip WhatsApp per-message fees entirely by sending from your own number? You skip Meta's per-message fees when you send from your own WhatsApp number over WhatsApp Web instead of the Cloud API. Per-message marketing and utility charges are a Platform cost. A business messaging from its own number is not on the Platform, so there is no per-message API bill to pay. [image: owner phone shopfront evening] This is the third path, and it is a different shape from everything above. The Cloud API and its Indian BSPs are the right tool when you need Meta's verified sender identity, formal template approval, and reach into tens of thousands of new, opted-in recipients. But a large share of everyday Indian business messaging is not that. It is the weekly update to an existing customer list, the standing reminder, the recurring broadcast you have been pasting by hand from your own phone. That work does not need the Platform, and on the Platform every one of those sends would meter against Meta's marketing or utility rate. Blueticks sits on this third path. It is not a Meta Cloud API or BSP reseller, and it does not resell or discount the API. It lets you schedule and automate messages from the WhatsApp number you already use, over WhatsApp Web, so there is no per-message API charge to skip in the first place. For businesses reaching Indian customers who want to avoid Meta's per-message marketing and utility fees, you can [schedule and automate from your own number with Blueticks](https://blueticks.co/signup) and carry no per-message API bill. Be square about the trade. This path gives you no Meta verification and no per-message billing, but also no guaranteed protection from bans, blocks, or rate-limiting. **Consent is the sender's responsibility**, on every path, and no tool, including this one, can promise a no-ban outcome. Message people who expect to hear from you, pace your sends, and keep the content relevant. The third path removes the per-message fee; it does not remove your duty to send responsibly. ## FAQ **How much does WhatsApp Business API cost per message in India in 2026?** It depends on the category and is set on Meta's India INR rate card. Marketing is the priciest band, utility and authentication are far lower, authentication-international is its own higher band, and service replies inside an open window are free. Verify the exact INR figure on [Meta's rate card](https://developers.facebook.com/docs/whatsapp/pricing#rate-cards) (as of 2026-08). **Is WhatsApp Business API pricing in India billed in rupees?** Yes. Per [Meta's pricing documentation](https://developers.facebook.com/docs/whatsapp/pricing), INR billing localization launched January 1, 2026 for accounts whose Sold-To country is India, so the India rate card is denominated in INR directly. **Are WhatsApp service messages free in India?** Yes. Meta's [platform pricing page](https://whatsappbusiness.com/products/platform-pricing/) states that replies inside an open customer-service window are sent "at no charge." Only business-initiated marketing, utility, and authentication templates are billed. **Why is my WhatsApp bill higher than Meta's published rate?** Because most Indian senders use a Business Solution Provider that adds platform fees or a per-message markup on top of Meta's rate. Meta's [rate card](https://developers.facebook.com/docs/whatsapp/pricing) is only the first layer; your provider's commercial model is the second. **Can I send WhatsApp marketing to Indian customers without paying per-message API fees?** Yes, if you send from your own number over WhatsApp Web rather than the Cloud API. Tools like Blueticks schedule from your existing number, so no per-message Platform charge applies. There is no ban or deliverability guarantee, and consent remains the sender's responsibility. --- # WhatsApp Broadcast Message Limit Per Day: How Much Can You Really Send in 2026? > There is no single daily broadcast number in WhatsApp. What you can send depends on which of three paths you send from. Here is the honest breakdown. URL: https://blueticks.co/blog/whatsapp-broadcast-message-limit-per-day Published: 2026-08-28 Author: Avi Kohen Category: industry There is no single WhatsApp broadcast message limit per day. What you can send depends on which path you send from: the free WhatsApp Business app enforces a soft anti-spam ceiling with no published number, while the Meta Cloud API meters you in documented tiers from 250 up to unlimited per rolling 24 hours. That is the honest 30-second answer, and most guides get it wrong by quoting one number as if it were law. The truth is that "per day" means three completely different things depending on how you send, and the number people search for most often does not exist. This article separates the real limits from the folklore, links every platform fact to Meta's own docs, and shows where a third path fits when neither the app nor the API is the right shape for your volume. One clarification before we start, because it is the single most common mistake in this category. Blueticks, the tool this site makes, is not the WhatsApp Business API and not the free app. It is a third path: your own number over WhatsApp Web. Keep the three separate in your head and the whole "how much can I send" question gets clean. ## How many WhatsApp broadcast messages can you send per day? The number depends entirely on the path, so here is the short table before the long explanation. On the **free WhatsApp Business app**, there is no published daily broadcast number. You can add up to 256 recipients to a single broadcast list, but the app polices *sending* through soft anti-spam signals, not a fixed daily quota. Send fast to people who never replied and you can be limited or banned well before any imagined "cap." On the **Meta Cloud API** (the WhatsApp Business Platform), the daily limit is explicit and tiered. Meta caps how many *unique customers* you can send business-initiated messages to in a rolling 24-hour window at [250, then 2,000, then 10,000, then 100,000, then unlimited](https://developers.facebook.com/docs/whatsapp/messaging-limits/), and above the 2,000 tier your number climbs the ladder automatically as your quality and volume hold up. On the **own-number path** (your existing number over WhatsApp Web, which is where Blueticks sits), there is no Meta-issued quota at all, because you are not on Meta's Business Platform. What governs you instead is WhatsApp's ordinary anti-spam behavior on a normal account, so sensible pacing, not a dashboard number, is the real limit. So "how many broadcast messages can I send on WhatsApp per day" has no universal answer. It has three answers, and picking your path is what sets your number. ## Why isn't there a single 'broadcasts per day' number in WhatsApp? Because WhatsApp was never one product. It is a consumer app, a small-business app, and a programmable platform, and each layer treats sending differently. The consumer and small-business apps are built to stop spam, not to license bulk sending. So their limits are deliberately vague. A hard, published "you may send N per day" number would be a spammer's specification sheet. Vagueness is the point: the app watches *how* you send, not just how much, and reacts to blocks, reports, and reply rates. This is why two accounts sending the same volume can get wildly different outcomes. The Cloud API is the opposite. It is a paid, accountable platform, so Meta publishes an exact ceiling and a clear path to raise it. There the daily limit is a real, queryable number tied to your [messaging limit tier](https://developers.facebook.com/docs/whatsapp/messaging-limits/). The "per day" confusion comes from mixing these worlds. People read the API's clean tier numbers, assume the app must have an equivalent hidden number, and go hunting for it. It is not hidden. It does not exist in that form. [image: Person at a bare desk by a bright window with a phone face-down and a coffee mug, calm morning light] ## What are Meta's tiered messaging limits (250 to unlimited per 24h)? On the Cloud API, your daily reach is set by your **messaging limit tier**, and Meta documents the ladder plainly. The tiers cap how many *unique customers* you can send business-initiated messages to in a rolling 24-hour period at [250, 2,000, 10,000, 100,000, and finally unlimited](https://developers.facebook.com/docs/whatsapp/messaging-limits/). A few details that trip people up: - The limit counts **unique people you reach**, not the number of messages. Replying to customers who messaged you first does not count against it; only business-initiated outreach does. - New numbers begin at the 250 tier. Reaching 2,000 takes a manual step (business verification, or delivering 2,000 high-quality template messages). Above 2,000 you climb automatically: when you keep a healthy [quality rating](https://developers.facebook.com/docs/whatsapp/messaging-limits#quality-rating) and use at least half your current limit over 7 days, Meta raises your tier within 6 hours. You do not apply; you earn it. - Business-initiated messages are **template-gated**. To message someone outside an open 24-hour window you must use a pre-approved [message template](https://developers.facebook.com/docs/whatsapp/cloud-api/guides/send-message-templates), and since July 2025 Meta bills [per template message delivered](https://developers.facebook.com/docs/whatsapp/pricing/), not per conversation. This is the legitimate high-volume road. If you genuinely need to reach tens of thousands of new customers a day with people who have opted in, the Cloud API through a provider is built for exactly that, and it is the honest recommendation for that scale. The cost is real though: Meta verification, a provider relationship, template approval, and [per-message pricing](https://developers.facebook.com/docs/whatsapp/pricing/) on every template you deliver. ## What daily limit does the WhatsApp Business app actually enforce? Here is where most of the internet gets it wrong. Search "whatsapp broadcast limit 35" and you will find confident claims that the app lets you broadcast to exactly 35 people, or send exactly 35 messages, per day. **That number is folklore. Meta does not publish it.** It appears nowhere in WhatsApp's or Meta's documentation, and treating it as a rule will only mislead you. What the WhatsApp Business app actually enforces is softer and smarter than a counter. A broadcast list can hold up to [256 recipients](https://faq.whatsapp.com/653415899610349) (that is a list-size cap, a different limit we cover in the [broadcast list limit guide](https://blueticks.co/blog/whatsapp-broadcast-limit), and if you need more than that see [sending to more than 256 contacts](https://blueticks.co/blog/whatsapp-broadcast-more-than-256-contacts)). But there is a second condition that matters more than list size: **a broadcast only reaches a person if they have saved your number in their contacts.** Send to people who have not, and the message silently does not land, which is the usual reason a [broadcast isn't delivering](https://blueticks.co/blog/whatsapp-broadcast-not-delivering). On top of that, the app watches your sending behavior. Rapid sends to strangers, a wave of blocks, or spam reports can get your number rate-limited or banned regardless of how few messages you sent. So the app's real "daily limit" is not a number you can plan against. It is a reputation you can lose. Plan around the reputation, not around a mythical 35. ## Per day vs per month: which WhatsApp broadcast limit hits you first? People also search for the WhatsApp broadcast message limit per month, expecting a monthly quota to sit above the daily one. On the app, there is no published monthly number any more than a daily one, so the honest answer is that neither is a fixed quota; behavior is what governs you. On the Cloud API, the binding constraint is almost always the **daily** tier, not a monthly figure. If you are at the 2,000 tier and try to reach 5,000 new customers in a day, you hit the 24-hour ceiling immediately, long before any monthly consideration. The practical monthly capacity is just your daily tier multiplied out, assuming your quality holds and you keep climbing. So for planning, ignore "per month" as a separate limit. Ask two questions instead: which path am I on, and what is my rolling 24-hour reality on that path. That is the limit that hits you first, and usually the only one that matters. ## What actually gets you banned when you broadcast at volume? Volume alone rarely triggers a ban. **Sending pattern does.** Across every path, the same signals put a number at risk: - Messaging people who never opted in or never saved your number. - A spike in **blocks and "report spam"** taps right after you send. - Identical, salesy, link-heavy messages fired in a rapid burst. - A brand-new number that starts blasting on day one with no warm-up. On the Cloud API these signals show up as a falling [quality rating](https://developers.facebook.com/docs/whatsapp/messaging-limits#quality-rating), which can freeze or drop your tier. On the app and the own-number path they show up as rate-limiting or a ban with no appeal dashboard. The mechanism differs; the cause is identical. The durable fix is not a clever workaround. It is consent and pace. Message people who expect to hear from you, keep content relevant, and spread sends over time instead of firing everything at once. **Consent is the sender's responsibility**, on every path, and no tool, including this one, can promise you will never be banned. Anyone who guarantees a no-ban outcome is selling you a story. ## How can you broadcast reliably at volume from your own number? Here is the path many guides skip, because it is neither the app nor the API. You can keep broadcasting from **the WhatsApp number you already use**, over WhatsApp Web, and let software handle the pacing and the repetition for you. This is the own-number path, and it is what Blueticks does. Be clear about the honest trade. On this path there is **no Meta verification and no per-message billing**, because you are not on the Cloud API. In exchange you live with WhatsApp Web semantics (your number, your account, ordinary consumer-grade behavior) and, as with every path, **no guaranteed protection from bans**. It is not the API, it does not pretend to be, and it is not the only tool that works this way; be fair to the Cloud API for true enterprise scale and to the other own-number tools out there. Where it fits best is the **durable, repeating job**: the weekly update to your customer list, the standing campaign you send every Sunday, the recurring reminder you have been pasting by hand. That is the work that actually compounds, and it is the work most likely to get you flagged if you fire it all in one burst. The answer is to pace it. Instead of sending 2,000 messages in five minutes, you schedule a recurring broadcast that spreads across the day at a human rhythm. If that is your situation, the practical move is simple: [connect the WhatsApp number you already use and schedule a recurring broadcast](https://blueticks.co/signup) that sends on a safe daily pace instead of all at once. Set the [recurring broadcast](https://blueticks.co/blog/schedule-recurring-whatsapp-messages) up once and let it repeat, keep every contact, and keep the pacing sane. Consent is still yours to earn, and sensible timing is still yours to keep, but the mechanical part, the part you were doing by hand at 11pm, sends itself. [image: Business owner standing by a large window in a minimal room, phone face-down at their side, looking out calmly] ## FAQ **Is there a WhatsApp broadcast message limit per day?** Not a single universal one. The free WhatsApp Business app enforces a soft, unpublished anti-spam ceiling; the Meta Cloud API sets an explicit tier from 250 to unlimited business-initiated conversations per rolling 24 hours; the own-number path has no Meta quota and is governed by ordinary anti-spam behavior. Your path sets your number. **Is the "35 messages per day" WhatsApp limit real?** No. The "35" figure is folklore. Meta does not publish it in any WhatsApp or Business Platform documentation. The app limits by sending behavior and reputation, not a fixed count of 35. **How many contacts can a WhatsApp broadcast reach?** A broadcast list holds up to [256 recipients](https://faq.whatsapp.com/653415899610349), and a recipient only receives it if they have saved your number. That is a list-size cap, separate from any daily send limit. To go beyond 256, see the [more-than-256-contacts guide](https://blueticks.co/blog/whatsapp-broadcast-more-than-256-contacts). **What is the WhatsApp broadcast message limit per month?** There is no separate published monthly quota. On the API your monthly capacity is just your daily tier multiplied out; on the app there is no fixed monthly number. The daily rolling window is the constraint that binds first. **Does sending more messages get my number banned?** Volume alone usually does not. Sending to people who did not opt in, triggering blocks and spam reports, and blasting from a cold number are what put a number at risk. Consent and steady pacing are the real protection, and no path can guarantee a no-ban outcome. --- # How to Send Automatic Birthday Messages on WhatsApp in 2026 (Set Once, Sends Every Year) > WhatsApp has no built-in birthday automation. Here's how to set up an automatic birthday message once and have it send from your own number every year. URL: https://blueticks.co/blog/automatic-whatsapp-birthday-messages Published: 2026-08-26 Author: Daniel Roth Category: productivity You remember your best client's birthday every year. You just remember it three days late, when the moment has passed and a message reads as an afterthought. Or you set a phone alarm, snooze it in a meeting, and forget again. The greeting takes ten seconds to write. Remembering to write it on the exact day, every year, is the part that keeps failing. An automatic birthday message on WhatsApp closes that gap. You write the greeting once, attach the contact and their date, and set it to repeat every year. Then you stop thinking about it. This guide covers whether WhatsApp can do this on its own, how to set it up on your own number, and how to run a whole birthday list without typing each one. ## Can WhatsApp send an automatic birthday message on its own? No. WhatsApp has no native birthday automation and no "repeat yearly" option anywhere in the app. The Business app's [greeting messages](https://faq.whatsapp.com/604590423442323/) and [away messages](https://faq.whatsapp.com/2565868990219715/) only auto-reply to an incoming message. Neither one sends a birthday greeting to a contact on their date. A third-party scheduler adds that. The distinction matters because it is easy to mistake WhatsApp Business auto-replies for a scheduler. A greeting message fires when a customer writes to you for the first time. An away message replies when someone contacts you outside your hours. Both are reactive, both go to whoever messaged you, and neither has a recipient field or a calendar. You cannot compose "Happy birthday, Sara" today and have it go out to Sara on the 14th. That is the native gap in one line: WhatsApp answers messages, it does not originate scheduled ones. For the full breakdown of what the app can and cannot schedule natively, see the [complete guide to scheduling WhatsApp messages](https://blueticks.co/blog/schedule-whatsapp-messages) and whether [WhatsApp has a send-later option](https://blueticks.co/blog/whatsapp-send-later) at all. This piece is the birthday-specific job on top of it. ## Why is a birthday message a recurring job, not a one-off send? A birthday lands on the same date every single year. So the durable setup is not one greeting you fire this week and forget. It is a rule you define once that regenerates on that date annually, for as many years as the person is in your contacts. Treat it as a one-off and you are back here next August, retyping the same message. [image: An open blank notebook and a face-down phone on a desk, planning a recurring WhatsApp birthday list] > "The birthday I always missed was my biggest account's. I set it once to repeat yearly, and now it just goes out from my number while I'm asleep." (synthetic operator note, reflecting a common power-user setup) This mental model separates a real automatic birthday message from a manual chore. A one-off send fires once and disappears. A recurring birthday message on WhatsApp is a pattern: the same greeting, the same recipient, the same date, repeating without you. Set the cadence to yearly and the tool re-queues the next send after each one goes out. The cadence mechanics themselves, daily, weekly, monthly, yearly, are covered in [how to schedule recurring WhatsApp messages](https://blueticks.co/blog/schedule-recurring-whatsapp-messages). The only cadence that matters for birthdays is yearly, anchored to a date. The point here is the framing: you are building a standing rule, not sending a card. Do that and the "I forgot again" problem is gone for good, not just this year. ## How do you set up an automatic birthday message on WhatsApp Web? To schedule a birthday message on WhatsApp, you add a scheduling layer to your own account over WhatsApp Web or a hosted gateway, write the greeting, pick the contact, set the date to their birthday, and choose a yearly repeat. It sends from your own number on the day, every year. This runs on your linked account, not Meta's Cloud API, so there are no templates to get approved. Here is the exact workflow: 1. **Link your account.** Open WhatsApp Web, or link a hosted gateway to your number by scanning the QR code. This is your own account as a linked device, not a separate bot. 2. **Open the contact.** Pick the person whose birthday you want to automate. 3. **Write the greeting once.** Type it the way you would live. No "sent via" footer gets added; the recipient sees an ordinary message from you. 4. **Set the date and time.** Choose their birthday as the send date and a time to land (mid-morning reads better than midnight). 5. **Choose a yearly repeat.** Switch the schedule from one-time to recurring and set the interval to yearly. The rule now regenerates every year on that date. 6. **Save.** The message sits in your queue with a `pending` status until its moment, then sends on its own. Yearly is a real repeat interval, sitting alongside daily, weekly, and monthly, so a birthday rule genuinely fires again 12 months later without a second setup. **What breaks:** on the basic browser-sending setup, WhatsApp Web has to be open and the computer awake at send time. Close the tab or sleep the laptop the morning of the 14th, and the birthday send is skipped silently, no error. That is the single most common way an automatic birthday message quietly fails. The fix is a hosted gateway that holds the queue off your machine, covered below. If you only want a nudge to yourself, that is a different tool, a [WhatsApp birthday reminder](https://blueticks.co/blog/send-whatsapp-reminder-messages) you act on manually. ## How do you automate birthdays for a whole contact list at once? You set up a birthday list in one pass instead of one contact at a time. Each row is a person, their number, their birthday date, and the greeting. You import the list, map each contact to their own date, set the whole batch to repeat yearly, and every birthday on it now fires on its own day. One setup covers the entire client roster. This is where the recurring framing pays off at scale. Fifty clients means fifty birthdays scattered across the year, and entering them one by one is the chore you are trying to kill. A spreadsheet of names, numbers, and dates, imported once, becomes fifty standing yearly rules in a single operation. The parsing details, the CSV and Excel column mapping, the phone-number formatting traps, are all in [how to bulk-schedule WhatsApp messages from a spreadsheet](https://blueticks.co/blog/bulk-schedule-whatsapp-messages-from-spreadsheet). A birthday list is just that same import with a date column that happens to be a birthday. One honest caveat before you scale it: a list of genuine contacts who know you is low-risk. The moment "birthday list" becomes a euphemism for a cold blast to hundreds of strangers, you have left birthday automation and entered broadcast territory, which carries real deliverability risk on a personal number. More on that line at the end. ## How do you personalise each birthday greeting without writing them one by one? You use merge fields. Instead of writing fifty separate greetings, you write one template with a placeholder for the first name, and the scheduler fills in each contact's name at send time. "Happy birthday, \{name\}!" becomes "Happy birthday, Sara!" for Sara and "Happy birthday, Ben!" for Ben, from a single line you wrote once. [image: A small wrapped gift and a face-down phone on a table, the personal side of automatic birthday wishes on WhatsApp] For a birthday greeting, a little personalisation is the difference between a message that reads as human and one that reads as a mailshot. A few birthday-specific things worth doing: - **First name via a merge field.** One template, correct name every time. This is what lets a single greeting serve the whole list. - **Timing on the day.** Pick a send time that suits the relationship. A client greeting at 9am reads as thoughtful; a 2am send reads as a bot. - **Keep it short and specific.** "Happy birthday, \{name\}, hope Cape Town treats you well today" beats a paragraph. Personal beats polished. The tone rule for birthdays is simpler than for reminders: warmth, not information. You are not confirming an appointment or chasing a payment, so drop the logistics. If your real need is a dated nudge cadence, the templates for that live in [how to send a reminder message on WhatsApp](https://blueticks.co/blog/send-whatsapp-reminder-messages). Birthdays are the warm end of the same engine. ## Will automatic birthday messages send when your phone or laptop is off? It depends on where the queue lives. A browser-based send needs the WhatsApp Web tab open at the scheduled moment, so a closed laptop means the birthday message never goes out. A hosted gateway holds the queue on a server linked to your account, so your laptop and phone can both be off and the greeting still sends on the day. WhatsApp's own design makes the second case possible. Per [WhatsApp's linked devices page](https://faq.whatsapp.com/378279804439436/), you can link up to four devices and they keep working without your phone staying connected, as long as the phone is not left unused for more than 14 days, after which the linked devices are logged out. That 14-day window is the housekeeping most people forget, and it is what quietly breaks a set-and-forget birthday list months later. The full offline mechanism, including what happens to a queued send when a link drops mid-window, is in [do scheduled WhatsApp messages send when your phone or computer is off](https://blueticks.co/blog/scheduled-whatsapp-messages-phone-computer-off). For birthdays the takeaway is one line: if the greeting has to land on the day whether or not you are at your desk, the queue has to live off your machine. ## Where Blueticks fits for automatic birthdays, and where it doesn't Blueticks runs the birthday job on your own number over WhatsApp Web or a hosted gateway, so the greeting goes out from the number your contacts already know, set once and repeating every year. The queue lives outside your laptop, each contact gets their own date and name via a merge field, and a yearly rule regenerates itself after each send. This is not the Meta Cloud API; there are no template categories or per-conversation fees. [image: A closed laptop on a quiet desk at night while a scheduled WhatsApp birthday message sends on its own] Here is the honest part, because it decides whether this is the right tool for you. If you want to auto-send birthday wishes on WhatsApp to real customers, clients, or contacts who know you, from your own number, this is the shape of the job. If instead you need to broadcast approved-template birthday offers to hundreds of thousands of subscribers at massive scale, a Business Solution Provider on the official Cloud API is the better call, and I would send you there. We are not the only WhatsApp scheduler. Two things no tool changes. **Consent is the sender's responsibility.** WhatsApp's own [Business Messaging Policy](https://business.whatsapp.com/policy) requires opt-in permission from the recipient before you message them, and its [unauthorized-automation guidance](https://faq.whatsapp.com/5957850900902049) is explicit that automated or bulk messaging that harms users is prohibited. Nobody can promise a no-ban outcome, and anyone who guarantees one is selling something. A birthday greeting to a contact who knows you is about the lowest-risk send there is; the same mechanism pointed at strangers is not. If you have been meaning to set this up: **write one birthday greeting now, add a contact's date, and set it to repeat yearly, so it sends from your own number every year without you.** You can [set up your first automatic birthday send here](https://blueticks.co/signup) in under a minute, then close the laptop. If a free-tier limit comes up at all, the current allowance is three concurrent scheduled messages, which is enough to prove the yearly-repeat works before you load the whole list. ## FAQ **Can WhatsApp automatically wish someone happy birthday?** Not on its own. WhatsApp has no native birthday automation. The Business app's greeting and away messages are reactive auto-replies to an incoming message, not proactive scheduled sends. To auto-send birthday wishes on WhatsApp you add a third-party scheduler that links to your own account, holds the greeting in a queue, and sends it on the date you set. **Can I send automatic birthday messages to a whole list at once?** Yes. Import a birthday list where each row is a contact, their number, and their date, map each person to their own birthday, and set the batch to repeat yearly. Every birthday on the list then fires on its own day from one setup, with a merge field filling in each contact's name. **Do automatic birthday messages repeat every year?** Yes, if you set the cadence to yearly. A birthday send is a recurring rule anchored to a date, not a one-off. Once it is set to a yearly repeat, the scheduler regenerates the next send automatically after each one goes out, so you set it up once and it fires every year. **Will sending automated birthday messages get my number banned?** There is no guaranteed no-ban outcome, ever. Consent is the sender's responsibility. WhatsApp's [Business Messaging Policy](https://business.whatsapp.com/policy) requires recipient opt-in, and it prohibits [unauthorized bulk or automated messaging](https://faq.whatsapp.com/5957850900902049). A birthday greeting to contacts who know you is low-risk; the same automation pointed at cold, unconsented lists at scale is what draws bans. **Is there a free way to schedule birthday messages on WhatsApp?** Yes, within limits. You can schedule a birthday message on WhatsApp Web from your own number without the Cloud API. If a free-tier cap applies, the current allowance is three concurrent scheduled messages, enough to set up and test a yearly birthday rule before you automate a longer list. --- # When to Use the WhatsApp Business API in 2026: The Signals That Say It's Time (and the Third Path If Neither Fits) > The honest threshold guide: when you actually cross from the free WhatsApp Business app to the Meta Cloud API, and what to do when neither path fits. URL: https://blueticks.co/blog/when-to-use-whatsapp-business-api Published: 2026-08-26 Author: Avi Kohen Category: industry Most people asking when to use the WhatsApp Business API are not actually at the API line yet. They have hit a wall in the free app, heard the API is the fix, and skipped the question that decides everything: what volume and what use case actually justify Meta's approval, verification, and per-message billing? Cross too early and you pay for machinery you will not fill. Stay too long and manual sending eats your day. This is the threshold, pinned to Meta's own docs, plus the third path most comparison guides leave out. ## When should you move from the WhatsApp Business app to the API? You should move to the WhatsApp Business API when you hit programmatic volume, need real chatbot or conditional automation, need many agents working one number, or need a CRM to trigger sends. Below that, you likely need neither at full strength. There are three paths in 2026: the free WhatsApp Business app, the Meta Cloud API through a provider, and the own-number gateway path that sits on a number you already run. That is the 30-second version. The rest of this article is the honest expansion, because the WhatsApp business API vs app decision has a missing middle that the binary framing hides. The head guide, [WhatsApp Business app vs API](/blog/whatsapp-business-app-vs-api), contrasts what each path *is* in full detail. This piece answers a narrower, harder question: at what point do you actually cross, and what do you do when you are past the app but the API is overkill? One line to fix before we go further, because it is the most common mistake in this category. Blueticks, the tool this site makes, is not the WhatsApp Business API and not the free app. It is the third path: your own number over WhatsApp Web. Keep the three separate in your head and the decision gets clean. ## What are the three WhatsApp sending paths in 2026, and who is each for? There are three ways to send business messages on WhatsApp in 2026. The free WhatsApp Business app is manual, single-number, and reactive. The Meta Cloud API (the WhatsApp Business Platform) is programmatic, template-gated, and billed per message through a provider. The own-number path runs on a number you already use, with no Meta verification and no per-message template fees, traded against WhatsApp Web behavior and no guaranteed protection from bans. Here is the honest three-way map. **1. The free WhatsApp Business app.** Meta's mobile app for one business number. Business profile, catalog, labels, and three reactive automations: greeting, away message, and quick replies. It cannot schedule, cannot run conditional flows, and cannot send true bulk campaigns. It is built for a solo operator answering DMs. When you outgrow "reactive," you feel it fast. The [WhatsApp Business app limitations](/blog/whatsapp-business-app-limitations) guide walks the seven ceilings you hit, so I will not re-list them here. **2. The Meta Cloud API / WhatsApp Business Platform.** A backend with no chat screen of its own. You send through code or a Business Solution Provider (BSP), register message templates for Meta's review, complete Meta business verification, and pay per delivered template message. Built for high volume, chatbots, multi-agent inboxes, and CRM integration. **3. The own-number / hosted-gateway path.** You link a number you already run over WhatsApp Web and automate it: schedule sends, run recurring reminders, message a list. No Meta business verification, no per-message template fees, and you keep your existing contacts and chat history. The trade is real: you inherit WhatsApp Web semantics, you send under your own discipline, and no tool on this path can promise you will never be restricted. Be fair about the third path: Blueticks is not the only own-number tool. Several vendors sit here, and the [WhatsApp Business API alternatives](/blog/whatsapp-business-api-alternatives) guide names them and what each is best for. The point of this section is the *shape* of the three paths, not a vendor pick. [image: Three smartphones face down beside a closed laptop representing the three WhatsApp sending paths] ## Which signals mean you've outgrown the WhatsApp Business app? You have outgrown the WhatsApp Business app when messages need to fire without a human tapping send, when several people must work one number at once, or when another system should trigger the message. Four signals mark the line: system-triggered notification volume, conditional automation or a chatbot, multiple agents on one number, and CRM or helpdesk integration. Any one of these is a real upgrade trigger. Run yourself through the four honestly. - **System-triggered volume.** Order confirmations, shipping updates, appointment reminders, OTP codes generated by software, not typed by a person, at hundreds-to-thousands per month. - **Conditional automation or a chatbot.** "If they ask about price, send the price list" or a bot that answers at 2am. The app's greeting and away messages are single static replies with no logic. - **Multi-agent on one number.** A queue routed across a team. The app is a single-operator tool with a handful of linked companion devices, not a contact center. - **CRM or helpdesk integration.** WhatsApp events flowing into HubSpot, Salesforce, or Zendesk, and messages pushed back out from those systems. If you answer yes to these, you are genuinely past the app. But "past the app" does not automatically mean "on the API," which is the distinction the next two sections draw. When people ask when do I need WhatsApp Business API, this list is the honest first filter, and it is deliberately about the work, not the size of the company. For the full readiness test before you apply, the [do I need the WhatsApp Business API](/blog/do-i-need-whatsapp-business-api) checklist covers it, and the [app limitations](/blog/whatsapp-business-app-limitations) piece maps each ceiling to an upgrade path. I am summarizing the triggers here, not reproducing either. ## At what volume or use case does the Meta Cloud API become the right call? The Meta Cloud API becomes the right call when you send approved-template broadcasts at real scale, need a verified official business badge, run a genuine multi-agent inbox, or wire tight CRM automation. It is billed per message, so the economics work when volume is high and mostly transactional. Below that, its approval, verification, and per-message costs are overhead you will not recoup. This is the core of knowing when to use WhatsApp Business API: not a feature wishlist, but the volume and use case that clear the cost. This is where the Cloud API genuinely wins, and it is worth being precise about why, with Meta's own docs as the source. **Templates and approval.** Per Meta's [message template guidelines](https://developers.facebook.com/docs/whatsapp/message-templates/guidelines), template messages are the only type you can send to a user outside an open customer service window, and every template must be categorized as authentication, marketing, or utility and approved before you can send it. Reviews typically resolve within about 24 hours. You cannot type a fresh promo and blast it; it goes through approval first. **Business verification.** The Platform expects a verified Meta business behind the account. Per Meta's [Official Business Account documentation](https://developers.facebook.com/documentation/business-messaging/whatsapp/official-business-accounts/), the verified badge and official-account status sit on top of Meta Business verification, which means submitting company documents through Meta Business Manager. That is a days-to-weeks project, not an afternoon. **Per-message pricing.** Meta deprecated conversation-based pricing and moved to per-message billing effective July 1, 2025, per the [WhatsApp Business Platform pricing docs](https://developers.facebook.com/docs/whatsapp/pricing). You now pay for each delivered template message, priced by the recipient's country and category, with service conversations free since November 1, 2024 and utility templates free inside an open 24-hour service window. The category structure matters for the threshold; the exact rate math does not belong here. For that, see [WhatsApp Business API pricing in 2026](/blog/whatsapp-business-api-pricing-2026) and, for the cost-versus-effort verdict, [is the WhatsApp Business API worth it](/blog/is-whatsapp-business-api-worth-it). The clean case for the API: a retailer firing thousands of shipping updates before noon, a bank sending authentication codes, a support team routing one number across twenty agents, an e-commerce backend triggering order messages. If that is you, the API is not overkill. It is the only thing that fits. [image: Logistics operations worker in a busy fulfilment area where high-volume WhatsApp Business API notifications would fit] ## What if you're above the app but the API is overkill? The own-number third path If you are past the free app but the API is overkill, the own-number path is built for exactly that gap. You link a WhatsApp number you already run over WhatsApp Web, then schedule sends, run recurring reminders, and message a list, with no Meta business verification, no per-message template fees, and your existing contacts and chat history intact. The trade is WhatsApp Web semantics, disciplined sending, and no guaranteed protection from bans. This is the missing middle. The binary "app or API" framing pushes a clinic that just wants Tuesday's reminders to go out toward the heavy machinery of the Platform, when the actual job is small: "send this Tuesday at 9," "follow up with non-responders in three days," "message my 150-person list." None of that needs programmatic infrastructure or template approval. It needs a scheduling and automation layer on the number you already use. What you keep on this path is what the API makes you give up: your own recognizable number, your saved contacts, and a real two-way chat history. What you take on is responsibility. WhatsApp Web behavior is the ceiling, sensible pacing is on you, and there is no vendor on this path, Blueticks included, that can promise you will never be restricted. **Consent is the sender's responsibility.** The mechanics of collecting and documenting opt-in are a topic of their own; the [WhatsApp opt-in compliance requirements](/blog/whatsapp-opt-in-compliance-requirements) guide covers the how, and Meta's own [opt-in documentation](https://developers.facebook.com/documentation/business-messaging/whatsapp/getting-opt-in) states plainly that businesses are required to obtain opt-in permission before messaging people. Where this path pays off is durable, repeating work, not a single test send. If your real need is a standing set of reminders that go out every week, or an ongoing broadcast to a list you own, that is the shape this path was built for. The [schedule WhatsApp messages](/blog/schedule-whatsapp-messages) guide walks the recurring-send mechanics, so I will not re-teach them here. If you land here, this is the practical move: link the WhatsApp number you already use, schedule your first recurring reminder or broadcast, and keep every contact. No Meta Business verification, no per-message template fees, no separate business number your customers will not recognize. [Start from your own number with Blueticks](https://blueticks.co/signup) and set up the repeating send you have been doing by hand. Consent is the sender's responsibility, and sensible pacing is yours to keep. ## How do you choose between the three? A threshold checklist You choose by matching who authors the message to the path. A system generating thousands of notifications points to the Cloud API. A person who would happily type each message but has no time to points to the own-number path. A solo operator answering incoming DMs stays on the free app. The table below maps common situations to the path that fits, so the decision is a lookup, not a guess. | Your situation | Recommended path | |---|---| | Solo operator answering incoming DMs, no scheduling need | Free WhatsApp Business app | | Thousands of automated order, shipping, or OTP notifications | Meta Cloud API via a BSP | | A real chatbot answering without a human | Meta Cloud API via a BSP | | Many agents sharing one number in a queue | Meta Cloud API via a BSP | | CRM or helpdesk triggering and receiving messages | Meta Cloud API via a BSP | | Recurring reminders and campaigns from your own number, no dev team | Own-number path | | A weekly promo to a saved-customer list, human-scale | Own-number path | | Timed follow-ups to a pipeline you nurture personally | Own-number path | This is a WhatsApp business solution comparison at the level that actually decides the purchase: not "which is more powerful," but "which one matches the work in front of you." The Cloud API wins on scale and programmability and loses on cost and setup friction for anyone who is not operating at scale. The own-number path wins on speed, familiarity, and keeping your number and contacts, and loses when you genuinely need programmatic volume, verified-badge trust, or a multi-agent contact center. For a named-vendor breakdown on the API and own-number sides, the [WhatsApp Business API alternatives](/blog/whatsapp-business-api-alternatives) guide compares specific tools. The cynical-but-accurate note: the API is marketed harder than it is needed, because per-message billing and BSP contracts are where the money is. Deciding which WhatsApp business solution is right for you starts with refusing to buy scale you do not have. [image: Solo business operator holding a phone at a shop counter, the own-number path for recurring WhatsApp reminders] ## Where does Blueticks fit, and where does it not? Blueticks fits the own-number path: it runs on the WhatsApp number you already use, adds scheduling, recurring reminders, and list campaigns, and skips Meta business verification and per-message template fees. It does not fit when you need programmatic notification volume, a verified official-business badge, a chatbot, or a multi-agent contact center. Those are Cloud API jobs, and for them the API is the right call, not Blueticks. The example that shows the fit is the durable, repeating job, not a one-off. A clinic that sends the same appointment reminders every week. A shop that runs a standing offer to its saved-customer list each month. A consultant nurturing a pipeline with timed follow-ups. In each case a human would be comfortable authoring the message but does not have time to send it by hand, and the work repeats. That is the own-number path's home turf. The mechanics of setting up those recurring sends and ongoing broadcasts live in the [schedule WhatsApp messages](/blog/schedule-whatsapp-messages) and [WhatsApp campaign management](/blog/whatsapp-campaign-management) guides, not here. Where Blueticks is the wrong tool, I will say so directly. If a system, not a person, should be firing the message, and it needs to happen thousands of times a day with delivery guarantees and CRM triggers, that is exactly when to use WhatsApp Business API, and no own-number tool is a substitute. Blueticks is also not the only option on its own path; other own-number tools exist, and the honest comparison is in the [alternatives](/blog/whatsapp-business-api-alternatives) guide. What the own-number path does not offer, from any vendor, is a guarantee against restriction. WhatsApp Web semantics and sensible pacing are the deal, and consent is the sender's responsibility. ## FAQ **When do I actually need the WhatsApp Business API?** You need the WhatsApp Business API when messages must fire programmatically at volume (thousands of automated order, shipping, or OTP notifications), when you run a genuine chatbot, when many agents share one number, or when a CRM triggers sends. Meta's per-message pricing and business verification make sense at that scale. Below it, the app or an own-number tool fits better. **Is the WhatsApp Business app enough for a small business?** For a solo or micro business answering incoming messages, yes. The free app covers a business profile, catalog, and reactive greeting, away, and quick-reply automations. It stops being enough the moment you need to schedule outbound messages, send true bulk campaigns, run conditional automation, or put several agents on one number. That is the upgrade trigger, not headcount. **Can I send bulk or recurring WhatsApp messages without the API?** Yes, at human scale. An own-number tool that runs on WhatsApp Web can schedule recurring reminders and send list campaigns from a number you already use, with no template approval or per-message Meta fees. For fully automated, million-message notification streams, the Cloud API is still the right tool. This is the WhatsApp business API vs app trade-off in one line: reach versus programmatic scale. **Will sending from my own number get me banned?** No tool can guarantee it will not. Sending from your own number over WhatsApp Web inherits WhatsApp's normal enforcement: high volume, misleading content, or ignoring blocks can lead to restrictions or bans. Sensible pacing and genuine opt-in are your protection. Consent is the sender's responsibility, and Meta requires businesses to obtain opt-in before messaging people. **Which WhatsApp business solution is right for me?** Match the path to who authors the message. A system generating high-volume notifications points to the Meta Cloud API. A person authoring human-scale messages that repeat points to the own-number path. A solo operator answering DMs stays on the free app. That single question, not raw feature counts, is the fastest way to decide which WhatsApp business solution fits. --- # How to Send WhatsApp Messages from Java on Your Own Number (2026) > One POST from the JDK, no build tool needed. Then the parts that bite Java: the plus sign in the path, the request that blocks a thread forever, and a retry that sends twice. URL: https://blueticks.co/blog/whatsapp-api-java Published: 2026-08-25 Author: Daniel Roth Category: productivity Your Spring service already knows the invoice is overdue, the build broke, the shipment moved. Getting that fact into WhatsApp is where it stalls, usually behind a Business Solution Provider contract nobody wants to sign for a handful of notifications a day. Here is the plain version. A whatsapp api java integration is one authenticated `POST` to a REST endpoint, sending from the WhatsApp number you already own, linked as a device over WhatsApp Web or a managed 24/7 gateway. It is not [Meta's Cloud API](https://developers.facebook.com/docs/whatsapp/cloud-api), so there are no templates, no Business verification, and no per-message billing anywhere below. Consent stays yours, and nobody can promise a number will never be actioned. ## What do you need before Java can send a WhatsApp message? Three things: a JDK 11 or newer, a WhatsApp number already linked to your Blueticks account, and a `bt_live_` API key. The recipient goes in the URL path as an E.164 number like `+15551234567`, not in the JSON body. That one detail causes most first-attempt failures in a java whatsapp api setup. The pre-flight, in order: 1. **Mint a key.** Open [dev.blueticks.co](https://dev.blueticks.co), sign in, create a key, copy it once. Keys are bearer tokens, so they belong in an environment variable or your secrets manager, never checked into a repo. The [own-number REST API guide](/blog/whatsapp-rest-api-own-number) covers the auth model in depth. 2. **Link a number.** Blueticks drives your number, not a Meta-provisioned one. Already connected a phone in the app? You are done. 3. **Check your JDK.** The whole guide runs on the standard library from Java 11 up, because `java.net.http.HttpClient` [ships in the JDK since Java 11](https://docs.oracle.com/en/java/javase/21/docs/api/java.net.http/java/net/http/HttpClient.html). No Maven, no Gradle, no third-party HTTP client required for the first send. Now the trap. The endpoint is `POST /v1/scheduled-messages/{chatId}` on `https://api.blueticks.co`, and `{chatId}` is a path segment. A recipient is an [E.164 number](https://www.itu.int/rec/T-REC-E.164) with a leading `+`, and a bare `+` in a path is ambiguous, so it has to be percent-encoded as `%2B`. You can also target a chat id directly, such as `1234567890@g.us` for a group. ## How do you send your first WhatsApp message from Java with no dependencies? Encode the `+` to `%2B`, set an `Authorization: Bearer` header, and `POST` a flat JSON body of `{"type":"text","text":"..."}` with the built-in `HttpClient`. Omit `sendAt` and it goes immediately. This is the send whatsapp message java baseline, and it needs nothing outside the JDK. ```java import java.net.URI; import java.net.http.HttpClient; import java.net.http.HttpRequest; import java.net.http.HttpResponse; import java.time.Duration; String apiKey = System.getenv("BLUETICKS_API_KEY"); // bt_live_YOUR_KEY_HERE String chatId = "+15551234567"; // The ONLY reserved character in an E.164 number is the leading '+'. // Encode just that to %2B; do NOT reach for URLEncoder here (see below). String segment = chatId.replace("+", "%2B"); // -> %2B15551234567 URI uri = URI.create("https://api.blueticks.co/v1/scheduled-messages/" + segment); String json = """ {"type":"text","text":"Your invoice #4471 is due tomorrow."}"""; HttpClient client = HttpClient.newBuilder() .connectTimeout(Duration.ofSeconds(5)) // connection phase only .build(); HttpRequest request = HttpRequest.newBuilder(uri) .timeout(Duration.ofSeconds(20)) // whole request/response .header("Authorization", "Bearer " + apiKey) .header("Content-Type", "application/json") .header("Idempotency-Key", "invoice-4471-reminder") .POST(HttpRequest.BodyPublishers.ofString(json)) .build(); HttpResponse response = client.send(request, HttpResponse.BodyHandlers.ofString()); System.out.println(response.statusCode() + " " + response.body()); ``` Three things about that body. `type` is required and validation-only, so a bare `{"text":"hi"}` is rejected. Text tops out at 4,096 characters. A `2xx` that returns a resource is wrapped in `{"success":true,"data":{...}}`, so the id lives at `data.id`, never at the top level. The [language-agnostic API walkthrough](/blog/send-whatsapp-message-from-api) shows the same call in shell, Python and Node, and the [PHP version is here](/blog/whatsapp-api-php). Now the Java-specific footgun in that snippet. The obvious move for the path is [`URLEncoder.encode()`](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/net/URLEncoder.html), and it *looks* right: it turns `+` into `%2B`, so your E.164 send works and you never notice. But `URLEncoder` implements `application/x-www-form-urlencoded`, the form/query encoder, and its own docs state "the space character is converted into a plus sign `+`." That is correct for a query string and wrong for a path segment. The day a chat id carries a space, or you feed it a value shaped differently from a bare phone number, `URLEncoder` ships a `+` where the server expected `%20` and the send resolves to the wrong recipient. Encode the one reserved character yourself, as above, or use a real URI builder (OkHttp's `HttpUrl` and Spring's `UriComponentsBuilder` both encode path segments correctly, shown next). The other one: `HttpClient.send()` throws on a real network failure. A thrown `IOException` means no HTTP response ever arrived, a different situation from a `4xx` or `5xx` status, and the error table below turns on exactly that distinction. ## Should you use OkHttp or Spring's RestClient instead? Use the raw JDK client when you want zero dependencies. Reach for [OkHttp](https://github.com/square/okhttp) when you want connection pooling and an interceptor chain, and [Spring's `RestClient`](https://docs.spring.io/spring-framework/reference/integration/rest-clients.html) when you are already inside a Spring app. All three java send whatsapp message paths hit the identical endpoint. The choice that actually matters is timeouts. The JDK `HttpClient` has a sharp default. Its request javadoc is explicit: "the effect of not setting a timeout is the same as setting an infinite Duration, i.e. block forever" ([HttpRequest.Builder](https://docs.oracle.com/en/java/javase/21/docs/api/java.net.http/java/net/http/HttpRequest.Builder.html)). Set `connectTimeout` on the client and `timeout` on the request, both, every time. A thread blocked forever on a socket is how one slow dependency drains a pool, the Java analogue of a queue worker parked on an open connection. OkHttp gives you separate connect, read and write timeouts and encodes the path for you: ```java import okhttp3.*; OkHttpClient client = new OkHttpClient.Builder() .connectTimeout(Duration.ofSeconds(5)) .readTimeout(Duration.ofSeconds(20)) .build(); HttpUrl url = new HttpUrl.Builder() .scheme("https").host("api.blueticks.co") .addPathSegment("v1").addPathSegment("scheduled-messages") .addPathSegment("+15551234567") // encoded correctly as a segment .build(); RequestBody body = RequestBody.create( "{\"type\":\"text\",\"text\":\"Your table is ready.\"}", MediaType.get("application/json")); Request request = new Request.Builder() .url(url) .header("Authorization", "Bearer " + System.getenv("BLUETICKS_API_KEY")) .header("Idempotency-Key", "booking-8812-ready") .post(body) .build(); try (Response response = client.newCall(request).execute()) { System.out.println(response.code() + " " + response.body().string()); } ``` Note `addPathSegment("+15551234567")` handles the `+` for you, which is the whole reason a URI builder beats string concatenation for a whatsapp business api java client. In a Spring app, `RestClient` does the same with `UriComponentsBuilder`, and you inject the key from configuration rather than reading `System.getenv` inline. Whichever client you pick, the request shape and the response envelope are identical. ## How do you parse the response without a brittle model? Read from the `data` wrapper, and model only the fields you use, defensively. A successful send returns `{"success":true,"data":{...}}` with `id`, `status` and `waMessageKey` under `data`. Two things bite a Java client: `data` can be absent on a `2xx` that has nothing to return, and `waMessageKey` is an object, not a String. With [Jackson](https://github.com/FasterXML/jackson-databind), annotate the DTO with `@JsonIgnoreProperties(ignoreUnknown = true)` so an added field never throws, and type `waMessageKey` as an object that is null until dispatch: ```java import com.fasterxml.jackson.annotation.JsonIgnoreProperties; import com.fasterxml.jackson.databind.ObjectMapper; @JsonIgnoreProperties(ignoreUnknown = true) record Envelope(boolean success, Data data) {} @JsonIgnoreProperties(ignoreUnknown = true) record Data(String id, String status, WaMessageKey waMessageKey) {} @JsonIgnoreProperties(ignoreUnknown = true) record WaMessageKey(boolean fromMe, String remote, String id, String _serialized) {} ObjectMapper mapper = new ObjectMapper(); Envelope env = mapper.readValue(response.body(), Envelope.class); if (env.data() == null) { // 2xx with no payload — nothing to read, do not dereference data. return; } String messageId = env.data().id(); // 24-char hex queue id ``` Modelling `waMessageKey` as a `String` is the mistake that surfaces in production, not in tests: it is `null` on the response to a scheduled send because the engine has not dispatched yet, so your test passes and the field quietly fills in later as an object. Treat it as nullable and read `id` as your handle meanwhile. ## How do you schedule a message for later and get sendAt right in Java? Add a `sendAt` field holding an [RFC 3339](https://www.rfc-editor.org/rfc/rfc3339) timestamp with an explicit offset. Build it with `OffsetDateTime` or `ZonedDateTime` bound to a named zone, then format with `DateTimeFormatter.ISO_OFFSET_DATE_TIME`. The accepted window is roughly 10 seconds to 365 days ahead. Anything outside that is rejected at validation. ```java import java.time.ZonedDateTime; import java.time.ZoneId; import java.time.format.DateTimeFormatter; String sendAt = ZonedDateTime .of(2026, 9, 1, 9, 0, 0, 0, ZoneId.of("Asia/Jerusalem")) .format(DateTimeFormatter.ISO_OFFSET_DATE_TIME); // 2026-09-01T09:00:00+03:00 String json = """ {"type":"text","text":"Reminder","sendAt":"%s"}""".formatted(sendAt); ``` The Java-specific way this goes wrong is the system-default zone. `LocalDateTime` carries no offset, and `ZoneId.systemDefault()` reads the [host's default](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/time/ZoneId.html): your laptop is `+03:00`, the container runs `UTC`, and the same code schedules two different moments depending on where it executes. Always name the zone explicitly with `ZoneId.of(...)`. A second one: compute `sendAt`, sit in a queue for nine seconds, and dispatch arrives already inside the floor with `400 sendAt must be at least 10 seconds in the future`. Compute it at send time or leave a minute of headroom. Recurring cadences and the production hardening around timezones are a separate mechanism, covered in the [Python scheduling guide](/blog/whatsapp-api-python-schedule). Do not rebuild that here. ## How do you send from Spring Boot without blocking the request? Never call the API inline in a controller. Hand the send to an async worker or a queue, bind the key through configuration, and let the worker own retries with a stable `Idempotency-Key` derived from the business object so a retry never double-sends. That last part is the whole game for a whatsapp api integration java that survives contact with real traffic. ```java @Service class WhatsAppSender { private final HttpClient client = HttpClient.newBuilder() .connectTimeout(Duration.ofSeconds(5)).build(); @Value("${blueticks.api-key}") // bound from config, not a literal private String apiKey; @Async @Retryable(retryFor = IOException.class, maxAttempts = 4, backoff = @Backoff(delay = 10_000, multiplier = 3)) public void send(String chatId, String text, String idempotencyKey) throws IOException, InterruptedException { String segment = chatId.replace("+", "%2B"); HttpRequest request = HttpRequest.newBuilder( URI.create("https://api.blueticks.co/v1/scheduled-messages/" + segment)) .timeout(Duration.ofSeconds(20)) .header("Authorization", "Bearer " + apiKey) .header("Content-Type", "application/json") .header("Idempotency-Key", idempotencyKey) // SAME key on every retry .POST(HttpRequest.BodyPublishers.ofString( "{\"type\":\"text\",\"text\":\"" + text + "\"}")) .build(); HttpResponse res = client.send(request, HttpResponse.BodyHandlers.ofString()); if (res.statusCode() == 429 || res.statusCode() >= 500) { throw new IOException("retryable: " + res.statusCode()); // let @Retryable back off } } } ``` The idempotency key is a method argument on purpose: derive it once from the order, ticket or reminder (`order-4471-shipped`) at dispatch, so all four attempts carry the identical value. Compute it inside the method from `Instant.now()` and every retry becomes a fresh message. Whether you use [Spring Retry](https://docs.spring.io/spring-framework/reference/) as shown or [Resilience4j](https://resilience4j.readme.io/), the rule is the same: retry only `IOException`, `429` and `5xx`, never a `400`, and always with the stable key. > **Ready to wire this into your app?** [Get a `bt_live_` key](https://blueticks.co/signup) and drop the queued Spring service above into your app. Your own number, your own contacts, no Meta Business verification and no per-message template fees. Point it at a live number and watch the first send land in seconds. [image: Server rack status lights at night behind the queued Spring Boot WhatsApp worker] Event-triggered sends, the ones fired from a webhook or a domain event rather than a schedule, belong to the [event automation guide](/blog/whatsapp-automation-api). This section is only the non-blocking mechanics: hand off, retry with a stable key, done. ## What errors does a Java client hit, and what should it do with each? Four HTTP statuses carry the decisions, and below them sit the non-HTTP failures a Java client actually hits: a thrown `IOException` with no status at all, and a JVM trust-store surprise. The rule that runs through all of it: an HTTP status means the server answered and told you something specific; a thrown exception means no response ever arrived. | Status | Meaning | What your client should do | | --- | --- | --- | | `400` | Body or `sendAt` failed validation | Fix, never retry. Read `error.message` | | `409` | Same `Idempotency-Key`, different body | Bug in your key derivation | | `429` | Rate limited | Back off, retry with the same key | | `5xx` | Server side | Retry with backoff and the same key | Two limits shape that. The free plan allows **5 requests per 6-hour slot**, shared across the REST and MCP surfaces, so a loop testing ten sends hits `429` on the sixth within a second; any subscription removes the ceiling. And `Idempotency-Key` is capped at 64 characters and scoped per workspace: reuse it with an identical body and the original response replays, returning the same message id, so detect a replay by the id, not the status. A `409` means you reused a key with a *different* body, which is a bug in how you derive the key. **An `IOException` is not a `5xx`.** `HttpClient.send()` throws `HttpTimeoutException` (a subclass of `IOException`) when the response misses your `timeout`, and `HttpConnectTimeoutException` when the connection phase misses `connectTimeout`. Both mean no response ever existed, so you cannot know whether the request landed, which is exactly why the stable idempotency key makes the retry safe. Code that only branches on `statusCode()` treats a timeout as an unhandled crash. **`PKIX path building failed`.** On a locked-down or older JVM the first HTTPS call can throw `sun.security.validator.ValidatorException: PKIX path building failed`, which reads like an API outage and is not. It is the JVM's trust store missing the CA that signed the endpoint's certificate. The fix is to update the JDK or import the CA into the `cacerts` trust store with `keytool`. Do not disable TLS verification, which turns a config problem into a security hole. ## How do you confirm the message actually arrived? Not from the `2xx`. Take the `id` from `data.id` and `GET /v1/scheduled-messages/{id}`, then read the status ladder: `pending`, `confirmed`, `received`, `read`, `played`, or `failed`. A create response only means the queue accepted the message. The ladder in one line each: - `pending` - accepted and waiting to dispatch - `confirmed` - WhatsApp itself took the message - `received` - delivered, the double grey tick - `read` - opened, the double blue tick - `played` - a voice note was played - `failed` - carries a `failureReason` The field to watch is `waMessageKey`. It is `null` on the response to a scheduled send and fills in as an object once the engine dispatches, which is why `confirmed` and a non-null `waMessageKey` arrive together. Your handle in the meantime is the 24-character hex `id`: you can `GET` it, `PATCH` it before dispatch, or `DELETE` it to cancel. Polling is fine for one message and stops being fine at volume. Past that, register a webhook and receive status changes instead. Registration, payload verification and duplicate handling all live in the [delivery-status webhooks guide](/blog/whatsapp-api-delivery-status-webhooks), deliberately not repeated here. [image: A paper checklist beside a face-down phone on a wooden table, confirming WhatsApp message delivery] ## Where Blueticks fits for a Java team, and where a BSP is the better call A hosted REST engine fits JVM shops for one structural reason: the maintained WhatsApp Web clients are Node projects. Running your own from Java means supervising a second runtime, a Node process and a browser profile, next to your JVM app forever. For approved template broadcast at scale or a multi-agent shared inbox, a Business Solution Provider is genuinely the better product. We are not the only WhatsApp API on your own number, and this is where the honest trade sits. That is the argument for a whatsapp business api java integration specifically. Whatsapp-web.js and Baileys are both Node, so "build it yourself" from Java means a session store, a reconnect supervisor and a pager rotation for something that is not your product. The [Node bot guide](/blog/whatsapp-bot-nodejs) shows what that maintenance looks like. Where a BSP wins is not close. Approved marketing templates to 50,000 people, an Official Business Account badge, ten agents on one inbox: that is what the [Cloud API and its partners](https://developers.facebook.com/docs/whatsapp/cloud-api) are built for. Our [read on when the Business API is worth it](/blog/is-whatsapp-business-api-worth-it) says the same. The trade is the number itself: one registered on the Cloud API stops behaving like a normal WhatsApp number. The middle ground is the common Java case. Transactional volume, real conversations, replies that go to a human, a number your customers already have saved. One honest warning, because a queue makes it easy to get wrong: fan 500 jobs onto your executor and you fire 500 sends as fast as the pool drains. That burst is the pattern that gets numbers flagged, whatever sent it, and [WhatsApp's policy on automated and bulk messaging](https://faq.whatsapp.com/5957850900902049) applies either way. Throttle the executor, spread a batch over hours, and remember that consent is the sender's responsibility. Nobody can guarantee a number will never be actioned. ## FAQ **Can I send a WhatsApp message from Java without Maven or a build tool?** Yes. The `HttpClient` example above needs nothing beyond the JDK, because `java.net.http` [ships in the standard library from Java 11 onward](https://docs.oracle.com/en/java/javase/21/docs/api/java.net.http/java/net/http/HttpClient.html). Maven or Gradle only matter if you want OkHttp, Jackson or Spring, and none of them adds capability, only ergonomics. **Which Java HTTP client should I use for the WhatsApp API?** The built-in `HttpClient` for zero dependencies, [OkHttp](https://github.com/square/okhttp) for connection pooling and interceptors, or Spring's `RestClient` when you are already in a Spring app. All three call the identical endpoint. Whichever you pick, set both a connect timeout and a request timeout, because the JDK client [blocks forever by default](https://docs.oracle.com/en/java/javase/21/docs/api/java.net.http/java/net/http/HttpRequest.Builder.html). **How do I stop a Java retry from sending the same WhatsApp message twice?** Send an `Idempotency-Key` header, derived once from the business object (`order-4471-shipped`) and passed into the worker so every retry reuses it. A replay returns the original response and the same message id instead of sending again. Compute the key from `Instant.now()` inside the retry and each attempt becomes a fresh message. **Why does my sendAt schedule the message at the wrong time?** Almost always the system-default zone. `LocalDateTime` has no offset and [`ZoneId.systemDefault()`](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/time/ZoneId.html) reads the host, so the same code schedules differently on a laptop versus a UTC container. Build the timestamp with `ZonedDateTime` bound to an explicit `ZoneId.of(...)` and format with `DateTimeFormatter.ISO_OFFSET_DATE_TIME`. **Will sending from Java get my WhatsApp number banned?** Nobody can guarantee it will not. You are messaging from your own number under [WhatsApp's Business Policy](https://www.whatsapp.com/legal/business-policy) and its [rules on automated and bulk messaging](https://faq.whatsapp.com/5957850900902049), and a loop firing unsolicited sends is the pattern most likely to get a number flagged. Message people who asked to hear from you, spread batches over hours, and stop when someone asks you to. Consent is the sender's responsibility. --- # WhatsApp MCP Tools in 2026: What an AI Agent Can and Can't Do on Your Number > The nine WhatsApp MCP tools an AI agent can call, a capability-and-limits table for each, which AI clients work today, and why none of it runs without a live session. URL: https://blueticks.co/blog/whatsapp-mcp-tools Published: 2026-08-24 Author: Daniel Roth Category: productivity You have read that an AI agent can run WhatsApp for you. Before you wire it into your morning, you want the boring truth: which actions it can take, and where each one dead-ends. This is that list, a reference and not a pitch, and half of it is the limits. Every tool below is real and verified against production, and so is every place it stops. ## What are the WhatsApp MCP tools an AI agent can actually call? Nine. An AI agent connected to a WhatsApp MCP server on Blueticks can call nine tools by name: audiences, campaigns, chats, contacts, engine, groups, scheduled_messages, utils, and webhooks. You describe an outcome in plain language and the agent picks the tool. The whole set, one line each: - **chats** - read, search, and reply inside conversations - **scheduled_messages** - send now or schedule for later - **contacts** - list contacts, fetch a profile picture - **groups** - create and manage WhatsApp groups - **audiences** - reusable contact lists for sending - **campaigns** - paced bulk delivery you can pause - **webhooks** - get an HTTPS callback on events - **engine** - check, reload, or log out the session - **utils** - validate numbers, preview links, tell the time That is the complete whatsapp mcp tool list. New to the protocol layer? The [WhatsApp and MCP primer](https://blueticks.co/blog/whatsapp-mcp) covers what MCP is and how a client discovers tools; this page assumes that and gives you the surface. And a connector that only reads and replies is [only half the loop](https://blueticks.co/blog/control-whatsapp-with-ai-beyond-chat-connector); these nine tools are the half that acts. ## Is it nine tools or ten? (and why both numbers are in circulation) Nine. The codebase declares ten canonical tool names, but only nine are ever published to a client, so nine is what an agent actually sees. A name can exist in the source before it is exposed on the connector, which is why a count from the code and a count from a live session differ by one. The practical version: what matters is not how many names live in a file, it is how many tools show up when your agent asks the server what it can call. That answer is nine, and it is nine for every client. Claude and ChatGPT are served the same nine, not a bigger menu for one. Seeing "ten" in one place and "nine" in another is just the source tree versus the exposed surface, and the exposed surface is the one you use. ## What can each tool do, and where does each one stop? Each tool is a small cluster of actions with a hard edge. The table below is the reference: what the tool does in plain outcomes, and where it stops. Read the right-hand column as carefully as the left. The limits decide whether these whatsapp mcp server tools fit your job. [image: Two neat side-by-side stacks of blank cards evoking each WhatsApp MCP tool's capability and its limit] | Tool | What it can do | Where it stops | |---|---|---| | **chats** | Look up chats, search them, read message history, load older history, pull media, list participants, and mark a thread read. | Reads only what your own linked session has synced. It cannot recover messages the session never received, and marking read acts on your side, not the recipient's. | | **scheduled_messages** | Send a message now, schedule one for later, list scheduled items, edit or cancel one, and check its delivery ack. | A scheduled send needs a live session at fire time, not at schedule time. The read ack is best-effort and often absent (see the next section). | | **contacts** | List your WhatsApp contacts and fetch a contact's profile picture. | It reads your existing contacts. It will not enrich a contact with a CRM record, and it cannot conjure a stranger who was never in your list. | | **groups** | Get a group's details (optionally with its members inline), create a new group, and update an existing one. | No leave-or-delete action on this surface, and every membership change still obeys WhatsApp's own group rules and limits. | | **audiences** | Build and reuse contact lists as send targets: create, get, update, delete a list, and append, update, or remove contacts in it. | It is a list container, not a consent ledger. It does not record who agreed to hear from you and will not screen out people who blocked you. | | **campaigns** | Schedule an audience for paced bulk delivery, then pause, resume, or cancel the run. | Pacing is not permission. There is no template approval and no guaranteed inbox placement, and slow delivery does not make cold bulk sending safe. | | **webhooks** | Subscribe to WhatsApp events over an HTTPS callback: create, list, get, update, and delete subscriptions. | It delivers the events the platform actually emits. An event that never fires (a missing read, below) will not arrive just because you subscribed to it. | | **engine** | Report the WhatsApp session's status, reload it, or log it out. | It inspects and restarts an existing session. It cannot create a session from nothing, and it cannot keep a browser tab you closed alive. | | **utils** | Validate a phone number, generate a link preview, and return the current date and time. | Validation checks format and reachability signals, not whether the person behind the number wants your message. | A few carry more than the name suggests. The **chats** tool alone exposes eight actions, and **scheduled_messages** carries six, including an `ack` action to check delivery after the fact. When people ask about whatsapp ai agent capabilities, this table is the honest answer: nine tools, roughly three dozen actions, and a real edge on each one. ## Which delivery states can you trust, and which are best-effort? Trust queued, sending, and delivered. Treat read as best-effort. A message moves through a lifecycle you can rely on up to delivery, then one final step, the read receipt, that frequently does not fire even when the recipient has plainly read it. Build around the dependable states and never block a workflow on read. Here is the chain in plain terms: - **Queued** - the message is accepted and waiting. Dependable. - **Sending** - it is on its way out from your session. Dependable. - **Delivered** - it reached the recipient's device. Dependable. - **Read** - the recipient opened it. Best-effort, and often missing. The read gap is a known, documented issue on our side, and it is fair to say so flatly. The read event does not always get recorded, so an agent that waits for "read" before its next step can wait forever on a message the person read an hour ago. Design any read-reactive automation to tolerate the signal being absent. And if the recipient turned read receipts off, no event is correct behaviour, not a bug. One thing to keep straight: this surface drives your own WhatsApp account, so the states above are our own lifecycle, not the [WhatsApp Business Platform](https://business.whatsapp.com/products/platform-pricing) Cloud API's sent/delivered/read contract. Do not assume Meta's message-ID semantics or per-message guarantees apply here. Different product, different rules. ## What can no WhatsApp MCP tool do for you? None of these nine tools will get you consent, keep your number safe, or turn your personal account into a business API. These hard edges hold no matter how you phrase the prompt. Knowing them up front saves you a banned number and a bad week. Read these as flatly as they are written: 1. **It will not get you consent.** The tools send what you tell them to send. **Consent is the sender's responsibility.** An agent will happily draft two hundred first-contact messages; whether those people agreed to hear from you is on you, not the tool. 2. **It will not guarantee you are not banned. Ever.** Automating a personal WhatsApp account carries real risk, because [unauthorized automated or bulk messaging violates WhatsApp's Terms of Service](https://faq.whatsapp.com/5957850900902049) and Meta enforces it. Read-and-reply on existing threads is low-risk; cold-blasting strangers is high-risk. Anyone promising a no-ban setup is selling something they cannot deliver. 3. **It does not turn your number into a Cloud API number.** This drives your existing account over WhatsApp Web or a hosted engine, so you inherit none of the Cloud API's machinery: no template categories, no per-message pricing, no business verification, and none of its sanctioned-delivery guarantees. One more thing, plainly: we are not the first WhatsApp MCP. Open-source servers predate us, they are a real option, and the self-hosted-versus-hosted decision already lives in our [hosted vs self-hosted comparison](https://blueticks.co/blog/best-whatsapp-mcp-servers). It owns that argument; this page points you there. ## Which AI client can use these tools today? Claude, as a one-click connector, today. Claude is the only AI client with a live in-product connector for this WhatsApp MCP server right now. ChatGPT can reach the exact same nine tools, but through the manual developer-mode route, not an in-product card. There is no Gemini path. That is the whole client picture. - **Claude** - a [custom connector using remote MCP](https://support.claude.com/en/articles/11175166-get-started-with-custom-connectors-using-remote-mcp) is live in-product. The click-path for connecting your WhatsApp number lives in [how to connect WhatsApp to Claude](https://blueticks.co/blog/connect-whatsapp-to-claude-mcp-integration). Follow it there; I am not reproducing a step of it here. - **ChatGPT** - MCP servers are reached through [developer mode](https://help.openai.com/en/articles/12584461-developer-mode-and-mcp-apps-in-chatgpt), a more manual flow than a connector card. It works, and it gets you the same nine tools. The exact route is in [connect WhatsApp to ChatGPT](https://blueticks.co/blog/connect-whatsapp-to-chatgpt-mcp). The takeaway: the client changes the setup ergonomics, not the capability. So the answer to what can claude do with whatsapp and the answer for ChatGPT are the same nine-tool answer. Pick the client you already live in. ## Which repeating jobs are these tools actually for? The tools earn their keep on work that repeats, not a one-time send. The value shows up when the same job runs every week without you starting it: the Monday follow-up sweep, the standing reminder loop, the triage pass every morning. A single tool call is a party trick. A job that repeats is the reason to connect anything. [image: A laptop and a face-down phone on a morning desk, the choice of AI client for WhatsApp MCP server tools] Think in loops, not one-shots: - **The Monday triage pass.** Every Monday, the agent reads the weekend threads with `chats`, tells you who is still waiting on a reply, and drafts the answers for you to approve. Same job, every week. - **The standing reminder loop.** A recurring nudge that fires on a schedule through `scheduled_messages`, so the invoice chase or the appointment reminder goes out without you remembering it. The route for that is [send WhatsApp reminder messages](https://blueticks.co/blog/send-whatsapp-reminder-messages). - **The weekly recurring send.** The same message to the same audience on a cadence, which is [recurring WhatsApp messages](https://blueticks.co/blog/schedule-recurring-whatsapp-messages) territory, not a one-off blast. I am deliberately not turning this into a recipe book. Concrete prompt recipes for these jobs already live in [how to automate WhatsApp with AI](https://blueticks.co/blog/automate-whatsapp-with-ai). The point is narrower: match the tool to the job that recurs, where a tool list becomes leverage. As one operator who runs a standing Monday triage framed it, the tool list is a menu you can only order from while the kitchen is open. ## What has to be in place before any tool call reaches a phone? A live WhatsApp session. Every one of the nine tools is a menu of errors until a real session is connected to your account. That is the single prerequisite, and it is where most first attempts fall over. The tools are ready. The question is whether there is a session for them to act through. [image: A dark home office at night with a closed laptop, showing why an always-on WhatsApp session matters] Here is the failure mode nobody warns you about. You connect through a browser tab during the day, everything works, then you shut the laptop at 18:00. Your clients message at 21:00. The agent tries to reply and every tool call errors, because the session that lived in that tab closed when the tab did. Nothing is broken. Nothing is connected either. WhatsApp itself caps how you connect: a standard account allows [up to four linked companion devices](https://blog.whatsapp.com/one-whatsapp-account-now-across-multiple-phones) beyond your primary phone, and any session you run counts against that. So the real choice is not whether to connect, it is whether your session survives you closing the laptop. A browser tab does not. An always-on hosted engine does, and that is the honest reason to pay for anything here: it keeps the session up while you sleep, so a 21:00 request actually leaves your number. No developer console, no template queue, no per-message fees, just a session that does not sleep. You now know exactly which nine tools exist and exactly where each one stops. The only open question left is whether there is a live session for your agent to run against, so [put your own number behind an always-on engine](https://blueticks.co/signup) and point the agent at the job that repeats every week, not the one-off you would have done by hand anyway. ## FAQ **What tools does the WhatsApp MCP server have?** It has nine: audiences, campaigns, chats, contacts, engine, groups, scheduled_messages, utils, and webhooks. Together they cover reading and replying in chats, sending and scheduling messages, managing contacts, groups, audiences and campaigns, event webhooks, session control, and utilities like phone validation. **What can Claude do with WhatsApp?** Claude can read and search your chats, draft and send replies from your own number, schedule messages, manage contacts and groups, run paced campaigns, and subscribe to event webhooks. It does all of it by calling the nine tools on your behalf. It cannot get you consent, and it cannot guarantee your number is never banned. **How many WhatsApp MCP tools are there?** Nine are exposed to any client. The codebase declares ten canonical names, but only nine are ever published to the connector, so nine is what an AI agent actually sees when it lists what it can call. Both Claude and ChatGPT are served the same nine tools, with no smaller or larger menu for either. **Can an AI agent read my WhatsApp messages?** Yes, through the chats tool, but only the messages your own linked session has synced. It can search history, load older messages, and pull media from conversations you already have. It cannot recover messages the session never received, and it reads nothing until you connect a live WhatsApp session to your account. **Can ChatGPT use the same WhatsApp tools as Claude?** Yes. ChatGPT reaches the identical nine tools, just through the manual developer-mode route rather than a one-click in-product connector. The capability is the same; only the setup differs. Claude is the only client with a live in-product connector today, and there is no Gemini path. --- # WhatsApp Send Later in 2026: Does WhatsApp Have a Send Later Option? > Short answer: WhatsApp has no send later button. Here is what people mistake for one, and the workflow that puts a message out at the time you picked. URL: https://blueticks.co/blog/whatsapp-send-later Published: 2026-08-22 Author: Daniel Roth Category: productivity You wrote the message at 11pm. It should land at 9am. You hold your thumb over the send button looking for the little clock other apps have, and there is no WhatsApp send later button to find. So you send it now and look like someone who works at midnight, or you set an alarm and hope. ## Does WhatsApp have a send later option? No. WhatsApp has no built-in send later option on iPhone, Android or WhatsApp Web as of August 2026. There is no clock icon and no scheduled-send menu in the app. A timed send needs a third-party scheduler or an operating-system automation. Four things get mistaken for a WhatsApp send later function. None of them is one: - **Greeting message** - auto-reply to a first inbound message. - **Away message** - auto-reply sent outside your business hours. - **Android Assistant or OEM scheduler** - third-party, phone must be awake. - **Mark as unread** - a reminder to yourself, nothing sends. WhatsApp's Help Center documents the automation it does ship: [greeting messages](https://faq.whatsapp.com/604590423442323/) and [away messages](https://faq.whatsapp.com/2565868990219715/) in the Business app, and [events in groups](https://faq.whatsapp.com/3313983622238973/), which schedules a gathering and can carry a call link. There is no page for scheduling a message, because there is no feature. Search it as WhatsApp send later or send later WhatsApp, the answer is the same. One thing changed in 2026, worth knowing before you build a habit around a workaround. WABetaInfo, which tracks WhatsApp betas, [first spotted a scheduled-messages prototype on 1 March 2026](https://wabetainfo.com/whatsapp-is-working-on-a-feature-to-schedule-messages/) and [reported on 11 June 2026](https://wabetainfo.com/whatsapp-is-testing-scheduled-messages-for-chats-and-groups/) that WhatsApp was still refining it. Their summary of the history is blunt: "WhatsApp has never introduced a dedicated tool to schedule messages." In the reported design you tap and hold the send button, and the window runs from 10 minutes ahead to a maximum of two weeks. As of that report the feature "is not available to users yet, and it is not enabled for beta testers at this stage." A native option may arrive. It has not, and a two-week ceiling would not cover a recurring Monday reminder anyway. ## Why aren't WhatsApp Business greeting and away messages a send-later feature? Because they are auto-replies, not scheduled sends. A greeting or away message fires in response to somebody messaging you, on WhatsApp's trigger, addressed to whoever wrote in. You cannot compose a message today, name a recipient and a time, and have it go out. That is a different mechanism entirely. Read the two Help Center pages side by side and the shape is obvious. [Greeting messages](https://faq.whatsapp.com/604590423442323/) answer a customer who opens a conversation. [Away messages](https://faq.whatsapp.com/2565868990219715/) answer one who writes in when you are unavailable. Both are reactive. Both go to whoever contacted you. Neither has a recipient field or a calendar. The practical test: try to use an away message to send a price update to a client on Thursday at 10am. You cannot, unless that client happens to message you first, at which point it is not your message going out on your schedule. It is a canned reply going out on theirs. The Business app is where most people look after the main app disappoints them. It is a good app. It does not do send later. [image: Phone face-down on a cafe table after closing, the moment an auto-reply fires instead of a scheduled send] ## Can you send a WhatsApp message later on iPhone? Not natively. iOS has no WhatsApp send later button in any version of the app. The usual workaround is a Time of Day automation in Apple's Shortcuts app, which fires on a clock but depends on your iPhone being on and available at that exact moment. Apple documents the trigger plainly. You "use an event trigger to run an automation at a specific time of day, when you use an alarm on your phone, or when you do an Apple Watch workout" ([Shortcuts User Guide](https://support.apple.com/guide/shortcuts/event-triggers-apd932ff833f/ios)). Useful, but it is a personal-device trick, not a delivery guarantee, and it does not survive a flat battery or a phone left in a bag. The full iOS walkthrough, including where Shortcuts helps and where it quietly does nothing, is in [how to schedule WhatsApp messages on iPhone](https://blueticks.co/blog/schedule-whatsapp-messages-iphone). This page is here to answer the yes or no. ## Can you send a WhatsApp message later on Android? Also not natively, and there is no WhatsApp send later option hiding in the Android app. Android has more room to improvise, so people reach for Google Assistant, an OEM scheduler baked into their phone's clock or messaging app, or a Tasker-class automation tool. All three are third-party, all three drive WhatsApp from the outside, and all three need the phone awake. That last part is not opinion. Google's own developer documentation says "Doze reduces battery consumption by deferring background CPU and network activity for apps when the device is unused for long periods of time" ([Optimize for Doze and App Standby](https://developer.android.com/training/monitoring-device-state/doze-standby)). A phone face-down on a nightstand at 3am is exactly the device state Doze was written for. An automation scheduled for 3am is exactly the job it defers. Which of these hold up, and which OEM schedulers silently drop a send, is covered in [how to schedule a WhatsApp message on Android](https://blueticks.co/blog/schedule-whatsapp-message-android). ## How do you actually set a WhatsApp message to send later in 2026? Here is how to send a WhatsApp message later in practice. You add a scheduling layer on top of your own WhatsApp account, compose the message now, and pick the date and time. It goes out at that moment from your own number, over WhatsApp Web or a hosted gateway linked to your account. The recipient sees an ordinary message. The whole sequence: 1. Open WhatsApp Web, or link a hosted gateway to your account by scanning a QR code or entering a link code. 2. Open the chat you want the message to land in. 3. Write the message the way you would write it live. 4. Pick the date and time. Check the timezone you are picking in, not your recipient's. 5. Confirm. The message sits in a queue with a `pending` status until its moment. 6. At the scheduled time your linked account sends it. No bot label, no "sent via" footer. Be precise about what a real WhatsApp send later workflow is not. It runs on your own number as a linked device, not on Meta's Cloud API, so there are no message templates to get approved. It is not a shield either: WhatsApp's rules apply exactly as they do when you type by hand. You now know WhatsApp has no send later button, and that every free workaround needs a phone awake at the moment of sending. If the next message on your list has a time attached to it, [set your first one to send later from your own number](https://blueticks.co/signup) and then close the laptop. The queue does not care whether you are at the keyboard. ## What happens if your phone or computer is off when the message is due? It depends entirely on where the queue lives. A browser-based send needs the browser tab open at the scheduled moment, so a closed laptop means nothing goes out. A hosted gateway holds the queue on a server that stays linked to your account, so your laptop and your phone can both be off. WhatsApp's multi-device design makes the second case possible. Per [WhatsApp's linked devices page](https://faq.whatsapp.com/378279804439436/), you can link up to four devices and they keep working without your phone staying connected, though your phone must not go unused for more than 14 days or the linked devices are logged out. That window is the housekeeping people forget. The full breakdown, including what happens to a queued message when a link drops mid-window, is in [do scheduled WhatsApp messages send when your phone or computer is off](https://blueticks.co/blog/scheduled-whatsapp-messages-phone-computer-off). ## Should you send later once, or send later every week? Almost nobody has exactly one timed message. They have a shape: the Monday standup nudge, the invoice reminder on the 1st, the check-in three days after a quote goes out. If you set up send later for a single message and stop, you have solved the smallest version of your problem and you will be back here at 11pm next week. [image: Paper weekly planner with repeating entries, the recurring version of a WhatsApp send later habit] The jobs worth automating are the repeating ones: - **Weekly client check-ins** - same message, same day, different week. - **Monthly invoice reminders** - the 1st, every month, no memory required. - **Recurring team nudges** - standup, timesheets, Friday wrap. - **Renewal and birthday follow-ups** - dated once, fired forever. A recurring rule is a different object from a one-off send. You define the pattern once and it regenerates. There is a safety valve too: a scheduled message can cancel itself if that contact writes to you before it is due, so a nudge does not go out to someone who already replied. Set the pattern up properly in [how to schedule recurring WhatsApp messages](https://blueticks.co/blog/schedule-recurring-whatsapp-messages). If what you are really building is a reminder cadence, the templates and timing are in [how to send a reminder message on WhatsApp](https://blueticks.co/blog/send-whatsapp-reminder-messages). ## What breaks: the failure modes of every send-later method Every WhatsApp send later method fails in its own way, and the ways are predictable. OS automations break when the app they drive changes shape. Browser-based sends break when the tab closes. Recurring rules break on timezones. Knowing which failure you are exposed to is most of the work. | Method | What breaks it | What you see | | --- | --- | --- | | Assistant or OEM scheduler | A WhatsApp app update changes the UI it drives | Silent no-send, no error | | Accessibility-service automation | Screen off, or the phone enters Doze | Fires late or not at all | | iOS Shortcuts | Phone off, locked, or the automation needs a tap | Nothing goes out | | Browser-tab scheduler | Tab closed, laptop asleep, browser updated | Message stays queued | | Any recurring rule | Timezone set wrong, or DST shifts the clock | Lands an hour off, twice a year | | Any method at all | Recipient has never messaged you | Unreliable delivery, reads as cold outreach | Two more things belong on this list. Delivery state is dependable up to a point. Queued, sending and delivered are the states worth building on. Read is not. On our own stack the read event is a documented open bug, recorded internally since 2026-04-24, where the read state often is not persisted even when the recipient clearly read the message. Separately, any recipient can switch read receipts off in [their privacy settings](https://faq.whatsapp.com/195231088335525), and then no read receipt exists for anyone to report. Treat read as best effort and never gate a workflow on it. And the part no tool solves: consent is the sender's responsibility. A scheduled message is still a message from you to a person who either agreed to hear from you or did not. Nobody can promise a no-ban outcome, and anyone who does is selling something. ## What send later can't do on its own, and what Blueticks adds A clock is not the hard part. Every workaround on this page can, on a good day, get one message out at one time. What none of them gives you is a message that goes out at the time you picked whether or not you are at the keyboard, from your own number, on repeat. [image: Closed laptop on an empty desk at night while the scheduled WhatsApp message sends without you] That is the gap Blueticks fills. The queue lives outside your laptop, so the send does not depend on a tab staying open or a phone staying awake. It goes out from the number your contacts already know, as a linked device on your own account. Recurring rules regenerate on their own, and a queued message can stand down if the contact replies first. For the full inventory of methods before you commit, the [complete guide to scheduling WhatsApp messages](https://blueticks.co/blog/schedule-whatsapp-messages) walks through all of them, and [scheduling on WhatsApp Web](https://blueticks.co/blog/schedule-whatsapp-web-messages) covers the browser surface. ## Frequently asked questions **Can you schedule a WhatsApp message to send later?** Not with WhatsApp alone. The app has no scheduling screen on iPhone, Android or WhatsApp Web in 2026. You schedule it with a separate layer that links to your own WhatsApp account, holds the message in a queue, and sends it from your number at the date and time you set. **Does WhatsApp have a send later function?** No. There is no send later function in WhatsApp today. WABetaInfo reported a scheduled-messages prototype in beta builds during 2026, with a 10-minute minimum and a two-week maximum, but as of their 11 June 2026 report it was not available to users and not enabled for beta testers. **Can I send a WhatsApp message later on iPhone?** Not with a native WhatsApp feature. The common iOS route is a Time of Day automation in Apple's Shortcuts app, which depends on your iPhone being on and available at that moment. A scheduler linked to your account is the version that survives a dead battery. Details in our iPhone guide. **How do I send a WhatsApp message later without an app?** Use WhatsApp Web in your browser with a scheduling extension, so there is nothing to install on your phone. That is also the answer to the "send later for WhatsApp Chrome extension" question: see [the Chrome extension guide](https://blueticks.co/blog/whatsapp-scheduler-chrome-extension) for how that surface works. **Can you set a WhatsApp message to send later to a group?** Yes, with a scheduler. A normal group takes a scheduled message the same way it takes a live one. Announcement-only groups and communities behave differently, and one group type will reject the send outright. The list is in [scheduling a message in a WhatsApp group](https://blueticks.co/blog/schedule-whatsapp-group-message). --- # WhatsApp API to Read Messages and Chat History on Your Own Number (Python & Node, 2026) > Meta's Cloud API sends, but it never hands you the conversations you already have. Here is the read path on your own number, endpoint by endpoint, gaps included. URL: https://blueticks.co/blog/whatsapp-api-read-messages-and-chats Published: 2026-08-21 Author: Daniel Roth Category: productivity You have three years of customer conversations sitting in WhatsApp. Every quote you gave, every address a client typed instead of emailing, every "can you do Thursday instead". Your code cannot see one line of it. Every WhatsApp API tutorial on the internet teaches you to send. This one is the return trip: a whatsapp api read messages path, verified endpoint by endpoint against production. ## Can you read your own WhatsApp messages through an API? Yes. Blueticks exposes a REST read path on your own connected number: `GET /v1/chats` lists your conversations, `GET /v1/messages` returns message history, and `GET /v1/search` spans both. Everything comes back as JSON. One boundary governs this whole article, and it is stated once here. This is the account owner reading their **own** WhatsApp, through their **own** connected number. Your chats, your history, your attachments. It is not a way to read anyone else's messages, and there is no third-party mode to ask about. Separate two things that get confused constantly. Inbound webhooks are a **push**: a message arrives, your server gets poked ([that path is here](/blog/whatsapp-api-webhooks-auto-reply)). A read API is a **pull**: you ask for history that already exists, including history from before your integration did. Push cannot give you last March. Pull can. Connecting a number is covered in the [own-number REST API guide](/blog/whatsapp-rest-api-own-number). From here I assume one is connected. ## Why doesn't Meta's Cloud API give you your chat history? Because the Cloud API is a send pipe with an inbound notification stream attached, not a store you can query. Its message reference documents exactly one endpoint, `POST /{Phone-Number-ID}/messages`. There is no `GET`, and nothing in the product returns a conversation you already had. Meta says it plainly in its own platform overview: "the contents of any message sent from a WhatsApp user to your business phone number is communicated via webhook" ([About the WhatsApp Business Platform](https://developers.facebook.com/documentation/business-messaging/whatsapp/about-the-platform)). Communicated, once, at the moment it happens. If your listener was down, or you had not built one yet, that message is gone from your side of the wire forever. The [Cloud API messages reference](https://developers.facebook.com/docs/whatsapp/cloud-api/reference/messages/) confirms the shape of the surface: send only. There is exactly one narrow exception, and it is worth knowing so nobody sells it to you as a chat history API. Meta ships a `history` webhook that fires when a partner onboards a WhatsApp Business app number onto Cloud API and the business agrees to share its chats. It covers "all messages sent or received within 180 days of the time when the business was onboarded", and per Meta's own [history webhook reference](https://developers.facebook.com/documentation/business-messaging/whatsapp/webhooks/reference/history/), "messages that are part of a group chat will not be included" and media asset IDs only arrive for media sent within 14 days of onboarding. One-time, partner-gated, 180 days, no groups, 14 days of media. That is a migration tool, not a read API. To answer "what did this customer say to me in March", the Cloud API has no move. That asymmetry, plus [skipping Meta Business verification entirely](/blog/whatsapp-api-without-meta-verification), is why this article exists. ## What can you actually read from your own connected number? Eleven endpoints across chats, messages, search, media and delivery state. Every one is a `GET` except the batch delivery lookup, all of them run against the number you connected, and all of them return the same envelope, so one client covers the whole surface. - `GET /v1/chats` - lists your conversations, newest first - `GET /v1/chats/{chatId}` - one chat by JID - `GET /v1/chats/{chatId}/participants` - group members with admin standing - `GET /v1/latest-chats` - chats with their recent messages attached - `GET /v1/messages` - message history, one chat or all - `GET /v1/messages/{waMessageKey}` - a single message by key - `GET /v1/search` - contacts and chats matched by name - `GET /v1/messages/media/{waMessageKey}` - the bytes behind an attachment - `GET /v1/messages/pinned/{chatId}` - pinned messages in one chat - `GET /v1/messages/ack/{waMessageKey}` - delivery state of one message - `POST /v1/messages/acks` - delivery state, up to 200 keys at once That is the whole whatsapp api read messages surface. Two shapes to internalise. List endpoints return `{ "success": true, "data": [...], "limit": N, "skip": N, "total": N }`; single-object endpoints return `{ "success": true, "data": {...} }`. Null fields are stripped on the way out, so a field you do not see is absent rather than null. Treat missing as normal. You can point this at your own number today and see real rows come back. [Connect your number and run your first `GET /v1/chats` call](https://blueticks.co/signup): no Meta Business verification, no per-message fees, and the chat history that the Cloud API structurally cannot hand you. Use the number you already message customers from, not a new one, because the history you want is the history that number already has. [image: Hands pulling one index card from a long library catalogue drawer, an analogue chat list lookup] ## How do you list and filter your chats? `GET /v1/chats` returns your conversations newest-first, offset-paginated with `limit` (1 to 200, default 50) and `skip`. Narrow it with `kinds` for contacts, groups or newsletters, `searchToken` for a name substring, `since` for an activity cutoff, and `includeLastMessage` to get a preview without a second call. This is the whatsapp api get chats baseline. In Python: ```python import os, requests BASE = "https://api.blueticks.co" HEADERS = {"Authorization": f"Bearer {os.environ['BLUETICKS_API_KEY']}"} r = requests.get( f"{BASE}/v1/chats", headers=HEADERS, params={ "kinds": "contact,group", # INCLUDE semantics, comma-separated "limit": 100, # 1-200, default 50 "skip": 0, "includeLastMessage": "true", "since": "2026-08-01T00:00:00Z", # ISO 8601, offset allowed }, timeout=30, ) body = r.json() for chat in body["data"]: print(chat["chatId"], chat["chatType"], chat["lastMessageAt"], chat.get("lastMessageText")) print(body["total"], "matched;", "windowed:", body.get("sinceApplied", False)) ``` And in Node, same call, no SDK: ```js const BASE = "https://api.blueticks.co"; const HEADERS = { Authorization: `Bearer ${process.env.BLUETICKS_API_KEY}` }; const qs = new URLSearchParams({ kinds: "contact,group", limit: "100", includeLastMessage: "true", includeArchive: "false", }); const res = await fetch(`${BASE}/v1/chats?${qs}`, { headers: HEADERS }); const { data, total, sinceApplied } = await res.json(); for (const c of data) { console.log(c.chatId, c.chatType, c.unreadCount, c.markedUnread, c.lastMessageText); } ``` Three behaviours that will otherwise cost you an afternoon. Archived chats are excluded unless you pass `includeArchive=true`. Chats with no resolved name are skipped unless you pass `includeWithoutName=true`, which matters a lot if you deal with numbers that were never saved as contacts. And `kinds` beats `filter` when you send both, because `kinds` can express a subset that the single-value `filter` cannot. Each row carries `chatId`, `name`, `chatType` (`contact`, `group` or `newsletter`), `lastMessageAt`, `unreadCount`, and `markedUnread`, the manual dot-badge state, which is deliberately separate from a real unread count. Full field lists are in the [Blueticks API reference](https://dev.blueticks.co/docs/api). ## How do you pull message history from one chat? `GET /v1/messages?chatId=` returns that chat's whatsapp message history, newest-first by default. Flip it with `order=asc`, bound it with `since` and `until`, page it with `limit` (1 to 200) and `skip`, and narrow it with `messageTypes`, `sender`, `hasMedia` or `queryAny`. One endpoint does all of it, so the get whatsapp messages api pattern collapses to a single function in your client. ```python params = { "chatId": "972501234567@c.us", "order": "asc", # oldest-first; default is desc "since": "2026-03-01T00:00:00Z", "until": "2026-04-01T00:00:00Z", "limit": 200, "messageTypes": "chat,image,document", # comma-separated or repeated "loadFromPhoneIfNeeded": "true", } r = requests.get(f"{BASE}/v1/messages", headers=HEADERS, params=params, timeout=60) for m in r.json()["data"]: who = "me" if m["fromMe"] else m.get("senderName") or m.get("author") print(m["timestamp"], who, m["type"], m.get("text", "")) ``` The Node equivalent, walking pages until a short page comes back: ```js async function history(chatId, { pageSize = 200 } = {}) { const out = []; for (let skip = 0; ; skip += pageSize) { const qs = new URLSearchParams({ chatId, order: "asc", limit: String(pageSize), skip: String(skip), }); const res = await fetch(`${BASE}/v1/messages?${qs}`, { headers: HEADERS }); const { data } = await res.json(); out.push(...data); if (data.length < pageSize) return out; // short page = end of the window } } ``` Message rows carry `waMessageKey` (an object, not a string: `fromMe`, `remote`, `id`, `_serialized`, `participant`), `chatId`, `from`, `author`, `senderName`, `timestamp`, `text`, `type`, `fromMe`, `ack`, and, on replies, a `quotedMessage` with the original's key and a preview. `from` mirrors WhatsApp's own semantics and is the **chat** JID, not the sender, so on an outgoing message it points at the recipient. Use `author` when you mean "who sent this". Getting those two backwards is the single most common bug I see in first-pass integrations. `type` is one of `chat`, `image`, `video`, `document`, `audio`, `ptt`, `sticker`, `gif`, `ptv`, `poll_creation`, `location`, `vcard` or `revoked`. System events are excluded by default and only come back if you name them in `messageTypes`. ## How do you search across every chat at once? Two different searches, and picking the wrong one wastes calls. `GET /v1/search` matches **names** across contacts and chats in one shot. `GET /v1/messages` with `chatId` omitted searches **content** across every chat, which is what you want for "find the invoice someone sent me". Name search first, with `types` to restrict the result kinds: ```python r = requests.get(f"{BASE}/v1/search", headers=HEADERS, params={"searchToken": "hadar", "types": "contacts,chats"}, timeout=30) found = r.json()["data"] print(len(found["contacts"]), "contacts,", len(found["chats"]), "chats") ``` Content search is the read whatsapp messages api move that saves you N calls. `queryAny` takes up to 24 terms and matches a message if the body, caption or filename contains **any** of them, so one paged pass covers a whole hunt: ```js const qs = new URLSearchParams({ queryAny: "invoice,receipt,fatura,חשבונית", // OR across up to 24 terms hasMedia: "true", mime: "application/pdf", // prefix match since: "2026-01-01T00:00:00Z", limit: "200", }); const res = await fetch(`${BASE}/v1/messages?${qs}`, { headers: HEADERS }); const { data, total } = await res.json(); console.log(`${total} PDF invoices across every chat`); ``` `mime` is a prefix, so `image/` catches every image type and `application/pdf` catches only PDFs. `filenameContains` and `sender` are case-insensitive substrings. Combine them freely: they compose in a single pass rather than forcing you to filter client-side. If you need a dashboard-style overview instead of a targeted hunt, `GET /v1/latest-chats` returns chats with their recent messages already attached, capped by `numberOfChats` (1 to 200, default 50) and `numberOfMessages` (0 to 100, default 20). One call, not fifty. ## How do you read media and attachments? In two steps. Message rows tell you an attachment exists but never carry the bytes, so first filter for media with `hasMedia=true`, `mime` and `filenameContains`, then fetch each file separately from `GET /v1/messages/media/{waMessageKey}`, passing the message's `chatId` as a query accelerator and reading `mediaUnavailable` before you touch the payload. ```python from urllib.parse import quote import base64 key = msg["waMessageKey"]["_serialized"] r = requests.get( f"{BASE}/v1/messages/media/{quote(key, safe='')}", headers=HEADERS, params={"chatId": msg["chatId"], "maxAttempts": 1}, timeout=60, ) media = r.json()["data"] if media.get("mediaUnavailable"): print("no bytes:", media["mediaUnavailable"]) else: open(media.get("filename", "download.bin"), "wb").write( base64.b64decode(media["dataBase64"]) ) ``` The media object gives you `url`, `mimetype`, `filename`, `dataBase64`, an `originalQuality` flag, and, when the bytes could not be produced, `mediaUnavailable` with one of five reasons: `expired`, `fetching`, `awaiting_sender`, `error` or `no_media`. They are not interchangeable. `fetching` and `awaiting_sender` are worth retrying; `expired` means WhatsApp aged the file out of CDN retention and there is nothing to retry against. `maxAttempts=1` is the fast path that skips the lazy-fetch poll. Leave it off for background archiving where you want the retries; set it to 1 when a user is waiting. ## Which message states can you trust, and which are best-effort? Every message row carries an `ack` integer: `-1` error, `0` pending, `1` server, `2` device, `3` read, `4` played. You can also read one key's state via `GET /v1/messages/ack/{waMessageKey}` or up to 200 keys via `POST /v1/messages/acks`. Trust the first three. Treat `3` as best-effort. I am going to be blunt here because the alternative is you finding out in production. On the outbound side, `queued`, `sending` and `delivered` are verified end to end. **Read state is not.** It is a documented open defect in our own tracker: the read log is written from a real-time ack handler that frequently never observes the read receipt, so a message the recipient clearly read often stays at `2`. Part of that is nobody's bug. If your recipient has read receipts switched off in their privacy settings, WhatsApp never produces the receipt in the first place, so no implementation can produce a `3` for them. The [WhatsApp Help Center on read receipts](https://faq.whatsapp.com/665923838265756/) lists exactly that as a cause in its missing-read-receipts section. Groups run the other way, and the same page is explicit about it: "This won't disable the read receipts for group chats or play receipts for voice messages. There's no way to turn those settings off." So: build alerting on `delivered`. Build reporting on `read` only if a soft undercount is acceptable. The outbound lifecycle in full, event by event, belongs to a different article, and I wrote it: [tracking outbound delivery status with webhooks](/blog/whatsapp-api-delivery-status-webhooks) owns the messages **you send**. This one owns the messages you **read back**. [image: Half-stocked warehouse shelf with the far end empty, illustrating truncated WhatsApp chat history] ## What breaks: pagination, backfill, and history that isn't on the device yet Six things, in roughly the order you will hit them: offset drift, unsynced history, JID validation, windowed `since`, lazy media and inlined payloads. The expensive one is number two, because it does not throw. It returns a clean `200` with a truncated window and no complaint at all. 1. **`skip` drifts under live traffic.** The list is newest-first. A message arriving mid-walk shifts every row down one, so page 3 re-serves a row from page 2. Deduplicate on `waMessageKey._serialized`, or page a fixed window with `since` and `until` instead of raw offsets. 2. **The history is not on the device yet.** The store holds what has been synced, not everything that ever existed. Pass `loadFromPhoneIfNeeded=true` to pull older messages on demand, or call `POST /v1/messages/load_older/{chatId}` with `{"pages": 5, "until_date": "2025-01-01"}`. Pages run 1 to 10 per call and are paced roughly 2.5 seconds apart, so this is slow, not free. Read `historyUnavailable` to tell "the phone has nothing left" from "already fully synced", and check `coverage.oldestLoadedIso` to answer "did I actually reach a year back" instead of assuming. 3. **`chatId` must be a JID.** The shape is `@c.us`, `@s.whatsapp.net`, `@g.us`, `@lid`, `@broadcast` or `@newsletter`. A bare `+14155551234` is a validation error, not a lookup. The suffix is not decorative: `@c.us` and `@g.us` are different addressing spaces. 4. **`since` on the chat list is windowed, not absolute.** It filters a widened fetch rather than querying the whole store, so `total` is the match count inside that window. The response sets `sinceApplied: true` to tell you so. Do not report it as a store-wide figure. 5. **Media resolves lazily.** `hasMedia: true` on a row means an attachment exists, not that bytes are ready. Branch on `mediaUnavailable` every time. 6. **`includeMediaContent=true` is heavy.** It inlines payloads on every row. For anything past a handful of messages, list first and fetch media per key. Paraphrasing an operator from a support thread rather than quoting him verbatim: the read call that scared him was not the one that errored, it was the one that returned eleven months of a fourteen-month relationship and looked completely healthy. Assume truncation. Verify coverage. ## What a raw read endpoint can't do that Blueticks adds A read endpoint hands you rows. What you actually want is a loop: read the conversation, decide something, then act on the same number, and know whether the action landed. Reading is half. The other half is sending, scheduling and delivery visibility on the identical connection. You are not stitching a read vendor to a send vendor and reconciling two identities. The same connected number that answers `GET /v1/chats` also takes `POST /v1/messages/{chatId}` for an immediate send and `POST /v1/scheduled-messages` for a queued one, and emits the outbound lifecycle events to your webhook. The same account is reachable four ways, each with live documentation: the [REST API](https://dev.blueticks.co/docs/api), the [MCP server](https://dev.blueticks.co/docs/mcp) for agent hosts, your own number rather than a rented sender identity, and webhooks for the event stream. There is an act half too, `mark_read`, `archive`, `pin`, `mute`, labels and notes, which turns the read path into real triage. That is an agent-shaped job rather than a REST-tutorial one, and it has its own article: [AI-driven WhatsApp inbox management](/blog/ai-whatsapp-inbox-management). [image: Two adjacent workstations connected by a single cable, the read then act loop on one WhatsApp number] ## Frequently asked questions **Can I read messages from someone else's WhatsApp account with this API?** No. The read path only ever covers the number you connected yourself. It returns your chats and your history on your own account. There is no mechanism for reading a third party's messages, and monitoring another person's account is not a supported use. **Does the WhatsApp Cloud API have a chat history endpoint?** No. Its [messages reference](https://developers.facebook.com/docs/whatsapp/cloud-api/reference/messages/) documents a single `POST` endpoint and no `GET`. The only history Meta exposes is a one-time partner-onboarding `history` webhook covering 180 days, excluding group chats, per [Meta's history webhook reference](https://developers.facebook.com/documentation/business-messaging/whatsapp/webhooks/reference/history/). **How far back does the whatsapp chat history api go?** As far back as the connected device has synced, which is not automatically everything. Use `loadFromPhoneIfNeeded=true` or `POST /v1/messages/load_older/{chatId}` to pull older pages from the phone, then check `coverage.oldestLoadedIso` on the response to confirm the depth you actually reached. **What is the difference between this and an inbound webhook?** An inbound webhook pushes new messages to you as they arrive and cannot show you anything from before you set it up. A read API pulls history that already exists, on demand. Most production systems use both: webhooks for reaction time, `GET /v1/messages` for context and backfill. **Can I search across all my chats in one call?** Yes. Call `GET /v1/messages` without `chatId` and it searches every chat. Add `queryAny` with up to 24 terms for an OR match on body, caption and filename, and combine it with `mime`, `hasMedia`, `sender` or `filenameContains` to narrow the result set in the same pass. --- # Control WhatsApp with AI in 2026: Why a Chat Connector Is Only Half the Loop > A chat connector acts only while you are in the chat. Here are the three pieces that make WhatsApp work at 03:00 when nobody is typing, and the failure that catches everyone. URL: https://blueticks.co/blog/control-whatsapp-with-ai-beyond-chat-connector Published: 2026-08-20 Author: Daniel Roth Category: productivity You connected WhatsApp to Claude or to ChatGPT. It reads your threads, tells you who is still waiting, drafts the reply, sends it from your number. Genuinely good. Then you close the chat and everything stops. That is not a bug and it is not a missing feature. It is what a chat connector is. Every guide on the internet, including ours, ends at the moment the connector starts working. This one starts there. ## What a WhatsApp chat connector actually does A chat connector gives your AI client a set of WhatsApp tools it can call during a conversation. You ask, it calls, it answers. It has no timer, no inbox listener, and no way to act between your messages. Nine tool families, all request and response. - `chats` - read threads, search, send inside a conversation - `scheduled_messages` - send now, or hand a send to the platform for later - `contacts` - look up who is who - `groups` - create, update, leave - `audiences` - reusable recipient lists - `campaigns` - paced bulk delivery with pause, resume, cancel - `webhooks` - register and manage HTTPS callbacks - `engine` - status, logout, reload - `utils` - phone validation, link preview, current date and time If you have not wired one up yet, the click-paths live on their own pages: [connect WhatsApp to ChatGPT](https://blueticks.co/blog/connect-whatsapp-to-chatgpt-mcp) and [connect WhatsApp to Claude](https://blueticks.co/blog/connect-whatsapp-to-claude-mcp-integration). Nothing below repeats those steps. This page assumes the connector already works and asks what you do with the other twenty-three hours of the day. ## Why the connector alone is not running your business with AI Because a connector only fires while you are typing. It cannot start a conversation at 09:00, cannot notice a customer replied at 23:40, and cannot tell you its own WhatsApp session died overnight. Triage and drafting are real value. Autonomy is a different mechanism, and you have to add it. Run the honest test. Ask your assistant to chase an unpaid invoice next Tuesday morning. In a pure chat connector, one of two things happens: the model tells you it will remind you (it will not, the session ends), or it calls `scheduled_messages` and hands the job to a platform that runs without it. The second one is the whole point, and almost nobody explains that the handoff is what did the work. Here is the split, laid out plainly: | Job | Chat connector alone | Needs the rest of the toolkit | |---|---|---| | "Who is waiting on me?" | Yes | - | | "Draft a reply to Dana" | Yes | - | | "Send this Tuesday at 09:00" | Creates it only | Platform fires it | | "React when a customer replies" | No | Inbound webhook | | "Tell me the send actually left" | No | Delivery webhook | | "Be reachable at 03:00" | No | Always-on engine | A [chief-of-staff style assistant](https://blueticks.co/blog/ai-whatsapp-assistant-chief-of-staff) is the first column done well. The second column is a different build, and it is where "control WhatsApp with AI" stops being a demo. ## The three pieces that close the loop Three, and they are independent of which chatbot you use. A scheduled send fires work forward in time. A webhook lets inbound events wake your code. A live engine makes both real at the moment they are due. Miss the third and the first two silently do nothing. 1. **Fire later** - `POST /v1/scheduled-messages/{chatId}` with a `sendAt`. 2. **React to inbound** - `POST /v1/webhooks` with the events you care about. 3. **Stay online** - an engine that is connected at fire time, not at schedule time. All three sit on the same REST surface your connector is already talking to, authenticated with `Authorization: Bearer bt_live_...` ([auth reference](https://dev.blueticks.co/docs/authentication)). That matters more than it sounds: the connector and your code are two clients of one platform, not two competing integrations. The [agent-native argument](https://blueticks.co/blog/whatsapp-agent-native) is exactly this, that the API and the MCP surface should be the same surface. ## Piece 1: schedule the send so it fires without you A scheduled send moves execution off your machine and onto the platform. You create it now, from a chat or from code, and the platform owns delivery from there. The window is wide: `sendAt` must be at least 10 seconds and at most 365 days in the future, RFC 3339. [image: A plain glass hourglass with sand mid-fall standing on a wooden windowsill in morning light] ```bash curl -X POST "https://api.blueticks.co/v1/scheduled-messages/+15551234567" \ -H "Authorization: Bearer $BLUETICKS_API_KEY" \ -H "Content-Type: application/json" \ -H "Idempotency-Key: invoice-4471-chase-1" \ -d '{ "type": "text", "text": "Morning Ilan, following up on invoice 4471.", "sendAt": "2026-08-25T09:00:00+03:00" }' ``` Three details that save you a bad week: - **The recipient goes in the path, not the body.** A phone number in E.164, or a chat id like `1234567890@g.us`. Posting to bare `/v1/scheduled-messages` returns `410 Gone`. - **`Idempotency-Key` is the retry control.** Max 64 characters, scoped to your workspace. Replay the same key with the same body and you get `200` and the original response instead of a second message. Same key with a different body returns `409 Conflict`. Without it, one network timeout plus one retry equals one customer receiving your invoice chase twice. - **`text` is 1 to 4096 characters** and a link preview card is attached automatically when the body contains a URL. Full variants for media and polls are in the [sending reference](https://dev.blueticks.co/docs/messages). The no-code version of this is one sentence to your assistant, covered in [scheduling WhatsApp messages from Claude](https://blueticks.co/blog/schedule-whatsapp-messages-from-claude-mcp). The production version, with timezone and retry discipline, is in [scheduling from Python](https://blueticks.co/blog/whatsapp-api-python-schedule). Both land on the same endpoint. The connector is a creation surface. The platform is the execution surface. Keep those two words separate in your head and most of the confusion about what AI can "do" on WhatsApp goes away. ## Piece 2: let inbound events wake your code A webhook is the inbound half. You register an HTTPS URL, the platform POSTs to it when something happens, and your code runs without anyone being in a chat. The `events` array on `POST /v1/webhooks` accepts 27 type strings today. Two of them matter on day one. [image: A small white motion sensor and a porch light mounted on a plain brick wall at dusk] ```bash curl -X POST "https://api.blueticks.co/v1/webhooks" \ -H "Authorization: Bearer $BLUETICKS_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "url": "https://hooks.example.com/whatsapp", "events": ["new_message_received_webhook", "message.delivered"], "description": "inbound + delivery" }' ``` **One naming trap.** The inbound event is `new_message_received_webhook`. If you copy an `events` example from an older spec snapshot you may see `message.received` instead. That string is not in the accepted enum and the request will be rejected. Use the long name. The two directions already have their own pages and I am not going to rewrite them here. Receiving inbound messages and answering them, with working Flask and Express handlers, is in [WhatsApp webhooks and auto-reply](https://blueticks.co/blog/whatsapp-api-webhooks-auto-reply). Tracking what happened to a message you sent is in [delivery status webhooks](https://blueticks.co/blog/whatsapp-api-delivery-status-webhooks), published the day before this one, and it is the natural companion to this section. What is worth repeating, because people build on it and get burned: - **`message.delivered` does not mean the recipient received it.** It fires from an internal `confirmed` state, meaning the send is visible in WhatsApp's own state. It is not the second grey tick and you should not render it as one. - **Do not build on read receipts.** `message.read` exists in the enum, but it rarely fires in practice. The events verified end to end today are `message.queued`, `message.sending` and `message.delivered`. Three of five. Treat the other two as best effort. - **The delivery lifecycle covers API-originated messages only.** A message you type on your phone emits nothing. ## Piece 3: keep an engine online for the moment the work is due This is the piece that decides whether any of the above is real. Your number is driven by an engine, either a browser session or a hosted always-on gateway. A scheduled send needs that engine connected **at fire time**, not at schedule time. It is the single most common failure in this entire stack. [image: A steady blue pilot flame burning inside a dark metal gas burner housing] Picture the sequence, because it is completely undramatic. Tuesday 16:00, you tell your assistant to chase the invoice Friday at 09:00. The scheduled message is created, the API returns cleanly, everyone is happy. Thursday 18:00 you shut the laptop for a long weekend. Friday 09:00 arrives and there is nothing on your side holding a WhatsApp session. Nothing errored on Tuesday. Nothing warned you Thursday. Check it before you rely on it, with one call: ```bash curl "https://api.blueticks.co/v1/engines" \ -H "Authorization: Bearer $BLUETICKS_API_KEY" ``` You get an array. Empty means no engine is paired, and that is a normal `200`, not an error. A populated entry carries `connected`, plus `state` and `stream` for the underlying WhatsApp connection. Your assistant can ask the same question through the `engine` tool's `status` action, in plain language: "is my WhatsApp engine connected?" Make that the first thing you check when something did not send, before you touch the connector config. When no engine is online, a send does not queue politely and hope. The API answers `503` with `No WhatsApp engine is connected for this account`, which your connector surfaces as the tool failing. Blunt, but at least it is honest ([error reference](https://dev.blueticks.co/docs/errors)). The two ways to be connected behave completely differently: | | Browser session | Hosted always-on gateway | |---|---|---| | Where it runs | Your browser tab | Managed infrastructure | | Laptop closed | Session ends | Keeps running | | 03:00 scheduled send | Nothing fires | Fires | | Good for | Desk hours | Everything you are not present for | Either way it is your own number, linked by QR scan, and WhatsApp caps a standard account at [four linked devices](https://faq.whatsapp.com/378279804439436) with each session counting against that. The longer version of this problem is in [scheduled messages with your phone and computer off](https://blueticks.co/blog/scheduled-whatsapp-messages-phone-computer-off). > **Your AI is awake at 03:00. Is your WhatsApp?** No Meta developer console, no template approval queue, no per-message fees. Put your own number on an always-on engine so the sends you scheduled actually leave. [Start free.](https://blueticks.co/signup) ## Wiring the whole loop from one Claude Code session For developers the fastest path is not a settings screen. Add the remote server to Claude Code, authorise it, then let the same session write the unattended half against the same API. Five steps, one terminal, and the result outlives the session. [image: A thick natural fibre rope coiled into a closed loop on weathered wooden decking] 1. **Add the server.** Claude Code's documented form for a remote HTTP MCP server is `claude mcp add --transport http `, per [the Claude Code MCP reference](https://code.claude.com/docs/en/mcp): ```bash claude mcp add --transport http blueticks https://api.blueticks.co/mcp ``` The `/mcp` path is not decoration. The bare host is not an MCP endpoint. Streamable HTTP is the current transport, [introduced in protocol revision 2025-03-26](https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http) to replace HTTP with SSE. 2. **Authorise it.** Run `/mcp` inside a session to complete the OAuth flow. Claude Code supports OAuth 2.0 for remote HTTP servers, and from v2.1.186 you can also run `claude mcp login ` straight from your shell. 3. **Verify the prerequisite before anything else.** "Is my WhatsApp engine connected?" If that answer is no, stop. Everything downstream fails for one reason and you will spend an hour blaming the connector. 4. **Mint an API key for the unattended half.** The connector authenticates as you, in a session. Your cron job, your queue worker and your webhook receiver cannot. They need a `bt_live_` key with the scopes they actually use, `messages:write` and `webhooks:write` being the usual pair. Get started at the [API quickstart](https://dev.blueticks.co/docs/quickstart), and the own-number model is explained in [WhatsApp REST API on your own number](https://blueticks.co/blog/whatsapp-rest-api-own-number). 5. **Let the session write the receiver.** This is where a coding agent earns its keep. It has the webhook schema in front of it from step 1, so ask it for the handler, the signature check and the idempotent write, then run it somewhere that is not your laptop. The division of labour at the end looks like this. The connector is your interactive surface: read, triage, draft, approve, schedule. The API key is your unattended surface: fire, react, retry, log. Same platform, same number, two clients, and neither one depends on which chatbot you happen to prefer. ## Where the two connectors stand right now Functionally the two clients reach the same nine tool families, so neither can do something to your WhatsApp the other cannot. The difference is how you get in. Claude connects through a remote connector today. ChatGPT connects through developer mode, and developer mode is not guaranteed to be present on your account. OpenAI's own wording, in the [connect-and-test guide](https://developers.openai.com/plugins/deploy/connect-chatgpt), is worth quoting exactly because people keep inventing plan tiers around it: > "Developer mode availability can depend on account and workspace policy." There is no listed WhatsApp app you install from a directory today. You add the server yourself. On a work account an admin can switch developer mode off entirely, which makes it a conversation with them rather than a setting you can win, so check before you plan an evening around it. If you want the comparison of hosted and self-hosted MCP servers rather than of chat clients, that is [the roundup](https://blueticks.co/blog/best-whatsapp-mcp-servers), not this page. The part that actually matters for this article: **none of the three loop pieces depend on the connector.** Scheduled sends, webhooks and engine status are REST endpoints. A cron job hitting them does not know or care whether you also talk to the same platform from Claude, from ChatGPT, or from neither. Pick the chat client on ergonomics. Build the loop once. ## What breaks, and how you find out Five failure modes, in the order they show up in real use. Four of the five are silent, which is the reason to instrument the loop rather than trust it. - **No engine at fire time.** The most common by a distance. Symptom: a scheduled send that never arrives and no error you ever saw. Detection: poll `GET /v1/engines` before you rely on a send, and move overnight work to an always-on engine. - **A duplicate send after a retry.** Symptom: a customer gets the same chase twice. Cause: a timeout on the send call, a retry, and no `Idempotency-Key`. Set one per logical send, not per HTTP attempt. - **Treating `message.delivered` as "they read it".** Symptom: your dashboard says delivered, your customer says they never got it. It certifies WhatsApp state, not a handset. - **A webhook receiver that 500s quietly.** Symptom: the loop works for a week then goes dead. Return `200` fast, do the work asynchronously, and log every event id you accept so you can tell a redelivery from a new event. - **Assuming session memory.** Symptom: you told the assistant "chase Ilan on Friday", it agreed, nothing happened. Nothing persisted, because a chat turn is not a scheduler. If it did not create a scheduled message or a row in your own system, it does not exist. One more that is not technical. Automating a personal WhatsApp account carries real risk, because [unauthorised automated or bulk messaging violates WhatsApp's Terms of Service](https://faq.whatsapp.com/5957850900902049) and WhatsApp enforces it. Replying inside conversations you were already having sits at the low end. Cold outreach at volume sits at the high end. Nobody selling you a connector can promise your number is safe, and anyone who does is selling something they cannot deliver. ## Frequently asked questions **Can ChatGPT or Claude send WhatsApp messages while I am asleep?** Not by themselves. A chat connector only acts during a conversation. To have something happen while you are asleep, the AI has to hand the job to a platform that runs without it, either as a scheduled message with a `sendAt`, or as a webhook that wakes your own code. The platform then needs a connected engine at that moment. **What is the difference between the MCP connector and the REST API?** They are two clients of the same platform. The connector is interactive and authenticates as you inside a chat session. The REST API uses a `bt_live_` key with scopes and runs unattended from cron jobs, queue workers and webhook receivers. Same number, same account, same nine tool families behind the scenes. **Why did my scheduled WhatsApp message not send?** In most cases no engine was connected when it came due. A scheduled send needs a live WhatsApp session at fire time, not at schedule time, so a browser tab you closed on Thursday cannot send on Friday. Check `GET /v1/engines`, or ask your assistant "is my WhatsApp engine connected?" **Which webhook events can I actually rely on?** `message.queued`, `message.sending` and `message.delivered` for outbound, and `new_message_received_webhook` for inbound. `message.read` is in the enum but rarely fires today, so do not build logic that waits for it. And `message.delivered` certifies WhatsApp state rather than a handset, so it is not the same thing as two grey ticks. **Do I need Claude Code specifically, or does the terminal matter?** Not at all. The loop is REST. Claude Code is convenient because `claude mcp add --transport http` plus `/mcp` gets you connected in under a minute and the same session can write your webhook receiver, but a cron job in any language hitting the same endpoints gives you an identical result. --- # How to Track WhatsApp Message Delivery Status with Webhooks (Outbound Lifecycle, 2026) > A WhatsApp webhook closes the loop your send call leaves open: the outbound lifecycle event by event, honest reliability notes, and receiver code in Python and Node. URL: https://blueticks.co/blog/whatsapp-api-delivery-status-webhooks Published: 2026-08-19 Author: Daniel Roth Category: productivity Your script fires a send. The call returns `201`, your log line says "sent", and then nothing ever happens again. Whether that message reached WhatsApp in 400 milliseconds, sat behind a reconnecting engine for nine minutes, or failed outright, your code has no idea. Sending is a push. Knowing is a pull nobody wrote. Here is the return path. ## How do you know a WhatsApp message actually arrived? You register a webhook. A WhatsApp webhook is an HTTPS URL you own that the platform POSTs to every time an outbound message of yours changes state. Instead of asking the API "any news?" on a loop, the change arrives at your server as it happens, tagged with the message it belongs to. The Blueticks outbound lifecycle is five events: - `message.queued` - accepted by the API, not yet dispatched - `message.sending` - engine has handed it to WhatsApp - `message.delivered` - confirmed present in WhatsApp's state - `message.read` - read receipt observed (best effort, see below) - `message.failed` - the send failed or was cancelled One scoping rule matters before you build anything: **these events fire for API-originated messages only.** A message you type on your phone, or schedule from the Blueticks dashboard, emits nothing. The lifecycle belongs to messages your code created. The other direction, inbound messages landing on your server and getting an auto-reply, is a separate pipeline I covered in [receiving inbound WhatsApp messages and auto-replying](https://blueticks.co/blog/whatsapp-api-webhooks-auto-reply). This article is strictly the outbound half. ## The outbound delivery lifecycle, event by event Each of the five WhatsApp webhook events marks one public transition, so you never get two events for the same step. The envelope is identical every time: an event id, a type, a timestamp, and a `data` object carrying the message record. | Event | Fires when | What you can do with it | | --- | --- | --- | | `message.queued` | The API accepts your send and writes the first lifecycle row | Record the handle, start a timeout clock | | `message.sending` | The engine has dispatched the message toward WhatsApp | Distinguish "our fault" from "WhatsApp's turn" | | `message.delivered` | The message is confirmed in WhatsApp's own state | Mark the step complete, trigger the next action | | `message.read` | A read receipt is observed for the message | Nice to have. Never gate a workflow on it | | `message.failed` | The send failed or was cancelled | Branch: retry, fall back to email, alert a human | A raw delivery event looks like this: ```json { "id": "evt_8fk2m1p0q7z3x9c4v6b2n5h1", "type": "message.delivered", "created_at": "2026-08-19T09:14:22.417Z", "data": { "id": "66c1f0a9e4b0a2d7c8901234", "to": "+15551234567", "type": "text", "text": "Your order shipped.", "waMessageKey": null, "status": "confirmed", "confirmedAt": "2026-08-19T09:14:22.104Z", "failureReason": null, "secret": "order-4471-shipped" } } ``` Two things there will save you an afternoon. `data.id` is the same handle the send call returned, so that is your correlation key. And **branch on the top-level `type`, not on `data.status`**: the status field is a coarser projection that reads `confirmed` for both `message.sending` and `message.delivered`. The envelope type is the precise signal. [image: Close-up of a network patch panel with amber and green link lights, some lit and most dark] ## Registering a webhook for delivery events Registering a WhatsApp API delivery status webhook takes one POST. You supply an HTTPS URL of up to 2048 characters, at least one event name, and an optional description. Back comes a webhook id, the event list, an enabled status and a timestamp. Four steps, start to finish: 1. **Stand up a receiver** at a public HTTPS URL that returns a 2xx quickly. Anything else counts as a failure. 2. **Register it** against the events you want. Subscribing to all five and filtering in code costs you nothing. 3. **Send one message** through `POST /v1/scheduled-messages/{chatId}` with no `sendAt`, which dispatches immediately and creates the lifecycle row the events hang off. 4. **Watch for `message.queued` first.** If it never arrives, the problem is registration, not delivery. ```bash curl -X POST "https://api.blueticks.co/v1/webhooks" \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $BLUETICKS_API_KEY" \ -d '{ "url": "https://example.com/hooks/whatsapp-delivery", "events": [ "message.queued", "message.sending", "message.delivered", "message.read", "message.failed" ], "description": "Delivery lifecycle stream" }' ``` The `GET`, `PATCH` and `DELETE` shapes on `/v1/webhooks/{id}` are in the [live Blueticks API reference](https://dev.blueticks.co/docs/api), which renders straight from the running spec. **What breaks:** a 4xx from your endpoint is treated as permanent and is never retried. If your receiver returns `422` because an unexpected field showed up, that event is gone. Only `408`, `425`, `429`, 5xx, timeouts and connection errors are retried, up to 8 attempts with backoff of 1 minute, 5 minutes, 15 minutes, 1 hour, 2 hours, 6 hours and 12 hours, roughly a 21-hour window, each attempt capped at a 10-second timeout. After 8 consecutive deliveries exhaust their retries the webhook is disabled and you have to re-enable it. For contrast, [Meta's Cloud API retries](https://developers.facebook.com/docs/whatsapp/cloud-api/guides/set-up-webhooks) "with decreasing frequency until the request succeeds, for up to 7 days". Different platform, different contract. ## What each event certifies, and what it does not The WhatsApp message delivered webhook is the event everyone wants and the one most likely to be misread. `message.delivered` certifies that the message is confirmed present in WhatsApp's own state for your account. It does **not** certify that the recipient's phone received it, and it is not the two-grey-ticks moment. Treat it as "WhatsApp has it", not "they have it". | Event | Certifies | Does not certify | | --- | --- | --- | | `message.queued` | The API accepted and stored the send | That an engine is connected | | `message.sending` | The engine dispatched it | That WhatsApp accepted it | | `message.delivered` | Confirmed in WhatsApp's state | Recipient device delivery, or two grey ticks | | `message.read` | A read receipt was observed | That the human read it, or that silence means unread | | `message.failed` | This attempt did not succeed | That the recipient is unreachable forever | The naming lands where it does because of deduplication. Internally there are more states than five and several describe the same public transition, so `message.delivered` binds to the "confirmed" state and the neighbouring internal states are deliberately left unmapped. That stops you receiving the same delivery twice under two names, at the cost of a word that does less work than it looks like it does. Blueticks sends from your own number over a linked WhatsApp session, the same [linked device mechanism](https://faq.whatsapp.com/1317564962315842) your laptop uses, not through the Meta Cloud API. None of Meta's message-status semantics apply here. Consent is still yours to collect, and no vendor can promise a number will never be restricted. **Point a URL at your own number's delivery stream and stop guessing.** [Start a Blueticks account](https://blueticks.co/signup), register one webhook, and your next API send tells you what happened to it. [image: Two pairs of hands exchanging a plain unmarked kraft-paper parcel in daylight] ## Closing the loop: send, wait for delivered, act The loop has three moving parts: send and keep the returned handle, receive events and match them back to it, then act on the terminal state. Your receiver's only job inside the request cycle is to acknowledge fast. Parse, enqueue, return 200, and do the real work somewhere else. Python, Flask, with a worker thread so the HTTP response is never blocked by your business logic: ```python import queue, threading from flask import Flask, request app = Flask(__name__) events = queue.Queue() seen = set() # swap for Redis SETNX in production @app.post("/hooks/whatsapp-delivery") def receive(): payload = request.get_json(silent=True) or {} events.put(payload) return "", 200 # acknowledge first, always def worker(): while True: evt = events.get() event_id = evt.get("id") if not event_id or event_id in seen: continue # idempotent: same event id on every retry seen.add(event_id) handle(evt.get("type"), evt.get("data") or {}) def handle(event_type, data): ref = data.get("secret") or data.get("id") if event_type == "message.delivered": advance_workflow(ref) elif event_type == "message.failed": fall_back(ref, data.get("failureReason")) elif event_type == "message.queued": start_timeout_clock(ref, seconds=180) threading.Thread(target=worker, daemon=True).start() ``` The same receiver in Node with Express: ```js import express from "express"; const app = express(); app.use(express.json()); const seen = new Set(); // swap for Redis SETNX in production app.post("/hooks/whatsapp-delivery", (req, res) => { res.sendStatus(200); // acknowledge first, always setImmediate(() => { const { id, type, data = {} } = req.body || {}; if (!id || seen.has(id)) return; // idempotent on retries seen.add(id); const ref = data.secret || data.id; if (type === "message.delivered") advanceWorkflow(ref); else if (type === "message.failed") fallBack(ref, data.failureReason); else if (type === "message.queued") startTimeoutClock(ref, 180); }); }); app.listen(3000); ``` Three details make this production-shaped rather than demo-shaped: - **The envelope `id` is stable across retries.** The same delivery re-POSTs an identical body, so deduplicating on `id` is exact rather than heuristic. A 15-second server-side collapse window catches genuinely duplicate emissions, but your own dedupe is what protects you across the 21-hour retry span. - **`data.secret` is a correlation token you choose.** Pass an opaque string of up to 256 characters on the send and it comes back on every event for that message, so you can join to your own order id with no lookup table. It is not a deduplication key: sending it twice sends two messages. For safe send retries there is a separate `Idempotency-Key` request header. - **`data.waMessageKey` is null on these events.** Match on `data.id` or `data.secret` instead. **What breaks:** the timeout clock is not decoration. If the engine behind your number is disconnected, `message.queued` fires and nothing follows, possibly for a long time. A workflow that waits forever for `message.delivered` has silently stopped. Subscribe to `session.connected` and `session.disconnected` alongside the message events so you can tell the two apart. ## Wiring the loop into an MCP connector or a Claude Code agent This is where the asymmetry bites hardest. An agent with a WhatsApp connector can send: it calls the tool, the tool returns, and the conversation moves on with no way to learn what happened next. The agent is writing into the dark. Webhooks are the only mechanism that gives it a return path. The [Blueticks MCP server](https://dev.blueticks.co/docs/mcp) exposes a `webhooks` tool with `create`, `list`, `get`, `update` and `delete` actions, so the agent can register its own callback instead of waiting for a human to configure one. The practical pattern: 1. The agent registers a webhook pointing at a small endpoint you control, subscribing to `message.delivered` and `message.failed`. 2. It sends through the `scheduled_messages` tool and sets `secret` to a task id it already owns. 3. Your endpoint writes the outcome somewhere the agent reads on its next turn: a task queue, a database row, a file it polls. 4. The agent resumes with a fact instead of an assumption, and can say "delivered at 09:14" or "failed, falling back to email". Step 3 is the part people skip. A webhook is asynchronous and an agent turn is synchronous, so something durable has to sit between them. One row keyed on your `secret` is enough. For the broader picture of what the connector can drive, see [WhatsApp automation through the API](https://blueticks.co/blog/whatsapp-automation-api). [image: A single runner's hand gripping a plain unmarked relay baton on a running track] ## Which delivery events are reliable today, and which are not Three of the five are dependable and one is not. `message.queued`, `message.sending` and `message.delivered` are verified end to end and are what you should build on. `message.failed` fires on real failures. `message.read` is best effort, and its absence carries no information at all. The honest version, which is not a table you will find on a vendor page: | Event | Status | Build on it? | | --- | --- | --- | | `message.queued` | Verified end to end | Yes | | `message.sending` | Verified end to end | Yes | | `message.delivered` | Verified end to end | Yes | | `message.failed` | Fires on genuine failures | Yes | | `message.read` | Known gap, fires rarely | No | Blueticks' own internal known-issues note from 2026-04-24 puts it plainly: `message.read` "rarely fires even when the recipient clearly reads the message". The backend is wired correctly; the gap is upstream, in how the read state gets recorded at all. A server-side fallback has been proposed and does not exist today. There is a second, permanent reason not to gate anything on reads, and it has nothing to do with us. WhatsApp lets every recipient turn read receipts off in [their privacy settings](https://faq.whatsapp.com/195231088335525), and when they do no read receipt is sent for a one-to-one chat. Group chats are the exception, where read receipts are always sent. Even a perfect implementation would produce a `message.read` for some recipients and permanent silence for others, with no way to tell the two apart. Any product promising reliable read tracking on one-to-one chats is describing something the platform does not offer. ## Why polling for delivery status falls apart Polling works for ten messages and collapses at a thousand. You can read status directly: `POST /v1/messages/acks` returns delivery state for up to 200 message keys per call, with an `ack` integer from -1 (error) through 0 (pending), 1 (server), 2 (device), 3 (read) and 4 (played). Useful endpoint. Terrible foundation for a workflow. Run the arithmetic. 5,000 in-flight messages at 200 keys per call is 25 requests per sweep. Poll every 30 seconds and that is 72,000 calls a day, nearly all returning a state you already knew. Stretch the interval to five minutes and median detection latency becomes 150 seconds, useless for anything that has to react. Webhooks invert the cost: one request per actual state change, zero when nothing happens. Use both, for different jobs. Webhooks drive behaviour. The batch ack endpoint handles reconciliation: a status column in a dashboard, or backfilling the window when your receiver was down and eight retries ran out. That sweep is the safety net that makes it reasonable to trust the stream the rest of the time. The send side itself is covered in [sending a WhatsApp message from the API](https://blueticks.co/blog/send-whatsapp-message-from-api). [image: A tarnished brass doorbell button on a weathered door frame, its nameplate slot empty] ## What raw delivery events cannot do that Blueticks adds Raw events tell you what happened to one message. They will not schedule the next one, hold a rate limit, group 800 sends into a campaign you can pause, or keep the session behind your number alive at 3am. That operational layer is why a whatsapp delivery status api is worth attaching to a product rather than a script. Concretely, what sits around the event stream: - **Campaign-level events.** `campaign.started`, `campaign.paused`, `campaign.resumed`, `campaign.completed` and `campaign.aborted` are subscribable the same way, so a bulk run reports its own progress instead of you inferring it from 800 individual message events. - **Session events.** `session.connected` and `session.disconnected` separate "nothing delivered because the messages are bad" from "nothing delivered because the number went offline". - **Scheduling.** Omit `sendAt` and it sends now, set it and the queue holds it, so you are not running cron to fire messages at 09:00 local time. - **A toolkit, not one endpoint.** The same account is reachable through the [REST API](https://dev.blueticks.co/docs/api) and the [MCP server](https://dev.blueticks.co/docs/mcp), over your own number, with the event stream wired to whichever you use. Honest framing: you can build a delivery-status pipeline on the raw events alone, and plenty of people should. ## Frequently asked questions **Does `message.delivered` mean the recipient received the message?** No. It certifies the message is confirmed present in WhatsApp's own state for your account. It is not the recipient's device confirming receipt and it is not equivalent to two grey ticks. For end-user copy, "sent successfully" is accurate and "delivered to their phone" is not. **Why am I not getting a `message.read` event?** Two reasons stack. A known gap on our side, recorded internally since 2026-04-24, means the read state often is not persisted even when the recipient reads the message. And recipients can [switch read receipts off](https://faq.whatsapp.com/195231088335525), in which case no read receipt is sent for us to report. Build on `message.delivered` instead. **Do I get delivery events for messages I send from my phone?** No. The lifecycle fires for API-originated messages only. Messages typed on your phone or scheduled from the dashboard emit nothing, because the events hang off the record your API call created. **What happens if my server is down when an event fires?** Non-2xx responses other than a permanent 4xx are retried up to 8 times with escalating backoff across roughly 21 hours. Every attempt carries an identical body and the same event `id`, so dedupe on that id. After 8 consecutive deliveries exhaust their retries the webhook is disabled. Reconcile anything you missed with the batch ack endpoint. **How is this different from Meta Cloud API webhooks?** Different platform entirely. Blueticks sends from your own number over a linked WhatsApp session, so the event names, payload shape, retry policy and the meaning of each state are ours, not Meta's. Code written against Cloud API status objects will not parse these events, and Cloud API semantics should not be assumed to describe this behaviour. --- # Can You Use the WhatsApp API Without Meta Business Verification? (2026) > Verification lifts ceilings, it does not grant access. Meta's own numbers for the unverified tier, plus the honest case for and against running on your own number. URL: https://blueticks.co/blog/whatsapp-api-without-meta-verification Published: 2026-08-18 Author: Avi Kohen Category: industry Most articles on this question answer it backwards. They treat Meta verification as a gate you either clear or sneak around, and they sell you the sneaking. The document trail says something duller and more useful: Meta's own API runs unverified, at published ceilings, and the real question is whether those ceilings fit you. Yes. Meta's own Cloud API runs without business verification, capped at 250 unique customers per 24 hours, 250 templates and 2 phone numbers. Verification lifts those ceilings. It does not grant access. - **Cloud API, unverified** - Meta's official API at starting ceilings. - **Cloud API through a BSP, verified** - full scale, template broadcast, badge eligibility. - **Own-number API over WhatsApp Web** - the number you already use, no Meta onboarding. ## Can you use the WhatsApp API without Meta Business verification? Yes, on Meta's own platform. [Meta's messaging limits documentation](https://developers.facebook.com/documentation/business-messaging/whatsapp/messaging-limits) states that "newly created business portfolios have a messaging limit of 250." That is an allowance, not a block. A brand-new portfolio, verified by nobody, can deliver business-initiated messages to 250 unique WhatsApp numbers in a rolling 24-hour window on day one. The word "limit" is doing precise work there, and Meta's own definition is worth reading rather than the paraphrase: > "Messaging limits are the maximum number of unique WhatsApp user phone numbers your business can deliver messages to, outside of a customer service window, within a moving 24-hour period." Three things follow. It counts unique recipients, not messages. It counts only business-initiated sends outside an open service window, so replies to people who messaged you first do not count against it. And it is a ceiling on reach, not a switch on capability. That leaves three real routes, and only the third avoids Meta entirely. The next section saves the most time, because for a meaningful share of readers the answer is to close this page. ## Who should stop reading here and get verified anyway? Five situations make Meta verification and a Business Solution Provider the correct answer, not the expensive one. If any of these describes you, the rest of this article is a distraction: the blue checkmark, template broadcast at Meta scale, official Business Platform support, a regulated-sector paper trail, or three or more agents working one shared queue. [image: A consultant holding out a blank sheet of paper to a client across a table in a bright office] **You need the blue checkmark.** Official Business Account status is granted by Meta and there is no route to it outside the WhatsApp Business Platform. Per [Meta's Official Business Accounts documentation](https://developers.facebook.com/documentation/business-messaging/whatsapp/official-business-accounts/), the badge requires five things together: policy compliance, 30 days registered on the platform, a business portfolio "verified through Business Verification," two-step verification enabled on the number, and an approved display name. Own-number tools cannot supply any of them. **You broadcast templated messages at scale.** Above a couple of thousand unique recipients a day, you belong on the ladder Meta built for it, with the throughput commitments that come with the platform. **You need someone to escalate to when a number or a template is rejected.** That escalation path is a property of the BSP relationship. Nobody outside the platform has it. **You are in finance, healthcare, insurance or anything with an audit trail.** Use the sanctioned channel. A regulator asking which approved system you messaged a customer on is not a conversation to have about a paired browser session. **Three or more people work the same WhatsApp queue.** Assignment, handoff, roles. Blueticks does not have a multi-agent shared inbox, and saying otherwise would be a lie you would discover in week one. If two or more of those fit, the tools worth pricing are Wati, Interakt, TimelinesAI and Periskope, or a BSP bought directly through Meta's partner flow. Our [WhatsApp Business API alternatives comparison](https://blueticks.co/blog/whatsapp-business-api-alternatives) prices thirteen of them from each vendor's own page and points three of its seven recommendation rows straight back at the official API. That is the honest shape of this market, and this page is not going to pretend otherwise. ## What does Meta Business Verification actually unlock? Business verification is an identity check on your company, not a licence to send. Meta describes it as a process for confirming your company's identity. Clearing it raises four published ceilings and makes you eligible for a fifth thing. It changes no message type, no API endpoint and no feature. [image: An open notebook with blank ruled pages and a rising four-step staircase sketched on the page beside a pencil] | What changes | Unverified | After verification | Meta's own source | | --- | --- | --- | --- | | Unique customers messaged outside a service window, per rolling 24h | 250 | 2,000, then automatic scaling to 10,000, 100,000 and unlimited | [Messaging limits](https://developers.facebook.com/documentation/business-messaging/whatsapp/messaging-limits) | | Message templates per WhatsApp Business Account | 250 | Up to 6,000, if a number also has an approved display name | [Template fundamentals](https://developers.facebook.com/documentation/business-messaging/whatsapp/templates/overview) | | Registered business phone numbers | 2 | 20 | [Business phone numbers](https://developers.facebook.com/documentation/business-messaging/whatsapp/business-phone-numbers/phone-numbers) | | Official Business Account eligibility | Not eligible | One of five requirements satisfied | [Official Business Accounts](https://developers.facebook.com/documentation/business-messaging/whatsapp/official-business-accounts/) | Two details in that table are routinely reported wrong, including in places you would expect better. Verification is not the only path to either raised ceiling. Meta's messaging limits page lists three routes to 2,000: verify your business, have your onboarding partner verify it, or deliver 2,000 template messages to unique numbers over a 30-day moving period at a high quality rating. And the phone number cap moves to 20 "if your business becomes verified, or if you have reached a messaging limit of 2,000," so volume alone gets you there. While we are correcting things, three separate concepts get flattened into the phrase "green tick," and they are not interchangeable: - **Business Verification** - free document review of your company, lifts the ceilings above. - **Official Business Account** - the badge, blue, five requirements, verification is one. - **Meta Verified** - a paid monthly subscription, [sold separately by Meta](https://www.facebook.com/business/tools/meta-verified-for-business) from $14.99 per month. Whether you belong on the platform at all is a prior question, answered in our [readiness test for the WhatsApp Business API](https://blueticks.co/blog/do-i-need-whatsapp-business-api). ## Does the Cloud API really work unverified, and what is the catch? It really works. There are three catches, and none of them is verification. Templates are still mandatory outside the 24-hour window, you still need a phone number that is not already on WhatsApp, and registering the number you already use has consequences that are easy to trigger and hard to reverse. **Templates apply at every tier.** [Meta's template fundamentals page](https://developers.facebook.com/documentation/business-messaging/whatsapp/templates/overview) is unambiguous: "Template messages are the only type of message that can be sent to WhatsApp users outside of a customer service window." That window opens for 24 hours when a user messages you, per [Meta's service messages documentation](https://developers.facebook.com/documentation/business-messaging/whatsapp/messages/send-messages). Unverified does not mean unstructured. You will write templates and wait for approval on day one. **The number is the real friction.** [Meta's business phone numbers documentation](https://developers.facebook.com/documentation/business-messaging/whatsapp/business-phone-numbers/phone-numbers) states plainly that "numbers already in use with WhatsApp cannot be registered unless they are deleted first." The number your customers have saved is not automatically available to you. **Migrating your existing number is conditional, not free.** This is where the popular advice goes wrong. If you delete your WhatsApp Business app account and register that number to the Cloud API directly, [Meta's migration documentation](https://developers.facebook.com/documentation/business-messaging/whatsapp/solution-providers/migrate-existing-whatsapp-number-to-a-business-account/) says "your existing messaging history will be lost, and you will be unable to use that number with the WhatsApp Business app again." Reversing it means [deleting the number from the platform](https://faq.whatsapp.com/209248051996804) first. The important nuance most summaries drop: onboarding through a partner that supports business-app numbers preserves your history and lets you keep using both. So the loss is a consequence of the direct path, not of the platform. Be fair to this route. If you are building something new, can dedicate a number, and 250 unique recipients a day is more than you need, the Cloud API unverified is the right answer and it costs nothing to verify later. Skip the rest of this page. ## What do you keep by running on your own number instead? You keep the number itself, with its history and its saved-contact status, and you skip the template approval queue and the per-message meter. What you take on is a connection problem: the Cloud API is hosted by Meta, and an own-number API is not, so something has to keep a WhatsApp session alive. [image: A face-down phone beside a closed laptop and a closed notebook on a home office desk] An own-number API pairs with the WhatsApp account you already have, the way WhatsApp Web does, and sends through that session. No Meta portfolio, no display name review, no dedicated number, no per-message charge, because Meta is not in the path. The tradeoff is that a paired session has to be running somewhere. Two answers exist to that. Either your machine stays on with WhatsApp Web open, or something runs the session server-side for you. In Blueticks that second option is a hosted gateway: each connected account gets its own Kubernetes workload, in one of two engine flavours, so sends continue with your laptop shut. It is not free capability. Verified in the product's own code today, creating a hosted engine on the Chrome/wa-js gateway flavour requires an active subscription carrying the offline-socket entitlement, and that entitlement allows one such engine. Without it the sends still work, but only while a browser session is open. If your reason for looking is that the WhatsApp Business app ran out of room rather than that Meta did, those ceilings are catalogued in [WhatsApp Business app limitations](https://blueticks.co/blog/whatsapp-business-app-limitations). Skip the Meta onboarding queue entirely and send from the number your customers already have. [Start free with Blueticks](https://blueticks.co/signup): no business verification, no template approval, no per-message fee, first scheduled message in about five minutes. ## What can an own-number WhatsApp API never do? Four hard limits, and three of them are WhatsApp's rather than any vendor's. No badge, ever. No button, list or template sends. Personal-account scale, not platform throughput. And no guarantee about your account's standing, from us or from anyone selling this mechanism. **No badge.** Official Business Account status flows from Meta's five criteria above, all of which live inside the WhatsApp Business Platform. There is no unofficial route, and any vendor implying otherwise is selling something they cannot deliver. WhatsApp documents what the consumer-facing badge means in its [help centre article on verified business accounts](https://faq.whatsapp.com/794517045178057). **No interactive or template message types.** This one is checkable in our code rather than our marketing. Blueticks's Baileys engine explicitly refuses `sendButtonsMessage`, `sendListMessage` and `sendTemplateMessage`, returning a `feature_not_supported_on_baileys` error before any handler runs. The engineering note in that file explains why: WhatsApp's servers deprecated those sends for standard, non-Cloud-API senders, so the engine can encode the message but WhatsApp either rejects it or the recipient's client renders nothing. **Personal-account scale.** A paired session sends at the pace a person sends. There is no published throughput figure because there is no throughput commitment. If your plan depends on sustained machine-speed throughput, you need the platform. **No no-ban promise.** State it plainly rather than in a footnote. The [WhatsApp Business Terms of Service](https://www.whatsapp.com/legal/business-terms/) prohibit developing or using "any applications that interact with our Business Services without our prior written consent," and the [WhatsApp Business Messaging Policy](https://whatsappbusiness.com/policy/) reserves Meta's right to "limit or remove your access" from anyone "messaging people at scale in an unauthorized manner." Sending through a paired session sits outside the WhatsApp Business Platform, so none of Meta's platform commitments on delivery, throughput or account standing apply. That is a statement about the mechanism, and it applies to Blueticks exactly as it applies to every other tool using it. Consent is yours either way, and this is not an own-number caveat. The same Messaging Policy governs the WhatsApp Business app too, and requires that people "have given you their mobile phone number" and that "you have received opt-in permission from the recipient." No tool on any route collects that for you. ## How do you choose? Three questions that settle it Three questions resolve almost every version of this decision, and each one routes to exactly one of the three options. Answer them in order and stop at the first that gives you a hard yes. [image: Three blank index cards laid out as a decision framework for choosing a WhatsApp API route] **1. Do you need to reach people who have not messaged you, at more than a couple of thousand a day?** If yes, you need Meta's ladder and templates, which means the Cloud API and eventually verification. Nothing outside the platform scales into that. If no, keep going. **2. Do you need the blue checkmark, official support, or a regulated-sector audit trail?** If yes, you need verification and a BSP, and you needed it before you started reading. If no, keep going. **3. Is the number you want to send from already saved in your customers' phones?** If yes, the own-number route is the only one that keeps it, because registering that number to the Cloud API directly costs you its history and its Business app. If no, and you can dedicate a fresh number, the unverified Cloud API is a perfectly good place to start. The comparison at the level of app versus platform, rather than tool versus tool, is laid out in [WhatsApp Business app vs API](https://blueticks.co/blog/whatsapp-business-app-vs-api). ## How do you ship an own-number WhatsApp API today? Connect the WhatsApp account you already have, then send with one HTTP call per message. The recipient is the path parameter, the body carries the message, and an optional timestamp turns the same call into a scheduled send. ``` POST /v1/scheduled-messages/{chatId} { "type": "text", "text": "Your order shipped.", "sendAt": "2026-08-20T09:00:00+03:00" } ``` That is the whole shape. `type` is one of `text`, `media` or `poll`. Omit `sendAt` and it sends now; include it and the message is queued, validated to land at least 10 seconds ahead and no more than 365 days out. From there a message moves through `pending`, `confirmed`, `received`, `read` and `played`, or `failed`. This page is the decision, not the build. The full walkthrough, with working code, delivery status, campaigns and the pacing discipline that goes with sending on your own number, lives in the [WhatsApp REST API on your own number guide](https://blueticks.co/blog/whatsapp-rest-api-own-number). Start there once you have decided this is your route. ## Frequently asked questions ### Can you use the WhatsApp Business API without verification? Yes. Meta's messaging limits documentation states that newly created business portfolios have a messaging limit of 250, meaning you can deliver business-initiated messages to 250 unique WhatsApp numbers in a rolling 24-hour window before verifying anything. Verification is one of three routes to raise that to 2,000. It gates scale, not access. ### Does Meta business verification give me the green tick? No, and three different things get called that. Business Verification is a free document review that lifts your ceilings. Official Business Account status is the badge, now blue, and Meta's documentation lists verification as one of five requirements alongside 30 days on the platform, two-step verification and an approved display name. Meta Verified is a separate paid subscription starting at $14.99 per month. ### What are the limits if I skip verification on the Cloud API? Four published ones. 250 unique customers messaged outside a service window per rolling 24 hours, 250 message templates per WhatsApp Business Account, 2 registered business phone numbers, and no eligibility for Official Business Account status. Templates and the 24-hour window apply identically whether you are verified or not. ### Can I use my existing WhatsApp number with the Cloud API? Not without cost. Meta's documentation states that numbers already in use with WhatsApp cannot be registered unless deleted first, and that deleting your WhatsApp Business app account to register directly loses your messaging history and locks you out of the app for that number. Onboarding through a partner that supports business-app numbers is the exception that preserves both. Own-number tools avoid the question by pairing with the account as it is. ### Is an unofficial WhatsApp API safe to use? "Unofficial" describes a mechanism, not a verdict, and the checkable consequence is this: a paired session runs outside the WhatsApp Business Platform, so Meta's commitments on delivery, throughput and account standing do not apply, and the WhatsApp Business Terms prohibit applications that interact with the Business Services without prior written consent. Nobody can promise you an outcome there. Recipient opt-in is required on every route and is yours to obtain. *Notes: every Meta and WhatsApp figure above was read from the linked primary source on 2026-08-16 and re-verified on 2026-08-18, and platform limits change without notice. Product behaviour described here was verified against the Blueticks production branch on 2026-08-18. Prices and ceilings quoted from Meta are Meta's, not ours.* --- # Connect WhatsApp to ChatGPT: the MCP Connector Setup (2026) > The click-path most guides still get wrong, the nine WhatsApp tools ChatGPT actually sees, and the prerequisite that decides whether any of it works. URL: https://blueticks.co/blog/connect-whatsapp-to-chatgpt-mcp Published: 2026-08-17 Author: Daniel Roth Category: productivity You can hand ChatGPT your WhatsApp. It reads your threads, tells you who is still waiting on a reply, drafts the answer, and sends it from your own number. What nobody tells you on the way in: it only works while something on your side holds a live WhatsApp session. If that something is a browser tab, it stops the second you close the laptop. This guide is written around that fact instead of hiding it in a footnote. ## Can you connect WhatsApp to ChatGPT? Yes. Add a remote MCP server as a plugin in ChatGPT developer mode. Two things must be true first: developer mode is available on your account, and a WhatsApp engine is connected and stays connected while ChatGPT works. - **ChatGPT developer mode** - turn it on in Settings before anything else. - **A live WhatsApp engine** - browser tab or always-on gateway, your choice. - **The connector URL** - `https://api.blueticks.co/mcp`, with the `/mcp` path. - **The invoke surface** - the Work tab, not the normal Chat tab. That is the whole shape of a whatsapp mcp chatgpt setup. ChatGPT runs the Model Context Protocol client, Blueticks runs the server, and the server exposes WhatsApp actions as tools ChatGPT can call. If the protocol layer is new to you, the [WhatsApp and MCP primer](https://blueticks.co/blog/whatsapp-mcp) covers the architecture first. ## What has to be true before you start Two prerequisites, and one of them disqualifies most people who try this on a whim. A WhatsApp engine has to be connected for ChatGPT to read or send anything at all, and developer mode has to be available on your ChatGPT account. Check both now, in that order. [image: Closed laptop on a dark desk at night, the moment a WhatsApp browser session ends] ### Your WhatsApp engine has to be connected, and stay connected ChatGPT does not talk to WhatsApp. It talks to a server, and that server drives a WhatsApp session you own. No live session, nothing for ChatGPT to drive. The behaviour is not vague. When a tool call arrives and no engine is online for the account, the Blueticks API answers `503 Service Unavailable` with `No WhatsApp engine is connected for this account`. ChatGPT surfaces that as the tool failing. It does not queue the message for later, and it does not tell you your laptop is asleep. There are exactly two ways to be connected, and they behave very differently: | | Browser extension on WhatsApp Web | Hosted always-on gateway | |---|---|---| | Where the session runs | Your browser tab | Blueticks infrastructure | | Laptop closed, browser quit | Session ends, tools fail | Keeps running | | Good for | Working hours, at the desk | Overnight sends, scheduled follow-ups, anything you are not present for | Say it plainly: the extension dies when the tab closes. Shut your laptop at 18:00, ask ChatGPT from your phone at 22:00 to send a reminder, and the extension path fails while the gateway path works. That single difference decides whether this is a toy or a tool. First-time connection is a QR scan either way, documented in the [Blueticks guides](https://blueticks.co/guides). One limit if you run both at once: WhatsApp caps a standard account at [four linked devices](https://faq.whatsapp.com/378279804439436) — more on a Meta Verified account — and each session counts. ### ChatGPT developer mode has to be available to you MCP servers are added in developer mode, and developer mode is not guaranteed to be there. OpenAI's own wording, in the plugin connection docs, is exactly this: > "Developer mode availability can depend on account and workspace policy." That is from [OpenAI's connect-and-test guide](https://developers.openai.com/plugins/deploy/connect-chatgpt), and it is the only statement on gating worth repeating. OpenAI does not publish a plan list there, so anyone naming tiers is guessing. Open Settings, look under **Security and login**, and see whether the toggle exists on your account. On a work account an admin can switch developer mode off, which makes it an ask for them, not a setting you can win. Fifteen seconds now, or a wasted evening later. ## How to connect WhatsApp to ChatGPT in four steps Turn on developer mode, add the Blueticks MCP server URL at `chatgpt.com/plugins`, install the plugin from your personal plugins directory, then switch the ChatGPT homepage tab from Chat to Work and invoke it with `@`. Four screens, no terminal, no config file, about five minutes. [image: An open notebook with blank ruled pages, a short column of hand-drawn tick boxes and a pen resting across it] ### Step 1: turn on developer mode In ChatGPT, open **Settings**, select **Security and login**, and turn on **Developer mode**. That path is straight from [OpenAI's documentation](https://developers.openai.com/plugins/deploy/connect-chatgpt). Everything in a chatgpt developer mode mcp setup hangs off this toggle. Without it there is nowhere to paste a server URL. Flag for anyone cross-checking against another article: most competing guides still send you to **Settings → Connectors → Advanced settings**. That path is stale. OpenAI renamed the Apps SDK to Plugins, and `developers.openai.com/apps-sdk` now answers `301` and redirects to [`developers.openai.com/plugins`](https://developers.openai.com/plugins). If your guide says Connectors, it predates the rename and the rest of its click-path probably drifted too. ### Step 2: add the Blueticks MCP server Go to `chatgpt.com/plugins` and select the plus button. Enter a name and description you will recognise in a tool list, like "Blueticks WhatsApp". Under **Connection**, choose the public endpoint option and enter the MCP server URL, [including the `/mcp` path](https://developers.openai.com/plugins/build/mcp-server): ``` https://api.blueticks.co/mcp ``` The path is not decoration. `https://api.blueticks.co` on its own is not an MCP endpoint and the connection will not come up. OpenAI's build guide describes the expected shape as a streamable HTTP endpoint "typically at `/mcp`", streamable HTTP being the current transport, [introduced in protocol revision 2025-03-26 to replace the HTTP+SSE transport from 2024-11-05](https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http). None of that is yours to configure. You just need the path on the URL. Create the connection. A Blueticks sign-in screen appears, you sign in, and you land back in ChatGPT. Review the tools ChatGPT discovered. You should see nine. If you see zero, jump to the troubleshooting section. ### Step 3: install it from your personal plugins Creating the connection does not install it. Open [your personal plugins](https://developers.openai.com/plugins/quickstart) at `chatgpt.com/plugins?view=personal`, find the plugin you just created, open it, and select the plus button to install. This is the step people skip: the plugin exists, the tools were discovered, and it still does nothing in a chat, because it was never installed. ### Step 4: switch to the Work tab and invoke it Return to the ChatGPT homepage. At the top, switch the tab from **Chat** to **Work**. Start a new Work chat, type `@` in the prompt box, and pick your plugin. That sequence is [OpenAI's documented quickstart flow](https://developers.openai.com/plugins/quickstart), not a workaround. Test with something read-only before you let it send anything: "list my five most recent WhatsApp chats". If chats come back, the chatgpt whatsapp connector is live end to end. If you get a tool error, your engine is almost certainly offline. ## Which WhatsApp tools does ChatGPT get? Nine, exposed by name. ChatGPT sees `audiences`, `campaigns`, `chats`, `contacts`, `engine`, `groups`, `scheduled_messages`, `utils` and `webhooks`. You never call them by name yourself. You describe the outcome and ChatGPT picks the tool. - `chats` - read and send inside conversations - `scheduled_messages` - send now or schedule for later - `contacts` - look up who is who - `groups` - create and manage WhatsApp groups - `audiences` - reusable contact lists for bulk sends - `campaigns` - paced bulk delivery, with pause and cancel - `webhooks` - get an HTTPS callback on events - `engine` - check connection state, log out, reload - `utils` - date and time, phone validation, link previews Two things worth knowing. `engine` is what to reach for when you suspect the prerequisite has broken: ask "is my WhatsApp engine connected?" and it answers with the live state instead of making you guess. And ChatGPT sees the same nine tools Claude sees. The server does not hand ChatGPT a smaller menu; the difference between the two setups is the client, not the capability. Depth on the scheduling tool lives in the [scheduling-from-MCP guide](https://blueticks.co/blog/schedule-whatsapp-messages-from-claude-mcp). ## What can you actually ask it to do? Three requests that pay for the setup on day one: triage the unread pile, answer one thread properly, and put a follow-up on the calendar so you stop carrying it in your head. Each maps to a tool without you naming it. [image: A phone lying screen down beside a coffee and a closed notebook on a kitchen table] **"Which WhatsApp conversations from the last two days are waiting on a reply from me?"** This lands on `chats`. You get a triaged list instead of a scroll. Reading is the part that eats the morning, not typing, so triage pays for the whole setup before you ever send whatsapp from chatgpt at all. **"Reply to Dana: the quote is going out Thursday, and ask if she wants the extended warranty line included."** Also `chats`. Read the draft, correct the tone in plain language, then let it go. It leaves from your number and lands in your sent messages like anything you typed by hand. **"Remind me to chase the Kaplan invoice next Tuesday at 09:00, and send them a nudge at the same time."** This lands on `scheduled_messages`, and here is the gotcha: a scheduled send needs an engine at fire time, not at schedule time. Schedule it from a browser tab, close the laptop, and Tuesday 09:00 arrives with nothing to send through. Same trap in any [WhatsApp follow-up automation](https://blueticks.co/blog/whatsapp-follow-up-reminder-automation) you build on this. ## Why isn't it working? Four causes, in the order they actually occur. Diagnose before you change anything: ask ChatGPT "is my WhatsApp engine connected?" first, because that one question resolves the most common failure and rules it out for the other three. 1. **Your engine is offline.** By far the most likely. Symptom: tools are listed, every call fails. The tab closed, the laptop slept, the session dropped. Reconnecting the plugin fixes nothing. Re-link your number, or move to the always-on gateway so it stops recurring. A session in a browser tab follows ordinary [WhatsApp Web](https://blueticks.co/blog/whatsapp-web-guide) behaviour: it ends when the tab does. 2. **Developer mode is unavailable or admin-disabled.** Symptom: no toggle in Settings, or it vanished after a policy change. Nothing on the Blueticks side is involved. OpenAI states availability depends on account and workspace policy, so this is a conversation with your admin. 3. **The URL is missing the `/mcp` path.** Symptom: the connection never comes up and no tools are discovered. People paste `https://api.blueticks.co` and stop. Open the plugin's connection settings and add the path. 4. **You are in the Chat tab, not Work.** Symptom: everything looks installed, and typing `@` does not offer the plugin. Switch the homepage tab to Work and start a new chat. An existing Chat-tab conversation will not pick it up. If the tools were discovered once and then went stale after a server-side change, the plugin's connection page has a **Refresh** action that re-reads the advertised metadata. ## ChatGPT or Claude: which should you connect? Functionally, a coin flip. Both clients reach the same nine tools on the same server, so neither can do something to your WhatsApp the other cannot. Pick on where you already work, not on capability. The honest split is ergonomic. ChatGPT keeps MCP servers behind developer mode and puts plugin use in the Work tab: more clicks up front, cleanly separated afterwards. Claude surfaces connectors in its main settings, which is fewer clicks to first use. The Claude side has its own screens and its own page, so read [how to connect WhatsApp to Claude](https://blueticks.co/blog/connect-whatsapp-to-claude-mcp-integration) rather than adapting this one. Nothing here transfers except the prerequisite, which is identical. ## What this is not Four honest limits, and they matter more than any step above. This is not the first WhatsApp MCP server, not Meta's Cloud API, not risk-free for your number, and not a substitute for having permission to message someone. **Not the first, and not the only one.** Open-source WhatsApp MCP servers predate this and deserve the credit. [lharries/whatsapp-mcp](https://github.com/lharries/whatsapp-mcp) pairs a Go bridge built on [whatsmeow](https://go.mau.fi/whatsmeow) with a Python MCP server; [jlucaso1/whatsapp-mcp-ts](https://github.com/jlucaso1/whatsapp-mcp-ts) does it in one Node process on [Baileys](https://github.com/WhiskeySockets/Baileys). Both are self-hosted, both work, and other hosted vendors exist in this field too. The comparison lives in the [WhatsApp MCP server roundup](https://blueticks.co/blog/best-whatsapp-mcp-servers), not here. **Your own number, not the Business API.** This drives your existing WhatsApp account over WhatsApp Web or a hosted gateway. No template approval queue and no Cloud API per-message pricing, and equally none of the Cloud API's guarantees: no Meta-sanctioned delivery contract, no business verification, no Meta support path. **Nobody can promise your number is safe.** Automating a personal WhatsApp account carries real risk, because [unauthorized automated or bulk messaging violates WhatsApp's Terms of Service](https://faq.whatsapp.com/5957850900902049) and Meta enforces it. Read-and-reply on existing conversations sits at the low end, cold outreach at volume at the high end. Anyone selling a guaranteed no-ban setup is selling something they cannot deliver. **Consent is yours, not the tool's.** ChatGPT will happily draft two hundred first-contact messages. Whether those people agreed to hear from you is your responsibility alone. One last disambiguation, because a phrase brings people here by mistake. If you searched for an openai whatsapp integration meaning the other direction, calling the OpenAI API from a WhatsApp Business number so a bot answers your customers, this page is not that. That build uses Meta's Cloud API or a provider on top of it, a separate business number, pre-approved templates and per-message billing. Real thing to build, completely different thing. For where ChatGPT itself stands on WhatsApp as a product, read [ChatGPT on WhatsApp](https://blueticks.co/blog/chatgpt-whatsapp). ## When ChatGPT can't reach your number, none of this happens Every step above assumes a live WhatsApp session. Remove it and the connector is a menu of nine tools that all return an error. The always-on gateway is what makes the rest of this page real, and it is the honest reason to pay for anything here. [image: Tangled charging cables and an unplugged adapter on a desk, the always-on connection problem] Put it the way it actually bites. The plugin is rarely the problem. The problem is that you close your laptop at six and your clients message at nine — nothing is broken, and nothing is connected either. That is the whole product argument. A browser tab gives you WhatsApp automation during office hours. A hosted gateway parks the session on infrastructure that does not sleep, so a 22:00 request from your phone actually leaves your number. > **Stop losing sends to a closed laptop.** No Meta developer console, no template approval, no per-message fees. Connect your own number to an always-on engine, then let ChatGPT read and send on it whether you are at your desk or not. [Get an always-on WhatsApp engine.](https://blueticks.co/signup) ## FAQ **Does ChatGPT have a WhatsApp connector?** Not a built-in one. You add WhatsApp yourself by connecting a remote MCP server as a plugin in ChatGPT developer mode. Blueticks serves that endpoint at `https://api.blueticks.co/mcp`, and once installed ChatGPT gets nine WhatsApp tools. **Can ChatGPT send WhatsApp messages for me?** Yes, from your own number, once the connector is installed and a WhatsApp engine is connected. You ask in plain language, ChatGPT calls the `chats` or `scheduled_messages` tool, and the message leaves your account. It fails if no engine is online. **Do I need ChatGPT Plus to add an MCP server?** OpenAI says only that "Developer mode availability can depend on account and workspace policy" and does not publish a plan list. Ignore any article that names tiers. Open Settings, look under Security and login, and check your own account. **Does this use the WhatsApp Business API?** No. It drives your existing personal WhatsApp account over WhatsApp Web or a hosted gateway. There is no Meta Cloud API involved, so no template approval and no per-message pricing, and also none of the Cloud API's guarantees. **Will my computer need to stay on?** With the browser extension, yes. Close the tab and every ChatGPT tool call fails. With the hosted always-on gateway, no: the session runs on Blueticks infrastructure and keeps working overnight, which is what [an always-on engine](https://blueticks.co/signup) is for. --- # AI WhatsApp Inbox Management in 2026: Shared Team Inbox or an AI Agent on Your Own Number? > Almost every best-known tool in this category sells a multi-agent shared inbox on the WhatsApp Business API. That is one of two shapes, and it is the wrong one for a solo operator. URL: https://blueticks.co/blog/ai-whatsapp-inbox-management Published: 2026-08-15 Author: Avi Kohen Category: industry You searched for AI WhatsApp inbox management and got a page of products that look interchangeable. They are not. Half of them cannot run on the number your customers already message, and the other half cannot give three people a queue to work. Buying the wrong half is a weeks-long mistake, because the two shapes do not migrate into each other. AI WhatsApp inbox management comes in two shapes: a multi-agent shared inbox on the WhatsApp Business API, and an AI agent reading the WhatsApp number you already use. They solve different problems and cannot be swapped. - **Shared team inbox** - many agents work one business number. - **AI agent on your own number** - one operator, AI reads and drafts. The rest of this piece is how to tell which one you are shopping for, what each can and cannot do, and what to check before you pay. ## What is AI WhatsApp inbox management? AI WhatsApp inbox management means software that reads incoming WhatsApp conversations, ranks or sorts them, and either drafts or sends replies. The label covers two unrelated architectures. One runs on Meta's WhatsApp Business Platform with a dedicated business number. The other drives the WhatsApp account you already own. The distinction is not marketing. It is a hard platform boundary, and Meta states it plainly. Per [Meta's business phone numbers documentation](https://developers.facebook.com/documentation/business-messaging/whatsapp/business-phone-numbers/phone-numbers): > "Registered numbers can still be used for everyday purposes, such as calling and text messages, but cannot be used with WhatsApp Messenger. Numbers already in use with WhatsApp cannot be registered unless they are deleted first." Read that twice if you are a small business. It means a shared-inbox product on the official API cannot manage the WhatsApp account currently on your phone. It manages a different number, one your existing customers have never messaged. Everything downstream of that fact, including whether an AI can summarise your real conversation history, follows from it. The wider argument for why AI clients are showing up on WhatsApp at all is in our piece on [WhatsApp going agent-native](https://blueticks.co/blog/whatsapp-agent-native). ## What are the two shapes of AI inbox management, and which one are you shopping for? Shape A is a multi-agent shared inbox on the WhatsApp Business API: several human agents plus AI working one business number, with assignment, routing and handoff. Shape B is a single AI agent connected to the WhatsApp number you already use, reading your real history and drafting replies for you. Different transport, different buyer. The best-known products in this category are almost all Shape A, and the vendors say so on their own pages. Wati's shared-inbox page states: "Manage conversations better by assigning chats to users. Create teams of users for sales, support, or day and night shifts." Respond.io's team inbox page describes a round-robin auto-assignment workflow so conversations are distributed between agents in turn, plus intent-based routing to the right team. TimelinesAI's shared-inbox page offers to "assign responsible agents." AiSensy describes itself as built on the official WhatsApp Business APIs, Interakt's own title puts the WhatsApp Business Platform in the first line, and Kipps.AI sells AI voice, WhatsApp and chat agents for automating support and lead qualification. Those are real products doing a real job. | | Shared team inbox (Shape A) | AI agent on your own number (Shape B) | | --- | --- | --- | | Transport | WhatsApp Business Platform (Cloud API) | The WhatsApp account you already have | | The number | A dedicated business number, not your existing one | The number your contacts already message | | Seats working one queue | Yes, that is the product | No | | Assignment and routing | Yes | No | | Reads your existing chat history | Only what arrives on the new number | Yes, your real threads | | Message charges | Meta charges per delivered template message | No Meta per-message meter | | Time to first use | Days to weeks, gated by Meta setup | Minutes, gated by pairing | Both columns are legitimate. The mistake is buying column two when your problem is column one, or paying for column one when nobody but you will ever touch the inbox. Vendor-by-vendor detail on the Shape A field, priced from each vendor's own page, is in [WhatsApp Business API alternatives](https://blueticks.co/blog/whatsapp-business-api-alternatives). [image: Printed vendor pages sorted into two piles during a WhatsApp inbox management comparison] **If you are the only person who will ever work this inbox, you do not need a shared queue or a second number.** Connect an AI client to the WhatsApp number you already use and have it triage today's threads before you open the app. [Start on Blueticks](https://blueticks.co/signup): no Meta verification, no per-message meter, no new number to hand out. ## Which shape fits you: a shared team inbox, or an AI agent on your own number? Four questions settle it, and none of them is about AI features. How many humans touch the inbox? Does the number your customers already use matter? Does someone need to be accountable for a specific conversation? And can you absorb Meta's setup and per-message charges? Two or more humans plus accountability means Shape A. Run them in order. 1. **How many people work the inbox?** One, including you? Shape B. Two or more people who need to avoid replying over each other? Shape A. This is the single highest-signal question and it is usually answered in five seconds. 2. **Does the existing number matter?** If your customers have saved a number and message it unprompted, a Shape A product will not manage that number, per Meta's documentation quoted above. You would be running a second identity in parallel. 3. **Does a conversation need an owner?** If a manager has to answer "who is handling the Rosen account right now," you need assignment. That is a Shape A primitive. No own-number tool substitutes for it. 4. **Can you carry Meta's meter?** Since July 1, 2025, [Meta charges the Business Platform per message](https://developers.facebook.com/documentation/business-messaging/whatsapp/pricing) rather than per conversation, and you are charged when a template message is delivered. That is a variable cost that scales with volume. Answering yes to question 3 ends the conversation. Blueticks does not have a multi-agent shared inbox, has never claimed to, and this piece is not going to start. If three agents need to work the same queue with assignment and handoff, the honest answers remain Wati, Interakt, TimelinesAI and Periskope. If you are still working out whether you belong on the official API at all, the framework is in [WhatsApp Business app vs API](https://blueticks.co/blog/whatsapp-business-app-vs-api). [image: Solo business owner starting the morning before opening the WhatsApp inbox on her phone] ## What can an AI agent actually do to your WhatsApp inbox on your own number? When you manage your WhatsApp inbox with AI on your own number, the useful capability is not "AI replies." It is structured reading at a scale you cannot do by hand: filtering a chat list to the threads where someone is waiting on you, scanning many chats in one pass, and pulling older history on demand. WhatsApp inbox triage is where the minutes are. Concretely, on the Blueticks MCP surface as it stands on production today, nine tools are exposed to a connecting AI client (chats, contacts, groups, audiences, campaigns, scheduled_messages, engine, webhooks and utils), and the `chats` tool alone carries fourteen actions. The public developer documentation at [dev.blueticks.co](https://dev.blueticks.co/docs/mcp) lists only four of them for chats, so the docs undersell the surface rather than oversell it. There is a file in the production codebase named `chat-list-triage.ts`, which tells you what the chat list was built for. The triage-shaped parts, in plain terms: - **Filter the list by kind.** A `kinds` filter keeps only contacts, groups or newsletters, so an agent scanning your direct messages never wades through 40 group chats. - **See who is waiting without opening anything.** The list can attach each chat's last message and a flag for whether that last message was yours. A chat with unread messages whose last message is not from you is, approximately, a chat waiting on your reply. - **Cut by time.** An activity cutoff keeps only chats active since an instant you name, which is how "what happened since Friday 5pm" becomes one call instead of forty. - **Scan many chats in one pass.** Message listing accepts a batch of up to 25 chats in a single call, with a wall-time budget so the batch reports which chats it did not reach instead of quietly dropping them. - **Hunt by content type.** Message listing filters across 13 message kinds plus MIME prefix, filename substring, sender and a keyword set, which is how you find the invoice PDF somebody sent in March. - **Page back deliberately.** History loading pulls up to 10 older pages in one call, paced for WhatsApp, and stops at a date you name. - **Housekeep.** Marking read, archiving and unarchiving are actions on the same tool. Those three are absent from the public docs entirely. Sending exists too, as text, media and poll actions on the chats tool and as a `send` action on `scheduled_messages` with a `send_at` for anything scheduled. But the read path is the one that earns the subscription, and the operating routine for it, including the morning brief prompt and the triage rubric, already has its own piece: [make Claude your WhatsApp chief of staff](https://blueticks.co/blog/ai-whatsapp-assistant-chief-of-staff). Which MCP server to run, and the honest comparison of the transports, is in [best WhatsApp MCP servers](https://blueticks.co/blog/best-whatsapp-mcp-servers). ## What can it not do? No assignment, no routing, no SLA dashboard, one connection per account An AI agent on your own number cannot be a team queue. There is no assignment, no routing rule, no coverage window and no response-time dashboard anywhere in the product. One connection reaches one number, the number that account paired. Two colleagues connecting their own AI clients reach two different numbers, not one shared queue. That is a product-shape fact, not a roadmap tease. A strict search across the whole v1 API and the whole MCP surface on production returns zero assignment, routing or SLA primitives, and the engine tool describes itself as "the WhatsApp engine connected to this account," singular. The Kanban boards Blueticks ships are not exposed on the MCP surface at all, so they are not a hidden assignment feature for an AI client either. The connection topology is not a Blueticks invention. WhatsApp itself is built around one primary phone per account. Per the [WhatsApp Help Center on linked devices](https://faq.whatsapp.com/378279804439436), you can stay connected "by linking up to four devices at a time to your primary phone," and "you'll still need your primary phone to register your WhatsApp account and link new devices." Four linked devices on one account is a fan-out of surfaces, not a fan-out of queues. Three more limits worth stating before you buy anything in this category. Own-number automation is not an official Meta product, so nobody credible offers a no-ban guarantee. No inbox tool collects opt-in for you, in either shape. And an AI reading your inbox reduces the scan without absorbing any accountability. The ceilings people usually hit before they start this search are catalogued in [WhatsApp Business app limitations](https://blueticks.co/blog/whatsapp-business-app-limitations). [image: Notebook page listing the limits of managing a WhatsApp inbox with AI on one number] ## What should you check before you buy an AI WhatsApp inbox tool? Six checks, in this order: which transport it runs on, which number it manages, whether it reads your existing history, whether assignment exists, what the message charges are, and how long setup actually takes. Every one is answerable from the vendor's own documentation in under ten minutes, and the answers sort products into the two shapes automatically. | Check | Ask the vendor | Why it decides the purchase | | --- | --- | --- | | Transport | Official Cloud API, or my existing account? | Determines every other answer | | The number | Which number will customers message? | A new number resets your saved-contact advantage | | History | Can it read chats from before I signed up? | Shape A starts from zero on a fresh number | | Assignment | Can I assign a conversation to a person? | The one feature a solo tool will never have | | Charges | Is there a per-delivered-message charge? | Meta's meter is variable, subscriptions are not | | Setup time | What blocks my first message? | Verification queues versus a pairing step | Two traps in this category specifically. First, "AI-powered" says nothing about transport, so a page can be entirely accurate and still leave you unable to work out which shape you are buying. Second, several vendors sell into both shapes under one brand, so price and evaluate the product line, not the company. The own-number discipline that goes with the second shape, including pacing, is covered in the [own-number REST API guide](https://blueticks.co/blog/whatsapp-rest-api-own-number). ## What this means for your business If you are on the official API, your cost base is moving twice in the next few months. If you are on your own number, the practical change in 2026 is that AI clients can now read your inbox directly, so the value of the read path went up while nothing about your cost structure moved. Which of those sentences applies to you is decided by the shape you picked. Meta's pricing page currently carries a dated notice at the top: "Pricing updates for Meta Business Agent, service, and utility messages will launch on August 1, 2026 and October 1, 2026." The page also states that its current rate cards and volume tiers are effective July 1, 2026, based on the WhatsApp Business account timezone. Three practical consequences: - **Shape A budgets are not fixed for the year.** Two dated changes are already announced for the second half of 2026, and they touch service and utility messages, which is the traffic an inbox product generates most of. Re-run your volume forecast rather than rolling last quarter's figure forward. Our breakdown of the current model is in [WhatsApp Business API pricing 2026](https://blueticks.co/blog/whatsapp-business-api-pricing-2026). - **Shape B has no Meta meter to re-forecast**, because it does not deliver template messages through the Business Platform. What it does have is a hard ceiling at one operator per connection, which is a real cost when you hire your second support person. - **The migration cost is asymmetric.** Moving from Shape B to Shape A means acquiring a number and clearing Meta setup, and your existing conversation history does not travel. Moving from Shape A to Shape B means giving up assignment. Neither is a switch you flip in an afternoon, which is exactly why the choice deserves the ten minutes. ## How do you put an AI agent on your own WhatsApp inbox? Three things, and about two minutes: the WhatsApp number you already use connected over WhatsApp Web or a managed gateway, an MCP connection between your AI client and that number, and a first prompt narrow enough to be useful. This is the Shape B path. It is not the Meta Cloud API and it does not involve a new number. Blueticks is a single-operator tool: your number, your sends, scheduled and sequenced, with an AI client able to read and triage the threads that are already there. The click-by-click setup for Claude specifically, including where each client keeps its configuration, is in the [Claude WhatsApp connection guide](https://blueticks.co/blog/connect-whatsapp-to-claude-mcp-integration). Then hand the routine to the [chief-of-staff piece](https://blueticks.co/blog/ai-whatsapp-assistant-chief-of-staff), which has the prompts. And if question 3 above came back yes, go buy Shape A. A shared inbox you actually need beats an AI agent you half-need, and the vendors named earlier build it properly. [image: Compact home-office desk set up to manage a WhatsApp inbox with AI from one number] ## Frequently asked questions **Is AI WhatsApp inbox management the same as a WhatsApp shared inbox?** No. A WhatsApp shared inbox is one specific shape of it: several human agents working one business number with assignment and routing, almost always on the WhatsApp Business Platform. The other shape is a single AI agent reading the personal or business number you already use. Both get marketed with the same phrase. **Can I manage my existing WhatsApp number with a shared team inbox product?** Generally not, if the product runs on the official API. Meta's business phone numbers documentation states that numbers already in use with WhatsApp cannot be registered unless they are deleted first, and that registered numbers cannot be used with WhatsApp Messenger. A few vendors offer own-number products alongside their API products, so check the product line rather than the brand. **Does Blueticks have a multi-agent shared inbox?** No. There is no assignment, no routing, no coverage window and no response-time dashboard, and one connection reaches one number. For a team queue with assignment and handoff, Wati, Interakt, TimelinesAI and Periskope are the honest answers. **What can an AI agent do with my WhatsApp inbox that I cannot do faster myself?** Read at scale. Filtering a chat list to threads where someone is waiting on you, scanning up to 25 chats in a single pass, and searching months of history by message type, filename or keyword are all things that take an agent seconds and take you an afternoon. Composing an individual reply was never the bottleneck. **Which one should I buy if I am a solo operator planning to hire?** Buy for today and re-evaluate at the hire. Shape B costs you nothing in Meta setup and starts working on the number your customers already have. When a second person joins the inbox and you need to answer "who owns this conversation," that is the trigger to move, and it is a clean trigger rather than a guess. --- # How to Send WhatsApp Messages from PHP on Your Own Number (2026) > Fifteen lines of cURL, no Composer needed. Then the parts that break: the plus sign in the URL, Guzzle's zero-second timeout, and a retry that sends twice. URL: https://blueticks.co/blog/whatsapp-api-php Published: 2026-08-11 Author: Daniel Roth Category: productivity Your PHP app already knows the invoice is overdue, the table is ready, the shipment moved. Getting that into WhatsApp is where it stalls, usually behind a Business Solution Provider contract nobody wants to sign for six notifications a day. Here is the plain version. A php whatsapp api integration means one authenticated `POST` to a REST endpoint, sending from the WhatsApp number you already own, linked as a device over WhatsApp Web or a managed 24/7 gateway. It is not [Meta's Cloud API](https://developers.facebook.com/docs/whatsapp/cloud-api), so no templates, no Business verification, no per-conversation billing anywhere below. Consent stays yours, and nobody can promise an account will never be actioned. ## What do you need before PHP can send a WhatsApp message? Three things: a PHP install with the cURL extension, a WhatsApp number already linked to your Blueticks account, and a `bt_live_` API key. The recipient goes in the URL path as an E.164 number like `+15551234567`, not in the JSON body. That one detail causes most first-attempt failures in a whatsapp api php setup. The pre-flight, in order: 1. **Mint a key.** Open [dev.blueticks.co](https://dev.blueticks.co), sign in, create a key, copy it once. Keys are bearer tokens, so they live in `.env` and never in a repo. The [own-number REST API guide](/blog/whatsapp-rest-api-own-number) covers scopes and the auth model. 2. **Link a number.** Blueticks drives your number, not a Meta-provisioned one. Already connected a phone in the app? You are done. 3. **Check your PHP version.** The raw REST path runs on any PHP with cURL. The official SDK needs 8.1 or newer, and 8.1 itself reached [end of life on 31 December 2025](https://www.php.net/eol.php). Now the trap. The endpoint is `POST /v1/scheduled-messages/{chatId}` on `https://api.blueticks.co`, and `{chatId}` is a path segment. A leading `+` is not safe there, so PHP must encode it with [`rawurlencode()`](https://www.php.net/manual/en/function.rawurlencode.php), which follows RFC 3986 and turns `+15551234567` into `%2B15551234567`. Not `urlencode()`: that encodes spaces as `+`, the form-encoding convention, wrong in a path. You can also target a chat id directly, such as `1234567890@g.us` for a group. ## How do you send your first WhatsApp message from PHP with zero dependencies? Build the URL with `rawurlencode()`, set an `Authorization: Bearer` header, and `POST` a flat JSON body of `{"type":"text","text":"..."}`. Omit `sendAt` and it goes immediately. Fifteen lines of `curl_init`, no Composer, no framework. This is the php send whatsapp message baseline that works on shared hosting. ```php %2B15551234567 $url = "https://api.blueticks.co/v1/scheduled-messages/{$to}"; $ch = curl_init($url); curl_setopt_array($ch, [ CURLOPT_POST => true, CURLOPT_RETURNTRANSFER => true, CURLOPT_CONNECTTIMEOUT => 5, CURLOPT_TIMEOUT => 20, CURLOPT_HTTPHEADER => [ "Authorization: Bearer {$apiKey}", 'Content-Type: application/json', 'Idempotency-Key: invoice-4471-reminder', ], CURLOPT_POSTFIELDS => json_encode([ 'type' => 'text', 'text' => 'Your invoice #4471 is due tomorrow.', ]), ]); $body = curl_exec($ch); $errno = curl_errno($ch); $status = curl_getinfo($ch, CURLINFO_RESPONSE_CODE); curl_close($ch); if ($errno !== 0) { // transport failed, no HTTP status exists throw new RuntimeException('curl: ' . curl_strerror($errno)); } $payload = json_decode($body, true, 512, JSON_THROW_ON_ERROR); $message = $payload['data']; // id, status, waMessageKey live under data ``` Three things about that body. `type` is required and validation-only, so a bare `{"text":"hi"}` is rejected. Text tops out at 4,096 characters. A `2xx` that returns a resource is wrapped in `{"success":true,"data":{...}}`, so the id is `$payload['data']['id']`, never `$payload['id']`. Do not assume `data` is always present, though — a `2xx` with nothing to return sends `{"success":true}` on its own, so read `data` defensively rather than indexing straight into it. The [language-agnostic API walkthrough](/blog/send-whatsapp-message-from-api) shows the same call in shell, Python and Node. Do not build this with `file_get_contents()` and a stream context. It looks tidier and hides the one thing you need most: the HTTP stream wrapper's [`ignore_errors` option defaults to `false`](https://www.php.net/manual/en/context.http.php), so a `400` or `429` gives you `false` and a warning instead of the JSON error explaining what was wrong. Turn it on and you are then parsing `$http_response_header` by hand to recover the status code, which is a worse cURL wrapper. Plenty of shared hosts disable `allow_url_fopen` anyway. [image: Hands beside a closed laptop and a blank sheet, working through the raw cURL send path in PHP] ## Guzzle or raw cURL: which belongs in a whatsapp php integration? Use Guzzle if you already have Composer: PSR-18 compatibility, a separate connect timeout, a typed exception hierarchy, and a retry middleware you do not have to write. Use raw cURL when Composer is not available, when the app is legacy, or when you want one file with no dependency graph. Both hit the identical endpoint. One thing to set on day one. Guzzle's request options document [`timeout` as "Default `0`" and `connect_timeout` as "Default `0`"](https://docs.guzzlephp.org/en/stable/request-options.html), meaning no timeout at all unless you say otherwise. A PHP-FPM worker blocked forever on a socket is how one slow dependency takes down a pool. ```php use GuzzleHttp\Client; use GuzzleHttp\Exception\ConnectException; $http = new Client([ 'base_uri' => 'https://api.blueticks.co', 'connect_timeout' => 5, 'timeout' => 20, 'http_errors' => false, // read the body yourself instead of catching 'headers' => ['Authorization' => 'Bearer ' . getenv('BLUETICKS_API_KEY')], ]); try { $res = $http->post('/v1/scheduled-messages/' . rawurlencode($chatId), [ 'headers' => ['Idempotency-Key' => $idempotencyKey], 'json' => ['type' => 'text', 'text' => $text], ]); } catch (ConnectException $e) { // No response ever arrived. Retryable, but ONLY because the key above is stable. throw $e; } $data = json_decode((string) $res->getBody(), true, 512, JSON_THROW_ON_ERROR); ``` The exception split is the part worth internalising. Guzzle's [`http_errors` defaults to `true`](https://docs.guzzlephp.org/en/stable/request-options.html), so a `400` throws and your error body ends up buried in an exception instead of in front of you. Setting it to `false` inverts that: branch on `$res->getStatusCode()` and read the JSON error every time. `ConnectException` still throws, and that is the useful distinction. It means no response ever existed, so you cannot know whether the request landed. A response, any response, means the server answered and told you something specific. Whether you may safely repeat either is a real question and not a PHP one; the [production hardening guide](/blog/whatsapp-api-python-schedule) covers it. The PHP mechanic is just this: attach a stable `Idempotency-Key`, and put `GuzzleHttp\Middleware::retry` on the handler stack instead of a `for` loop with `sleep()`. One more reason the choice matters later: Guzzle is a PSR-18 client and raw cURL is not, which is what lets the official SDK below discover it automatically. ## Should you install the official PHP SDK instead of calling REST directly? Install it on a modern Composer project if you want typed responses and automatic path encoding. Skip it on shared hosting, below PHP 8.1, or on a stack the package has not been tested against. It is a convenience layer over the same REST calls, not a different capability. ```bash composer require blueticks/blueticks guzzlehttp/guzzle ``` The second package is not optional. The SDK ships no HTTP client of its own: it requires `psr/http-client`, `psr/http-factory` and `php-http/discovery`, then finds whatever concrete client you installed at runtime. With none present, [discovery throws `Http\Discovery\Exception\NotFoundException`](https://docs.php-http.org/en/latest/discovery.html), which reads as a crash rather than a missing dependency. Guzzle is the usual choice; `symfony/http-client` works too. ```php use Blueticks\Blueticks; $client = new Blueticks(['apiKey' => getenv('BLUETICKS_API_KEY')]); $message = $client->scheduled_messages->create('+15551234567', [ 'type' => 'text', 'text' => 'Your table is ready.', 'idempotency_key' => 'booking-8812-ready', ]); echo $message->id, ' ', $message->status; ``` The chat id is the first positional argument and the SDK `rawurlencode`s it into the path for you, which removes the most common first-call mistake. The magic `idempotency_key` entry is lifted out of the array and sent as a header. Media works the same way with `'type' => 'media'` and a `mediaUrl`, covered in the [image and document guide](/blog/whatsapp-api-send-image-pdf-document). Two honest caveats, because the package page will not tell you either. **It is new.** [`blueticks/blueticks` on Packagist](https://packagist.org/packages/blueticks/blueticks) is MIT, currently v5.0.0, published 21 July 2026, and lightly used so far. The source is small and readable, so if a response shape surprises you, read the resource class. Our [API quickstart](https://dev.blueticks.co/docs/quickstart) carries the same install line, worth checking because the repository sits under a `serenix-com` GitHub org and looks third-party at a glance. **Its tested ceiling is PHP 8.3.** The package declares `php: ^8.1`, and [Composer's caret operator](https://getcomposer.org/doc/articles/versions.md) means `>=8.1 <9.0`, checked against [the PHP actually running Composer](https://getcomposer.org/doc/articles/composer-platform-dependencies.md). Its CI matrix and README list 8.1, 8.2 and 8.3 only. So it installs cleanly on 8.4 and 8.5, and you are then running untested-against code. Not hypothetical: Laravel 13 requires PHP `^8.3`, so a shop that stays current sits at the top of the tested range or above it. The raw REST path has no such ceiling. ## How do you schedule a message for later and get sendAt right in PHP? Add a `sendAt` field holding an RFC 3339 timestamp with an explicit UTC offset. Build it with `DateTimeImmutable` plus an explicit `DateTimeZone`, then format with the `DateTimeInterface::RFC3339` constant. The window is roughly 10 seconds to 365 days ahead. Anything outside that is rejected at validation. ```php $sendAt = (new DateTimeImmutable('2026-09-01 09:00', new DateTimeZone('Asia/Jakarta'))) ->format(DateTimeInterface::RFC3339); // 2026-09-01T09:00:00+07:00 $body = ['type' => 'text', 'text' => 'Reminder', 'sendAt' => $sendAt]; ``` Three PHP-specific ways this goes wrong. **`date('c')` looks correct and is not.** It emits a valid offset, so it passes validation, but the offset comes from `date_default_timezone_get()`. Your laptop says `+03:00`, the container says `+00:00`, and the same code schedules two different moments. **`DateTime` mutates.** The manual states that `DateTimeImmutable` "behaves the same as `DateTime` except new objects are returned when modification methods such as `DateTime::modify()` are called" ([PHP manual](https://www.php.net/manual/en/class.datetimeimmutable.php)). Loop over 200 reminders calling `->modify('+1 day')` on a shared `DateTime` and every send drifts a day further than the last. **Off by ten seconds.** Compute `sendAt` when the job is created, sit in a queue for nine seconds, and dispatch arrives with a timestamp already inside the floor: `400 sendAt must be at least 10 seconds in the future`. Compute it at send time or leave a minute of headroom. Recurring cadences are a different mechanism, covered in the [recurring messages guide](/blog/schedule-recurring-whatsapp-messages). ## How do you send from Laravel without blocking the HTTP request? Never call the API inline in a controller. Dispatch a queued job, bind configuration through `config/services.php`, and let the queue own retries. Laravel's HTTP client has sane timeouts where raw Guzzle has none, and the job's `tries()` and `backoff()` give you the retry curve for free. Put the key in `config/services.php` as `'blueticks' => ['key' => env('BLUETICKS_API_KEY')]` and read it with `config('services.blueticks.key')`. Not style: Laravel's docs are explicit that once `config:cache` has run, "the `env` function will only return external, system level environment variables" ([configuration docs](https://laravel.com/docs/12.x/configuration)), so an `env()` call inside a job silently becomes `null` on your first cached production deploy. ```php namespace App\Jobs; use Illuminate\Contracts\Queue\ShouldQueue; use Illuminate\Foundation\Queue\Queueable; use Illuminate\Support\Facades\Http; class SendWhatsAppMessage implements ShouldQueue { use Queueable; public function __construct( public string $chatId, public string $text, public string $idempotencyKey, // derived from the ORDER, not from time() ) {} public function tries(): int { return 5; } public function backoff(): array { return [10, 60, 300, 900]; } public function handle(): void { $res = Http::withToken(config('services.blueticks.key')) ->withHeader('Idempotency-Key', $this->idempotencyKey) ->connectTimeout(5) ->timeout(20) ->post( 'https://api.blueticks.co/v1/scheduled-messages/' . rawurlencode($this->chatId), ['type' => 'text', 'text' => $this->text], ); if ($res->status() === 429 || $res->serverError()) { $res->throw(); // let the queue back off and retry } if ($res->failed()) { $this->fail(new \RuntimeException('permanent: ' . $res->body())); } } } ``` The `tries()` and `backoff()` methods are documented on both [Laravel 12](https://laravel.com/docs/12.x/queues) and [Laravel 13](https://laravel.com/docs/13.x/queues); on 13 the same delays can be written as a `#[Backoff([10, 60, 300, 900])]` attribute. The idempotency key is constructor state on purpose: compute it once from the business object at dispatch so all five attempts carry the identical value. Compute it inside `handle()` from a timestamp and every retry becomes a fresh message. **`Http::retry()` is the tempting shortcut and it has a sharp edge.** The docs describe it as retrying "if a client or server error occurs" ([HTTP client docs](https://laravel.com/docs/12.x/http-client)), which includes `400`s that will never succeed and, without a stable key, turns one timeout into two delivered messages. Restrict it: `Http::retry(3, 200, fn ($e) => $e instanceof ConnectionException)`. Laravel's defaults do beat raw Guzzle, with `timeout` at 30 seconds and `connectTimeout` at 10. One pacing warning, because a queue makes this easy to get wrong. Fan 500 jobs onto Horizon with ten workers and you fire 500 sends as fast as the workers drain. That burst is the pattern that gets numbers flagged, whatever sent it, and [WhatsApp's policy on automated or bulk messaging](https://faq.whatsapp.com/5957850900902049) applies either way. Throttle the queue and spread a batch over hours. Which events deserve a message at all is covered in the [event-triggered automation guide](/blog/whatsapp-automation-api). > **Ready to wire this into your app?** [Get a `bt_live_` key](https://blueticks.co/signup) and paste the job above into your existing Horizon setup. Your own number, your own contacts, no Meta Business verification and no per-message template fees. [image: Server rack status lights at night, the queue workers behind a Laravel WhatsApp job] ## What errors does a PHP client actually hit, and what should it do with each? Four of them carry PHP-relevant surprises. Below those sit three failure modes that are not HTTP errors at all: a silent `json_decode`, a transport error with no status code, and a missing CA bundle. Which codes are permanently fatal and which are worth a retry is covered in the [production hardening guide](/blog/whatsapp-api-python-schedule). | Status | Meaning | What your client should do | | --- | --- | --- | | `400` | Body or `sendAt` failed validation | Fix, never retry. Read `error.message` | | `409` | Same `Idempotency-Key`, different body | Bug in your key derivation | | `429` | Rate limited | Back off, retry with the same key | | `5xx` | Server side | Retry with backoff and the same key | Two limits shape that. The free plan allows **5 requests per 6-hour slot**, shared across the REST and MCP surfaces, so a loop testing ten sends hits `429` on the sixth within a second; any subscription removes the ceiling. And `Idempotency-Key` is capped at 64 characters and scoped per workspace: reuse it with an identical body and the original response replays, returning the same `201` and the same message id, so detect a replay by the id, not the status. The body `secret` field is not a dedup key. Send the same `secret` twice and you sent two messages. **`json_decode` returns `null` twice over.** The manual says `null` "is returned if the `json` cannot be decoded or if the encoded data is deeper than the nesting limit" ([json_decode](https://www.php.net/manual/en/function.json-decode.php)), and `null` is also what valid JSON `null` decodes to. Pass `JSON_THROW_ON_ERROR`, available since PHP 7.3, and get a `JsonException` instead of a mystery empty value three frames later. **`curl_errno` and HTTP status are different universes.** A `500` is a successful transfer: `curl_exec` returns the body, `curl_errno` is `0`, `CURLINFO_RESPONSE_CODE` is `500`. A DNS failure or timeout returns `false` with a non-zero `curl_errno` and no status code at all. Check `curl_errno()` first. Code that only reads the status treats a timeout as a success with an empty body. **Error 60 on Windows and XAMPP.** "SSL certificate problem: unable to get local issuer certificate" is not an API problem, it is a local PHP with no CA bundle. Download the Mozilla CA extract and point `curl.cainfo` and `openssl.cafile` in `php.ini` at the `cacert.pem`. What not to do is disable verification. curl's documentation is blunt: "We **strongly** recommend this is avoided and that even if you end up doing this for experimentation or development, **never** skip verification in production" ([curl SSL certificates](https://curl.se/docs/sslcerts.html)). ## How do you confirm the message actually arrived? Not from the `201`. Take the `id` from `data.id` and `GET /v1/scheduled-messages/{id}`, then read the status ladder: `pending`, `confirmed`, `received`, `read`, `played`, or `failed`. In a whatsapp api php client, a `201` only means the queue accepted it. `confirmed` means WhatsApp itself took the message, `received` is the double grey tick, `read` the double blue tick, and `failed` carries a `failureReason`. The field to watch is `waMessageKey`, and two things about it catch people out. It is an object (`fromMe`, `remote`, `id`, `_serialized`), not a string, and it is `null` on the response to a scheduled send because the engine has not dispatched yet. It fills in when the message actually goes out, which is why `confirmed` and a non-null `waMessageKey` arrive together. Your handle in the meantime is `id`: a 24-character hex queue id you can `GET`, `PATCH` before dispatch, or `DELETE` to cancel. Polling is fine for one message and stops being fine at volume. Past that, register a webhook and receive status changes instead. Registration, payload verification and duplicate handling all live in the [webhooks and auto-reply guide](/blog/whatsapp-api-webhooks-auto-reply), deliberately not summarised here. [image: A notebook checklist beside a phone on a wooden table, confirming WhatsApp message delivery] ## Where Blueticks fits for a PHP team, and where a BSP is the better call A hosted REST engine fits PHP shops for one structural reason: the maintained WhatsApp Web clients are Node projects. Running your own means supervising a Node process and a browser profile next to your PHP app forever. For template broadcast at scale or a multi-agent shared inbox, a Business Solution Provider is genuinely the better product. That is the argument for whatsapp api integration in php specifically. In Python or Node you can at least weigh a library against a hosted API. As of August 2026 a PHP team has no equivalent choice: whatsapp-web.js and Baileys are both Node, so "build it yourself" means a second runtime, a session store, a reconnect supervisor and a pager rotation for something that is not your product. The [Node bot guide](/blog/whatsapp-bot-nodejs) shows what that maintenance looks like. Where a BSP wins is not close. Approved marketing templates to 50,000 people, an Official Business Account badge, Meta's throughput tiers, ten agents on one inbox: that is what the [Cloud API and its partners](https://developers.facebook.com/docs/whatsapp/cloud-api) are built for, and [pricing is per delivered template message](https://business.whatsapp.com/products/platform-pricing). Our [read on when the Business API is worth it](/blog/is-whatsapp-business-api-worth-it) says the same. The trade is the number itself: one registered on the Cloud API stops being a normal WhatsApp number. The laravel whatsapp api case is the middle ground. Transactional volume, real conversations, replies that go to a human, a number your customers already have saved. One `Http::post` in a queued job. ## FAQ **Can I send a WhatsApp message from PHP without Composer?** Yes. The `curl_init` example above needs nothing beyond the cURL extension and runs on shared hosting. Composer only matters if you want Guzzle or the SDK, and neither adds capability, only ergonomics. **Which PHP versions does the Blueticks PHP SDK support?** Its `composer.json` declares `php: ^8.1`; its CI matrix and README list 8.1, 8.2 and 8.3. It installs on 8.4 and 8.5 because a caret constraint permits any 8.x, but those are not covered by its tests. On 8.4 or newer, accept that or call REST directly. **How do I stop a retry from sending the same WhatsApp message twice?** Send an `Idempotency-Key` header, computed once from the business object (`order-4471-shipped`) and stored with the job so every retry reuses it. A replay returns the original `201` and the same message id instead of sending again. Not the body `secret` field: that is a correlation tag, and sending the same one twice sends two messages. **Will sending from PHP get my WhatsApp number banned?** Nobody can guarantee it will not. You are messaging from your own number under [WhatsApp's Business Policy](https://www.whatsapp.com/legal/business-policy) and its [rules on automated and bulk messaging](https://faq.whatsapp.com/5957850900902049), and a loop firing unsolicited sends is the pattern most likely to get a number flagged. Message people who asked to hear from you, spread batches over hours, and stop when someone asks you to. --- # ChatGPT on WhatsApp in 2026: Where It Works, Where It Doesn't, and How to Get GPT Replies on Your Own Number > It was never a clean ban and unban. Meta banned, then charged a fee the Commission called equivalent to a ban. Here is where that leaves your number. URL: https://blueticks.co/blog/chatgpt-whatsapp Published: 2026-08-09 Author: Avi Kohen Category: industry You saved the contact, you used it for months, and one day the replies stopped. Then a colleague in Berlin told you it works fine for her. Both of you are right, and the reason is a country code. ## Is ChatGPT available on WhatsApp right now? Only if your WhatsApp number carries an EEA country code. OpenAI restored ChatGPT on WhatsApp across the European Economic Area on 13 July 2026, following an EU antitrust order against Meta. Everywhere else the assistant is still unavailable and no return date has been announced. Your ChatGPT WhatsApp status is decided by the block below. ### Status block, verified 2026-08-08 | Region | ChatGPT on WhatsApp | Basis | | --- | --- | --- | | **EEA** (27 EU states plus Iceland, Liechtenstein, Norway) | **Available.** Restored 13 July 2026 via the verified 1-800-ChatGPT contact | [OpenAI's own announcement](https://x.com/ChatGPT/status/2076654365121855835), following the [European Commission's interim measures](https://ec.europa.eu/commission/presscorner/detail/en/ip_26_1276) | | **United States** | **Not available.** No announced return date | Outside the only carve-out in [Meta's Business Solution Terms](https://www.whatsapp.com/legal/business-solution-terms) | | **United Kingdom** (not in the EEA since Brexit) | **Not available.** No announced return date | Outside the same carve-out | | **India** | **Not available.** No announced return date | Outside the same carve-out | | **Brazil** | **No announced availability.** Meta's terms do permit AI providers on +55 numbers, but OpenAI's July announcement named the EEA only | Meta's terms carve-out; OpenAI announcement scope | | **Rest of world** | **Not available.** No announced return date | Outside the carve-out | > **Re-check this block on any of three triggers:** a final European Commission decision in case AT.41034, any OpenAI announcement extending 1-800-ChatGPT beyond the EEA, or 60 days from publication, whichever comes first. Nothing else in this article depends on the table staying true. ### Eligibility follows your number, not your location A VPN will not help you and a holiday in Lisbon will not help you either. Meta's Business Solution Terms, last modified 6 March 2026, put the test on the number itself: general-purpose assistant technologies "may be made available to WhatsApp users who have registered phone numbers with a European Economic Area or Brazil country code." Registered country code, not device location, not IP address. That is also why the UK sits in the unavailable column despite being in Europe. The EEA is the 27 EU member states plus Iceland, Liechtenstein and Norway. Britain left, so +44 is outside the carve-out. ## Why did ChatGPT disappear from WhatsApp in the first place? Meta changed its own rules. On 15 October 2025 it introduced a policy banning third-party general-purpose AI assistants from the WhatsApp for Business API, leaving Meta AI as the only assistant on the platform. The Terms of Service update took effect on 15 January 2026, and OpenAI and Perplexity both wound their WhatsApp assistants down. The wording in the current terms is broad. Providers and developers of "large language models, generative artificial intelligence platforms, general-purpose artificial intelligence assistants, or similar technologies as determined by Meta in its sole discretion" are "strictly prohibited from accessing or using the WhatsApp Business Solution" where that technology is "the primary (rather than incidental or ancillary) functionality being made available for use." Read the qualifier, because it is the half most coverage drops. The bar lands on assistants as the *primary* functionality. Task-specific business bots survive it, and the terms say so directly: "Notwithstanding the foregoing, you may retain an AI Provider as your Third Party Service Provider." A bot that tracks orders, books appointments, answers support questions or chases an abandoned cart is still permitted, everywhere, and none of what follows in this article changes that. What is barred is turning your WhatsApp presence into a distribution channel for an open-ended assistant. One further clause matters if you already run an AI-assisted support flow: you may not let Business Solution Data train or improve any AI model, with a narrow exception for fine-tuning a model that is for your exclusive use. The [no-code agent walkthrough](https://blueticks.co/blog/build-whatsapp-agent-no-code) covers what a compliant, task-scoped setup looks like in practice. [image: Annotated printed policy pages spread on a desk, representing Meta's Business Solution terms and the EU interim measures] ## Why did it come back in Europe and nowhere else? Because a regulator ordered it, and the regulator's jurisdiction has a border. On 9 June 2026 the European Commission adopted interim measures against Meta in case AT.41034, ordering it to reinstate third-party general-purpose AI assistants on the WhatsApp for Business API and to keep them there until the investigation ends. The remedy is EEA-shaped because the underlying finding is. The Commission's press release is the primary document and it is worth reading in full rather than through recaps, because the sequence is more interesting than the summary. ### It was never a clean ban and unban Almost every secondary account tells this as a two-step story: Meta banned rival assistants, the EU made Meta stop. There was a third step in between, and it is the one that mattered. The Commission opened its investigation in December 2025, issued a Statement of Objections in February 2026, then a supplementary Statement of Objections in April 2026. In between, on 4 March 2026, Meta revised the policy and accepted third-party general-purpose AI assistants back onto WhatsApp. It just charged them for the privilege. In the Commission's words, Meta "charged a fee which, at first sight, is in practice equivalent to the previous access ban." Meta's own developer documentation shows what that looked like operationally. Charging for AI providers began on 16 February 2026 in Italy (+39), extended on 11 March 2026 to a list of 29 further countries which is precisely the rest of the EEA, and also to Brazil (+55) on the same date. Then, effective 13 May 2026, Meta "will no longer charge 'AI Providers' for non-template messages delivered to users in certain markets." The European entries drop off the rate card on that date. Brazil does not. So the fee wall came down in the EEA roughly four weeks before the interim measures decision, after the supplementary Statement of Objections had already telegraphed the order. The Commission still issued the decision, which tells you it wanted the access locked rather than voluntary. The order requires reinstatement "under the same terms and conditions that were in place before 15 October 2025, when such access was notably free of charge for all such AI assistants," maintained until a final decision, and it gave Meta five working days to comply. ### Why the remedy stops at the EEA border The legal basis explains the map. The Commission acted under Article 102 TFEU and Article 54 of the EEA Agreement, using the interim-measures power in Article 8(1) of Regulation 1/2003. Its preliminary finding is that Meta, through WhatsApp, "has at first sight held a dominant position in the **EEA-wide** market for consumer communication applications since at least January 2023." An EEA-wide dominance finding produces an EEA-wide remedy. It gives an American, British or Indian user nothing, not because anyone chose to exclude them, but because the Commission has no authority to order anything on their behalf. This was only the second time the Commission has imposed interim measures under Regulation 1/2003 in the regulation's history, which is a fair measure of how unusual the intervention was. Teresa Ribera, Executive Vice-President for Clean, Just and Competitive Transition, framed the urgency this way: "In rapidly evolving markets, competition can be lost long before a final decision is adopted. This is why these interim measures will remain in place for the duration of the investigation, in order to prevent harm that would be almost impossible to repair." One number that gets misquoted constantly, so here it is precisely. If Meta contravenes the interim-measures decision, the Commission may fine it up to 10% of "the total turnover in the business year preceding the infringement," and may separately impose daily periodic penalty payments of up to 5% of average daily turnover. That is a ceiling on a penalty for non-compliance, not an automatic fine, and not "10% of global annual revenue" as it is often rendered. ## What the European ruling does not give you as a business It reinstates access for AI providers, not for you. The order is about OpenAI and its peers putting their own assistants back on their own numbers. Whether an ordinary business may now run a general-purpose GPT assistant on *its* WhatsApp number through the Cloud API is a separate question, and the honest answer today is that it is unresolved. Here is why it stays unresolved rather than resolving in your favour. The carve-out in Meta's terms is drafted around who the technology is "made available to," and the prohibition itself turns on whether the assistant is "the primary (rather than incidental or ancillary) functionality being made available for use, **as determined by Meta in its sole discretion**." Sole discretion is not a standard you can plan a deployment against. An EEA business could read the carve-out as permission. Meta could read the same clause the other way on any given Tuesday, and nothing in the interim-measures decision constrains that reading, because the decision addresses AI providers' access rather than business customers' use cases. If you are building a task-specific bot, none of this touches you and the [build versus buy comparison](https://blueticks.co/blog/whatsapp-ai-agent) is the more useful read. If you want an open-ended assistant answering as your business on a Meta-issued number, you are betting on an ambiguity. That is the honest framing, and it is exactly why the next section exists. ## What you actually wanted: GPT replies on your number, not OpenAI's Most people searching for this do not want to chat with OpenAI's assistant. They want their own WhatsApp number to reply intelligently. Those are different products, and the second one never depended on the ruling at all. 1-800-ChatGPT cannot do it, even where it works. It is OpenAI's number, OpenAI's contact card, OpenAI's conversation. Your customers do not have it saved. Nothing you send through it goes out under your name, none of it lands in your chat history, and you cannot schedule from it, follow up on it, or route a reply into your CRM. It answers questions for whoever messages it. It does not run your inbox. The distinction that survives every regulatory change is whose number, whose contacts, whose automation. An assistant on OpenAI's number is a consumer utility whose availability is decided by a Commission timetable and a country code. An assistant on your number is infrastructure you control. If you are in the EEA and reading this thinking availability solved your problem, it solved a different one. [image: A face-down phone beside a notebook diagram, representing GPT replies on your own WhatsApp number] > **Your number, your contacts, your automation.** If you are in the US, the UK, India or anywhere else in the unavailable column, no announcement is coming to fix this for you, and there is no free assistant to fall back on. Connect the WhatsApp number you already use, wire it to the model you already pay for, and skip Meta verification, template approval and per-message fees entirely. [Start free at blueticks.co/signup.](https://blueticks.co/signup) ## How do you get GPT-powered replies on your own WhatsApp number? Three components, and none of them is the Meta Cloud API. You connect your existing WhatsApp account through WhatsApp Web or a hosted gateway, expose send and read as HTTP calls, and put a model between the inbound message and the outbound reply. Regulatory status is irrelevant to all three. **The connection is own-number, not Cloud API.** This matters more than it sounds. The Cloud API needs a Meta-issued or migrated number, business verification and approved templates, and it is the surface all of the policy above applies to. The own-number route drives the account you already have, linked once with a QR scan, which is why the AI provider terms are not the governing document. It is also why you get no Meta guarantees. Details of that trade-off are in the [own-number REST API guide](https://blueticks.co/blog/whatsapp-rest-api-own-number). **The model sits in a workflow platform, not in WhatsApp.** The practical shape is an inbound webhook, an OpenAI node or HTTP call to your model, and an outbound send. A send is a single POST with the recipient in the path and a flat JSON body, using an `Authorization: Bearer` header: ``` POST https://api.blueticks.co/v1/scheduled-messages/+441234567890 Authorization: Bearer bt_live_YOUR_KEY_HERE Content-Type: application/json { "type": "text", "text": "Thanks, I have your order. Shipping Tuesday." } ``` The full field list, the n8n, Make and Zapier equivalents and the expression mapping are already written up in the [workflow platform walkthrough](https://blueticks.co/blog/send-whatsapp-n8n-make-zapier). I am not going to rebuild it here. If you would rather skip the workflow layer and let an agent hold the connection directly, that is the [WhatsApp API for AI agents](https://blueticks.co/blog/whatsapp-api-for-ai-agents) route. **What this costs you in risk, stated plainly.** Nobody can promise your number will not be banned, and anyone offering that guarantee is overclaiming. WhatsApp's terms prohibit unauthorised bulk and automated messaging, and behaviour is what actually drives enforcement. Replying to people who messaged you first is the low end of the risk curve. Blasting a cold list is the high end, and no vendor changes that. Consent is yours to collect and yours to defend. Pacing, caps and opt-in discipline are build requirements, not disclaimers. ## Where Blueticks fits, and what it does not do yet Blueticks connects your existing WhatsApp number to a hosted engine and exposes it as a REST API and a hosted MCP endpoint, so a model can read chats and send messages as you. The free plan is $0 with three scheduled messages at a time, and there is no Meta verification step because there is no Cloud API involved. Now the part most vendors would leave out. Inside the product, **Claude is the connector that is officially supported today. ChatGPT and Gemini are both marked coming soon.** The backend already ships a ChatGPT-shaped tool manifest, so the work is real and in progress, but the in-product connector is not live and I am not going to imply otherwise. If you want a GPT model specifically, today that means routing through the REST API and a workflow platform or your own code rather than a one-click connector. If Claude is acceptable, the [MCP integration](https://blueticks.co/blog/connect-whatsapp-to-claude-mcp-integration) is the two-minute path. ## FAQ **Is ChatGPT on WhatsApp banned?** It depends entirely on the country code of your WhatsApp number. See the status block near the top of this article, which is dated and is the only place availability is stated. The underlying rule is that Meta's Business Solution Terms bar general-purpose AI assistants from the WhatsApp for Business API, with a carve-out for numbers registered with an EEA or Brazil country code. **Can I put a ChatGPT bot on my own WhatsApp number?** Not through the Meta Cloud API with any confidence. Meta's terms bar general-purpose assistants as primary functionality "as determined by Meta in its sole discretion," and the European ruling addressed AI providers' access rather than business use cases, so that question is genuinely open. You can run GPT-powered replies on your own number over WhatsApp Web or a hosted gateway, which is a different mechanism and not governed by those terms. **Are AI chatbots allowed on WhatsApp at all now?** Yes, if they have a job. Task-specific business bots for support, orders, bookings and notifications remain permitted worldwide and were never the target. The terms even provide for retaining an AI provider as your third-party service provider. What is barred is an open-ended general-purpose assistant as the primary function. **Will ChatGPT come back to WhatsApp in the US, UK or India?** No return date has been announced for any of them. The European reinstatement came from a Commission order grounded in an EEA-wide dominance finding, which has no reach outside the EEA. Absent a similar intervention by another regulator or a voluntary decision by Meta, there is no mechanism in play that would restore it elsewhere. **What is the difference between using 1-800-ChatGPT and running GPT on my own number?** Whose number it is. 1-800-ChatGPT is OpenAI's contact answering whoever messages it, with no connection to your customers, your chat history or your CRM. Your own number sends under your name, to contacts who already have you saved, with scheduling, follow-ups and delivery status you can act on. **Does any of this affect the WhatsApp Business app or ordinary business messaging?** No. Everything above concerns the WhatsApp for Business API and general-purpose AI assistants on it. Normal business messaging, the WhatsApp Business app, and per-message Cloud API pricing are unchanged by the AI provider policy. [image: Two people planning an automation flow with blank cards on a meeting table] ### Notes on sourcing The regulatory facts here come from the European Commission's own press release for case AT.41034, read through the presscorner API rather than the rendered page, which serves no article text. The policy wording comes from Meta's Business Solution Terms and its AI provider pricing documentation. OpenAI's help centre blocks automated access, so the EEA restoration is sourced to OpenAI's own public announcement and to the Commission decision, and the numeric form of the 1-800-ChatGPT contact has been deliberately left out rather than reproduced from a secondary source. --- # How to Send WhatsApp Messages from n8n, Make, or Zapier On Your Own Number (2026) > There is no Blueticks node to search for. There is an HTTP Request node and an API key, and that is enough. Every field, for all three platforms. URL: https://blueticks.co/blog/send-whatsapp-n8n-make-zapier Published: 2026-08-07 Author: Daniel Roth Category: productivity You already have the workflow. A form fills, a payment clears, six steps run. The step you cannot find is the one that puts a WhatsApp message in front of a human, from the number that human already has saved. ## Can you send WhatsApp messages from n8n, Make, or Zapier without the Meta Cloud API? Yes. You send it as a plain HTTPS POST to an own-number WhatsApp API, which drives your existing WhatsApp account through WhatsApp Web or a hosted gateway rather than Meta's Cloud API. No business verification, no template approval, no Meta-issued number. Be clear on what that looks like in the builder, because this is where guides mislead people. **There is no Blueticks app in Zapier, no Blueticks module in Make, and no n8n WhatsApp node for Blueticks, built-in or community.** Search the picker and you will find nothing. What you use instead is the generic HTTP Request node (n8n), the HTTP app (Make), or Webhooks by Zapier, pointed at `https://api.blueticks.co/v1/...` with a `bt_live_` API key in an `Authorization` header. That is the whole integration, it works identically on all three platforms, and it is why the rest of this article is about fields rather than apps. Honest counterpoint up front: if your job is template broadcast to tens of thousands of numbers, or a shared inbox with six agents, read [the BSP section](#when-should-you-use-a-bsp-instead-of-any-of-this) before building anything. ## What do you need before you build the workflow? Four things, and only one takes real setup. This is a checklist, not a tutorial, and each item links to where it is actually taught. 1. **A connected WhatsApp number.** Your existing account, linked once through the browser extension or the always-on cloud gateway. The gateway is the one that keeps sending with your laptop shut. 2. **A `bt_live_` API key.** What it unlocks and where it belongs are in [the own-number REST API guide](https://blueticks.co/blog/whatsapp-rest-api-own-number). 3. **An account on one of the three platforms.** n8n Cloud or self-hosted, Make, or Zapier. 4. **A publicly reachable callback URL**, only if you want replies and delivery status back. One number to plan around: on a free plan the `/v1` API allows **5 requests per 6-hour window**, shared across REST and MCP. An active subscription lifts it. It will stop a test loop dead. > **Read this before you build a loop.** A workflow platform makes an unattended blaster a four-node job. One send per row of a 5,000-row sheet, back to back, is the most reliable way to get your number restricted. Batching, delays and caps are covered below, and they are build instructions, not disclaimers. ## How do you send a WhatsApp message from n8n with the HTTP Request node? An n8n WhatsApp send is one node. Drop in **HTTP Request**, set Method to POST, put the recipient in the URL path, attach a header credential carrying your key, and send a JSON body with a `type` discriminator. No installation, because the node ships with n8n. [image: Hands on a keyboard beside a sheet of handwritten notes, setting up an HTTP request node] Every field, using [n8n's own HTTP Request node labels](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.httprequest/): | Field | Value | | --- | --- | | **Method** | `POST` | | **URL** | `https://api.blueticks.co/v1/scheduled-messages/+5511987654321` | | **Authentication** | `Generic Credential Type` | | **Generic Auth Type** | `Header Auth` | | Header credential → **Name** | `Authorization` | | Header credential → **Value** | `Bearer bt_live_YOUR_KEY_HERE` | | **Send Body** | on | | **Body Content Type** | `JSON` | | **Specify Body** | `Using JSON` | Two details trip people up. The recipient lives **in the path**, not in a `to` body field: the endpoint is `POST /v1/scheduled-messages/{chatId}`, and the segment takes E.164 with a leading plus (`+5511987654321`, `+4915123456789`) or a WhatsApp chat id (`5511987654321@c.us`, or `...@g.us` for a group). And the Authentication dropdown offers `Predefined Credential Type` first; there is no predefined entry here, so pick `Generic Credential Type` → `Header auth`. The body is flat, with no nested `media` or `poll` objects, and `type` is required even for plain text. To defer rather than fire now, add `sendAt`: camelCase, ISO 8601 with an offset, at least 10 seconds ahead and at most 365 days out. ```json { "type": "text", "text": "Reminder: your appointment is tomorrow at 14:00.", "sendAt": "2026-08-08T09:00:00+02:00" } ``` Per the endpoint's published response schema, the fields you branch on are `id`, `waMessageKey` (the message key object, **not** `key`, and null until the engine dispatches), `status`, and the `confirmedAt` / `receivedAt` / `readAt` / `failedAt` timestamps. The status enum runs `pending` → `confirmed` → `received` → `read` → `played`, with `failed` terminal: `confirmed` means WhatsApp accepted it, `received` is the second grey tick. For the same call in cURL, Python or Node, see [the API first-send guide](https://blueticks.co/blog/send-whatsapp-message-from-api). ### Mapping a trigger's output into the request body in n8n This is where a working whatsapp n8n integration usually stalls: the send works with a hardcoded string and breaks the moment real trigger data arrives. n8n uses `{{ }}` delimiters, `$json` for the current item, and `$('Node Name')` for any earlier node. Say a Webhook node named `New Order` receives `{"customer": {"phone": "+4915123456789", "name": "Lena"}, "order_id": 4417}`. In expression mode the URL becomes `https://api.blueticks.co/v1/scheduled-messages/{{ $json.customer.phone }}`, and the body references the named node so it survives extra steps between trigger and send: ```json { "type": "text", "text": "Hi {{ $('New Order').item.json.customer.name }}, order #{{ $('New Order').item.json.order_id }} is confirmed." } ``` `$json` is documented as shorthand for `$input.item.json`, so it points at whatever the immediately preceding node handed you. Insert a Set or Filter node between trigger and send and `$json.customer.phone` silently becomes undefined, and the request 400s on the path parameter. The named form keeps working, and [n8n's page on referencing previous nodes](https://docs.n8n.io/build/work-with-data/reference-data/reference-previous-nodes) adds `.first()` and `.last()` for ambiguous item pairing. Two more traps: numbers without the leading `+` fail the E.164 check, and an expression resolving to an empty string leaves a trailing slash that reads as a missing recipient. ### Why your n8n webhook never fires when you self-host Self-hosted n8n derives its webhook URL from environment variables, and behind Docker, NAT or a reverse proxy the URL printed in the editor is not the URL the outside world can reach. Nothing errors. The callback simply never arrives. The mechanism is explicit in the docs: n8n "creates the webhook URL by combining `N8N_PROTOCOL`, `N8N_HOST` and `N8N_PORT`. If n8n runs behind a reverse proxy, that won't work." Set it manually with `N8N_WEBHOOK_URL`, which [n8n's reverse-proxy configuration page](https://docs.n8n.io/deploy/host-n8n/configure-n8n/basic-configuration/configuration-examples/configure-webhook-urls-with-reverse-proxy) notes replaces the deprecated `WEBHOOK_URL` (still accepted, logs a deprecation warning), and set `N8N_PROXY_HOPS` to the number of proxies in front of you. Diagnose in order. Copy the URL n8n shows and `curl` it from outside your network; a timeout or a private address means the URL is the problem, not the workflow. Then confirm you are on the **Production URL**: per the [Webhook node docs](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.webhook/), the Test URL only listens while you are actively watching for a test event, while the production URL registers on publish and its runs land in the Executions tab. The ways out are a tunnel for development, a correctly configured reverse proxy, or n8n Cloud. ## How do you send a WhatsApp message from Make.com? Add the **HTTP** app's **Make a request** module, or **Make an API Key Auth request** to store the key as a reusable connection. Same POST, same path-based recipient, same flat body. [image: An open notebook showing an unlabelled flow sketch beside a stopwatch, planning batched WhatsApp sends] To send whatsapp from make.com, set **URL** to `https://api.blueticks.co/v1/scheduled-messages/+5511987654321`, **Method** to `POST`, one **Headers** row of `Authorization` / `Bearer bt_live_YOUR_KEY_HERE`, **Body type** `Raw`, and **Content type** `JSON (application/json)`. Make's mapping is the second of three dialects here. Rather than typing an expression, you click the field and pick the item from the mapping panel, which inserts a token prefixed by the source module's id. You type the JSON scaffolding by hand in **Request content** and drop tokens into the string positions, like `"text": "Hi {{2.name}}, your booking on {{2.date}} is confirmed."`. That numeric prefix matters when you clone a scenario: cloned modules get new ids, so a mapping that looks fine can point at the wrong module. ### What Make's blocking HTTP module means for your scenario's operation count Make meters per module run, and the HTTP module blocks while waiting for the response. A scenario iterating 500 rows and sending one message each does not cost one unit. It costs at least 500, plus the iterator's own run, and it holds an execution slot for all 500 round trips. Make's help centre defines an operation as a single module run to process data or check for new data, with the count depending on how many bundles the module processes; their worked example is a Send-an-email module sending 5 emails costing 5 operations. Your HTTP module behaves the same. As of August 2026, [Make's pricing page](https://www.make.com/en/pricing) expresses plan allowances in **credits**, most actions consuming one each. Treat the vocabulary as movable and the model as stable: one module run, one billable unit. Read the live page, not any number in a blog post. The blocking part has a second cost that never reaches an invoice. At 800ms per send, 500 sends is roughly seven minutes of one scenario holding its slot, so on a tighter schedule runs overlap or queue. Batch across runs instead. ## How do you send a WhatsApp message from Zapier? Use the **Webhooks by Zapier** app, action event **POST** for a normal JSON send, or **Custom Request** when you need control over the raw body. Zapier's help docs list four send actions: GET, POST, PUT and Custom Request. [image: A paper ledger marked with pencil tally strokes, representing counting per-task automation costs] For a whatsapp zapier integration, the POST action takes **URL** (`https://api.blueticks.co/v1/scheduled-messages/+919876543210`, phone inserted through the field picker), **Payload Type** set to `JSON` rather than Form or XML, **Data** as key/value rows (`type` → `text`, `text` → your message), and **Headers** carrying `Authorization` / `Bearer bt_live_YOUR_KEY_HERE`. The field picker is the third mapping dialect: click into a field, choose the source step, and Zapier inserts a token. No expression syntax, but no inline string manipulation either, so anything needing a transform before it hits the path is a Formatter step in front of the webhook. Body handling differs by action: POST builds key/value pairs, while [Custom Request](https://help.zapier.com/hc/en-us/articles/8496326446989-Send-webhooks-in-Zap-workflows) sends raw JSON from the Data field exactly as entered, unparsed. ### What a fan-out costs you on Zapier's per-task pricing Zapier bills per task, and a task is any successful action that runs. A Zap sending to 500 recipients costs roughly 500 tasks every time it runs, scaling linearly in a way a self-hosted n8n instance does not. Two parts of that accounting are free, and getting them right changes the estimate. Per [Zapier's plan and pricing FAQs](https://help.zapier.com/hc/en-us/articles/8496196837261-Zapier-plan-and-pricing-FAQs), "Zap triggers never use tasks", and Filter, Paths, Formatter, Delay and Looping steps do not consume tasks either. Only successful actions count. So the 500-recipient fan-out is: trigger free, Looping step free, 500 successful POSTs at 500 tasks. Run it weekly and one workflow is 2,000+ tasks a month. [Zapier's pricing page](https://zapier.com/pricing), read on 7 August 2026, puts the free plan at 100 tasks per month and starts paid tiers at 750, which makes a single 500-recipient send five times the entire free allowance. Tiers move, so check the live page. ## How do you get replies and delivery status back INTO your workflow? Two directions, and they are not symmetrical. Inbound (your workflow calling the API) is everything above. Outbound (a WhatsApp event pushing into your workflow) means giving the sender a URL and naming the events to push. Registration and signature verification are covered in [the webhooks and auto-reply guide](https://blueticks.co/blog/whatsapp-api-webhooks-auto-reply); this section is only about which node catches the event. In **n8n**, add a **Webhook** node, set Method to POST, publish the workflow, copy the **Production URL**, and branch with a Switch or IF node on the event field. There is no first-party n8n guide, so this is the build-it-yourself path, and reachability matters more here than anywhere else. **Make and Zapier** are easier, because Blueticks ships first-party outbound guides for both. In Zapier, start a Zap with **Webhooks by Zapier → Catch Hook** and copy the generated URL; in Make, add a **Custom webhook** module and copy its address. Paste that URL into the Webhooks tab of the Blueticks API page. Screenshot walkthroughs live in-product at [the Zapier webhook guide](https://app.blueticks.co/webhook-zapier-guide) and [the Make webhook guide](https://app.blueticks.co/webhook-make-guide). To be exact: outbound-only guides for receiving events, not native apps, and they do not send anything. Watch the vocabulary here, because it trips people: the webhook **event names are a different set from the `status` values you polled earlier, and they do not line up one-to-one**. The events are `message.queued`, `message.sending`, `message.delivered`, `message.failed` and `message.read`. Internally they are driven off the message's own status, and the mapping is not the one the names suggest — `message.delivered` fires when the message reaches **`confirmed`**, and its payload carries `status: "confirmed"`, not `"delivered"`. There is no `message.received` event at all. So a Switch node keyed on the status expecting `received` will simply never fire — in fact `received` never appears in any webhook payload at all. **Branch on the event name**, which arrives as `type` at the top level of the body; the message itself sits under `data`, so the status you would otherwise have tested is `data.status`. Retries are the subtle part: every platform will happily re-fire a step, and a request-level `Idempotency-Key` header exists for exactly that, worked out in [the automation API guide](https://blueticks.co/blog/whatsapp-automation-api). The platform-specific half is only that each retry must reuse the same key rather than minting a fresh one. If you wanted the agent-driven path instead of a workflow builder, that is [the MCP route](https://blueticks.co/blog/build-whatsapp-agent-no-code). ## How do you send to a list without getting your number restricted? Batch it, delay between sends, cap the run, and stop on the first error instead of retrying into a wall. Nobody can promise a number will not be restricted, and anyone who does is selling something. What you control is the shape of the workflow. The concrete build, in n8n terms, with equivalents on all three: 1. **Batch.** Put a **Loop Over Items** node (in the picker as Loop Over Items, formerly Split In Batches) in front of the HTTP Request and set **Batch Size** small. Thirty is a starting point, not a magic number. 2. **Delay.** Add a **Wait** node inside the loop, Resume set to `After Time Interval`, then set **Wait Amount** and **Wait Unit**. Seconds, not milliseconds. Uniform intervals are themselves a pattern, so vary it if your data allows. 3. **Cap the run.** Limit how many messages one execution can send and let tomorrow's take the rest. A cap is the only control that survives a bad input file. 4. **Stop on error.** Leave "Retry On Fail" off for the send node and route the error output somewhere you will look. A retry storm against a struggling connection turns one failure into fifty. On Make the same shape is an Iterator plus a Sleep module; on Zapier it is Looping by Zapier plus Delay, neither of which consumes tasks, so pacing there is free. If your list starts in a spreadsheet, [the bulk-from-spreadsheet guide](https://blueticks.co/blog/bulk-schedule-whatsapp-messages-from-spreadsheet) covers the data side. And one sentence on consent, because it is not ours to carry: **collecting opt-in from every recipient is the sender's responsibility.** Be clear-eyed about what that does and does not buy you — WhatsApp's own position is unconditional: its products are [not intended for bulk or automated messaging, both of which have always been a violation of its Terms of Service](https://faq.whatsapp.com/5957850900902049). Opt-in lowers the chance recipients report you; it does not grant permission. ## When should you use a BSP instead of any of this? Two cases, and neither is close. If you are broadcasting approved templates to tens of thousands of numbers, use a Business Solution Provider on Meta's Cloud API. That is what the platform is engineered for: high daily throughput ceilings, a quality-rating system, and messaging limits that scale up as you behave well. An own-number API runs at personal-account scale, and no workflow design changes that. The second case is a shared inbox. If four or six agents need to work the same WhatsApp number, with assignment, internal notes and handover, you want a proper BSP-backed agent desk. An own-number API gives your code a way to send and receive. It does not give six humans a queue to work from. There are real costs on the other side, which is why the own-number path exists at all: business verification, template approval before you can message outside the 24-hour service window, and per-message billing on [Meta's published pricing](https://developers.facebook.com/docs/whatsapp/pricing/). But in either of those two situations the HTTP Request node is the wrong tool, and you will find out in month two rather than week one. [The BSP alternatives comparison](https://blueticks.co/blog/whatsapp-business-api-alternatives) is where to start that evaluation. ## What does Blueticks add once your workflow is running? Look at what the workflow is not doing. Your HTTP Request node fires and returns. There is no send queue behind it, so a burst goes out as a burst. No backoff except the retry logic you hand-built. No delivery state beyond what you poll for or catch in a webhook you wired yourself. No pacing except the Wait node you remembered to add, and no record of what went out except execution history that rolls off. Blueticks is what the HTTP node is calling. The queue, the connected WhatsApp session, the gateway that keeps sending with your laptop closed, the delivery lifecycle that produces `confirmed` / `received` / `read`, the scheduling window that lets `sendAt` mean something 90 days out: that is the part you would otherwise build and then maintain. Which is why this integration is one node instead of a subsystem. The workflow platform decides *when* and *to whom*, using triggers you already have wired. The API owns sending it reliably and telling you what happened. Point your HTTP Request node at a `bt_live_` key from [a free account](https://blueticks.co/signup) and the send side collapses into one POST. ## FAQ **Is there a Blueticks n8n node?** No. There is no n8n WhatsApp node for Blueticks, built-in or community, and no Zapier app or Make module either. You use the generic HTTP Request node, the HTTP app's Make a request module, or Webhooks by Zapier, pointed at `https://api.blueticks.co/v1/` with your key in an `Authorization` header. **Does this use the WhatsApp Cloud API?** No. It sends through your own existing WhatsApp account, over WhatsApp Web or a hosted gateway. That is why there is no business verification, no template approval and no Meta-issued number, and also why it runs at personal-account scale. **Will my number get banned?** Nobody can guarantee it will not, and treat any guarantee as a red flag. WhatsApp states plainly that its products are [not intended for bulk or automated messaging, both of which have always been a violation of its Terms of Service](https://faq.whatsapp.com/5957850900902049) — that is unconditional, not something opt-in exempts you from, and restriction is a real outcome. Batch, delay, cap the run, and only message people who opted in. **Can I send images and PDFs from a workflow?** Yes. Set `"type": "media"` and supply `mediaUrl` (https only) or `mediaBase64`, with `text` doubling as the caption. There is no separate `caption` field. Details are in [the image and document guide](https://blueticks.co/blog/whatsapp-api-send-image-pdf-document). **What does a 500-recipient send cost on Zapier versus self-hosted n8n?** On Zapier, roughly 500 tasks, since successful actions count while triggers, filters and looping steps do not. Self-hosted n8n costs compute, with no per-execution fee. Make sits between them at one billable unit per module run. Figures live on [Zapier's pricing page](https://zapier.com/pricing) and [Make's pricing page](https://www.make.com/en/pricing). **Can I schedule a message instead of sending it now?** Yes. Add `sendAt` as an ISO 8601 timestamp with an offset, at least 10 seconds ahead and no more than 365 days out. The scheduling contract, including editing and cancelling a queued message, is in [the own-number REST API guide](https://blueticks.co/blog/whatsapp-rest-api-own-number). **Which platform should I pick for whatsapp automation n8n workflows specifically?** If you are already on one, stay there, because the integration is identical on all three. If you are choosing fresh and expect fan-outs, self-hosted n8n is the only one where sending to 500 people does not multiply the bill by 500. --- # WhatsApp Business API Alternatives in 2026: Named Tools Compared (What Each Is Actually Best For) > Thirteen named tools, priced from each vendor's own page in August 2026. Which are still the official API, which skip it entirely, and when you should just use a BSP. URL: https://blueticks.co/blog/whatsapp-business-api-alternatives Published: 2026-08-06 Author: Avi Kohen Category: industry You priced the WhatsApp Business API, saw the Meta verification queue and the per-message meter behind it, and started looking for something else. Half the "alternatives" you find are the same API with a different logo on the dashboard. The other half never say what they connect to. This piece names thirteen tools and prices every one from the vendor's own live page, pulled on 2026-08-06. No aggregators, no review sites. Where a vendor does not publish a figure, that is stated instead of guessed. ## Why do people look for a WhatsApp Business API alternative in the first place? Three rejection triggers account for almost all of it: Meta business verification, the per-message meter, and being pushed onto a separate business number. None is a complaint about the API's quality. They are complaints about its entry cost. The verification trigger is procedural. Per [Meta's messaging limits documentation](https://developers.facebook.com/documentation/business-messaging/whatsapp/messaging-limits), a newly created business portfolio starts at a messaging limit of 250. The definition is narrower than it sounds: it counts unique numbers you deliver to "outside of a customer service window, within a moving 24-hour period," it is set at portfolio level and shared across every phone number in that portfolio, and replies inside an open service window do not count. The routes to 2,000 are to verify your business, have a partner verify it, or send 2,000 delivered template messages to unique numbers over a 30-day moving period at a high quality rating. The meter trigger is arithmetic. Effective July 1, 2025, [Meta charges the Business Platform per message rather than per conversation](https://developers.facebook.com/documentation/business-messaging/whatsapp/pricing), and marketing templates are charged. The main exception is the free entry point window: reply within 24 hours to a user who arrived through a Click to WhatsApp ad or a Facebook Page call-to-action button, from the Android or iOS app, and Meta opens a 72-hour window in which any message type, templates included, is free. The number trigger is the one people underestimate. [Meta's business phone number documentation](https://developers.facebook.com/documentation/business-messaging/whatsapp/business-phone-numbers/phone-numbers) states that numbers already in use with WhatsApp cannot be registered unless they are deleted first. The number your customers have saved is not automatically available to you. Whether you belong on the API at all is settled ground here. The decision framework is in [WhatsApp Business app vs API](https://blueticks.co/blog/whatsapp-business-app-vs-api); the readiness test is in [do I need the WhatsApp Business API](https://blueticks.co/blog/do-i-need-whatsapp-business-api). Assume both are done. This starts at the shortlist. ## What are the two kinds of alternative: a cheaper BSP, or skipping the API entirely? There are exactly two categories, and confusing them is the most expensive mistake in this search. Category A is still the official WhatsApp Business Platform, bought through a different reseller or at a different price shape. Category B does not touch the API and drives the WhatsApp account you already have. Category A inherits every API property: verification, template approval, a dedicated number, Meta's per-message charges. What changes is the software wrapped around it and the markup. Meta routes businesses to these through the "Find a Partner" flow on the [WhatsApp Business Platform site](https://whatsappbusiness.com/products/business-platform/), which is a matching tool rather than a browsable list you can look a vendor up in. Category B pairs with an existing WhatsApp account, typically by QR scan, and sends through that session. No verification, no template queue, no meter, and the sending identity is the number your contacts already have. Note that the two categories are product lines, not companies: several vendors sell into both. The reasoning behind picking a lane is published in [is the WhatsApp Business API worth it](https://blueticks.co/blog/is-whatsapp-business-api-worth-it). What follows is the vendor list. ## Which named tools run on the official API, and what does each one actually sell you? Seven tools here ride the official API, and asking which is the best WhatsApp API provider is the wrong question until you know what you are buying. They differ less on features than on what they are structurally for: a team inbox, a commerce hub, raw number hosting, or metered infrastructure. [image: Printed vendor proposals stacked and annotated during a WhatsApp API provider evaluation] | Tool | Structurally for | Pricing model | Entry price, verified 2026-08-06 | | --- | --- | --- | --- | | Wati | All-round team inbox and campaign suite | Subscription + message charges on Wati's own rate card | Growth $69/mo month-to-month, or $708/yr (about $59/mo) in USD markets | | AiSensy | India-first broadcasting and Meta ads | Subscription + recharged conversation credits + paid add-ons | Basic ₹1,500/mo on the India page; $45/mo on the USD page | | Interakt | WhatsApp plus Instagram commerce hub | Subscription + per-message charge by template category and region | Growth $55/mo plus taxes on the US page | | Zoko | Ecommerce and Shopify order flows | Subscription with a conversation allowance or markup | Starter $49.99/mo, with $0.015 markup on all conversations at that tier | | DoubleTick | Bot-building and broadcast for sales teams | Subscription, quoted annually | Starter $169.9/mo billed yearly | | Twilio | CPaaS infrastructure, not a marketing product | Pure usage, no subscription | $0.005 per message, inbound or outbound, plus Meta's template fees | | 360dialog | Number hosting and API access, sold per number | Flat fee per number + Meta at pass-through | Regular €49 per number per month, plus Meta messaging fees | What the table cannot show, from each vendor's own page in August 2026: **Wati** prices by geography rather than one global card: Growth resolves to ₹2,699/month month-to-month on the India card and $69 in USD markets, and lists 1 channel, 3 users, 15,000 broadcasts and 1,000 automation triggers. One thing to catch for cost modelling: its page does not describe message charges as Meta pass-through, it says usage is "Charged based on WATI rate card." **AiSensy** has a Free Forever tier that includes the official API and a Blue Tick application, but its own page states broadcasting is not available on it. Paid tiers run ₹1,500, ₹3,200, ₹9,100 and ₹45,000, or $45, $99, $299 and $899 on the USD page, and the chatbot builder is a separate ₹2,500/month add-on. **Interakt** sells the second channel: Growth and Advanced both cover WhatsApp and Instagram in one inbox. Its Starter tier reads "Not Applicable" on the main matrix and appears separately at $12/month for Instagram only, and its pricing URL redirects by region, so stamp any Interakt figure with where you saw it. **Zoko** prices conversations rather than seats, with Elite at $139.99/month including 100,000 conversations at no markup. **DoubleTick** publishes both six-month and annual terms; the headline $169.9 and $217.8 are the monthly equivalents of the annual ones. **Twilio** is the one people miscategorise. It sells infrastructure: no platform subscription, Meta's template fees passed through, and you build the product yourself. **360dialog** sells the number and the pipe, publishing 80 messages per second standard throughput and up to 1,000 on High Throughput; its €99 Marketplace tier also lists a "Messaging tool package," so check which tier you are pricing before assuming you need to supply your own front end. Which of these builds better multi-step sequences is a different axis, answered in the [drip campaign tool buyer's guide](https://blueticks.co/blog/best-whatsapp-drip-campaign-tools). ## Which named tools send from your own number without the API? Six tools here can send from a WhatsApp account you already have, paired by QR scan rather than provisioned through Meta. They split into three mechanisms: a browser extension, a hosted paired session behind a developer API, and a shared-inbox layer over connected numbers. Two of them, Green API and TimelinesAI, also sell an official WhatsApp Business API product alongside the paired one. [image: A face-down smartphone beside a handwritten notebook, representing sending from your own WhatsApp number] | Tool | Paired-session mechanism, per the vendor's own description | Pricing model for the paired product | Entry price, verified 2026-08-06 | | --- | --- | --- | --- | | Blueticks | Chrome extension driving WhatsApp Web, plus an optional hosted 24/7 gateway | Flat subscription, no per-message fee | Free plan $0; paid from $9/mo ($7 annual) | | WASenderApi | QR-scan pairing of your WhatsApp account, developer REST API | Flat per-connected-number subscription | Basic $6/mo for 1 number ($5.10 annual) | | Green API | Paired instances with a developer API and SDKs (also sells a separate official WABA product) | Flat monthly per instance on the paired product; the WABA product is metered per message | Developer $0/mo; Business $12/mo | | Maytapi | QR pairing of a phone, REST API for chats, groups and channels | Flat per phone | Sandbox free; Developer $29 per phone per month, or $24 billed annually | | TimelinesAI | Shared inbox and CRM sync over regular WhatsApp numbers (also publishes a WABA integration) | Per seat | CRM Integration $25/seat/mo | | Periskope | Multi-number, multi-agent inbox with a groups focus | Per user and per phone, billed separately | Starter $20/user/mo month-to-month, $15 annual | The mechanism differences matter more than the prices. **Blueticks** is a browser extension driving WhatsApp Web, plus a hosted cloud gateway so sends continue when the browser is closed. It is not a Meta API provider and should not be read as one in these tables. On blueticks.co as of 2026-08-06, Basic and Standard are labelled "Browser-Only Sending - Must keep WhatsApp Web open"; "Works when you're offline" appears only on Pro, at $50/month ($45 annual). **WASenderApi**, **Green API** and **Maytapi** are the developer end. WASenderApi describes onboarding as "Scan a QR code to link your WhatsApp account securely with our platform in seconds," at $6, $15, $30 and $45 a month for 1, 3, 6 and 10 numbers. Green API ships SDKs in Python, Node.js, PHP, Java, Go and 1C, and separately runs the official WABA product described above, which carries a per-country monthly subscription plus per-category message rates and an optional credit line. Maytapi's free Sandbox is capped at 5 conversations a month and 150 messages a day, and its Developer plan is $29 per phone per month with $24 the annual-commit rate. **TimelinesAI** and **Periskope** are inbox layers rather than senders. TimelinesAI's pricing page states it "works with regular WhatsApp numbers that are connected to either WhatsApp Business or WhatsApp Messenger," at $25, $40 and $60 per seat, and its help centre documents a parallel WABA integration. Periskope's feature list says "Custom APIs and Webhooks for WhatsApp groups, chats and numbers (no Business API required)," and its page carried a "Prices are increasing soon" banner on 2026-08-06, so treat its figures as current-but-expiring. One structural fact applies to the QR-linked mechanism itself, Blueticks included, and it belongs here rather than buried in an FAQ. Sending through a paired WhatsApp session runs outside the WhatsApp Business Platform, so it is not part of Meta's solution-partner programme and carries none of Meta's platform commitments on throughput, delivery or account standing. That is a statement about the mechanism, not about any vendor's conduct. Two of the six are not only that, and the distinction matters when you shortlist. **Green API** also sells an official product headed "WhatsApp Business API (WABA): Official Integration," with template messages, a per-country subscription and per-category message rates. **TimelinesAI** publishes a WABA integration too, including WhatsApp Coexistence. On those official products Meta's commitments apply, and so does Meta's meter. Price each product line separately rather than treating the company as one category. Consent is entirely yours either way: no own-number tool collects opt-in for you, and the [own-number REST API guide](https://blueticks.co/blog/whatsapp-rest-api-own-number) covers the pacing discipline that goes with it. ## What are the best Wati alternatives in 2026, and which one replaces what? The best Wati alternative depends on which part of Wati you are paying for. Wati bundles four jobs: a multi-agent shared inbox, broadcast campaigns, chatbot automation, and BSP access to the API. Different tools replace different pieces, and no single product replaces all four for less. - **Same job, cheaper.** The obvious Interakt alternative case runs in reverse here: Interakt at $55/month Growth is the closest swap, with AiSensy at ₹1,500/month Basic behind it. Both are on the official API with published entry prices below Wati's. - **Ecommerce order flows, not a general inbox.** Zoko at $49.99/month Starter. - **Only the API and the number, not the software.** 360dialog at €49 per number per month with Meta at pass-through, or Twilio at $0.005 per message and no subscription if you have engineers. - **The multi-agent inbox specifically.** TimelinesAI at $25/seat and Periskope at $20/user are inbox-first products working over regular numbers. - **Stop paying Meta per message.** That is the own-number camp, a different product rather than a cheaper Wati. The same logic answers the AiSensy alternative question: if flows are what you need, its ₹2,500/month add-on is the line item to compare, not the base plan. Here is the honest structural point, and it is why this section exists. If what you are paying Wati for is the multi-agent shared inbox, most of the own-number camp does not replace it, and **Blueticks does not have a multi-agent shared inbox at all**. Blueticks is a single-operator tool: your number, your sends, scheduled and sequenced. If three agents need to work the same queue with assignment and handoff, the honest answers on this list are Wati, Interakt, TimelinesAI or Periskope. The app-level ceilings that start this search are catalogued in [WhatsApp Business app limitations](https://blueticks.co/blog/whatsapp-business-app-limitations). ## Setup and verification side by side: what does each tool require before your first message? The setup gap is wider than the price gap. Official-API tools require a Meta business portfolio, usually business verification, and a number not currently registered on WhatsApp. Own-number tools require a QR scan. That difference is measured in weeks against minutes. | Requirement | Official-API tools (Wati, AiSensy, Interakt, Zoko, DoubleTick, Twilio, 360dialog) | Own-number tools (Blueticks, WASenderApi, Green API, Maytapi, TimelinesAI, Periskope) | | --- | --- | --- | | Meta business portfolio | Required | Not required | | Business verification | One of three routes to lift the 250 starting limit toward 2,000 | Not applicable | | Display-name review | Not needed to start sending. Triggered when you reach a higher messaging limit, and changes then need approval before use | Not applicable | | Dedicated new number | Usually. A number already in use with WhatsApp cannot be registered unless deleted first | No. Uses the number already on your phone | | Template pre-approval | Required outside the 24-hour service window | Not applicable | | Onboarding queue | Yes, via provider signup and Meta review | No | | Time to first message | Days to weeks, gated by verification and template review | Minutes, gated by a QR scan | Every platform cell traces to Meta, not to a vendor: the portfolio-level 250 start and the routes to 2,000 from [Meta's messaging limits documentation](https://developers.facebook.com/documentation/business-messaging/whatsapp/messaging-limits), the number-reuse rule from [Meta's business phone numbers documentation](https://developers.facebook.com/documentation/business-messaging/whatsapp/business-phone-numbers/phone-numbers), the review trigger from [Meta's display names documentation](https://developers.facebook.com/documentation/business-messaging/whatsapp/display-names), which states that a display name undergoes verification when you reach a higher messaging limit, and template approval plus the opt-in requirement from [Meta's platform overview](https://developers.facebook.com/documentation/business-messaging/whatsapp/about-the-platform). Two caveats. AiSensy's Free Forever tier includes the official API with no setup fee, so "the API always costs money to start" is not universally true. And "minutes to first message" describes pairing, not readiness: you still need a list and recorded consent. Whether these requirements are worth clearing for your business is answered in [do I need the WhatsApp Business API](https://blueticks.co/blog/do-i-need-whatsapp-business-api). ## Pricing side by side: subscription, per-message meter, or neither? Four pricing shapes exist here, and the shape matters more than the sticker: subscription plus Meta's meter, pass-through per number, usage-priced infrastructure, and flat subscription with no meter at all. The same monthly volume produces very different bills across the four. [image: Small business owner working through WhatsApp API pricing models with a calculator and printed invoices] **Subscription plus a per-message charge.** Wati, AiSensy, Interakt, DoubleTick. Read whose card that charge sits on: AiSensy publishes Meta's India rates directly, at ₹1.09 per marketing message and ₹0.145 for utility and authentication with service free, while Wati bills usage on the WATI rate card rather than as Meta pass-through. **Pass-through per number.** 360dialog at €49 per number per month for Regular, with Meta's fees passed through. Its partner pages describe the arrangement as "zero markup on Meta fees." The markup mechanism itself is explained in [our European pricing breakdown](https://blueticks.co/blog/whatsapp-business-pricing-europe-2026). **Usage-priced infrastructure.** Twilio at $0.005 per message with no subscription, and Zoko's Starter tier, which marks conversations up $0.015 instead of including an allowance. **No meter.** On their paired-session products, Blueticks, WASenderApi, Maytapi, TimelinesAI, Periskope and Green API's instance tiers all charge a flat subscription with no per-message fee. Green API's separate WABA product is the exception in this group: it is metered per message by category, like any official-API tool. Run one volume through it: 2,000 marketing messages a month to Indian recipients. On AiSensy's India Basic that is ₹1,500 plus roughly ₹2,180 in Meta fees, about ₹3,680 total, with the chatbot builder adding ₹2,500 if you need flows. On Twilio the platform side alone is $10, plus Meta's template fees and the engineering time to build the product Twilio does not ship. On WASenderApi Basic or Blueticks the platform fee is the whole bill and the message count does not move it. Per-country Meta rates vary sharply; the detail is in our [WhatsApp Business API pricing breakdown](https://blueticks.co/blog/whatsapp-business-api-pricing-2026). Two caveats: Wati's and AiSensy's pricing is region-gated, so what you see depends on where you are, and Interakt's Enterprise, DoubleTick's Enterprise, 360dialog's Performance Messaging and Periskope's Enterprise are quote-only with no published figure to compare. If the flat-fee shape is what you want, Blueticks is a $0 evaluation. Two things to know first, both from the pricing page: browser sending needs WhatsApp Web open at send time on Free, Basic and Standard, and the 24/7 gateway that removes that requirement is the Pro plan at $50/month ($45 annual). Keep the number your customers already know: [start free with Blueticks](https://blueticks.co/signup) and schedule your first message in under five minutes, with no Meta verification, no template queue, and no per-message fee. ## When should you stop looking for an alternative and just use a BSP? Stop looking and buy the official API when you need template broadcast at scale, the verified-business badge, a genuine multi-agent inbox, guaranteed throughput, regulated sending, or deep backend integration. In those six cases the API is not the expensive option. It is the only one that works. This is the section people skip, and it saves the most money. Be honest about which of these describes you. **You broadcast tens of thousands of templated messages a month.** Published throughput comes with the Business Platform: 360dialog lists 80 messages per second standard and up to 1,000 on High Throughput. Where a vendor from the own-number table publishes comparable throughput, as TimelinesAI does, it is describing its official WABA product, which makes the point rather than answering it. **You need the verified-business badge.** Official Business Account status comes through Meta, tied to business verification. [Meta's own platform overview](https://developers.facebook.com/documentation/business-messaging/whatsapp/about-the-platform) notes that portfolio verification "factors into improved functionality, such as higher throughput and Official Business Account status." There is no unofficial route to it. **Three or more people work the same WhatsApp queue.** Assignment, routing, roles, escalation. Wati, Interakt and Zoko all sell this. Blueticks does not have it. **You need delivery you can put in a contract.** 360dialog publishes a sub-4-hour first-response SLA on Regular, sub-30-minute on Premium, plus Meta support escalations. Vendors outside the platform publish service promises of their own, Green API advertises "SLA 100 %", but escalation into Meta when a number or a template is the problem is a property of the BSP relationship, and no paired session gets you it. **You are in a regulated sector.** Finance, healthcare, insurance, anything with an audit trail or a regulator who will ask which sanctioned channel you used. Use the sanctioned channel. **Your messaging fires from backend systems at scale.** Order events, payment confirmations, appointment reminders pushing thousands of utility templates. Twilio at $0.005 per message or 360dialog at €49 per number is the right architecture, and utility is the cheaper template category anyway. If two or more of those describe you, close this tab, pick a provider through Meta's "Find a Partner" flow, and [budget for the real API running cost](https://blueticks.co/blog/whatsapp-business-api-cost-calculator) before you sign. An alternative that does not do the job is not cheaper. ## Which alternative fits your situation? A pick-by-scenario table Match the tool to the constraint that actually binds. For most solo operators that is the meter or the setup queue. For teams it is usually the shared inbox, and that one points straight back at the API camp. [image: Two colleagues mapping a WhatsApp tool decision on paper cards at a meeting table] | Your situation | Pick | Why, and the catch | | --- | --- | --- | | Three-plus agents on one WhatsApp queue | Wati, Interakt, or TimelinesAI | Multi-agent assignment is the product. Wati Growth $69/mo, Interakt Growth $55/mo, TimelinesAI $25/seat. On the first two you also pay Meta per message | | Shopify or ecommerce order flows | Zoko | Starter $49.99/mo, built around store events. Conversations carry a $0.015 markup at that tier | | High-volume templated broadcast | 360dialog or Twilio | 360dialog €49/number/mo with Meta at pass-through; Twilio $0.005/message, no subscription. Both are sold as API access, so check which tier bundles a front end before you budget | | In India, want the cheapest credible API entry | AiSensy | Basic ₹1,500/mo, plus a Free Forever tier that includes the API but excludes broadcasting. Flows cost ₹2,500/mo extra | | Developer embedding WhatsApp in your own product, own number | Green API, WASenderApi, or Maytapi | Green API Developer $0/mo, WASenderApi Basic $6/mo, Maytapi $29/phone/mo ($24 annual). All QR-paired, so outside the Business Platform. Green API also sells a separate official WABA product if you need the sanctioned route | | Managing many WhatsApp groups across numbers | Periskope | $20/user/mo month-to-month, users and phones billed separately. Prices flagged as increasing soon | | One operator scheduling from the number customers already know, no meter | Blueticks | Free to evaluate. The catch, stated first: Free, Basic and Standard are browser-only and need WhatsApp Web open at send time; offline sending is Pro at $50/mo ($45 annual). No multi-agent inbox, and consent is yours to manage | Three of those seven rows point at the official API and two more point at tools that are not ours. That is the honest shape of this market. The [drip campaign tool guide](https://blueticks.co/blog/best-whatsapp-drip-campaign-tools) scores the sequencing axis this table does not. ## FAQ ### What is the best Wati alternative in 2026? It depends which part of Wati you are replacing. Same job cheaper on the official API: Interakt at $55/month Growth or AiSensy at ₹1,500/month Basic, as of August 2026. Ecommerce: Zoko at $49.99/month. Raw API access without software: 360dialog at €49 per number per month. A multi-agent inbox over regular numbers: TimelinesAI at $25 per seat. ### What is an unofficial WhatsApp API, and is it safe? "Unofficial" describes a mechanism, not a verdict. It means the tool sends through a WhatsApp account you already have, typically paired by QR, rather than through Meta's WhatsApp Business Platform. The checkable consequence: that mechanism is not part of Meta's solution-partner programme and carries none of Meta's platform commitments on throughput, delivery or account standing, and that applies to Blueticks exactly as it does to everyone else using it. Some vendors sell both, so check which product you are buying: Green API and TimelinesAI each publish an official WhatsApp Business API product alongside a paired-session one. ### Which WhatsApp Business API alternatives have no per-message fees? The paired-session products. As of August 2026, Blueticks, WASenderApi, Maytapi, TimelinesAI, Periskope and Green API's instance tiers all publish flat subscriptions with no per-message charge. Two caveats: Green API's separate official WABA product is metered per message by category, and every official-API tool here adds a per-message charge on top of the subscription, whether billed at Meta's rates or on the vendor's own card. ### Is there a free WhatsApp Business API alternative? Several, with different limits. Green API lists a Developer tier at $0/month, Maytapi a Sandbox capped at 5 conversations a month and 150 messages a day, Blueticks a free plan, and AiSensy a Free Forever tier that includes the official API but states broadcasting is not available on it. Interakt is not one of them: its Starter tier reads "Not Applicable" on the main plan matrix and the only priced Starter entry is $12/month covering Instagram only. ### Do I need a new phone number to use a WhatsApp Business API alternative? On the official API, usually yes. Meta's documentation states that numbers already in use with WhatsApp cannot be registered unless they are deleted first, so the number your customers have saved is not automatically available. Own-number tools invert this: they pair with the account already on your phone, which is the main reason people choose them. *Notes: every competitor figure above was read from that vendor's own pricing page, or the pricing endpoint serving it, on 2026-08-06; prices change without notice. Wati's, AiSensy's and Interakt's pricing pages are region-served, and the figures shown identify their region. Periskope displayed a "Prices are increasing soon" banner on that date. Several vendors sell more than one product line, and the tables above price the one named in the row. Callbell was considered and dropped because its pricing page did not make its WhatsApp connection mechanism determinable on the date of writing. Platform rules trace to Meta's documentation, linked inline.* --- # WhatsApp Onboarding Sequence for New Customers: Running It as a Rolling Intake (2026) > Your day-by-day plan works for one batch. Here's the operating model for a rolling intake: cohort-anchored enrollment, a weekly cadence, and no no-reply branch. URL: https://blueticks.co/blog/whatsapp-onboarding-sequence-new-customers Published: 2026-08-03 Author: Daniel Roth Category: productivity You wrote the plan. Welcome, first real action, check-in, nudge. It works beautifully for the eight customers who signed up last week. Then a ninth signs up on Wednesday, a tenth on Friday, and you are suddenly running three clocks at once with nothing written down about which customer is where. That is the part nobody writes about. The message plan is solved. The operating model for a continuous intake is not. ## Why does a WhatsApp onboarding sequence break the moment you have a second customer? A day-by-day plan assumes everybody starts on the same day. On a rolling intake they don't. On any given Tuesday one customer is on day 0 and another is on day 7, and the plan you wrote has no opinion about that. The plan is fine. The enrollment model underneath it is the thing you have not designed. The message shape is settled ground and I am not going to rewrite it here. If you need the four-touch build (welcome, first action, check-in, nudge) with the exact per-step setup, that lives in [how to set up a WhatsApp automation sequence](https://blueticks.co/blog/whatsapp-automation-sequence-setup). If you want the longer post-purchase spine that runs out to day 30, that is [the drip sequence guide](https://blueticks.co/blog/whatsapp-drip-sequence). Both are done. Neither tells you what to do when customers keep arriving. Here is the failure in practice. You launch your sequence on Monday for last week's signups. Wednesday, three more customers sign up. You have two bad options: add them to the running sequence and hope, or start a second sequence and now maintain two. By week four you are maintaining seven, none of them are in the same state, and the whole thing has quietly turned back into the to-do list you built the automated WhatsApp messages sequence to escape. The fix is not a better message plan. It is deciding, explicitly, how people enter and leave. Everything below is that decision. ## Does an onboarding drip start a personal clock for each customer, or move everyone together? Everyone moves together. A Blueticks drip runs over a shared audience, and the gap before the next step is anchored on the previous step's completion for the whole group, not on each recipient's signup date. There is no per-contact "their day 3". A mid-sequence joiner never receives step 0. This is the single most misread thing about the product, so let me be exact about the mechanics. A drip is a list of ordered steps over one shared audience. Each step is dispatched as a real campaign tagged with the drip and the step index, which is why steps inherit campaign pacing and deduplication rather than reinventing them. The gap attached to a step is a value plus a unit, and the unit set is `minute`, `hour`, `day`, `week`, `month`, `year`. Minute is the floor. There is no seconds option, and the gap value itself is just an unbounded non-negative number, so there is no maximum delay either. `year` is a unit, not a ceiling. The final step carries no gap, because nothing follows it. When a step's campaign finishes its send wave, the orchestrator takes that completion timestamp, adds the gap, and creates the next step's campaign due at that moment. Read that again: the anchor is the previous step's completion, not anyone's signup. If step 1 takes six hours to finish sending because you have a large audience and an 8-second default pause between messages, the day-3 message lands three days after that finish, for everyone, at the same time. The second consequence is the one nobody has written down. Every step re-resolves the audience when its campaign is created. So a contact you add to the audience board mid-sequence is picked up by the *next* step and never receives the earlier ones. They join at step 4 with no welcome. That is not a bug you can configure away. It is what shared-audience enrollment means. Treat it as a design constraint, not a defect. Cohort anchoring is what makes one drip serve fifty people with zero per-person bookkeeping. It costs you per-person timing precision. Decide which one you actually need before you build. ## Should you run weekly cohorts or one sequence per customer? Two models work. Run a fresh drip per intake window (a weekly cohort) when volume is steady and a day of timing drift is harmless. Schedule messages individually per customer when volume is tiny or the exact date carries consequences. The deciding question is whether the *specific day* matters, not how many customers you have. | | Weekly cohort drip | One sequence per customer | | --- | --- | --- | | How you enroll | Add this week's new customers to one audience, launch one drip | Schedule each message by hand against that person's own dates | | Timing anchor | Previous step's completion, shared by the cohort | Whatever date you type | | Timing precision | An individual's "day 3" drifts by up to the length of your intake window | Exact to the person | | Work per extra customer | Effectively zero once the audience exists | Every message, every time | | Mid-sequence joiners | Join at the next step, never get step 0 | Not applicable | | Best for | Setup nudges, feature walkthroughs, a whatsapp nurture sequence that tolerates drift | Trial-expiry warnings, renewal dates, anything with a legal or billing deadline | My rule of thumb after running both: hand-scheduling stops being tolerable somewhere around five to ten new customers a week. That is a judgement from operating it, not a measured threshold. The real trigger is emotional. The first week you skip a follow-up because you couldn't face building it, switch to cohorts. The hybrid is what most people land on and it is fine. Cohort drip for the qualitative touches, one hand-scheduled message per customer for the single date-critical one. Two systems, but each is doing the job it is actually good at. **Run next week's intake as a sequence instead of a to-do list.** Drop this week's new customers into one audience, set the steps once, and let them fire on schedule from your own number, with no per-message fees and no API setup. [Start with Blueticks free](https://blueticks.co/signup). [image: cohort seedlings windowsill] ## What does an onboarding operator's week actually look like? Onboarding is a weekly job, not a day-0 task. The cadence that holds up: build and launch Monday, read the exit list midweek, prune Friday. Three touches from you per week, regardless of whether four customers arrived or forty. The whole point of the cohort model is that this cadence does not grow. **Monday, build and launch.** Take everyone who signed up since last Monday, put them in one audience, and launch the drip with a first-step due time. That is the entire enrollment ritual. Ten minutes. **Wednesday, read the exits.** This is the part that makes the week worth having. When a recipient replies and the drip has stop-on-reply enabled, they are recorded as an exit on that drip, with the reason, the step they had reached when they exited, a timestamp, and a best-effort snapshot of what they sent. Best-effort is doing real work in that sentence: the snapshot may carry the text, or just a media type, or a small thumbnail for an image reply, or nothing useful at all. Do not build a process that assumes you can always read what they said. Assume you get a name and a step, and open the chat for the rest. The step index is the signal to read first. Three people exiting at step 1 means your welcome is landing. Three exiting at step 4 with confused questions means step 2 didn't explain what it needed to. **Friday, prune.** Remove anyone who has gone live and no longer needs the rest, and anyone who has gone genuinely cold. Exits are keyed on the recipient's WhatsApp identity and the set only grows, so once someone is out they stay out of every later step, even if they get re-added to the audience board later. > "I stopped trying to know where every customer was. I only need to know who left this week and at which step. That is a five-minute read, and it is the only onboarding metric that ever changed what I did next." — composite operator account, written by me from repeated support conversations, not a verbatim customer quote. **The gotcha:** a paused drip does not advance. If a step's campaign completes while the drip is paused, nothing creates the next step, and there is no background sweep that will notice later. Resuming re-drives the transition and catches up. Pausing and forgetting for two weeks is a real way to strand a cohort. ## What happens when an onboarding step gets no reply? Nothing happens, and that is the honest answer. There is no no-reply branch. A recipient leaves the sequence for exactly three recorded reasons, and "did not reply" is not one of them. Silence is the default path. The sequence just continues to the next step on schedule. Let me refuse the things you are probably about to look for. There is no conditional branching. There is no wait-until-condition step. There are no per-step reply rules. The exit reasons are exactly `replied`, `opted-out`, and `manual`. Opt-out always removes someone. `replied` removes them only when stop-on-reply is switched on, and that switch is **per drip, not per step**. You cannot let a reply to step 1 stop the sequence while a reply to step 3 does not. If you want the mechanics of stop-on-reply itself, [the setup guide covers it](https://blueticks.co/blog/whatsapp-automation-sequence-setup). The design consequence is the useful part. Every step after the first has to make sense to somebody who has said nothing, because most of them will have said nothing. That rules out a whole genre of follow-up copy. No "as I mentioned". No "since you didn't get back to me". No message whose first line only parses if the reader answered the last one. Each step stands alone, adds one new thing, and does not scold. Where you get real branching is your Friday pass. The exit list is the automatic branch. Manual removal is the deliberate one. A whatsapp follow up sequence built this way is a straight line with a human reading the exits once a week, and honestly that is enough for onboarding. ## Which onboarding messages count as utility and which count as marketing? Only if you send through Meta's Cloud API. Onboarding straddles the category line: a setup instruction is utility, a day-7 upgrade nudge is marketing, and one sequence can contain both. If you send from your own number through WhatsApp Web, none of this applies to you. No categories, no approval queue, no per-message fee. Start with the trap, because it is the expensive one. On the Cloud API, [every template must be categorized as authentication, marketing, or utility](https://developers.facebook.com/documentation/business-messaging/whatsapp/templates/template-categorization), you pick the category at creation, and WhatsApp validates your pick against the template's contents. Get it wrong and the template is rejected, or an approved one gets automatically re-categorized later by Meta's recurring review of approved templates. Your day-1 "here's how to finish setup" is a good utility candidate. Your day-7 "upgrade for X" is marketing no matter how you word it. The money direction matters and people get it backwards. [Meta's pricing docs](https://developers.facebook.com/documentation/business-messaging/whatsapp/pricing) state that marketing templates are always charged on delivery, while "utility templates delivered within an open customer service window are free", and that volume tiers unlock lower rates for utility and authentication only. Marketing gets no volume discount. The window is customer-initiated. A user messaging your business opens a 24-hour customer service window, and each new inbound message from them extends it. You cannot open it yourself. On delivery risk: do not plan around a fixed marketing cap per person. Meta's [per-user marketing template limits](https://developers.facebook.com/documentation/business-messaging/whatsapp/templates/marketing-templates/per-user-limits) are personalised and adapt over time based on that individual's recent read rate and inbox volume, and a blocked send returns error `131049`. There is no published number to design against, and retrying immediately just re-hits it and corrupts your own delivery reporting. For the full category and pricing breakdown, see [the 2026 pricing category guide](https://blueticks.co/blog/whatsapp-business-pricing-categories-2026-utility-marketing-authentication). For the opt-in side, [our collection guide](https://blueticks.co/blog/whatsapp-opt-in-collection-guide) covers consent capture. [image: phone face down morning] ## How do you tell whether onboarding actually worked? Measure per cohort, not per contact. The onboarding-specific number is cohort completion: of the people who arrived in one intake window, what share reached the first real win. Pair it with exit-reason mix as a quality signal. Generic delivery and reply rates are covered elsewhere and are not the onboarding job. Be clear about the reporting boundary. Each step runs as its own campaign, so per-step delivery lives with that campaign, and [the drip sequence guide](https://blueticks.co/blog/whatsapp-drip-sequence) already defines per-step drop-off. Delivery, read, and reply definitions belong to [the campaign analytics guide](https://blueticks.co/blog/whatsapp-campaign-analytics-metrics-that-matter). I am not redefining either. What the drip itself records is the exit list: reason, step index, timestamp, and the best-effort reply snapshot. That is your quality signal. A cohort where most exits are `replied` at step 1 or 2 is working. A cohort where the exits are `opted-out` is telling you the sequence is unwanted, and you should shorten it before you send it again. Cohort completion is not a surfaced number. Nothing in the product knows what your "first win" is, whether that is a connected account, a first invoice, or a first message sent. You track it in a sheet: one row per cohort, the size, how many hit the win, and the exit mix. Four rows in and the comparison between weeks starts telling you things a per-contact view never will, because you changed one step between cohort two and cohort three and can see it. ## What can't the WhatsApp app do for a continuous intake? The Business app has greeting messages and quick replies. It has no sequencer, no concept of a cohort, and no record of who exited where. For a one-off batch you can fake it with reminders. For a continuous intake it collapses into a spreadsheet job, which is exactly the job you were trying to delete. A greeting message fires once, to everyone, with no step 2. Quick replies are canned text you still have to send by hand. Neither carries state, so neither can answer "who is on day 3". That is the gap a whatsapp sequence tool fills: an ordered set of steps over an audience, a gap after each step, reply-driven exits recorded with the step they happened on, and a drip status you can read at a glance (`draft`, `active`, `paused`, `completed`, `aborted`). **The caveat before you commit, and it is a real one.** Browser-only sending needs WhatsApp Web open and the machine awake when each step comes due. A closed laptop at the moment a step fires does not lose the message. It lands whenever the machine comes back, which for a day-1 setup nudge can mean 2am, or a day late. Cohort timing you designed is not cohort timing you get. There is no business-hours guard on the send path to protect you from a badly-timed due date either. The offline gateway is the fix, and per [the Blueticks pricing page](https://blueticks.co/) it sits on the Pro plan at $50 per user per month, or $45 billed annually. Free, Basic, and Standard are browser-only. If your cohort launches at 9am on a Monday when you are definitely at your desk, browser-only is genuinely fine. If your steps land while you are asleep, budget for the gateway rather than discovering it the hard way. ## FAQ **Can I start a WhatsApp onboarding sequence automatically when someone buys?** Not on the drip surface. Enrollment is by audience membership, and steps re-resolve that audience when each step launches. There is no per-customer purchase trigger and no CRM or webhook enrollment into a drip. The workable pattern is a scheduled intake window: add the period's new customers to the audience and launch a fresh drip for that cohort. **How long should a WhatsApp onboarding sequence be?** Short. Four to five touches over the first week or two covers almost every case. For the actual day-by-day shapes, use [the automation sequence setup guide](https://blueticks.co/blog/whatsapp-automation-sequence-setup) for the compact version and [the drip sequence guide](https://blueticks.co/blog/whatsapp-drip-sequence) for the longer post-purchase spine. **What's the difference between an onboarding sequence and a nurture sequence?** Onboarding drives one specific action for someone who already bought. Nurture keeps someone warm who has not. Same machinery, different success condition. The full comparison is in [the setup guide](https://blueticks.co/blog/whatsapp-automation-sequence-setup); I am not duplicating it here. **Do I need the WhatsApp Business API for this?** No. Sending from your own number means no template categories, no approval queue, and no per-message fee. You take on the Cloud API's category and pricing rules only if you choose that path. **What if a customer replies halfway through?** With stop-on-reply enabled on the drip, they exit immediately and are excluded from every later step. The exit records the step they had reached and a best-effort snapshot of what they sent. That switch is per drip, so it applies to every step or none. **Can I add someone to a sequence that already started?** You can add them to the audience, and they will be picked up by the next step. They will not receive any step already sent, including the welcome. For anyone who arrives mid-cohort, either hand-send the opening message or hold them for next week's cohort. --- # WhatsApp Group API on Your Own Number: Send, Create & Manage Groups from Code (Python & Node, 2026) > Sending to a group is one path segment. Creating one, adding twelve people in a single call, promoting an admin and knowing in advance which groups will reject you is the rest of the job. URL: https://blueticks.co/blog/whatsapp-api-send-message-to-group Published: 2026-08-02 Author: Daniel Roth Category: productivity Sending a message to a group from code is the easy part. It is one path segment. What eats an afternoon is everything around it: finding the group's id, creating the group in the first place, adding twelve people without making twelve calls, and working out why one particular group swallows every send. This is the whole group surface of the Blueticks `/v1` API, read off production source on 2026-08-02, with runnable Python and Node. ## Can you send a WhatsApp message to a group via API? Yes. A group id is a path recipient exactly like a phone number: `POST /v1/scheduled-messages/{chatId}` with a `@g.us` id in the path. It runs on your own WhatsApp number through a connected engine, not the Meta Cloud API. What you need before the first call, in one block: - **API key** - a `bt_live_` token sent as `Authorization: Bearer ` - **A connected engine** - `GET /v1/engines` returns an empty array when nothing is paired, not an error - **`groups:read`** - required for list and get - **`groups:write`** - required for every mutation - **Base URL** - `https://api.blueticks.co` Keys are minted in the dashboard. One thing worth knowing before you go hunting for checkboxes: the backend forces `scopes: ['*']` and `environment: 'live'` on every key created through the app, so a dashboard-minted key already carries the wildcard, and the wildcard satisfies both `groups:read` and `groups:write`. The scope names still matter, because that is the vocabulary you see when something is denied. A key without the right scope returns `403` with `code: "permission_denied"` and the message `Missing required scope: groups:write`. Three per-key rate buckets sit in front of these routes, each with its own counter: | Bucket | Limit | Window | Applies to | | --- | --- | --- | --- | | `tool:read` | 120 | 60s | list groups, get group, common groups | | `tool:write` | 60 | 60s | create, patch, all member routes | | `tool:media` | 30 | 60s | the group picture route only | These are fixed windows, not rolling ones. The counter is incremented in Redis and the 60-second expiry is set on the first request of a window, so a burst at second 59 and another at second 61 both pass. Exceeding a bucket returns `429` with `Retry-After`, `X-RateLimit-Limit` and `X-RateLimit-Remaining` headers. Separately, accounts without an active subscription share a plan-level ceiling of 5 API requests per fixed six-hour UTC slot, so slots begin at 00:00, 06:00, 12:00 and 18:00 UTC. Auth setup, key rotation and what "your own number" actually means are covered in the [WhatsApp REST API on your own number](/blog/whatsapp-rest-api-own-number) guide. This piece assumes you already have a key. ## How do you find a group's @g.us id from code? Two read routes return group ids. `GET /v1/groups` lists groups with `limit`, `skip`, `searchToken` and `includeArchive`. `GET /v1/groups/{id}` returns the richer single group. The list row is deliberately slimmer than the single-group object, and that difference bites people. Start with the search: ```python import requests BASE = "https://api.blueticks.co" H = {"Authorization": f"Bearer {API_KEY}"} r = requests.get( f"{BASE}/v1/groups", headers=H, params={"searchToken": "warehouse", "limit": 25}, timeout=60, ) r.raise_for_status() body = r.json() for g in body["data"]: print(g["id"], g.get("name"), g.get("participantCount")) print(body["total"], "matches") ``` `searchToken` is a case-insensitive substring match on the group name, 1 to 128 characters. `limit` is 1 to 200 and defaults to 50, `skip` defaults to 0, and archived groups are excluded unless you pass `includeArchive=true`. The query object is strict, so a typo like `search=warehouse` is rejected rather than ignored. Now the trap. A list row is a `GroupListItem` and carries exactly eight fields: `id`, `name`, `description`, `owner`, `createdAt`, `lastMessageAt`, `participantCount`, `restrict`. There is no `announce` and no `participants` on a list row. Do not write code that reads either one off the list. The `/v1` envelope also deep-strips `null` and `undefined` properties from every 2xx body before it goes on the wire, so a group whose metadata has not synced yet comes back with those keys **absent**, not present-and-null. In Python use `.get()`. In JavaScript use `??`. A response looks like this: ```json { "success": true, "data": [ { "id": "120363042318711234@g.us", "name": "Warehouse Ops", "participantCount": 34, "restrict": false, "lastMessageAt": "2026-08-01T18:42:07.000Z" } ], "limit": 25, "skip": 0, "total": 1 } ``` For the full object, including `announce` and the member list, fetch the group directly and ask for participants: ```python r = requests.get( f"{BASE}/v1/groups/120363042318711234@g.us", headers=H, params={"include": "participants"}, timeout=60, ) g = r.json()["data"] admins = [p["chatId"] for p in g.get("participants", []) if p["isAdmin"]] ``` `include` accepts exactly one value, `participants`. There is no `include=picture`, no `include=admins`, and no useful comma-separated form. Omit it and the `participants` key is simply not in the response. Two alternatives are worth knowing. `GET /v1/chats?kinds=group` returns group chats through the general chat list, which is handy when you are already paging chats. And `GET /v1/contacts/{id}/common_groups` returns the groups your number shares with a given contact, in the same slim list-item shape, under `groups:read`. The [Node.js WhatsApp bot guide](/blog/whatsapp-bot-nodejs) covers the general chat-discovery path in more detail. About the id format itself. The `groupId` path parameter is validated against `^\d+(?:-\d+)?@g\.us$`. That accepts both the modern form, `120363042318711234@g.us`, and the legacy form built from the creator's number and a timestamp, `15551234567-1633024800@g.us`. It does **not** accept `@c.us`, and it does not accept `@lid`. The member-reference validator is wider and does accept `@lid`, so the whatsapp group id g.us rule is narrower than the member rule sitting right next to it in the same file. [image: warehouse team huddle] ## How do you send a message to that group in Python and Node? The recipient lives in the URL. `POST /v1/scheduled-messages/{chatId}` takes the group's `@g.us` id in the path exactly where a phone number would go, and returns `201`. That is the entire difference between a group send and a one-to-one send. ```python r = requests.post( f"{BASE}/v1/scheduled-messages/120363042318711234@g.us", headers={**H, "Content-Type": "application/json"}, json={"type": "text", "text": "Dock 3 inbound at 14:00."}, timeout=60, ) m = r.json()["data"] print(m["status"], m.get("waMessageKey")) ``` ```javascript const res = await fetch( `${BASE}/v1/scheduled-messages/120363042318711234@g.us`, { method: "POST", headers: { Authorization: `Bearer ${API_KEY}`, "Content-Type": "application/json" }, body: JSON.stringify({ type: "text", text: "Dock 3 inbound at 14:00." }), }, ); const { data } = await res.json(); console.log(data.status, data.waMessageKey ?? null); ``` `type` is required and is one of `text`, `media`, `poll`. Add an ISO 8601 `sendAt` with an offset to defer it. A `201` is acceptance, not delivery, and `waMessageKey` is absent until the engine has actually dispatched. Posting to the bare collection path with no recipient returns `410 Gone`. The request body, the response envelope, the status lifecycle and the delivery-polling loop are all documented in the [send endpoint reference](/blog/send-whatsapp-message-from-api), so I will not restate them here. **Skip the Meta Business verification queue.** No Official Business Account, no template approval, no per-message platform fee on the send. Your existing WhatsApp number, one POST, groups included. [Start free at blueticks.co/signup](https://blueticks.co/signup). ## How do you create a WhatsApp group from an API call? `POST /v1/groups` with a `name` and a `participants` array creates the group and returns the created group with its members already inlined. The name is 1 to 100 characters, the array is 1 to 256 entries, and every member is either a JID or a `+E.164` phone number. ```python r = requests.post( f"{BASE}/v1/groups", headers={**H, "Content-Type": "application/json"}, json={ "name": "Q4 Planning", "participants": ["+15555550100", "15555550101@c.us"], }, timeout=60, ) if r.status_code >= 400: err = r.json()["error"] print(err["code"], err["message"], err.get("details")) raise SystemExit(1) g = r.json()["data"] print(g["id"], len(g["participants"])) ``` ```javascript const res = await fetch(`${BASE}/v1/groups`, { method: "POST", headers: { Authorization: `Bearer ${API_KEY}`, "Content-Type": "application/json" }, body: JSON.stringify({ name: "Q4 Planning", participants: ["+15555550100"] }), }); const body = await res.json(); if (!body.success) { console.error(body.error.code, body.error.message, body.error.details ?? []); process.exit(1); } console.log(body.data.id); ``` Three things account for most first-call failures on the create whatsapp group api path. **The body is strict.** Unknown keys are rejected outright, not ignored. `{"name": "...", "members": [...]}` fails because the field is `participants`. `{"name": "...", "participants": [...], "description": "..."}` fails because `description` is not accepted at create time; set it afterwards with a `PATCH`. You get `400` with `code: "invalid_request"` and a `details` array of `{path, code, message}`. For an unknown key the `path` is empty and the offending key name is in `message`; for a bad *value*, such as a malformed phone, `path` names the field, for example `participants.0`. **Phone format is exact.** The member validator accepts a JID matching `^\d+(?:-\d+)?@(?:c\.us|g\.us|lid)$`, or a phone matching `^\+\d{6,15}$`. A leading `+` is mandatory on the phone form, and six to fifteen digits after it. `"15555550100"` with no plus is a `400`. **Create normalizes, the member routes do not.** The create handler runs every entry through a phone-to-JID normalizer before dispatching to the engine, stripping the `+` and appending `@c.us`. The member sub-resource routes covered in the next section hand your value to the engine as-is. Send `+15555550100` to create if you like, but send `15555550100@c.us` to the member routes. The response is the full group object, and `participants` is always inlined on a create even though you did not ask for it. Every error body across the whole surface has the same shape, which makes the handling above reusable: ```json { "success": false, "error": { "code": "invalid_request", "message": "Unrecognized key(s) in object: 'members'", "requestId": "req_...", "request_id": "req_..." } } ``` `code` is drawn from a fixed map: `invalid_request` for 400 and 422, `authentication_required` for 401, `permission_denied` for 403, `not_found` for 404, `rate_limited` for 429, and `internal_error` for anything 5xx. ## How do you add, remove, promote and demote members? Member management is five raw routes mounted outside the Feathers service, all requiring `groups:write` and all charged to the `tool:write` bucket. Every one of them returns HTTP `200`. | Verb + path | Effect | | --- | --- | | `POST /v1/groups/{id}/members` | Add one or many participants | | `DELETE /v1/groups/{id}/members/{chatId}` | Remove a participant | | `POST /v1/groups/{id}/members/{chatId}/admin` | Promote to admin | | `DELETE /v1/groups/{id}/members/{chatId}/admin` | Demote to member | | `DELETE /v1/groups/{id}/members/me` | Leave the group yourself | The add member to whatsapp group api route takes either a single `chatId` or a `participants` array of 1 to 256 entries, and at least one of the two must be present. So a batch add is **one** HTTP call, not N: ```javascript const res = await fetch(`${BASE}/v1/groups/${groupId}/members`, { method: "POST", headers: { Authorization: `Bearer ${API_KEY}`, "Content-Type": "application/json" }, body: JSON.stringify({ participants: ["15555550100@c.us", "15555550101@c.us", "15555550102@c.us"], }), }); const body = await res.json(); if (!body.success) throw new Error(`${body.error.code}: ${body.error.message}`); ``` It is one HTTP call, but not one atomic operation. Internally the service loops and dispatches one engine call per participant, and surfaces the first failure. If participant seven is unreachable you get an error, and participants one through six are already in the group. Treat a failed batch add as "partially applied" and re-read the group rather than blindly retrying the whole array. Response shapes are small and are **not** the group object. Add, remove, promote and demote all return `{"ok": true}` inside the success envelope. Leaving returns a slightly larger object: ```json { "success": true, "data": { "ok": true, "groupId": "120363042318711234@g.us", "left": true } } ``` Now the part the API cannot help you with. Every one of these operations is subject to WhatsApp's own permission model, and the API has no way to override it. Promoting, demoting, removing and renaming generally require your number to already be an admin of that group. Adding somebody can fail purely because of *their* privacy settings, which no amount of correct request formatting fixes. When WhatsApp refuses, the engine's rejection surfaces as `422` carrying the engine's own message, so read `error.message` rather than assuming your payload was wrong. One line, no hedging: **adding people to groups without their consent is how accounts get reported and banned.** Meta's [WhatsApp Business Platform policy and spam enforcement](https://developers.facebook.com/documentation/business-messaging/whatsapp/policy-enforcement) page sets out an escalation ladder for accounts that repeatedly violate the Business Messaging Policy - feature limits, then blocks, then permanent disablement - and an unofficial engine does not exempt you from any of it. If you want the group scheduling workflow without writing any code, the extension path is covered in [scheduling a WhatsApp group message](/blog/schedule-whatsapp-group-message). [image: phone face down slate] ## How do you rename a group or lock it to admins-only? `PATCH /v1/groups/{id}` updates group metadata. The body is strict and must contain at least one of `name` or `settings`, otherwise you get a `400` telling you exactly that. ```python r = requests.patch( f"{BASE}/v1/groups/{group_id}", headers={**H, "Content-Type": "application/json"}, json={ "name": "Q4 Planning (locked)", "settings": {"announce": True, "restrict": True}, }, timeout=60, ) print(r.json()) # {"success": true, "data": {"ok": true}} ``` The two flags do different things and people mix them up constantly: - **`announce: true`** - only admins can post messages in the group - **`restrict: true`** - only admins can edit the group's subject, description and picture - **`editInfoAdminsOnly`** - a friendly alias for `restrict` If you send both `restrict` and `editInfoAdminsOnly` in the same request, the explicit `restrict` wins. `settings.description` is also accepted here, 1 to 2048 characters, and it is dispatched to the engine as its own separate call so that a failure setting the admin flags cannot silently swallow a description update, or the other way round. The group picture is its own route, `PUT /v1/groups/{id}/picture`, and it is the one group route charged to the `tool:media` bucket at 30 requests per minute rather than 60. It accepts two content types. As JSON, supply at least one of `fileDataUrl` (a base64 data URL, up to 20,971,520 characters) or `url` (https only, up to 2048 characters); `fileName` caps at 255 characters and `fileMimeType` at 127. As `multipart/form-data`, put the bytes in a part named `file`, capped at 20 MiB by the upload middleware. Both paths return `{"ok": true}`. The same base64-versus-URL-versus-upload tradeoff applies to message attachments, which is unpacked in the guide to [sending images, PDFs and documents](/blog/whatsapp-api-send-image-pdf-document). There is no `DELETE /v1/groups/{id}` - the service implements no remove handler at all. Deleting a WhatsApp group is not an operation WhatsApp offers anyway; you remove the members and leave, which is what `DELETE /v1/groups/{id}/members/me` is for. Two timing details worth planning around. The group fetch and the leave route both pass an explicit 60,000 ms engine timeout, because the engine serializes the entire group metadata payload synchronously and leaving involves a metadata write plus an acknowledgement. On a group with several hundred members, both routes are genuinely slow. Set your HTTP client timeout above 60 seconds for those two calls or your own client will give up before the API does, and a timeout on the API side comes back as `504` with the message `WhatsApp engine did not respond in time`. ## Which groups will reject your send, and why the API treats it as permanent Community parent groups and announce-only groups where you are not an admin are the two group types that reliably swallow sends on the WhatsApp Web path. The useful move is to detect the second case with a read call before you spend a send. Here is the predictive check. Fetch the group with participants, then compare the `announce` flag against your own admin status: ```python r = requests.get(f"{BASE}/v1/groups/{group_id}", headers=H, params={"include": "participants"}, timeout=90) g = r.json()["data"] me = "15555550100@c.us" # your own number as a JID announce = g.get("announce", False) i_am_admin = any(p["chatId"] == me and p["isAdmin"] for p in g.get("participants", [])) if announce and not i_am_admin: print("admins-only group, this send will not land") ``` Read `announce` from `GET /v1/groups/{id}`, never from `GET /v1/groups`, because the list row does not carry it. And read the flag honestly: `announce` is the group-level "only admins can post" toggle. It is deliberately documented in the schema as distinct from the per-user posting ability, which the engine resolves separately and does not expose on the public object. So `announce: true` plus `isAdmin: false` is a strong negative signal, not a proof, and `announce: false` is not a guarantee either. The community case is worse, and I would rather say so than sell you a check that does not exist. The public `Group` object has exactly ten fields: `id`, `name`, `description`, `owner`, `createdAt`, `lastMessageAt`, `participantCount`, `announce`, `restrict`, `participants`. There is no `groupType`, no `isCommunity`, no `parentGroupId`. You cannot predict a community-parent failure from a `/v1` read. The workaround is behavioural, not technical: send to the subgroup, not to the announcement group at the top of the community. When one of these does fail, the failure is not worth retrying. The internal reliability job classifies failure strings like "cannot send to this group", "not a participant" and "group no longer exists" into a `genuine` bucket, as opposed to the `transient` bucket that holds media and timeout errors. That word is an internal analytics category, not a status the API hands back to you. What a caller actually sees on the message object is `status: "failed"` and a human-readable `failureReason` string. Read `failureReason` and stop retrying when it names the group. [image: empty chairs circle morning] ## What the Meta Cloud API can and cannot do here, and where this fits Meta shipped a Groups API for the Cloud API, and any comparison written before late 2025 is out of date. It exists, and it solves a genuinely different problem than the one most people arrive with. Per [Meta's own Groups API documentation](https://developers.facebook.com/documentation/business-messaging/whatsapp/groups), the feature "is now open to all businesses with an Official Business Account (OBA)", and "Groups are not available for WhatsApp Business app phone numbers." The documented flows cover creating and deleting groups, generating and resetting invite links, removing participants, retrieving group information, and sending and receiving messages inside those groups. The shape of it is the thing to notice. Meta describes groups as "an invite-only experience where participants join using a group invite link you send them", and the [group management reference](https://developers.facebook.com/documentation/business-messaging/whatsapp/groups/reference) says plainly: "Since you cannot manually add participants to the group, simply send a message with your invite link to WhatsApp users." So the Cloud API path is: get an Official Business Account, create a fresh group on a business number your customers have never saved, and wait for people to accept an invite link. That is a reasonable product. It is not the thing you were looking for if the group you care about already exists, already contains your suppliers or your class or your ops team, and is attached to the number you have been using for three years. The whatsapp api own number path answers that instead, and the trade is honest. Your requests drive a real WhatsApp session belonging to your real number, which is exactly why an existing group is reachable at all and exactly why your account's standing is on the line. There is no Meta intermediary absorbing policy risk on your behalf. Every rule about consent, frequency and content applies to you directly, and WhatsApp can restrict any number. The operational floor matters too. A browser tab driving WhatsApp Web stops the moment the tab closes. If a group send is supposed to fire at 06:00, something has to be awake at 06:00, which is what the hosted gateway is for. ## FAQ ### Can I send a message to a WhatsApp group via API? Yes. Put the group's `@g.us` id in the path of `POST /v1/scheduled-messages/{chatId}`, exactly where a phone number would go, with `type` and a body. It returns `201`. It runs on your own WhatsApp number through a connected engine, so no Meta Business verification is involved. ### How do I get a WhatsApp group id? Call `GET /v1/groups` with an optional `searchToken` for a case-insensitive name match, and read `id` off each row. `GET /v1/chats?kinds=group` works too. Ids look like `120363042318711234@g.us`, or the legacy `15551234567-1633024800@g.us` form built from a number and a timestamp. ### Can I create a WhatsApp group from the API? Yes. `POST /v1/groups` with `name` (1 to 100 characters) and `participants` (1 to 256 entries, each a JID or a `+E.164` phone). The body is strict, so unknown keys are rejected rather than ignored. The response is the created group with its participants already inlined. ### Do I need Meta Business verification for this? No. Blueticks drives the WhatsApp number you already use, so there is no Official Business Account, no template approval and no per-message platform fee on the send. Meta's own Groups API does require an Official Business Account and is unavailable on WhatsApp Business app numbers. ### Why did my send to a community fail? Community parent groups and announce-only groups where you are not an admin are known failure cases on this path. The failure is classified as permanent rather than transient, so retrying will not help. Send to the subgroup instead. The public group object exposes no community flag, so you cannot detect it in advance. ### How many people can I add to a group at once? Up to 256 in a single `POST /v1/groups/{id}/members` call using the `participants` array. It is one HTTP request but not one atomic operation: the service dispatches one engine call per participant and surfaces the first failure, so a partial add is possible. ### Can I schedule a message to a group? Yes. Add an ISO 8601 `sendAt` with an offset to the same send body. It must be at least 10 seconds in the future and no more than 365 days out. Something has to be connected when the time arrives, which is what the always-on gateway handles. --- # How to Send Images, PDFs & Documents via the WhatsApp API (Python & Node, 2026) > Attachments are where WhatsApp API integrations quietly break. Here is the real media request contract: caption in `text`, the mediaKind enum, filename rules, two different size ceilings, and the GIF that arrives as a file. URL: https://blueticks.co/blog/whatsapp-api-send-image-pdf-document Published: 2026-08-01 Author: Daniel Roth Category: productivity Text sends work on the first try. Attachments are where people lose an afternoon. The caption lands in the wrong field, the invoice arrives named `a8f3c2.pdf`, and the animated GIF shows up as a downloadable file nobody taps. This is the actual media request contract, verified against the production Blueticks `/v1` API on 2026-08-01, with runnable Python and Node for every case. ## Can you send an image or PDF over the WhatsApp API on your own number? Yes. Blueticks sends media from the WhatsApp number you already use, driving WhatsApp Web through a browser session or an always-on hosted gateway. It is not the Meta Cloud API. There is no Business verification, no template pre-approval, and no per-message Meta charge on the send itself. That distinction matters for attachments specifically. On [Meta's WhatsApp Business Platform pricing](https://developers.facebook.com/docs/whatsapp/pricing), business-initiated messages are charged per delivered template message across Marketing, Utility and Authentication categories, and a media-carrying promotional template is a Marketing template every time. On the WhatsApp Web path there is no template object at all, so a PDF is just a message from your number. The honest part: nothing here makes your number unbannable. WhatsApp's [Business Messaging Policy](https://whatsappbusiness.com/policy/) states plainly that it may "limit or remove your access to or use of the WhatsApp Business Services if you receive significant amounts of negative feedback, cause harm to WhatsApp or our users, violate or encourage others to violate our terms or policies." Sending unwanted attachments to strangers is a fast way to trigger exactly that. Every rate limit in this article is a limit on our API, not a promise from WhatsApp. If you have not made a single API call yet, start with [sending a plain text message from the API](/blog/send-whatsapp-message-from-api) and come back. This article assumes you already have a `bt_live_` key and a linked number. ## What a media send actually needs: a URL, base64, or a file upload Every whatsapp api send media call needs exactly one source of bytes. You pick from three: `mediaUrl` (https only), `mediaBase64` (raw base64 or a `data:` URL), or a `multipart/form-data` request carrying a `mediaFile` part. Everything sits at the top level of the body. There is no nested object and no separate caption field. Two mental models to kill before you write a line of code, because both are how every other WhatsApp API works: - **There is no `media: { url, caption }` object.** The body is flat: `type`, `mediaUrl`, `mediaKind`, `mediaFilename`, `text`. - **There is no `caption` field.** The `text` field carries the caption on a media send, capped at 4,096 characters, the same field a text message uses for its body. `type` is required on every send and takes `text`, `media` or `poll`. It is validation-only: it does not change the route, it tells the API which flat fields to enforce. Send `"type": "media"` with neither a URL, base64, nor an upload and you get a `400` reading `media requires 'mediaUrl', 'mediaBase64', or a 'mediaFile' upload`. Precedence is fixed. If you send both `mediaUrl` and `mediaBase64`, **`mediaUrl` wins** and the base64 is ignored. A `mediaFile` upload arrives out of band and never competes with the JSON body. One more thing about `mediaUrl`: it must be `https://`, and the API rejects `localhost` plus the private IPv4 and IPv6 ranges before it fetches anything. A URL on your laptop or an internal `10.x` host will fail. The bytes are then re-hosted to Blueticks storage, which is why the `mediaUrl` echoed back on the response object is not the URL you sent. [image: Blank photo prints, a memory card and a USB-C cable on slate — the local files behind a media upload] ## How do you send an image with a caption in Python and Node POST to `https://api.blueticks.co/v1/scheduled-messages/{chatId}` with `type: "media"`, a `mediaUrl`, and your caption in **`text`**. The recipient is a path segment in E.164 form, not a body field. Every 2xx comes back wrapped in `{"success": true, "data": {...}}`. One structural thing to understand before you read the response, because it changes what you get back: **omitting `sendAt` does not just send sooner, it takes a different code path.** With no `sendAt` the API sends *directly* and writes no queue row at all. Add a `sendAt` and it writes a queue row you can later fetch, patch or cancel. The two paths return different handles, and the examples below omit `sendAt`. Python, using `requests`: ```python import requests API_KEY = "bt_live_YOUR_KEY_HERE" TO = "+15551234567" # recipient is a PATH segment, not a body field resp = requests.post( f"https://api.blueticks.co/v1/scheduled-messages/{TO}", headers={"Authorization": f"Bearer {API_KEY}"}, json={ "type": "media", "mediaUrl": "https://cdn.example.com/promo/spring-lookbook.jpg", "mediaKind": "image", "text": "Your spring lookbook is here. Reply STOP to opt out.", }, timeout=30, ) resp.raise_for_status() msg = resp.json()["data"] print(msg["id"], msg["status"], msg["mediaKind"]) ``` Node 18+, no dependencies: ```javascript const API_KEY = "bt_live_YOUR_KEY_HERE"; const TO = "+15551234567"; const resp = await fetch(`https://api.blueticks.co/v1/scheduled-messages/${TO}`, { method: "POST", headers: { Authorization: `Bearer ${API_KEY}`, "Content-Type": "application/json", }, body: JSON.stringify({ type: "media", mediaUrl: "https://cdn.example.com/promo/spring-lookbook.jpg", mediaKind: "image", text: "Your spring lookbook is here. Reply STOP to opt out.", }), }); if (!resp.ok) throw new Error(`Send failed: ${resp.status}`); const { data } = await resp.json(); console.log(data.id, data.status, data.mediaKind); ``` The response object, trimmed to the fields that matter for a whatsapp api image caption send: ```json { "success": true, "data": { "id": "true_15551234567@c.us_3EB0C767D097F5A3B7A2", "waMessageKey": { "fromMe": true, "remote": "15551234567@c.us", "id": "3EB0C767D097F5A3B7A2", "_serialized": "true_15551234567@c.us_3EB0C767D097F5A3B7A2" }, "to": "+15551234567", "type": "media", "text": "Your spring lookbook is here. Reply STOP to opt out.", "mediaUrl": "https://api.blueticks.co/v1/utils/asset/PLM7K9PVZB19abis", "mediaKind": "image", "status": "confirmed", "createdAt": "2026-08-01T09:14:22.104Z" } } ``` Two things here surprise people. **`id` is not a database id.** On a direct send there is no queue row, so `id` is the *serialized WhatsApp message key* — the same string as `waMessageKey._serialized`. It is addressable via `GET /v1/messages/{id}`, and it will be rejected by `GET /v1/scheduled-messages/{id}`, which only accepts a 24-character hex queue id. On a **scheduled** send (one with `sendAt`) `id` is that 24-hex queue id instead. Same field, two different handles, decided by whether you sent `sendAt`. **`status` is already `confirmed`,** not `pending`, because the engine returned a key in-line. You get `pending` back only when it did not. And notice what is **absent**: every `/v1` success body is deep-stripped of nulls before it goes out, so a field with no value is a missing key rather than `"field": null`. On this response `sendAt`, `confirmedAt`, `failedAt` and `failureReason` are simply not there. Falsy-but-meaningful values (`false`, `0`, `""`) are kept. Parse with `.get()` and optional chaining, never `data["failureReason"]`. `mediaKind` is optional. Leave it out and the API infers the kind from the URL and content type. Set it when you care about the bubble WhatsApp renders, which is most of the time. There is also a second route, `POST /v1/messages/{chatId}`, which takes the same flat media body and is explicitly fire-and-forget. It has its own rate-limit bucket, so it does not share a budget with the route above, and it carries `withTyping` and `typingSeconds` — both **ignored on media and poll sends**, text only. Since a `sendAt`-less call to `/v1/scheduled-messages` already skips the queue, treat `/v1/messages` as the route that says so explicitly rather than as the only way to send immediately. ## How do you send a PDF so the filename shows correctly Set `mediaKind: "document"` and pass `mediaFilename`. The field is optional and 1 to 255 characters. When you omit it, the API derives a name in a strict order: your explicit `mediaFilename`, then the last path segment of `mediaUrl`, then `file.` guessed from a `data:` URI mime type, then the literal string `file`. That derivation order is exactly why documents from signed cloud storage URLs arrive looking broken. A presigned S3 or GCS link ends in something like `.../7f3a91c2-4b8e?X-Amz-Signature=...`, the query string is stripped, and the recipient sees an attachment called `7f3a91c2-4b8e`. Always pass `mediaFilename` for a send document whatsapp api call. For a local file, skip base64 entirely and use `multipart/form-data`. Python: ```python import requests API_KEY = "bt_live_YOUR_KEY_HERE" TO = "+15551234567" with open("invoice-2026-08-001.pdf", "rb") as fh: resp = requests.post( f"https://api.blueticks.co/v1/scheduled-messages/{TO}", headers={"Authorization": f"Bearer {API_KEY}"}, data={ "type": "media", "mediaKind": "document", "mediaFilename": "invoice-2026-08-001.pdf", "text": "Your August invoice is attached.", }, files={"mediaFile": ("invoice-2026-08-001.pdf", fh, "application/pdf")}, timeout=120, ) resp.raise_for_status() print(resp.json()["data"]["id"]) ``` Node, with native `FormData`: ```javascript import { readFile } from "node:fs/promises"; const form = new FormData(); form.set("type", "media"); form.set("mediaKind", "document"); form.set("mediaFilename", "invoice-2026-08-001.pdf"); form.set("text", "Your August invoice is attached."); form.set( "mediaFile", new Blob([await readFile("invoice-2026-08-001.pdf")], { type: "application/pdf" }), "invoice-2026-08-001.pdf", ); const resp = await fetch(`https://api.blueticks.co/v1/scheduled-messages/${TO}`, { method: "POST", headers: { Authorization: `Bearer ${API_KEY}` }, // do NOT set Content-Type body: form, }); if (!resp.ok) throw new Error(`Upload failed: ${resp.status}`); ``` Two failure modes worth writing on a sticky note. First, do not set `Content-Type` yourself on a multipart request; `fetch` and `requests` generate the boundary token and hand-setting the header breaks parsing. Second, on a multipart upload the API defaults `mediaFilename` to the uploaded file's original name, so `open("tmp.pdf")` ships an attachment named `tmp.pdf`. > **Sending your first attachment today?** [Mint an API key and send an image or PDF from your own number](https://blueticks.co/signup) in under ten minutes. No Meta Business verification, no template approval queue, no per-message Meta fees. [image: Blank sheets beside a flatbed scanner, the source files for a send document whatsapp api workflow] ## Which media kinds work, and which ones silently break `mediaKind` accepts exactly seven values: `image`, `video`, `audio`, `document`, `sticker`, `voice`, `gif`. Each maps to a different bubble in the chat. Two pairs get confused constantly, and one of them fails silently rather than erroring, which is the worst kind of failure. | `mediaKind` | What the recipient sees | | --- | --- | | `image` | Inline photo, caption below | | `video` | Inline player with a caption | | `gif` | Looping autoplay bubble, no controls — **MP4 bytes**, not `.gif` | | `audio` | Attached audio file with a play control | | `voice` | Push-to-talk waveform bubble | | `document` | Named file card, tap to download | | `sticker` | Borderless sticker | There is no format allowlist at our request layer, so what actually constrains you is what the WhatsApp client renders. Meta publishes that list for the Cloud API in its [supported media types reference](https://developers.facebook.com/docs/whatsapp/cloud-api/reference/media): images are **JPEG and PNG** (WebP is scoped to stickers, not images), audio covers AAC, AMR, MP3, MP4 audio and OGG, and video is **3GPP and MP4**. Those are Cloud API figures rather than WhatsApp Web ones, but they are the right shape to design against — WebP in particular is a sticker format, not a general image format. **The GIF trap.** WhatsApp never transmits a `.gif` over the wire. It ships MP4 with a `gifPlayback` flag. So if you send `image/gif` bytes with `mediaKind: "image"`, the WhatsApp Web preparation path falls back to **document**, and your animation arrives as a file card. No error, no failed status, just a dead attachment. To get the autoplay bubble you must transcode to MP4 first and send `mediaKind: "gif"`, which makes the engine set `sendVideoAsGif` on dispatch. **Voice versus audio.** `voice` renders the push-to-talk waveform that plays inline and can advance a message to a `played` status. `audio` renders an attached file. Same bytes, completely different recipient behavior. Pick deliberately. ## The two size ceilings, and when to stop using base64 There are two separate caps and they are nowhere near each other. The JSON `mediaBase64` field is capped at 15,728,640 characters, and base64 inflates binary by roughly one third, so the real ceiling is about **11 MB of actual file**. The multipart `mediaFile` path runs through a 100 MB upload limit and streams out of band, skipping base64 entirely. The decision rule is short: 1. File already on a public https URL? Use `mediaUrl`. Zero upload cost on your side. 2. File on disk and comfortably inside the ~11 MB base64 ceiling? `mediaBase64` is fine if JSON is simpler for you. 3. File on disk and anywhere near that ceiling, or you would rather not burn a third of your payload on encoding? Use `multipart/form-data` with `mediaFile` and you are working against the 100 MB limit instead. Our accepting 100 MB does not mean WhatsApp delivers 100 MB. The client sets its own ceilings, and they are far tighter per type. Meta publishes hard numbers for the Cloud API in its [supported media types reference](https://developers.facebook.com/docs/whatsapp/cloud-api/reference/media): 5 MB for JPEG and PNG images, 16 MB for audio and video, 100 MB for documents, 500 KB for an animated sticker. Those are Cloud API figures rather than WhatsApp Web figures, but they are the right order of magnitude to design against. A 40 MB video will be accepted by our API and then fail or be rejected downstream. [image: Server rack indicator lights at night, the always-on gateway behind scheduled WhatsApp media sends] ## How do you send media to a whole audience without getting flagged Loop your list and issue one media send per recipient. There is no bulk media endpoint, by design. The real constraints are two stacked rate limits, both verified against production on 2026-08-01, plus your own pacing, which should be far slower than either. - `POST /v1/scheduled-messages/{chatId}` is capped at **60 requests per 60 seconds**. - `POST /v1/messages/{chatId}` uses a separate counter, also **60 per 60 seconds**. Separate buckets, so they do not share a budget. - Free accounts additionally get **5 API calls per fixed 6-hour UTC slot**. The slots are hard boundaries at 00:00, 06:00, 12:00 and 18:00 UTC and the counter resets at each one, so this is not a rolling window: exhaust it at 05:59 and you have a full five again a minute later. Paid plans with API access skip that layer entirely. - On a `429` the response carries `Retry-After`, `X-RateLimit-Limit` and `X-RateLimit-Remaining`. Read the headers instead of guessing. Media is heavier than text on every axis. Each send fetches or uploads bytes, re-hosts them, and hands a prepared media object to WhatsApp. Do not pace attachments the way you pace text. ```python import time, requests for contact in audience: # your own opted-in list r = requests.post( f"https://api.blueticks.co/v1/scheduled-messages/{contact['phone']}", headers={"Authorization": f"Bearer {API_KEY}"}, json={ "type": "media", "mediaUrl": contact["asset_url"], "mediaKind": "image", "text": f"Hi {contact['first_name']}, your order photo is attached.", }, timeout=60, ) if r.status_code == 429: time.sleep(int(r.headers.get("Retry-After", "60"))) continue r.raise_for_status() time.sleep(6) # ~10/min: well under the 60/60s route cap ``` Consent is yours to own, not the API's. WhatsApp's Business Messaging Policy is unambiguous: "You may only contact people on WhatsApp if: (a) they have given you their mobile phone number; and (b) you have received opt-in permission from the recipient confirming that they wish to receive subsequent messages or calls from you." Blueticks will happily send whatever you POST. WhatsApp is the one deciding whether your number stays healthy. For list mechanics, segmentation and the trade-offs against broadcast lists, see the dedicated guide on [sending bulk WhatsApp messages](/blog/how-to-send-bulk-whatsapp-messages). For timezone-correct `sendAt` values, idempotency keys and backoff on retries, the [Python scheduling article](/blog/whatsapp-api-python-schedule) covers all three properly. ## How do you confirm a media message actually delivered Poll `GET /v1/scheduled-messages/{id}` with the queue id from a **scheduled** send — one you created with a `sendAt`. A direct send has no queue row, so its `id` is a wire key: fetch that one with `GET /v1/messages/{id}` instead, and note it already came back `confirmed`. The documented happy path runs `pending` to `confirmed` to `received` to `read`, with `played` terminal for voice and audio. `confirmed` means WhatsApp accepted the message and a key exists. `received` is the double grey tick. `read` is double blue. That ladder is the lifecycle, **not the full set of values `status` can hold**. The field is typed against the canonical 15-value status list, and when a message has no lifecycle timestamp yet the API returns its raw stored status instead. In practice the two extra values you will actually see are **`sent`** and **`sent_pending_ack`** — the latter meaning WhatsApp took the message but no acknowledgement has come back yet. Branch on a terminal **set** rather than on the five happy-path states, and keep the rarer schema values in it defensively: ```python TERMINAL = {"received", "read", "played", "failed", "error", "expired", "cancelled"} ``` The identity field is **`waMessageKey`**, not `key`. It is an object with `fromMe`, `remote`, `id` and `_serialized`, and it is **absent from the response** until the engine has actually dispatched. A queued message with no `waMessageKey` key at all has not reached WhatsApp yet, no matter what its status says. Test for absence, not for `null`. ```python import time, requests for _ in range(10): r = requests.get( f"https://api.blueticks.co/v1/scheduled-messages/{message_id}", headers={"Authorization": f"Bearer {API_KEY}"}, timeout=30, ) m = r.json()["data"] # absent-not-null: use .get(), these keys are stripped when empty print(m["status"], m.get("waMessageKey"), m.get("failureReason")) if m["status"] in TERMINAL: break time.sleep(15) ``` Media fails in ways text does not, and pretending otherwise wastes your debugging time. Upload stages stall, mimetypes get misread, and until recently a large share of those surfaced as a bare unknown error. Blueticks shipped media-specific failure diagnostics on 2026-07-31 that tag the failing stage on every non-OK return path, so a failed media send now records where it broke rather than just that it broke. Read `failureReason` on the message object first. One limitation to plan around: posting media into a **community parent group or an announce-only group** is a known open failure on the WhatsApp Web path, and the API classifies "cannot send to this group" as a permanent failure rather than something worth retrying. Send to the subgroup, not the announcement channel. If polling feels wrong for your architecture, register a webhook instead and let delivery events come to you. That is covered end to end in the [webhooks and auto-reply guide](/blog/whatsapp-api-webhooks-auto-reply). [image: Phone face down beside a handwritten checklist while a scheduled media send delivers] ## What a laptop-based media send cannot do, and where Blueticks fits A script driving WhatsApp Web from your own browser works until the tab closes. Then the queue stops, nothing retries, and there is no record of what went out. That is fine for a one-off invoice and unworkable for anything scheduled at 6am. The hosted gateway is what changes the equation. It keeps your number connected 24/7 without a browser on your desk, so a `sendAt` two weeks out actually fires, `POST /v1/scheduled-messages/{id}/cancel` can pull a queued attachment back before it goes, and every send carries a status row you can query later. Scheduled media is only meaningful if something is awake to send it. The conceptual model, including what "your own number" means legally and operationally, is covered in the piece on the [WhatsApp REST API on your own number](/blog/whatsapp-rest-api-own-number). ## FAQ ### Can I send a PDF via the WhatsApp API? Yes — to send pdf via whatsapp api, POST `type: "media"` with `mediaKind: "document"` and either a `mediaUrl`, a base64 payload, or a multipart `mediaFile` upload. Always pass `mediaFilename` so the recipient sees a real name instead of a URL fragment. The endpoint is `POST /v1/scheduled-messages/{chatId}` with the recipient in the path. ### What image formats does the whatsapp api send image path accept? There is no format allowlist enforced at the request layer, so the constraint is what the WhatsApp client itself renders. Meta's Cloud API reference lists images as JPEG and PNG only, both capped at 5 MB — WebP is a sticker format there, not a general image format. Those caps are a sensible design target even on the WhatsApp Web path. ### Why does my GIF arrive as a downloadable file? Because WhatsApp never transmits raw `.gif`. It ships MP4 with a gif-playback flag. Sending `image/gif` bytes with `mediaKind: "image"` silently falls back to a document attachment. Transcode to MP4 and send `mediaKind: "gif"` to get the looping autoplay bubble. ### How big can an attachment be on a whatsapp api send file call? Two ceilings. The JSON `mediaBase64` field caps at 15,728,640 characters, which is roughly 11 MB of real file after base64 inflation. The multipart `mediaFile` path allows up to 100 MB and streams out of band. WhatsApp's own per-type limits are much lower and apply after ours. ### Do I need Meta Business verification to send media this way? No. Blueticks drives your existing WhatsApp number through WhatsApp Web or a hosted gateway, so there is no Meta Business account, no template approval, and no per-message Meta charge. You are still bound by WhatsApp's Business Messaging Policy, and WhatsApp can restrict any number for policy violations. ### Can I schedule an image or document for later? Yes. Add an ISO 8601 `sendAt` with an offset to the same body. It must be at least 10 seconds in the future and no more than 365 days out. Scheduled sends return a queue id you can later fetch, edit with `PATCH`, or pull back with the cancel endpoint. ### Why did my media send to a community fail? Posting media into a community parent group or an announce-only group where you cannot post is a known limitation on the WhatsApp Web path. The API treats "cannot send to this group" as a permanent failure, not a transient one, so retries will not help. Send to the individual subgroup instead. --- # Build a WhatsApp Agent in 5 Minutes (No Code): Read, Triage, and Reply from Claude (2026) > Five minutes, no code, no Meta approval. Connect your own number to Claude, paste one standing brief, and let the agent read and rank your WhatsApp before you touch it. URL: https://blueticks.co/blog/build-whatsapp-agent-no-code Published: 2026-07-31 Author: Daniel Roth Category: productivity You have forty unread WhatsApp threads and three of them matter. Finding those three is the job, and nobody has ever automated it for you. Here is the five-minute build: connect the number you already use, paste one standing brief, and get a ranked shortlist before a single message leaves your account. ## What does it actually mean to build a WhatsApp agent with no code? To build a WhatsApp agent with no code you assemble four things: a live WhatsApp connection, a tool scope, standing instructions, and guardrails. Installing a connector is plumbing. The agent is what you write on top, and its first job is to read and triage your chats, not to send. - **Live connection** - your own number, reachable by the model. - **Tool scope** - which actions it is allowed to call. - **Standing instructions** - the brief that defines its job every time. - **Guardrails** - draft-don't-send, plus escalation rules for the messages that need you raw. People conflate the plumbing with the agent constantly, and it costs them a working setup. The Model Context Protocol is [an open-source standard for connecting AI applications to external systems](https://modelcontextprotocol.io/docs/getting-started/intro), which its own docs compare to "a USB-C port for AI applications." A port is not a workflow. The connector lets Claude reach WhatsApp. It does not tell Claude what you want done, in what order, or what it must never do without asking. Read-first is the frame that makes this safe. A no code WhatsApp agent that starts by sending is a liability on your personal number. One that starts by reading costs you a bad summary and a re-prompt. Why this interface arrived as a protocol rather than a dashboard is the argument in our piece on [agent native WhatsApp](https://blueticks.co/blog/whatsapp-agent-native). ## What do you need before the five minutes start? Three things: a WhatsApp number you already use, an MCP-capable client such as Claude, and an engine that stays online when your laptop does not. The first two take two minutes. The third is the one people skip, and it is why most of these builds quietly stop working in week two. **Your own number.** Not a new one, not a business identity. The agent reads your real history because it drives a real session on your account. WhatsApp supports [up to four linked devices without keeping your primary phone connected](https://faq.whatsapp.com/378279804439436), and the same Help Center page notes you must log in on your primary phone every 14 days to keep linked devices attached. Put that 14-day tap on a recurring reminder. It is the most boring way this setup dies. **An MCP client.** Anthropic documents custom connectors over remote MCP as [available on Claude, Cowork, and Claude Desktop across the Free, Pro, Max, Team, and Enterprise plans](https://support.claude.com/en/articles/11175166-get-started-with-custom-connectors-using-remote-mcp), with Free accounts limited to one connector. A Claude WhatsApp setup does not need a paid plan to try. **An engine that outlives your session.** This gets its own section below. For now: if the thing holding your WhatsApp session is a process on your laptop, your agent's working hours are your laptop's working hours. The daily routine you build on top is in our guide to [Claude as a WhatsApp chief of staff](https://blueticks.co/blog/ai-whatsapp-assistant-chief-of-staff). ## Minute 0 to 2: how do you give the agent a live WhatsApp connection? Link your number once, then add a remote connector in Claude by pasting a URL and approving a login. Nothing to install, no key to store, no config file to edit. Two minutes, most of it waiting for a QR scan. Create a Blueticks account, link the number the way you would link WhatsApp Web, then in Claude open Connectors, add a custom connector, and paste `https://api.blueticks.co/mcp`. Claude sends you to a Blueticks screen to sign in and approve access. That is standard OAuth, so Claude never sees a password and you can revoke it from your settings later. When you come back, nine WhatsApp tools are live in the session, and the one that matters today is `chats`. I am not re-teaching the click path, because it already exists in full. The [connect-to-Claude walkthrough](https://blueticks.co/blog/connect-whatsapp-to-claude-mcp-integration) covers every screen, both the connector route and the key route, plus troubleshooting for when the tools do not appear. Come back here once Claude can list your chats. ## Minute 2 to 4: how do you write the agent's instructions so it reads and triages instead of blasting? Paste one standing brief into Claude's project or agent instructions and the agent behaves the same way every day. The brief has five parts: a read-only scope, a four-bucket triage rubric, an escalation rule, a draft-don't-send rule, and an output format you can skim in 60 seconds. This is the actual build. [image: Handwritten index card of standing instructions and four triage buckets propped against a keyboard] Copy the whole block. Edit the bracketed bits to your accounts and keywords, then leave it alone for a week before tuning. ``` You are my WhatsApp chief of staff. These rules apply to every request in this project. SCOPE - Use read actions only: list my chats, read messages in a thread, search history. - Do not send, schedule, archive, mark as read, add a contact, or create anything until I ask for it in that specific message. - If a request would need a write action, say so and stop. Do not do it. TRIAGE RUBRIC Put every thread you read into exactly one of these four buckets: - NEEDS A REPLY TODAY: someone asked me a direct question, someone is blocked on me, or the thread mentions invoice, payment, refund, contract, reschedule, or cancel. Anything from [Riverbend Supply, Acme Dental, K. Alvarez] lands here regardless. - WAITING ON THEM: my last message ended in a question or a request and they have not answered yet. - FYI: worth knowing, no action from me. - IGNORE: group chatter, forwards, greetings, and anything that neither names me nor asks me something. ESCALATION Tag with [ESCALATE] and do NOT draft a reply for: money owed or disputed, anything legal or contractual, and any message where the sender sounds angry or is threatening to leave. Bring those to me raw, with the sender and one line of context. DRAFTING When I ask for a reply, write the draft and stop. Match how I wrote earlier in that same thread, not a generic professional register. Show me the text and the recipient. Never call a send or schedule action unless my message contains the word SEND. OUTPUT FORMAT Return exactly this, nothing else: 1. NEEDS A REPLY TODAY, max 7 lines. Each line: name, how long they have waited, what they want, under 15 words. 2. WAITING ON THEM, max 5 lines, same shape. 3. Counts only for FYI and IGNORE. Do not list them. 4. Any [ESCALATE] items at the bottom. ``` Four clauses are load-bearing. **Scope** stops an eager model marking forty chats as read while it helps. **Named accounts and literal keywords** encode your priorities as something a model handles reliably instead of asking it to guess. **Escalation** exists because a disputed invoice is the message you least want smoothed over by a competent draft. And the **output caps** matter more than they look, because a triage list you have to triage is not triage. One honest note. That scope clause is an instruction, not a permission wall. The connector grants read and write together, so nothing in your brief physically blocks a write. In ordinary conversation what stops one is Claude asking you before it calls a tool, which is why the next section is about approvals rather than trust. Two things switch that prompt off, and you should know both before you rely on it: clicking "Allow always" for a tool, and Research, during which Claude ["can invoke tools from your connectors automatically without further approval"](https://support.claude.com/en/articles/11175166-get-started-with-custom-connectors-using-remote-mcp). Anthropic's advice for that second case is to disable any tools that can take write actions, and it is worth following. ## Minute 4 to 5: how do you run the first triage pass and verify it worked? Ask for one narrow window, read the output, then spot-check a single thread it named. Verification takes longer than the run. You are hunting two failure modes: an agent that summarised nothing because it read nothing, and an agent that produced a confident list of threads that do not exist. Start with this, and nothing more ambitious: > "Read my one-to-one WhatsApp chats since Monday 9am. Apply the standing rubric. Skip group chats entirely." Good output looks boring. Four or five lines under NEEDS A REPLY TODAY, two or three under WAITING ON THEM, counts for the rest, no prose. If you get a paragraph of summary, the output format clause did not take, and the usual cause is pasting the brief into a single chat instead of the project instructions. Then run three checks. 1. **Spot-check one named thread.** Take the top line, open that chat on your phone, confirm the person and the ask are real. A model that cannot reach your chats will still write a plausible list. This is the only way to tell the difference on run one. 2. **Check a thread it dropped.** Pick a conversation you know is live and confirm it got classified, even into IGNORE. Silent omission is the expensive error, and it usually means your time window was wrong. 3. **Run a self-send test before you enable sending.** Ask for a draft to your own number, approve it, watch it arrive. One message, to you, nothing at stake. If that round-trips cleanly, the write path works with an audience of one. Do the self-send test even though you are not sending anything today. It turns your first real send into a repeat of something you already watched work. > **Connect your own number and run your agent's first triage pass tonight.** A free Blueticks account, the number you already use, and the hosted connector. No Meta verification, no card, and a ranked shortlist instead of forty unread threads. [Start at blueticks.co/signup.](https://blueticks.co/signup) ## How do you let the agent draft replies without giving it permission to send? Keep drafting and sending as two separate acts, and leave send on per-call approval permanently. The agent writes, you read, you say the word. Promote it to sending later only inside a scope narrow enough to describe in one sentence. [image: Hand hovering over a face-up phone at a desk, pausing before approving a drafted WhatsApp reply] The protocol assumes this. The MCP specification states that "for trust & safety and security, there SHOULD always be a human in the loop with the ability to deny tool invocations," and adds that clients should ["show tool inputs to the user before calling the server"](https://modelcontextprotocol.io/specification/2025-06-18/server/tools). Anthropic's connector guidance is equally blunt: review tool approval requests carefully and only click "Allow always" for [a server and tool you trust to run unsupervised](https://support.claude.com/en/articles/11175166-get-started-with-custom-connectors-using-remote-mcp). Read tools are a defensible candidate. A send tool is not. When you promote the agent, clamp it: one chat, one message type, confirmation required. "You may send delivery confirmations to the Riverbend Supply thread only, one line, and only after showing me the text." That is auditable at a glance. "You may reply to customers" is not. Consent is yours, not the tool's. WhatsApp's Business Messaging Policy says you may only contact people who gave you their number and [opted in to receiving messages from you](https://whatsappbusiness.com/policy/), and that you are "solely responsible for determining the method of opt-in." An agent does not inherit permission from your good intentions. It inherits your recipient list. ## Why does a laptop-hosted MCP server break your agent the moment you close the lid? Because a self-hosted bridge is a process on your machine holding a session tied to your machine. Sleep, reboot, a closed terminal, or a dropped hotel wifi and the agent is offline. Nothing errors loudly. Your 7am brief simply does not happen and you find out at 11. [image: Closed laptop on a dark empty desk at night showing why a laptop-hosted MCP server goes offline] Credit where it is due, because these projects came first and they are good software. [lharries/whatsapp-mcp](https://github.com/lharries/whatsapp-mcp) pairs a Go bridge on the `whatsmeow` library with a Python MCP server and keeps your history in a local SQLite file. [WAHA](https://waha.devlike.pro/) is a self-hosted gateway that can expose an MCP endpoint. If you want your data on your own disk and you enjoy owning the stack, those are the right tools. The limit is architectural, not a quality problem. A local stdio process starts when your client starts and dies when your machine does. Fine for interactive work, where you are sitting there anyway. Fatal for standing work, which is the entire value of the brief you just pasted: overnight triage, the Monday sweep, the follow-up that fires while you are on a plane. An agent that only runs while you watch it is a demo. Our [comparison of hosted and open-source options](https://blueticks.co/blog/best-whatsapp-mcp-servers) weighs the trade-offs. ## What can this agent not do, and where is the honesty line? It is not the first WhatsApp MCP, it is not the Meta Cloud API, and no tool can promise your number will never be banned. It runs on your own number over WhatsApp Web or a hosted gateway, which is exactly why it reads your real conversations and exactly why WhatsApp's normal limits still apply to you. **Not Meta's official path.** The [WhatsApp Cloud API](https://developers.facebook.com/docs/whatsapp/cloud-api/overview) is a separate product for programmatic business messaging, with pre-approved templates and, [effective July 1, 2025, per-message pricing](https://developers.facebook.com/docs/whatsapp/pricing). It cannot do this job either: Meta's own docs state a number registered on the platform ["cannot be used with WhatsApp Messenger"](https://developers.facebook.com/docs/whatsapp/cloud-api/phone-numbers), so it has no access to your existing chats. **No ban guarantee exists.** WhatsApp's Terms of Service prohibit using the service in ways that involve "sending illegal or impermissible communications such as bulk messaging, auto-messaging, auto-dialing, and the like" ([WhatsApp Terms of Service](https://www.whatsapp.com/legal/terms-of-service)). Reading your own chats is low-risk. What moves your risk is behaviour: volume, cold first contact, and how many people block or report you. **Not a 24/7 customer-facing chatbot.** It is your agent, on your number, working your inbox. Nobody on the other end is talking to a bot. If you want one answering strangers, that is a different architecture, and the [WhatsApp AI agent build-vs-buy comparison](https://blueticks.co/blog/whatsapp-ai-agent) covers the routes to it. **Its judgement is only as good as your rubric.** The failure mode is predictable. It catches the lead you forgot about in week one, and in the same pass it files your best customer's two-word message under IGNORE, because two words with no question mark look like noise. That is not the model being stupid. That is a missing line in your brief. Put the name in. ## What does a hosted always-on engine add once your agent is running? It makes the brief run on its own clock instead of yours: overnight triage waiting when you wake, scheduled sends that fire with your laptop shut, delivery status the agent can read back, and no local bridge to restart. The agent stops being something you operate and starts being something that operated while you slept. Map that back to the rubric. **NEEDS A REPLY TODAY** is worth most at 7am, before your day fills, so the read has to happen while you sleep. **WAITING ON THEM** only works as a standing sweep, because the point is catching silence, and silence never triggers anything. Approved drafts want to leave at 8:30am Tuesday, not at the 11pm moment you approved them. That is the gap a hosted engine fills. Blueticks runs your WhatsApp session on a managed 24/7 engine and exposes it to Claude through a hosted remote connector at `https://api.blueticks.co/mcp`, so there is no process on your laptop to keep alive. Sends that fire while your machine is off use the same [offline gateway](https://blueticks.co/blog/scheduled-whatsapp-messages-phone-computer-off). The claim, as narrow as it deserves: a first hosted, no-code, product-grade agent-native WhatsApp interface. Not the first WhatsApp MCP. The open-source servers got there before us. > **Connect your own number and run your agent's first triage pass tonight.** Free account, the number you already use, the hosted connector added in Claude in about two minutes. No Meta verification, no per-message fees, no card. [Get started at blueticks.co/signup.](https://blueticks.co/signup) ## Frequently asked questions **Do I need the WhatsApp Business API for this?** No. This runs on the number you already use, over WhatsApp Web or a hosted gateway, with no Meta approval and no templates. The Cloud API is a separate product for high-volume business messaging, priced per message since July 1, 2025, and a number registered on it cannot be used with regular WhatsApp. **Can I use ChatGPT or Gemini instead of Claude?** Yes, in principle. MCP is an open standard supported across a wide range of clients, so any MCP-capable client can hold the same connection and the same standing brief. Claude is the path documented end to end here, so it is the shortest route to a working first run today. **Will this get my WhatsApp number banned?** Nobody can promise it will not, and anyone who does is overclaiming. Reading and triaging your own chats is low-risk. Sending through automation on a personal number carries the same exposure as any WhatsApp Web tool, since WhatsApp's terms prohibit bulk and auto-messaging. **Can the agent run while my computer is off?** Only if the WhatsApp session is hosted somewhere that stays awake. A self-hosted local bridge stops the moment your laptop sleeps, and the overnight run silently does not happen. A managed engine keeps the session and any scheduled sends alive independently of your machine. **How is this different from a WhatsApp chatbot?** A chatbot answers strangers on your behalf, automatically, in public. This agent works your side of the inbox: it reads your threads, ranks what needs you, and drafts replies you approve. The output is a shortlist for you, not a conversation for them. **Can it send messages on its own?** Not by default, and I would leave it that way for the first month. The brief tells it to draft and stop, and in ordinary conversation Claude asks before each tool call, so sending stays a deliberate act. Two exceptions matter: "Allow always" removes the prompt for that tool, and during Research Claude can invoke connector tools automatically without further approval, which is why Anthropic tells you to disable write-capable tools there. When you promote it, clamp the rule to one chat, one message type, confirmation required. --- # How to Build a WhatsApp Bot in Node.js on Your Own Number (No Meta Verification, 2026) > Runnable Node code for a WhatsApp bot on the number your customers already have saved. Send, receive in Express, schedule follow-ups, and the production bits that stop double-sends. URL: https://blueticks.co/blog/whatsapp-bot-nodejs Published: 2026-07-30 Author: Daniel Roth Category: productivity You want a bot that answers from the number your customers already have saved. Not a fresh number, not a Business verification queue, not a per-message bill. This is the whatsapp bot node js tutorial for that, and every snippet runs on a stock Node 22 install with no SDK. ## What can a Node.js WhatsApp bot actually do on your own number, and what can't it? A whatsapp bot nodejs on your own number can send text, media and polls, read your chat list, receive inbound messages over a webhook, and hold a scheduled send server-side. It cannot use Meta message templates, cannot safely reach strangers, and nobody can promise you an account will not be actioned. What you get: - **Send** text, media and polls to contacts, groups and channels - **Receive** inbound messages and reactions as HTTPS webhook deliveries - **Schedule** a send up to 365 days out without running a scheduler - **Read** chats, messages and delivery acks, and quote-reply in-thread What you do not get: - Meta message templates, or an Official Business Account badge - Any guarantee against a ban. WhatsApp's [Terms of Service](https://www.whatsapp.com/legal/terms-of-service) prohibit "bulk messaging, auto-messaging, auto-dialing, and the like," plus non-personal use it has not authorised. - Cold outreach. Consent is yours, and WhatsApp's advice is to [only message people who contacted you first](https://faq.whatsapp.com/361005896189245). One framing note, because it decides everything downstream. This drives the number you already own, through WhatsApp Web or an always-on gateway linked as a device. It is not [Meta's WhatsApp Business Platform](https://developers.facebook.com/documentation/business-messaging/whatsapp/about-the-platform), and that is not a marketing distinction: Meta's docs state that "numbers already in use with WhatsApp cannot be registered unless they are deleted first," and that a registered Cloud API number "cannot be used with WhatsApp Messenger" ([business phone numbers](https://developers.facebook.com/documentation/business-messaging/whatsapp/business-phone-numbers/phone-numbers)). The official path costs you the number your customers know. The [own-number REST API guide](/blog/whatsapp-rest-api-own-number) has the side-by-side. ## Should you build on whatsapp-web.js or Baileys, or call a hosted API? Build on the libraries when the session must live on your own infrastructure, or when nobody else may hold it. Call a hosted API when the bot is the product and reconnect loops, auth-state persistence and process supervision are not what you want to maintain. Both are honest answers. This is a real fork, and for once it is in your own language. [whatsapp-web.js](https://wwebjs.dev/guide/) and [Baileys](https://github.com/WhiskeySockets/Baileys) are Node libraries that predate every hosted own-number API, and thousands of bots run on them today. whatsapp-web.js "works by launching the WhatsApp Web browser application and managing it using Puppeteer," so you run a real Chromium per session; Baileys speaks the protocol over WebSockets with no browser, which is dramatically lighter. What you own when you build: | You maintain | whatsapp-web.js | Baileys | |---|---|---| | Runtime cost | A Chromium process per number | A WebSocket, no browser | | Auth state | [`LocalAuth`](https://wwebjs.dev/guide/creating-your-bot/authentication) needs a persistent filesystem, so it is "not compatible with hosts that provide ephemeral file systems"; `RemoteAuth` needs a session store: "either implement your own store or use already implemented ones" (`wwebjs-mongo`, `wwebjs-aws-s3`) | You persist credentials yourself from the [`creds.update`](https://baileys.wiki/docs/socket/connecting/) event | | Reconnect | Your own retry around client events | Your own. After a QR scan "WhatsApp will forcibly disconnect you, forcing a reconnect," and you handle that `restartRequired` case yourself | | Queue and supervision | Yours | Yours | | Version drift | Breaks when WhatsApp Web internals shift | Breaks when the protocol shifts | Two lines from the projects themselves, more useful than my opinion. whatsapp-web.js: "it is not guaranteed you will not be blocked by using this method. WhatsApp does not allow bots or unofficial clients on their platform, so this shouldn't be considered totally safe." And a code comment in [Baileys' connection guide](https://baileys.wiki/docs/socket/connecting/), on the helper most tutorials open with: "DONT EVER USE THE `useMultiFileAuthState` IN PROD." Read those as maturity, not warning labels: they tell you where the maintenance sits, which is the axis to choose on. The [Python counterpart](/blog/build-whatsapp-bot-python) walks the same fork. [image: Phone face-down beside a closed laptop, the linked-device pairing a bot session needs] ## What you need before the first line of Node: an API key, a paired number, and a chat ID Three things, in this order: a `bt_live_` API key, a WhatsApp number already paired to a live engine, and a recipient the API accepts. Pairing is the step people skip, and it is not optional. A send from an unpaired workspace has nothing to dispatch through, so it queues forever. Pair by linking the account as a device, the way you link WhatsApp Web, or turn on the always-on gateway so it survives your laptop closing. WhatsApp allows [up to four linked devices](https://faq.whatsapp.com/378279804439436) per primary phone, so a bot session does not cost you your desktop one. Verify from Node first: ```js const BASE = "https://api.blueticks.co"; const KEY = process.env.BLUETICKS_API_KEY; // export BLUETICKS_API_KEY="bt_live_..." async function api(path, init = {}) { const res = await fetch(`${BASE}${path}`, { ...init, headers: { Authorization: `Bearer ${KEY}`, "Content-Type": "application/json", ...init.headers }, }); const body = await res.json(); if (!res.ok) { const e = body.error ?? {}; throw new Error(`${res.status} ${e.code}: ${e.message} req=${res.headers.get("x-request-id")}`); } return body.data; } const engines = await api("/v1/engines"); if (engines.length === 0) throw new Error("No engine paired. Link a device first."); console.log(await api("/v1/engines/me")); // { phone, name, platform } ``` `GET /v1/engines` returns one entry per online engine with `connected`, `state` and `hasSynced`. An empty array is the failure you are checking for, not an error status. `GET /v1/engines/me` reports the number actually on the other end, the fastest way to catch "I paired the wrong account." The recipient is an E.164 phone (`+15551234567`) or a WhatsApp JID (`15551234567@c.us`, `120363...@g.us` for a group, `...@newsletter` for a channel). To find one, `GET /v1/chats` returns `chatId`, `name`, `chatType`, `unreadCount` and `lastMessageAt`, paged with `limit` (1 to 200) and `skip`. Auth and the recipient-format rules live in the [send endpoint reference](/blog/send-whatsapp-message-from-api). ## How do you send your first WhatsApp message from Node.js in about 15 lines? Post to `/v1/scheduled-messages/{chatId}` with a Bearer key and a flat JSON body. The recipient is the path segment, not a body field. Omit `sendAt` and it goes now; include it and the API holds the message. A `201` comes back wrapped as `{"success": true, "data": {...}}`. ```js // send.mjs | node 22, no dependencies const BASE = "https://api.blueticks.co"; const KEY = process.env.BLUETICKS_API_KEY; export async function send(chatId, text, { sendAt, idemKey } = {}) { const res = await fetch(`${BASE}/v1/scheduled-messages/${encodeURIComponent(chatId)}`, { method: "POST", headers: { Authorization: `Bearer ${KEY}`, "Content-Type": "application/json", ...(idemKey ? { "Idempotency-Key": idemKey } : {}), }, body: JSON.stringify({ type: "text", text, ...(sendAt ? { sendAt } : {}) }), signal: AbortSignal.timeout(30_000), }); const body = await res.json(); if (!res.ok) { const err = new Error(`${res.status} ${body.error?.code}: ${body.error?.message}`); err.status = res.status; err.retryAfter = Number(res.headers.get("retry-after")) || null; // seconds, on 429 throw err; } return body.data; // { id, status, waMessageKey, sendAt, ... } } console.log(await send("+15551234567", "Bot is alive.")); ``` That is the whole whatsapp api node js surface for sending: one endpoint, no SDK, no `axios`. Global `fetch` landed in Node v17.5.0 and stopped being experimental in v21.0.0, backed by undici ([Node globals reference](https://nodejs.org/api/globals.html)). Node 18 went end of life on 30 April 2025 and Node 20 on 30 April 2026, so target v22 or v24 ([Node release schedule](https://raw.githubusercontent.com/nodejs/Release/main/schedule.json)). Three gotchas worth ten minutes now instead of an hour later: 1. **`type` is required.** `{text: "hi"}` alone is a `400`. For media it is `{type: "media", mediaUrl: "https://..."}`, https only. 2. **Do not post to the bare collection.** `POST /v1/scheduled-messages` with the recipient in the body returns `410 Gone`. 3. **`text` caps at 4096 characters.** Mentions go inline as `@[Display Name]()`, never as a structured field. Every response carries an `X-Request-Id` header, echoed into error bodies as `error.requestId`. Log it. ## How do you receive inbound messages in Express and route them to a stateful reply? A node whatsapp webhook is one subscription plus one Express route that acknowledges immediately and only then decides on a reply. Create the subscription in the dashboard, not from code, because that is the path that issues a signing secret. Then spend your attention on routing and per-chat state that survives a restart. That ordering is a real constraint, not a preference. A webhook created in the dashboard gets an HMAC signing secret. One created through `POST /v1/webhooks` does **not**: the create path stores only `owner`, `url`, `events`, `description` and `enabled`, so no secret exists, the response carries no `signingSecret`, and its deliveries go out **unsigned**. Worse, a handler that 401s them fails **silently**: a `401` is classified as a permanent failure, so the delivery is dropped after a single attempt with no retry, and it never counts toward the auto-disable threshold. Nothing tells you. You have to alert on failed deliveries yourself. So register in the dashboard, then read the secret back over the API. ```js // api() returns body.data. A paged list flattens to // { success, data: [...], limit, skip, total }, so this is already the array. const webhooks = await api("/v1/webhooks"); // needs the webhooks:read scope const hook = webhooks.find((h) => h.url.endsWith("/hooks/whatsapp")); console.log(hook.signingSecret); // whsec_... present for dashboard-created webhooks ``` The `url` must be `https://`, so for local work register a tunnel URL. A signed delivery arrives with `Blueticks-Webhook-Signature` (`v1=`, HMAC-SHA256 over `{timestamp}.{rawBody}`), `Blueticks-Webhook-Timestamp` in unix seconds, and `X-Blueticks-Signature` over the raw body alone. Their absence is exactly how you tell an unsigned webhook from a signed one. The verification handler (raw body, constant-time compare) is written out in full in the [webhooks and auto-reply guide](/blog/whatsapp-api-webhooks-auto-reply). Import it and move on. Create it from code instead and you must protect the endpoint another way: an unguessable path, a shared token in the URL, or an IP allowlist. Treat the body as untrusted either way. Two rules for what happens next. **Acknowledge before you work:** attempts time out after 10 seconds, and a timeout is treated as *transient*, so it retries up to 8 attempts over roughly 21 hours, and 8 consecutively exhausted deliveries do auto-disable the webhook. That contrast is the useful part. A slow handler fails loudly, in the end. A handler returning a permanent 4xx (anything but `408`, `425` or `429`) fails on the first attempt and stays quiet. **Route on a table, not a chain of `if`s,** because state is per chat and must outlive the process. ```js import express from "express"; import { verify } from "./verify.js"; // from the webhooks guide import { send } from "./send.mjs"; const app = express(); const seen = new Set(); // inbound message keys. Use Redis in production. const step = new Map(); // chatId -> conversation step. Same. const routes = [ [/^(hi|hello|start)$/i, () => "Hi. Reply 1 for opening hours, 2 for a callback."], [/^1$/, () => "We are open 09:00 to 18:00, Monday to Friday."], [/^2$/, (chatId) => { step.set(chatId, "awaiting_time"); return "What time suits you?"; }], ]; app.post("/hooks/whatsapp", express.raw({ type: "application/json" }), async (req, res) => { if (!verify(req)) return res.sendStatus(401); res.sendStatus(200); // ACK FIRST. Then think. const event = JSON.parse(req.body.toString()); const key = event.id?._serialized; // WhatsApp's own message key if (!key || seen.has(key)) return; // redelivery, already handled seen.add(key); if (event.id?.fromMe) return; // never reply to yourself const chatId = event.from?.id?._serialized ?? event.from; const text = (event.body ?? "").trim(); let reply; if (step.get(chatId) === "awaiting_time") { step.delete(chatId); reply = `Booked for ${text}. We will confirm shortly.`; } else { reply = routes.find(([re]) => re.test(text))?.[1](chatId); } if (reply) await send(chatId, reply); }); app.listen(3000); ``` `express.raw()` on that route only, so `req.body` stays the bytes the HMAC was computed over. And log one real delivery before you trust a field name: the payload is WhatsApp's message object flattened, so `event.id._serialized`, `event.from` and `event.body` are what you will see. ## How do you schedule a follow-up from the bot without running your own cron? Add `sendAt` to the same call. The API holds the message and dispatches it, so there is no worker to keep alive and no in-memory queue to lose on restart. `sendAt` must be RFC 3339 with an explicit offset, at least 10 seconds ahead, and no more than 365 days out. ```js const sendAt = new Date(Date.now() + 24 * 3600_000).toISOString(); await send(chatId, "Still want that callback? Reply YES and we will book it.", { sendAt, idemKey: `followup:${chatId}:${bookingId}`, }); ``` `new Date().toISOString()` produces `2026-07-31T09:00:00.000Z`, which is accepted. What is not accepted is a hand-built local string with no offset, and what is not correct is "now plus 24 hours" when you meant "9am tomorrow in the recipient's timezone." Adding milliseconds moves an instant; a wall clock does not follow. Build the local time first, convert second. Those DST traps are worked through in the [production scheduling guide](/blog/whatsapp-api-python-schedule), and they are language-independent. Cancel with `POST /v1/scheduled-messages/{id}/cancel`. Expect one oddity: a cancelled message reports `status: "failed"` with `failureReason: "cancelled by user"`, and a later `GET` on that id returns `404`. You still want a nightly job for recurrence, since `sendAt` takes one instant, not a cron expression. > **Ready to point your bot at a real number?** [Get a /v1 API key](https://blueticks.co/signup) and have Node sending from your own WhatsApp number this afternoon. No Meta Business verification, no per-message template fees, no Chromium to babysit. [image: Network rack status LEDs at night, the always-on side of a production WhatsApp bot] ## How do you take the bot to production: idempotency, delivery acks, and safe pacing? Three changes separate a demo from a whatsapp bot nodejs you can leave running: an idempotency key so a retry never double-sends, reading the delivery ack instead of trusting the `201`, and bounded pacing with real `429` handling. Most first bots ship with none of them and duplicate on the first timeout. ### 1. Make retries and redeliveries idempotent Send an `Idempotency-Key` header derived from the business object. An identical body under the same key replays the original response: same `201`, same message id, no second message. A different body under it returns `409`. Keys are workspace-scoped, capped at 64 characters. The `secret` body field is a correlation tag, not a dedupe key; sending it twice creates two messages. The derivation rules are in the [automation API guide](/blog/whatsapp-automation-api). The Node-specific part is *where* the key sits: in an async worker pool it must be computed when the job is created, never when an attempt runs. ```js import pLimit from "p-limit"; const limit = pLimit(3); // bounded concurrency const jobs = bookings.map((b) => ({ chatId: b.phone, text: `Reminder: ${b.service} tomorrow at ${b.localTime}.`, idemKey: `booking:${b.id}:reminder`, // per business object, ONCE })); await Promise.all(jobs.map((job) => limit(() => withRetry(job)))); ``` Regenerate the key per attempt, or reach for `crypto.randomUUID()`, and every retry sends a fresh message. That is the most common duplicate-send bug in this space. Inbound needs the mirror of it. Deliveries retry, so the same message can hit your handler twice. Dedupe on WhatsApp's own message key (`event.id._serialized`), not a timestamp and not the text, in Redis with a day-long TTL rather than a `Set` a restart wipes. ### 2. Read the ack, do not trust the 2xx A `201` means the API accepted the message. It says nothing about delivery. The real ladder is five states plus a failure, and only four of them have a dedicated webhook event: | `status` | What it means | WhatsApp equivalent | Webhook event | |---|---|---|---| | `pending` | Accepted, waiting to dispatch | no tick | `message.queued` | | `confirmed` | WhatsApp's **server** took it, `waMessageKey` now present | single tick | `message.delivered` | | `received` | Reached the recipient's device | double grey tick | none, read the ack | | `read` | Opened | double blue tick | `message.read` | | `played` | Voice note played | blue mic | none, read the ack | | `failed` | Did not send, read `failureReason` | none | `message.failed` | Read that fourth column carefully, because one event name lies to you. **`message.delivered` fires on `confirmed`, the server ack, not device delivery.** For the double grey tick, subscribe to `ack_changed_webhook` instead: it carries the raw numeric ack (`-1` error, `0` pending, `1` server, `2` device, `3` read, `4` played), and you branch on `2`. There is no `message.played` event at all; `played` surfaces only as ack `4`. `waMessageKey` is the discriminator when something goes missing. It is an object of five fields (`fromMe`, `remote`, `id`, `_serialized`, plus `participant` on group messages) and only `fromMe` is guaranteed. Null values are stripped from every `2xx` body, so an undispatched message has no `waMessageKey` property at all rather than a `null` one: test for absence, never for `null`. Absent means it never reached WhatsApp; present means the problem is downstream. Subscribe rather than poll: `message.queued`, `message.delivered`, `message.read` and `message.failed` push transitions to you. Poll `GET /v1/scheduled-messages/{id}` only for a few high-stakes sends. On a free workspace polling dies fastest of all, because the 5-per-6-hour plan quota counts every read. ### 3. Pace it, and stop looping the send endpoint The send bucket allows 60 requests per 60 seconds per API key. Separately, a free workspace gets 5 API requests per 6-hour UTC window across the whole `/v1` surface. That second one is an evaluation quota: two sends and three status checks exhausts it. A subscription removes it. A `429` tells you how long to wait rather than making you guess. Both limiters send `Retry-After` in seconds; the per-key bucket additionally sends `X-RateLimit-Limit` and `X-RateLimit-Remaining`. Honour the header, and fall back to backoff with jitter when it is absent: ```js const RETRYABLE = new Set([429, 500, 502, 503, 504]); async function withRetry(job, attempts = 4) { for (let i = 0; i < attempts; i++) { try { return await send(job.chatId, job.text, { idemKey: job.idemKey }); } catch (err) { if (!RETRYABLE.has(err.status) || i === attempts - 1) throw err; // Server-stated wait wins; otherwise back off with jitter. const wait = err.retryAfter ? err.retryAfter * 1000 : Math.min(30_000, 500 * 2 ** i) * (0.5 + Math.random()); await new Promise((r) => setTimeout(r, wait)); } } } ``` Never retry `400`, `401`, `403`, `404`, `409` or `410`. None resolve on a second attempt, and a retried `409` compounds an idempotency conflict. I am not going to give you a safe messages-per-hour number, because there is not one: WhatsApp's enforcement is behavioural, not a published rate. And looping the send endpoint is the wrong shape for one-to-many work anyway. There is no bulk send endpoint. Use `POST /v1/audiences` then `POST /v1/campaigns`, which handles pacing, per-contact substitution and progress counters for you. [image: A hand resting on a closed notebook and pencil beside a closed dark laptop, tea and reading glasses] ## How do you deploy the bot and keep it running? Run the Express process anywhere with a stable HTTPS hostname, point the webhook at it, and health-check the WhatsApp session rather than the process. A whatsapp bot own number setup fails quietly: your Node app being up is not the same as your number being connected. The deploy is unremarkable, which is the point: one process, one port, two secrets (`BLUETICKS_API_KEY` and the `whsec_` signing secret), Redis for the dedupe set and per-chat state. No Chromium, no persistent volume, no session files. Five readiness checks before you call it live: 1. `GET /v1/engines` returns a non-empty array with `connected: true`. 2. `GET /v1/engines/me` shows the number you expect. 3. Send yourself a test and confirm `status` reaches `received`, not just `confirmed`. 4. Message the bot from a second phone and confirm the reply lands. 5. Replay one webhook body twice and confirm your dedupe drops the second. **What breaks**, in the order it will bite you: - **The session disconnects and your process stays green.** Subscribe to `session.disconnected` and alert on it. A queued message with no engine dispatches nothing and reports no error. - **The primary phone goes quiet.** WhatsApp requires you to open the app on the primary phone at least once every 14 days to keep linked devices connected, and disconnects them after 30 days of inactivity ([linked devices](https://faq.whatsapp.com/378279804439436)). A bot on a spare handset in a drawer dies on day 15. - **A refactor breaks signature checks.** Body-parsing middleware mounted above the webhook route breaks the HMAC, and every delivery starts 401ing. This is the outage that will not announce itself: a `401` is a permanent failure, so each delivery is dropped after one attempt, with no retry and no auto-disable to tip you off. Alert on failed deliveries, not just on your own error rate. Then reconcile. Your database thinks it queued 400 reminders; `GET /v1/scheduled-messages?status=pending` is the only source of truth for what actually is. Diff nightly, because a message that never got queued produces no error. The [own-number API reference](/blog/whatsapp-rest-api-own-number) covers the list path. ## What a Node script can't give you: audiences, campaigns, and team visibility A script sends. It does not give you a contact list a colleague can edit, a campaign with per-recipient personalisation and progress counters, or a shared view of what went out. Two of the three are API calls; the third is the dashboard the data already lands in. `POST /v1/audiences` creates a named list, up to 1000 contacts per call, each carrying up to 32 custom string variables (keys start with a letter or underscore, values up to 1024 characters). `POST /v1/campaigns` targets it with single-brace tokens in the body (`{firstName}`, plus built-ins like `{whatsappname}` and `{phone}`), and reports live `sentCount`, `deliveredCount`, `readCount` and `failedCount`. `onMissingVariable: "fail"` is the default, and it rejects the campaign at create time rather than sending a message with `{firstName}` visible in it. Anything created through `/v1` also appears in the dashboard, so a colleague can pause a campaign without you deploying. Triggered sequences build on this in the [automation API guide](/blog/whatsapp-automation-api). ## FAQ **Can I build a WhatsApp bot in Node.js without the Meta API?** Yes. A whatsapp bot without meta api drives the number you already own through WhatsApp Web or a hosted gateway linked as a device, and you call a REST endpoint from Node. No templates, no Business verification, no per-message template fees. The trade: you stay subject to WhatsApp's [Terms of Service](https://www.whatsapp.com/legal/terms-of-service) and [Messaging Guidelines](https://www.whatsapp.com/legal/messaging-guidelines), and carry the account risk yourself. **whatsapp-web.js, Baileys, or a hosted API?** Build on the libraries when the session has to stay on your own infrastructure. Baileys is a WebSocket client with no browser, far lighter than whatsapp-web.js, which runs a Chromium per session. Either way you own auth-state persistence, reconnection and supervision; a hosted API trades those for one HTTP call. **How do I stop my Node bot sending the same message twice?** Two guards. Outbound: an `Idempotency-Key` header derived from the business object, computed once when the job is created and reused on every retry. Inbound: dedupe on WhatsApp's message key (`event.id._serialized`) in Redis with a TTL, because deliveries retry up to 8 times. **How do I know a message was actually delivered?** Not from the `201`. Read the ladder: `pending`, `confirmed`, `received`, `read`, `played` or `failed`. `confirmed` means WhatsApp's server took it and `waMessageKey` is now present; `received` is the double grey tick. Watch the event names, because `message.delivered` fires on `confirmed` (server ack), not on device delivery, and there is no `message.played`. For the double grey tick subscribe to `ack_changed_webhook` and branch on ack `2`. An absent `waMessageKey` means it never reached WhatsApp. **What does the official Meta Cloud API give me that this doesn't?** Templates, an Official Business Account badge, and Meta's throughput tiers. It also costs you the number: Meta's docs say numbers already in use with WhatsApp must be deleted before registration, and a registered number [cannot be used with WhatsApp Messenger](https://developers.facebook.com/documentation/business-messaging/whatsapp/business-phone-numbers/phone-numbers). New business portfolios start at a [messaging limit of 250](https://developers.facebook.com/documentation/business-messaging/whatsapp/messaging-limits), and since 1 July 2025 [pricing is charged per delivered template message](https://developers.facebook.com/documentation/business-messaging/whatsapp/pricing). Ready to point Node at a real number? [Get an API key](https://blueticks.co/signup) and send from the number your customers already have saved, with no Meta verification and no per-message template fees. --- # WhatsApp API for AI Agents: Give Your Agent a Working Send-and-Read Tool (2026) > Your agent can query production and file tickets but still hands you WhatsApp drafts to copy-paste. Here is the tool definition, the send call, and what actually breaks. URL: https://blueticks.co/blog/whatsapp-api-for-ai-agents Published: 2026-07-29 Author: Daniel Roth Category: productivity Your agent can read the calendar, open a pull request, and query production. Then someone asks it to text a customer, and it writes you a draft to copy-paste into your phone. WhatsApp is the last channel most agents cannot actually touch. The fix is smaller than it looks: one tool definition, one authenticated endpoint, and a number your contacts already have saved. ## What does an AI agent actually need to use WhatsApp? An agent needs four things to send on WhatsApp: a number it is permitted to send from, an authenticated HTTP endpoint, a tool definition describing that endpoint in your framework's schema format, and a return path for replies. Everything after that is production hardening. The bare checklist: - **A sending number** - one your recipients recognise, already connected - **An authenticated endpoint** - HTTP with a bearer token, callable from your executor - **A tool definition** - JSON Schema in Claude, OpenAI, or LangChain shape - **An inbound path** - a signed webhook, so replies reach your agent - **Failure semantics** - idempotency keys, retries, delivery status Two very different products answer to the name "WhatsApp API," and picking the wrong one costs a sprint. Meta's WhatsApp Business Platform (the Cloud API) is the sanctioned enterprise route. It bills per message as of July 1, 2025, and Meta's own docs are explicit that rates vary by template category and recipient country code on [the WhatsApp pricing page](https://developers.facebook.com/documentation/business-messaging/whatsapp/pricing/). It also requires a dedicated business number. Meta states plainly that registered numbers "cannot be used with WhatsApp Messenger" and that ["numbers already in use with WhatsApp cannot be registered unless they are deleted first"](https://developers.facebook.com/documentation/business-messaging/whatsapp/business-phone-numbers/phone-numbers). This article is about the other route, and it is worth saying up front: **everything below runs on your own existing WhatsApp number**, driven through WhatsApp Web or a managed cloud gateway. It is not the Meta Cloud API. No business verification, no template approval, no per-message fee, and the message arrives from the number people already text you on. The tradeoffs are real and I cover them in full further down. If you want the category argument rather than the implementation, [WhatsApp going agent-native](https://blueticks.co/blog/whatsapp-agent-native) makes it. ## Which WhatsApp interface should your agent call: hosted MCP or the /v1 REST API? Use the hosted MCP server when the agent is a chat client you do not control the loop of, like Claude. Use the `/v1` REST API when you own the executor and want a typed tool your own code invokes. Both hit the same engine and the same connected number, so the choice is about who runs the loop. [image: Two brass keys of different shapes on a slate surface, representing hosted MCP versus REST API access paths] | | Hosted MCP server | `/v1` REST API | |---|---|---| | **Best for** | Claude, Claude Code, any MCP client | Your own agent, LangChain, a cron job | | **Auth** | OAuth 2.1 authorization code, PKCE `S256` required | `Authorization: Bearer bt_live_...` | | **Transport** | Streamable HTTP at `https://api.blueticks.co/mcp` | HTTPS at `https://api.blueticks.co/v1` | | **Setup** | One URL paste, no code | Mint a key, write the executor | | **Surface** | 9 action-based tools | Full endpoint surface | | **Schema discovery** | Automatic via `tools/list` | You write the tool definition | Honesty first, because it matters here: **Blueticks was not the first WhatsApp MCP server**, and the open-source ones are good. [`lharries/whatsapp-mcp`](https://github.com/lharries/whatsapp-mcp) wraps the Go [`whatsmeow`](https://github.com/tulir/whatsmeow) library, stores your history in local SQLite, and has earned roughly 5,950 GitHub stars. It runs entirely on your machine, which is the right answer if data residency is your hard constraint. Its last commit was July 13, 2025, so budget for maintenance. [`jlucaso1/whatsapp-mcp-ts`](https://github.com/jlucaso1/whatsapp-mcp-ts) does the same over [Baileys](https://github.com/WhiskeySockets/Baileys) in TypeScript. What a hosted server changes is uptime and the loop around it. A local MCP server dies when your laptop sleeps. A managed gateway keeps the WhatsApp session alive server-side, survives restarts, and exposes the same tools over OAuth so `claude.ai` on your phone can reach it. That is the whole difference. If you want the no-code walkthrough on its own, [running WhatsApp from Claude](https://blueticks.co/blog/whatsapp-mcp) covers it. ## How do you connect the hosted MCP server so an agent gets WhatsApp tools with no code? Point your MCP client at `https://api.blueticks.co/mcp`, authenticate through the browser OAuth flow, and the client discovers nine WhatsApp tools automatically. In Claude Code that is one CLI command plus one slash command. On claude.ai it is the "Add custom connector" button. No tool definitions to write. For Claude Code: ```bash claude mcp add --transport http blueticks https://api.blueticks.co/mcp ``` Then run `/mcp` inside the session, select the server, and choose **Authenticate**. Your browser opens the consent screen and the status flips to connected. On claude.ai, go to Settings then Connectors, click **Add custom connector**, paste the same URL, and hit Connect. Anthropic documents both paths in [the Claude Code MCP guide](https://code.claude.com/docs/en/mcp) and [the remote MCP connector docs](https://claude.com/docs/docs/connectors/custom/remote-mcp). The nine tools your `claude whatsapp` client receives are `scheduled_messages`, `chats`, `contacts`, `groups`, `campaigns`, `audiences`, `engine`, `webhooks`, and `utils`. Each takes a required `action` string. `scheduled_messages` accepts `send`, `get`, `list`, `update`, `cancel`, and `ack`. **Two failure modes worth knowing before you debug the wrong thing.** First, the server is Streamable HTTP only, and the JSON-RPC session runs over `POST`. A plain `GET https://api.blueticks.co/mcp` in a browser returns a small `200` discovery document listing the server's capabilities and tools, not an MCP session, so seeing JSON there tells you nothing about whether your client can connect. The legacy SSE endpoint at `/mcp/sse` returns `405` by design: the [MCP specification](https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http) deprecated the standalone HTTP+SSE transport back in protocol revision `2025-03-26`, and the current revision is `2026-07-28`. If your client is trying to open an SSE stream, that is the bug. Second, PKCE is mandatory and `S256` is the only accepted challenge method. A client that omits `code_challenge` gets a `400 invalid_request` with "PKCE required: code_challenge (S256) is mandatory", which some older MCP clients will surface as a generic connection failure. ## How do you write a WhatsApp tool definition for your own agent? Define one tool with two required parameters, `chat_id` and `text`, then have your executor `POST` to `/v1/scheduled-messages/{chat_id}`. The critical detail every framework gets wrong the first time: **the recipient is a URL path segment, not a body field.** The body carries only `type` and the content. [image: Handwritten notebook page with a boxed diagram beside a mechanical pencil on a wooden desk] Claude's Messages API uses `name`, `description`, and `input_schema`, per [Anthropic's tool use docs](https://platform.claude.com/docs/en/agents-and-tools/tool-use/overview): ```json { "name": "send_whatsapp_message", "description": "Send a WhatsApp message from the user's own connected number. Use for reminders, confirmations, and replies to people who have messaged first.", "input_schema": { "type": "object", "properties": { "chat_id": { "type": "string", "description": "Recipient as a WhatsApp chat id: '@c.us' for a person, '@g.us' for a group. E.164 like '+14155551234' also works." }, "text": { "type": "string", "description": "Message body, max 4096 characters." }, "send_at": { "type": "string", "description": "Optional ISO 8601 timestamp with offset to schedule instead of sending now. Must be 10 seconds to 365 days in the future." } }, "required": ["chat_id", "text"] } } ``` OpenAI's Responses API flattens the same schema and wants `strict` turned on. [OpenAI's function calling guide](https://developers.openai.com/api/docs/guides/function-calling) recommends always enabling strict mode, which requires `additionalProperties: false`: ```python tools = [{ "type": "function", "name": "send_whatsapp_message", "description": "Send a WhatsApp message from the user's own connected number.", "parameters": { "type": "object", "properties": { "chat_id": {"type": "string"}, "text": {"type": "string"}, }, "required": ["chat_id", "text"], "additionalProperties": False, }, "strict": True, }] ``` LangChain infers the schema from type hints, so the docstring is the description. [The LangChain tools docs](https://docs.langchain.com/oss/python/langchain/tools) note that type hints are required: ```python from langchain.tools import tool import os, requests @tool def send_whatsapp_message(chat_id: str, text: str) -> str: """Send a WhatsApp message from the user's own connected number. Args: chat_id: Recipient chat id, e.g. '14155551234@c.us' text: Message body, max 4096 characters """ r = requests.post( f"https://api.blueticks.co/v1/scheduled-messages/{chat_id}", headers={"Authorization": f"Bearer {os.environ['BLUETICKS_API_KEY']}"}, json={"type": "text", "text": text}, timeout=30, ) r.raise_for_status() return r.json()["data"]["id"] ``` Note the `type` field in that body. It is required and validation-only: `text`, `media`, or `poll`. A request without it fails schema validation before it reaches WhatsApp. For media you swap in `mediaUrl` (https only) and optionally `mediaKind`. For polls you send `pollQuestion` plus a `pollOptions` array of 2 to 12 items. ## How does the agent send a message, and what does the response actually look like? A send is one `POST` to `/v1/scheduled-messages/{chatId}` with a bearer key. It returns `201 Created` and a body wrapped in `{"success": true, "data": {...}}`. An immediate send comes back `status: "confirmed"` with the real WhatsApp message key. A send with `sendAt` comes back `status: "pending"` with a queue id. ```bash curl -X POST https://api.blueticks.co/v1/scheduled-messages/14155551234@c.us \ -H "Authorization: Bearer bt_live_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" \ -H "Content-Type: application/json" \ -H "Idempotency-Key: order-1024-shipped" \ -d '{"type": "text", "text": "Your order #1024 shipped. Tracking: https://example.com/t/1024"}' ``` The response for an immediate send: ```json { "success": true, "data": { "id": "true_14155551234@c.us_3EB0C7...", "waMessageKey": { "fromMe": true, "remote": "14155551234@c.us", "id": "3EB0C7...", "_serialized": "true_14155551234@c.us_3EB0C7..." }, "to": "14155551234@c.us", "type": "text", "text": "Your order #1024 shipped. Tracking: https://example.com/t/1024", "status": "confirmed", "createdAt": "2026-07-29T09:14:22.108Z" } } ``` Four things your executor must handle correctly: 1. **Read `data`, not the top level.** Every 2xx on `/v1` is envelope-wrapped. `resp.json()["data"]["id"]`, never `resp.json()["id"]`. 2. **`sendAt` is camelCase**, and it must be at least 10 seconds and at most 365 days in the future. Anything else is a 400. 3. **Null fields are stripped from the wire.** A pending scheduled message has no `waMessageKey` key at all rather than a `null` one. Check with `.get()`, not `is None`. 4. **The message key field is `waMessageKey`**, not `key`. Its `_serialized` value is what every per-message read endpoint takes. Add `"sendAt": "2026-07-30T09:00:00Z"` to that body and you get `{"id": "6a52f1c9...", "status": "pending", "sendAt": "..."}` instead, with a 24-hex queue id you can `PATCH` or cancel until it dispatches.
**Give your agent a WhatsApp number in 10 minutes.** Connect the number you already use, mint a `bt_live_` key, and paste the tool definition above. No Meta business verification, no template approval queue, no per-message fee, and the message lands from a number your contacts recognise. [Mint your API key and send the first message](https://blueticks.co/signup).
## How does the agent read chats and receive inbound messages via signed webhooks? Reading is two `GET` endpoints: `/v1/chats` for conversations and `/v1/messages` with an optional `chatId` query param for message history. Inbound is a webhook you register once. Since backend `20260728_1347`, deliveries are HMAC-signed, so your handler can verify them. [image: Wax-sealed envelope on a sorting table, a physical stand-in for signed WhatsApp webhook deliveries] ```bash curl "https://api.blueticks.co/v1/chats?limit=20&filter=contacts" \ -H "Authorization: Bearer bt_live_..." curl "https://api.blueticks.co/v1/messages?chatId=14155551234@c.us&limit=50&order=desc" \ -H "Authorization: Bearer bt_live_..." ``` Register a webhook and keep the secret it returns: ```bash curl -X POST https://api.blueticks.co/v1/webhooks \ -H "Authorization: Bearer bt_live_..." \ -H "Content-Type: application/json" \ -d '{ "url": "https://your-server.com/hook", "events": ["new_message_received_webhook", "message.delivered", "message.failed"], "description": "agent inbound" }' ``` The response carries `signingSecret`, prefixed `whsec_`. **Read this part carefully or you will chase a ghost:** the signing secret is issued only for newly created webhooks. A webhook you registered before signing shipped has no secret, gets no signature headers, and keeps delivering unsigned. If your verification code rejects everything, check `GET /v1/webhooks` for a `signingSecret` field first. If it is missing, recreate the webhook. Every signed delivery carries three headers. `Blueticks-Webhook-Timestamp` is unix seconds. `Blueticks-Webhook-Signature` is `v1=`, an HMAC-SHA256 over the exact string `"{timestamp}.{rawBody}"`. `X-Blueticks-Signature` is `sha256=` over the raw body alone, for handlers that skip replay windows. ```python import hmac, hashlib, os from flask import Flask, request, abort app = Flask(__name__) SECRET = os.environ["BLUETICKS_WEBHOOK_SECRET"].encode() @app.post("/hook") def hook(): raw = request.get_data() # raw bytes, BEFORE any JSON parsing ts = request.headers.get("Blueticks-Webhook-Timestamp", "") sig = request.headers.get("Blueticks-Webhook-Signature", "") expected = hmac.new(SECRET, f"{ts}.".encode() + raw, hashlib.sha256).hexdigest() if not hmac.compare_digest(sig.removeprefix("v1="), expected): abort(401) event = request.get_json() # {"id": ..., "type": "message.delivered", "created_at": ..., "data": {...}} if event["type"] == "message.delivered": print(event["data"]["waMessageKey"]["_serialized"], event["data"]["status"]) return "", 200 ``` Hash the **raw request bytes**. Re-serializing the parsed object drifts on key order and whitespace and fails every check. That single mistake accounts for most signature-verification support tickets. The event envelope is `{id, type, created_at, data}`, where `created_at` is snake_case (the envelope only) and `data` is the same public message object the send endpoint returns. ## What breaks in production: rate limits, retries, idempotency, and delivery status Four things bite at scale: the plan quota, the per-key buckets, retry duplication, and mistaking "accepted" for "delivered". All four have concrete numbers you can code against, and 429s now carry real headers so you can back off instead of guessing. [image: Single-file turnstile gate in an empty concourse, illustrating API rate limits on agent send traffic] **Rate limits.** Free accounts get 5 API requests per 6-hour window, shared across REST and MCP, so it is a build-and-test budget rather than a production one. Any active subscription lifts that. On top of it, per-key buckets apply: 60 sends per minute, 600 message reads per minute, 120 chat reads per minute. A 429 returns `Retry-After`, `X-RateLimit-Limit`, and `X-RateLimit-Remaining`. Read those instead of sleeping a fixed interval. **Idempotency.** Agents retry. A timed-out `POST` that actually succeeded will double-send unless you pass an `Idempotency-Key` header (64 chars max, scoped per workspace). Reuse the same key with the same body and the original response replays. The gotcha: **a replay returns `201`, the same status as the original**, not `200`. Detect a replay by comparing the returned message id, never by the status code. A different body under the same key returns `409 Conflict`. And do not confuse this with the body's `secret` field, which is a correlation tag only and does not deduplicate anything. **Delivery status is a lifecycle, not a boolean.** The enum runs `pending` to `confirmed` to `received` to `read`, then `played` or `failed`. `confirmed` means WhatsApp accepted it. It does not mean anyone saw it. If your agent tells a user "delivered" on `confirmed`, it is lying by one hop. Subscribe to `message.delivered`, `message.read`, and `message.failed` and branch on `event.data.status`. **Webhook retries.** A failed delivery retries up to 8 times on a backoff that stretches from 1 minute to 12 hours, with a 10-second per-attempt timeout. After 8 consecutive failures the webhook auto-disables. Your handler must be idempotent, because a slow 200 still counts as a failure and the same event will arrive twice. ## What this is not: own number, not the Meta Cloud API This runs your personal or business WhatsApp account through WhatsApp Web or a managed gateway. It is not Meta's sanctioned Business Platform, it carries account risk, and nobody honest will promise you otherwise. Consent for every message you send is yours to obtain, not something an API can launder. The limits, plainly: - **Account risk is real.** WhatsApp's Help Center states that ["Our products are not intended for bulk or automated messaging, both of which have always been a violation of our Terms of Service"](https://faq.whatsapp.com/5957850900902049), and that it will use legal action against those it determines are engaged in such abuse. A separate page warns that ["using an unauthorized application and/or unsupported device violates our Terms of Service and can result in your account being banned"](https://faq.whatsapp.com/1064395290901991). **There is no no-ban guarantee here.** Agents that reply to people who messaged first, send reminders users asked for, and pace their outbound sit far from the enforcement line. Cold blasting strangers does not, whatever the transport. - **Consent is on you.** Your agent will happily send to any `chat_id` it is handed. Gate that list in your own code. - **Personal-account scale.** No enterprise throughput tier, no priority queue. - **Session dependency.** WhatsApp allows [up to four linked devices at a time](https://faq.whatsapp.com/378279804439436), and its own docs note that linked devices "will log out if your phone is unused for over 14 days." A cloud gateway removes the laptop from that chain, not the phone. If enterprise volume, template messaging, and Meta's contractual support are what you actually need, the Cloud API is the correct product. Pay the per-message fee and the setup time. ## Where the DIY path ends and Blueticks starts Self-hosted whatsmeow and Baileys MCP servers are genuinely fine for a single developer on one machine. They stop working when the agent needs to run without you: overnight scheduling, a session that survives a laptop lid, delivery status you can query, and OAuth so a phone-based client can reach it. That is the line. Below it, clone the repo. Above it, the managed pieces are the ones that take real operational work to rebuild: - **A gateway that stays connected**, running server-side so a closed laptop does not stop your agent mid-run. - **Scheduling on the same call.** Add `sendAt` and the message queues, with `PATCH` and cancel available until it dispatches. No second scheduler service. - **Signed webhooks with retries.** 8 attempts, backoff, auto-disable, HMAC. That is a week of work to do properly. - **A hosted OAuth MCP server** so Claude on your phone reaches the same number as your backend cron job. - **Idempotency built into the send path**, which is what stops a retrying agent from texting a customer twice. The REST side of this, without the agent framing, is covered in [the own-number WhatsApp REST API walkthrough](https://blueticks.co/blog/whatsapp-rest-api-own-number). ## Frequently Asked Questions **Can an AI agent send WhatsApp messages from my own number?** Yes. A `whatsapp ai agent` calls `POST /v1/scheduled-messages/{chatId}` with a bearer API key, and the message goes out from your existing connected WhatsApp account. There is no Meta business verification and no template approval. The recipient sees the number they already have saved for you. **Is this the same as the WhatsApp Cloud API?** No. The Cloud API is Meta's sanctioned platform, bills per delivered template message since July 1, 2025, and requires a dedicated business number that cannot already be in use with WhatsApp Messenger. This runs your own existing account over WhatsApp Web or a managed gateway. Different product, different tradeoffs, different risk profile. **What is the difference between the MCP server and the REST API?** The `whatsapp mcp server` is for clients that run their own agent loop, like Claude. You paste a URL, authenticate with OAuth, and the client discovers nine tools. The REST API is for when you own the executor and want a typed tool definition your code invokes. Same engine, same number, same connected session underneath. **Why is my webhook signature verification failing?** Three usual causes. You are hashing re-serialized JSON instead of the raw request bytes. You forgot to strip the `v1=` prefix before comparing. Or the webhook predates signing and has no `signingSecret`, in which case it delivers unsigned and there is nothing to verify. Check `GET /v1/webhooks` and recreate it if the field is absent. **Will automating WhatsApp with AI get my number banned?** It can. WhatsApp's terms prohibit bulk and automated messaging, and unauthorized clients are grounds for a ban. Nobody can promise otherwise. What lowers the risk is behaviour: reply to people who contacted you first, send only what recipients asked for, pace your volume, and keep an opt-out. To `automate whatsapp with ai` safely, build a responder rather than a broadcaster. **How do I check whether my number is actually connected before the agent sends?** Call `GET /v1/engines`. It returns an array of connected engines with `connected`, `state`, and `hasSynced` fields. An empty array means nothing is paired, which is the check worth putting in front of every agent send so a failure surfaces as "not connected" rather than a confusing send error. --- # WhatsApp API in Python: How to Schedule Messages in Production (Timezones, Idempotency & Retries, 2026) > Your first scheduled POST works. This is everything that breaks after it: naive timestamps, double sends on retry, 429s, and messages that vanish without a trace. URL: https://blueticks.co/blog/whatsapp-api-python-schedule Published: 2026-07-28 Author: Daniel Roth Category: productivity Your script scheduled a reminder for 9am and it landed at 4am. Or it landed twice. Or it never landed and there was nothing in your logs to explain why. None of those are bugs in the API. They are the five things that break when a working `POST` turns into a whatsapp api python schedule that has to run unattended, and every one of them has a specific fix. ## What breaks when a Python WhatsApp schedule goes from a script to production A whatsapp api python schedule fails in five predictable places once real traffic hits it, and each one is a section below. This article assumes your first scheduled `POST` already returns a `201`; if it does not, read the [WhatsApp API quickstart](/blog/send-whatsapp-message-from-api) first, which covers key creation, recipient formatting and the first send end to end. 1. **The timestamp.** Right on your laptop, wrong on a UTC server. 2. **The retry.** A read timeout fired again and the recipient got two messages. 3. **The error handling.** You retried a `400`, which will never stop being a `400`. 4. **The burst.** You looped 300 sends and collected `429`s instead of deliveries. 5. **The silence.** One message never arrived and nothing in your code knows why. One framing note before the code. This whatsapp api python integration drives the WhatsApp number you already own, over WhatsApp Web or an always-on managed gateway linked as a device. It is not [Meta's Cloud API](https://developers.facebook.com/docs/whatsapp/cloud-api), so no message templates, no Business verification and no per-conversation billing appear anywhere below. Consent is yours: WhatsApp's policy on [unauthorized use of automated or bulk messaging](https://faq.whatsapp.com/5957850900902049) applies no matter which tool sent the message, and nobody can promise you an account will not be actioned. ## How to build a sendAt timestamp in Python that is actually correct `sendAt` is validated as an RFC 3339 datetime that must carry an explicit `Z` or a UTC offset. A naive local-time string fails with `400 sendAt: Invalid datetime`, so build the value with `datetime.now(timezone.utc)` (never `utcnow()`) and always serialize with `.isoformat()`. This is the field that breaks most often. Three failures live in it. **Failure one: `utcnow()` is naive.** `datetime.utcnow()` returns a datetime with `tzinfo` set to `None`. Calling `.isoformat()` on it produces `2026-07-28T09:00:00`, with no offset, and the API rejects it. The Python docs are blunt about this: the module has deprecated `utcnow()` since 3.12 and states that "the recommended way to create an object representing the current time in UTC is by calling `datetime.now(timezone.utc)`" ([datetime docs](https://docs.python.org/3/library/datetime.html)). **Failure two: `str()` instead of `.isoformat()`.** This one is quiet. `str(aware_dt)` renders `2026-08-01 09:00:00+00:00` with a space where [RFC 3339](https://www.rfc-editor.org/rfc/rfc3339) wants a `T`. The offset is there, the value looks correct in your log line, and the API still returns `400 sendAt: Invalid datetime`. An f-string that interpolates a datetime hits this by accident. **Failure three: DST.** "Now plus 24 hours" is not "same time tomorrow." Adding a `timedelta` moves a fixed number of seconds; a wall clock does not. Take 9:00am on 2026-10-31 in `America/New_York`, add 24 hours to the UTC instant, and you land at 08:00 EST on November 1st, because US daylight time ends that morning per the [IANA time zone database](https://www.iana.org/time-zones). An hour early on an appointment reminder is a missed appointment. To schedule a WhatsApp message, Python has to construct the local wall-clock time first and convert second, using stdlib [`zoneinfo`](https://docs.python.org/3/library/zoneinfo.html) (3.9+, backed by the IANA database). On Windows there is no system tz database, so declare a dependency on [`tzdata`](https://pypi.org/project/tzdata/). ```python from datetime import datetime, timezone from zoneinfo import ZoneInfo def send_at_local(year, month, day, hour, minute, tz_name): """9am in the RECIPIENT's zone, serialized the way the API wants it.""" local = datetime(year, month, day, hour, minute, tzinfo=ZoneInfo(tz_name)) return local.astimezone(timezone.utc).isoformat() send_at_local(2026, 11, 1, 9, 0, "America/New_York") # '2026-11-01T14:00:00+00:00' <- correct, 9am EST send_at_local(2026, 11, 1, 9, 0, "Asia/Kolkata") # '2026-11-01T03:30:00+00:00' ``` Both `Z` and a numeric offset are accepted, with or without fractional seconds. The window is bounded at both ends: at least 10 seconds ahead, no more than 365 days out. One rule that saves a migration later: store an IANA zone name per contact (`"Europe/Berlin"`), never a UTC offset. Offsets change twice a year. Zone names do not. If you are still weighing scheduling against sending immediately, the [send-versus-schedule breakdown](/blog/send-schedule-whatsapp-messages-api) covers that choice. [image: wristwatch crown macro] ## How to make a scheduled send idempotent so a retry never double-sends Pass an `Idempotency-Key` header derived from the business object, computed **once, above the retry loop**. Reusing the key with an identical body replays the original response, returning the same message id and creating no second message. Reusing it with a changed body returns `409`. The derivation rules (never a random UUID, always the thing that must produce exactly one message) are covered in full in the [WhatsApp automation API guide](/blog/whatsapp-automation-api), and the replay and conflict semantics in the [own-number REST API reference](/blog/whatsapp-rest-api-own-number). The angle those two do not cover is where the key sits relative to your retry code, which is the only place it can actually go wrong: ```python import hashlib # Computed ONCE, from the business object. Not inside the loop. idem_key = hashlib.sha256(f"booking:{booking_id}:reminder".encode()).hexdigest() for attempt in range(4): resp = session.post( url, headers={"Authorization": f"Bearer {API_KEY}", "Idempotency-Key": idem_key}, json=body, timeout=(5, 30), ) ... ``` A key generated inside the loop, or refreshed per attempt, defeats the entire mechanism. Every retry then looks like a brand new request and sends a brand new message. A SHA-256 hex digest is exactly 64 characters, which is also the header's maximum length, so it fits with nothing to spare. Two behaviours a Python caller has to handle: - **The status code does NOT change on replay.** A first create is `201`, and so is the replay of that same key. Asserting `status_code == 201` is safe, and the way to tell a replay from a fresh create is that the returned message id is the one you already have, not the status code. Do not branch on `200` here. - **Keys expire.** Stored records live 24 hours from creation, so a key reused a week later is a fresh request, not a replay. One trap worth naming: the body field `secret` is a correlation tag, not a dedupe key. The API's own field description says so directly. Sending the same `secret` twice creates two messages. ## How to retry a failed API call with exponential backoff, and which errors to never retry Retry connection errors, read timeouts, `5xx` and `429`. Never retry `400`, `401`, `403`, `404`, `409`, `410` or `422`, because none of them will resolve on a second attempt. Add jitter to the backoff, cap total attempts, and always set an explicit timeout. | Response | Retry? | Why | |---|---|---| | Connection error / read timeout | Yes | The request may never have reached the server | | `500`, `502`, `503`, `504` | Yes | Transient server-side | | `429` `rate_limited` | Yes, after your own backoff | You are early, not wrong | | `400` `invalid_request` | No | The body is malformed and will stay malformed | | `401` `authentication_required` | No | Bad or missing key | | `403` `permission_denied` | No | The key lacks the `messages:write` scope | | `404` `not_found` | No | Wrong id, or nothing pending under it | | `409` | No | Idempotency key conflict; retrying makes it worse | | `410` | No | You posted to the collection path with no recipient | The error codes in that table are the six locked strings on the `/v1` surface (`invalid_request`, `authentication_required`, `permission_denied`, `not_found`, `rate_limited`, `internal_error`), and every error body carries them as `error.code`. One implementation, using `requests` with `urllib3`'s `Retry` so you add no dependency: ```python import requests from requests.adapters import HTTPAdapter from urllib3.util.retry import Retry retry = Retry( total=4, backoff_factor=0.5, backoff_jitter=0.3, # urllib3 2.x backoff_max=30, status_forcelist=(429, 500, 502, 503, 504), allowed_methods=frozenset({"GET", "POST"}), # POST is NOT retried by default respect_retry_after_header=True, raise_on_status=False, ) session = requests.Session() session.mount("https://", HTTPAdapter(max_retries=retry)) ``` Two things there deserve a second look. `allowed_methods` replaced the old `method_whitelist` argument in urllib3 2.0, and `POST` is deliberately absent from the default set, which for this library is `HEAD, GET, PUT, DELETE, OPTIONS, TRACE`. You have to opt it in by name. See the [urllib3 Retry reference](https://urllib3.readthedocs.io/en/stable/reference/urllib3.util.html) for the current signature. Jitter matters because a fleet of workers that all fail at the same second will all retry at the same second, rebuilding the exact burst that broke them. `backoff_jitter` spreads them out. `respect_retry_after_header=True` makes urllib3 sleep for a server-stated interval when one is present, the behaviour [RFC 9110 defines for `Retry-After`](https://www.rfc-editor.org/rfc/rfc9110#field.retry-after). Leave it on for portability, but do not count on it here: as the rate-limit section below shows, this API sends no `Retry-After`, so your `backoff_factor` is what actually paces the retry. If you prefer decorators, [`tenacity`](https://pypi.org/project/tenacity/) does the same job with `@retry`. Set the timeout as a tuple, `timeout=(5, 30)`, so a connect stall and a slow read fail separately. And note the ordering: retrying a `POST` at all is only safe because the idempotency key makes the duplicate a no-op. ## WhatsApp API rate limits: the two separate ceilings, and how to pace a batch There is not one whatsapp api rate limit, there are two independent ones. A per-API-key bucket on the send endpoint allows 60 requests per 60 seconds. Separately, a plan-level quota gives free accounts 5 API requests per 6-hour UTC window across the whole `/v1` surface, while any active subscription is unlimited. Be clear about what that second number means, because it is the one that surprises people. The free tier's API quota is an **evaluation** quota, not a production one. Five requests, in a fixed 6-hour window (four windows a day, aligned to 00:00 / 06:00 / 12:00 / 18:00 UTC), counted across every `/v1` call you make, including reads. Two sends and three status checks exhausts it. It will `429` a production cron job on day one. An active subscription removes it entirely. Keep that separate from the product's plan features, which are a different thing: the Free plan can send bulk campaigns from the app (they carry Blueticks branding, and Pro removes it). The API request quota is not the campaign feature. When you do hit a `429`, read the response rather than guessing: ```python if resp.status_code == 429: body = resp.json()["error"] # The plan quota puts the wait in the body. The per-key bucket gives you nothing, # so fall back to a fixed backoff rather than reading a header that is not there. wait = body.get("upgrade", {}).get("seconds_remaining") time.sleep(int(wait or 60)) ``` The gotcha, and it is worth knowing before you write the handler: **the `429` carries no rate-limit headers at all.** No `Retry-After`, no `X-RateLimit-Limit`, no `X-RateLimit-Remaining`, confirmed against a forced `429` on a live key. The only machine-readable wait signal the API emits is `error.upgrade.seconds_remaining`, and that appears on the plan-quota `429` only. Hit the per-key bucket and you get a bare `429` with nothing to tell you how long to wait, so your client needs its own fixed backoff. A `200` carries no budget information either, so you cannot pre-emptively pace from a successful response. You find the ceiling by hitting it. For pacing a batch, a small sleep between sends or a bounded worker pool is enough, and there is no verified "safe" messages-per-hour number to give you. But looping the send endpoint is the wrong shape for one-to-many work in the first place. As of July 2026 there is no bulk or batch send endpoint on `/v1`: the supported mechanism is `POST /v1/audiences` plus `POST /v1/campaigns`, which the [own-number REST API guide](/blog/whatsapp-rest-api-own-number) walks through. > **Hitting the evaluation quota already?** [Get an API key and go unlimited](https://blueticks.co/signup). Timezone-correct, idempotent scheduled sends from your own WhatsApp number, with no Meta Business verification and no per-message fees. [image: server rack leds] ## How to see what is actually queued: listing and reconciling scheduled messages The whatsapp scheduled message api lists the queue at `GET /v1/scheduled-messages`, paging with `limit` (1 to 200, default 50) and `skip` (default 0), not `page` or `cursor`. Optional filters are `status`, `chatId`, `searchToken` and `order` (`asc` or `desc`, default `desc`). The pagination counters are siblings of `data`, not nested inside it. A successful list body looks like this: ```json { "success": true, "data": [ … ], "limit": 50, "skip": 0, "total": 412 } ``` That flat shape is what breaks a first attempt: `body["data"]["total"]` raises, `body["total"]` works. Here is the reusable generator: ```python def iter_scheduled(session, api_key, **filters): """Page /v1/scheduled-messages until the offset passes `total`.""" skip, limit = 0, 200 while True: r = session.get( "https://api.blueticks.co/v1/scheduled-messages", headers={"Authorization": f"Bearer {api_key}"}, params={"limit": limit, "skip": skip, **filters}, timeout=(5, 30), ) r.raise_for_status() body = r.json() yield from body["data"] skip += limit if skip >= body["total"]: return ``` Notice what that loop does **not** do: it never breaks on an empty page. `status=pending` is applied before pagination, so `total` is exact. Every other status value is derived from the delivery log and filtered **after** the page is cut, which means a filtered page can come back short or completely empty while later pages still hold matches, and `total` reflects the pre-filter count. Break on an empty page and you will silently truncate your own reconciliation. Two more asymmetries to plan for. The `chatId` filter takes a WhatsApp JID (`15551234567@c.us`), not the E.164 string the send path accepts in its URL. And cancel and edit live elsewhere: `POST /v1/scheduled-messages/{id}/cancel` is named in the [quickstart](/blog/send-whatsapp-message-from-api), and the `PATCH` edit path in the [own-number reference](/blog/whatsapp-rest-api-own-number). The reconciliation itself is the production point. Your database thinks it queued 400 reminders. The queue is the only source of truth for what is actually pending. Diff the two nightly and alert on the delta, because a message that never got queued produces no error anywhere. ## How to diagnose a scheduled message that never arrived Work the runbook in order. Fetch the message, read `status`, then `failureReason`, then check whether `waMessageKey` is present, then check whether an engine is even connected. Each step tells you which half of the pipeline failed, and you stop at the first one that answers. 1. **Fetch it.** `GET /v1/scheduled-messages/{id}`, then `data = resp.json()["data"]` (every single-object `2xx` body is wrapped as `{"success": true, "data": {...}}`) and read `data["status"]` first. If it still says `pending` past its `sendAt`, nothing dispatched. 2. **Read the failure reason.** If `data` carries a `failureReason`, that string is the answer and there is nothing further to do in code. 3. **Check for the wire key.** This is the discriminator. `waMessageKey` present means WhatsApp accepted the message and the problem is downstream delivery. Absent means it never reached WhatsApp at all. **Empty values are stripped from every `2xx` body**, so an absent key is a missing dictionary entry, not a `None` value: write `if "waMessageKey" not in data:` or `data.get("waMessageKey")`, never `data["waMessageKey"] is None`, which raises a `KeyError`. 4. **Check the session.** If nothing dispatched, the cause is usually not your code. `GET /v1/engines` returns one entry per connected engine with `connected`, `state` and `hasSynced`. An empty `data` array means no engine is paired, and a scheduled message cannot dispatch through a disconnected session. 5. **Quote the request id.** Every response, success and error, carries an `X-Request-Id` header, echoed into error bodies as `error.requestId`. Log it on every call. It is the single fastest thing to paste into a support ticket. Two behaviours worth knowing before you go hunting. A cancelled message does not report a `cancelled` status: the cancel endpoint returns `status: "failed"` with `failureReason: "cancelled by user"`, and the queue row is soft-deleted, so a later `GET` on that id returns `404`. And the full status ladder and its tick mapping are documented in the [quickstart](/blog/send-whatsapp-message-from-api). At any real volume, stop polling and [subscribe to webhooks](/blog/whatsapp-api-webhooks-auto-reply) instead. [image: hands coffee window morning] ## Do you still need cron or APScheduler if the API schedules server-side? For a one-shot send at a known future time, you need nothing. Set `sendAt`, the API holds the message, and building a dispatcher that wakes up to fire it is the most common over-engineering in this space. You still want a small python whatsapp scheduler for recurrence, conditional rules, and sends anchored to a business object that can move. The anti-pattern is a long-running process that holds pending messages in memory and sends them when the clock hits. If it dies, the messages die with it. Pushing the wait server-side is the entire point. Three cases genuinely still need a local scheduler: - **Recurrence.** `sendAt` takes one absolute instant. It does not accept a cron expression or a repeat rule, so a weekly reminder is recomputed and re-posted each cycle. - **Conditional rules.** "Every weekday at 9am local, skip public holidays" is your business logic, not a timestamp. - **Moving anchors.** "24 hours before the booking" changes when the booking is rescheduled. The correct shape is a short job that computes the next `sendAt` and calls the API, then exits. With [APScheduler](https://apscheduler.readthedocs.io/en/3.x/userguide.html) (3.11 at time of writing): ```python from apscheduler.schedulers.blocking import BlockingScheduler from apscheduler.triggers.cron import CronTrigger from zoneinfo import ZoneInfo sched = BlockingScheduler(timezone=ZoneInfo("UTC")) @sched.scheduled_job(CronTrigger(hour=2, minute=0)) def queue_tomorrows_reminders(): for booking in bookings_starting_tomorrow(): schedule_message( chat_id=booking.phone, text=f"Reminder: {booking.service} tomorrow at {booking.local_time}.", local_dt=booking.reminder_local_dt, tz_name=booking.timezone, # IANA name, stored per contact business_key=f"booking:{booking.id}:reminder", ) ``` That job runs for a few seconds a night. The API holds the messages for the other 23 hours and 59 minutes. When an anchoring object moves, cancel the queued message and create a new one with a new key, a pattern the [send-and-schedule guide](/blog/send-schedule-whatsapp-messages-api) covers in more depth. ## Putting it together: one production sender The whole whatsapp api python schedule collapses into one function: a UTC-converted timestamp built from the recipient's zone, an idempotency key derived from the business object and computed outside the retry path, bounded backoff with the right taxonomy, and an explicit timeout. Here is the whole schedule whatsapp message python path in one block, and it is the one worth copying. ```python import hashlib import requests from datetime import timezone from requests.adapters import HTTPAdapter from urllib3.util.retry import Retry from zoneinfo import ZoneInfo BASE, API_KEY = "https://api.blueticks.co", "bt_live_YOUR_KEY" NEVER_RETRY = {400, 401, 403, 404, 409, 410, 422} session = requests.Session() session.mount("https://", HTTPAdapter(max_retries=Retry( total=4, backoff_factor=0.5, backoff_jitter=0.3, backoff_max=30, status_forcelist=(429, 500, 502, 503, 504), allowed_methods=frozenset({"GET", "POST"}), respect_retry_after_header=True, raise_on_status=False, ))) def schedule_message(chat_id, text, local_dt, tz_name, business_key): """Queue one message. Calling again with the same business_key is a no-op. local_dt: a NAIVE datetime holding the recipient's wall-clock time. tz_name: an IANA zone name, e.g. "America/New_York". """ send_at = local_dt.replace(tzinfo=ZoneInfo(tz_name)).astimezone(timezone.utc) resp = session.post( f"{BASE}/v1/scheduled-messages/{chat_id}", headers={ "Authorization": f"Bearer {API_KEY}", "Idempotency-Key": hashlib.sha256(business_key.encode()).hexdigest(), }, json={"type": "text", "text": text, "sendAt": send_at.isoformat()}, timeout=(5, 30), ) if resp.status_code in NEVER_RETRY: raise RuntimeError( f"{resp.status_code} {resp.json()['error']['message']} " f"req={resp.headers.get('x-request-id')}" ) resp.raise_for_status() return resp.json()["data"] # 201 on create AND on idempotent replay ``` Look at what you did not have to build: a scheduler process, a durable queue, a dispatch worker, a dead-letter path, and a Meta Business verification. What you got instead is a message that arrives from the number your recipient already has saved, which is the whole reason this shape exists rather than a [Cloud API alternative](/blog/whatsapp-rest-api-own-number). One honest caveat before you wire it up: the free tier's 5 requests per 6-hour window is an evaluation quota. It is enough to prove the integration works and not enough to run it. Budget for a subscription before the cron job goes live, not after it starts throwing `429`s. ## FAQ **How do I schedule a WhatsApp message in Python?** To schedule a WhatsApp message, Python posts to `https://api.blueticks.co/v1/scheduled-messages/{chatId}` with an `Authorization: Bearer` header and a body of `{"type": "text", "text": "...", "sendAt": "..."}`. The recipient is a path segment, not a body field. `sendAt` must be an RFC 3339 datetime with an explicit offset, at least 10 seconds ahead and within 365 days. **Why does my sendAt timestamp get rejected?** Almost always a missing offset. `datetime.utcnow().isoformat()` produces a naive string and returns `400 sendAt: Invalid datetime`. So does `str(dt)`, which uses a space separator instead of a `T`. Use `datetime.now(timezone.utc)` (or a `ZoneInfo`-aware datetime) and serialize with `.isoformat()`. **How do I stop a retry from sending the same WhatsApp message twice?** Send an `Idempotency-Key` header derived from the business object, computed once before your retry loop and reused on every attempt. An identical body replays the original response: same `201`, same message id, no second message. A different body under the same key returns `409`. Keys are workspace-scoped, max 64 characters, and stored for 24 hours. **Which WhatsApp API errors should I retry?** Connection errors, read timeouts, `5xx` and `429`. Never `400`, `401`, `403`, `404`, `409`, `410` or `422`. A `409` in particular means an idempotency key conflict, and retrying compounds it. Use `status_forcelist=(429, 500, 502, 503, 504)` and opt `POST` in via `allowed_methods`, since urllib3 excludes it by default. **What happens when I hit the rate limit?** You get `429` with `error.code` of `rate_limited`. The per-key send bucket allows 60 requests per 60 seconds and returns a bare `429` with **no rate-limit headers** (no `Retry-After`, no `X-RateLimit-*`), so your client needs its own fixed backoff. The free plan quota (5 requests per 6-hour UTC window) is the only one that tells you how long to wait, as `error.upgrade.seconds_remaining` in the body. An active subscription removes the plan quota. **Do I need cron or APScheduler if the API schedules for me?** Not for a one-shot future send. Set `sendAt` and let the API hold it. You still want a nightly job for recurrence (`sendAt` takes one absolute instant, not a cron expression), for conditional rules, and for reminders anchored to objects that can move. Compute the next send time and post it, rather than holding messages in a long-running process. **How do I list everything I have scheduled?** `GET /v1/scheduled-messages` with `limit` (max 200, default 50) and `skip`. The counters `limit`, `skip` and `total` are siblings of `data` in the response, not nested inside it. Filter with `status`, `chatId` (a WhatsApp JID, not E.164), `searchToken` and `order`. Page on the offset, not on an empty page. **Why did my scheduled message never send?** Fetch it by id and read `status`, then `failureReason`. If `waMessageKey` is absent from the response, it never reached WhatsApp; if present, the problem is downstream delivery. Empty values are stripped from responses, so test for a missing key rather than `None`. Then check `GET /v1/engines`: a disconnected session cannot dispatch anything. --- # How to Schedule a Message in a WhatsApp Group in 2026 (And the Group Types Where It Won't Work) > You have the group, you have the message, and you want it out at 7am. Here's the workflow that works, and the honest list of group types where it won't send. URL: https://blueticks.co/blog/schedule-whatsapp-group-message Published: 2026-07-27 Author: Daniel Roth Category: productivity You wrote the Monday standup message on Sunday night. Sending it now pings 40 people at 11pm, and by Monday it's buried under weekend chatter. WhatsApp gives you no send-later button, so you either set an alarm for yourself or you queue it properly. The scheduling part is easy. The part nobody writes down is that four different things get called "groups" in WhatsApp, they behave differently at send time, and one of them will reject your message no matter which tool you use. ## Can you schedule a message to a WhatsApp group? Yes. WhatsApp has no built-in send-later button for groups, so you schedule it through WhatsApp Web using a scheduler that queues the message and sends it at your chosen time from your own number. The group receives an ordinary message from you, with no bot label. Which chat types accept a scheduled send: - **Normal group** - works, the everyday case. - **"Only admins can send messages" group, you're an admin** - works. - **"Only admins can send messages" group, you're not an admin** - you can't post at all, live or scheduled. - **Community announcement group, you're a community admin** - text and polls send; images are the weak spot. - **Channel** - not a group at all, different object, different rules. One thing to settle first: this runs on your own WhatsApp number over WhatsApp Web, or over an always-on managed gateway that acts as a linked device on that same number. It is not the Meta Cloud API and not the WhatsApp Business Platform. No business number, no template approval, no per-message fee. WhatsApp is building a native "Schedule Send" that [WABetaInfo reports would work in both chats and groups](https://wabetainfo.com/whatsapp-is-testing-scheduled-messages-for-chats-and-groups/), but it isn't enabled even for beta testers, and the full beta story lives in our piece on [scheduling from WhatsApp Web](https://blueticks.co/blog/how-to-schedule-a-message-on-whatsapp-web). If you need a message in a group next Tuesday at 8:45, you need a scheduler today. The cross-device version of this workflow is in the [guide to scheduling WhatsApp messages](https://blueticks.co/blog/schedule-whatsapp-messages). ## How do you schedule a message in a WhatsApp group, step by step? Six steps: open WhatsApp Web, add a scheduler, open the group, verify it's the right group, write the message, set the time. The two that only matter for groups are verifying the target and deciding about @mentions, because a group message is public and permanent the second it lands. 1. **Open web.whatsapp.com and link your phone** if you haven't already. Scan the QR once and the browser stays linked. Walkthrough in [scheduling on WhatsApp Web](https://blueticks.co/blog/schedule-whatsapp-web-messages). 2. **Add a scheduler and reload the tab.** Blueticks puts a clock icon next to the message box in every chat, groups included. 3. **Open the group, then check the participant list before you queue anything.** "Sales Team" and "Sales Team 2026" sit next to each other in the sidebar, and a message that lands in the wrong group at 7am is public and read before you're awake. Open group info, confirm two or three names you recognise. Six seconds. 4. **Write the message and decide about mentions.** An @everyone or @name mention in a scheduled message behaves exactly like a live one. It pings every member at the time you chose, including the ones whose phones are on their nightstands. Fine for a Friday roster. Not fine weekly for 200 people. 5. **Pick the date and time, then confirm.** The queue is reviewable, so you see everything lined up instead of trusting memory. 6. **Edit or cancel before it fires.** Nothing has left your machine yet, so a cancelled message was never sent. At send time the group sees a normal message from you. No "scheduled" badge, no forwarded label, no automation marker. Members can't tell you wrote it on Sunday, which is the point, and also why step 3 matters. [image: phone facedown desk dawn] ## Which WhatsApp group types can you schedule to, and which ones won't work? Four objects wear the word "group" in WhatsApp and they don't share send rules. A normal group takes anything you can type. An admins-only group takes messages from admins and refuses everyone else. A community announcement group takes admin posts. A channel isn't a group at all. | Chat type | Can you schedule to it? | What decides it | |---|---|---| | Normal group (up to 1,024 members) | Yes: text, media and polls | Nothing special, you're a participant who can post | | Group set to "Only admins can send messages" | Only if you are an admin | A WhatsApp permission, not a tool limitation | | Community announcement group | Only if you are a community admin. Text and polls send; media is unreliable | Community admin status, plus the media gap below | | Channel | Not a group. One-way broadcast, admins only | Channels are a separate product | **Normal groups.** You can [create a group with up to 1,024 members](https://faq.whatsapp.com/3242937609289432), and a scheduled message to one behaves like any other. This is the case most readers are here for, and it just works. **The "only admins can send messages" setting.** Any group admin can open group settings and choose whether [all participants or only admins can send messages](https://faq.whatsapp.com/526742385997912). WhatsApp added it for [schools, community centres and non-profits that run a group for announcements](https://blog.whatsapp.com/new-group-setting-for-admins). If it's on and you're not an admin, you cannot post. Not live, not scheduled, not through any tool. A scheduler queues a message and then hands it to WhatsApp to send; it has no private door into a permission WhatsApp is enforcing, so a queued message to a WhatsApp announcement group you can't post in will simply fail. Ask an admin to promote you, or pick a group where you can post. **Community announcement groups.** Creating a Community automatically creates an announcements group where [community admins send messages to all members](https://faq.whatsapp.com/582420703681043), and members [reply and react](https://faq.whatsapp.com/1859295147860069) rather than post their own. A Community holds [up to 100 groups and 2,000 members in total](https://faq.whatsapp.com/438859978317289), which makes that one chat the highest-leverage room most organisers have. Scheduled text and scheduled polls both land there today. We had a bug that broke that path, it was fixed, and it's verified in production. The honest caveat: on very large communities the first send attempt can exceed the send timeout and complete on a retry, so the message can arrive slightly after the minute you picked. Announcing a 7:00pm livestream to 2,000 people? Schedule it for 6:45, not 6:59. **Channels.** A channel is a [one-way broadcast where followers can't reply or interact with admins](https://faq.whatsapp.com/549900560675125). Different object, out of scope here. > **Skip the API paperwork and send from your own number.** No Meta Cloud API application, no business number, no per-message fees. Queue your next group message in WhatsApp Web and it goes out on time. [Start free.](https://blueticks.co/signup) ## Can you schedule a poll or an image to a group? Polls: yes. A scheduled poll arrives as a real WhatsApp poll that members vote in, including inside community announcement groups. Images to a normal group: yes. Images to a community announcement group: this is the least reliable path today, and it's a known open gap rather than a hypothetical. A poll is not a message with buttons drawn on it. It's a distinct WhatsApp object with its own send path, which is why it gets its own answer. WhatsApp supports [creating polls in chats](https://faq.whatsapp.com/796470361614974), and a scheduled one behaves like a live one: members vote, the creator gets notified, results update in place. Useful for anything with a deadline, like a Wednesday-morning "who's coming Friday" you wrote on Monday. Media is where I'd plan defensively. To a normal group, a scheduled image or PDF goes out fine. To a community announcement group, large-community media sends can fail on the first attempt and depend on a retry. Until that's closed, don't build a time-critical image drop into a community around it. Send it to the member groups, or post it live and watch it land. One rule outranks all of this: a poll or an image in a 500-person group generates 500 notifications. In a 1:1 chat a badly timed message is a minor annoyance. In a group spanning three time zones it's 500 people learning your messages arrive at inconvenient hours. If you're weighing which surface to schedule from, the [Chrome extension comparison](https://blueticks.co/blog/whatsapp-scheduler-chrome-extension) covers it. ## How do you set a recurring group reminder for a standup, class or rent day? Queue it once as a repeating send instead of retyping it weekly. Training reminders, monthly dues, Friday rosters: the group messages people forget, and the ones a recurring schedule handles permanently. Set day, time and interval once, and it fires on its own. People search for a WhatsApp group calendar because a group has no repeating calendar object. WhatsApp added Events to Communities announcement groups in 2024, where you can [create an event and have members confirm attendance](https://blog.whatsapp.com/new-to-communities-events-and-replies-in-announcement-groups), but that's an RSVP card for one occasion, not a recurring engine. A repeating scheduled message is the closest working substitute, and the honest answer when someone asks how to set a reminder in WhatsApp for a whole group at once. Three that earn their keep: - **Tuesday 8:45am standup prompt** in the team group, so the thread is warm before the call. - **Building dues on the 1st** in the residents group, so nobody has to be the nag. - **Friday 4pm shift roster** in the staff group, same hour weekly, so people stop asking. Repeat intervals, editing and pausing belong to the [recurring WhatsApp messages guide](https://blueticks.co/blog/schedule-recurring-whatsapp-messages). ## What happens to a scheduled group message if your computer is off? Two states, decided by where the send actually runs. A browser-based scheduler is JavaScript in your tab, so the machine has to be awake with WhatsApp Web open at send time. An always-on managed gateway runs the send on a server, so your laptop can be shut. [image: closed laptop night lamp] Close the lid at midnight and a browser-tab schedule set for 7am waits until the machine wakes, and for a group message tied to a real event, late is the same as wrong. The gateway keeps the session live as a linked device on your own number: still your number, still your groups, still not an API account. Your phone isn't the constraint, since a linked session keeps working as long as [the phone connects at least once every 14 days](https://faq.whatsapp.com/378279804439436). Device-by-device breakdown: [do scheduled WhatsApp messages send when your computer is off](https://blueticks.co/blog/scheduled-whatsapp-messages-phone-computer-off). ## Scheduling to one group vs. broadcasting to many people A group is one chat: one copy of the message, every member sees every reply, no personalization, and the members already opted into the room. A campaign is many separate one-to-one chats: personalized fields, per-recipient delivery status, and a much higher consent bar. | If you want... | Use... | Because | |---|---|---| | Everyone to see the same announcement and each other's replies | A scheduled group message | One chat, one copy, shared thread | | Each person's name or order number in their own message | A campaign to individual chats | Groups have no personalization | | To know who received and read it, per person | A campaign | A group shows group-level ticks, not per-member status | | To reach people who never joined a shared room | A campaign, with their consent | Adding strangers to a group is the fastest route to being reported | To be blunt about what people are actually asking: a group is not a way to dodge broadcast limits. Dropping 900 customers into a group so you can message them in one shot is worse than a campaign, not cleverer. They can all see each other's numbers, they can all reply to each other, and WhatsApp's own guidance is to [get permission from contacts before adding them to a group](https://faq.whatsapp.com/361005896189245). If you genuinely need many one-to-one sends, that's a campaign, and it isn't gated behind a paid plan: the Free plan sends bulk campaigns with Blueticks branding on them, and Pro removes the branding. Setup, segmentation and analytics live in [WhatsApp campaign management](https://blueticks.co/blog/whatsapp-campaign-management). [image: community hall gathering] ## What gets you muted, removed, or reported in a group Groups punish frequency and irrelevance faster than any other surface on WhatsApp, because everyone watching is a potential reporter. No tool changes that. WhatsApp acts on reports and on its own detection regardless of how a message was sent, so consent and appropriateness are yours to get right. WhatsApp's responsible-use guidance is worth reading literally: "Don't bulk message, auto-message, or auto-dial using WhatsApp," and only message "those who have contacted you first or have requested you contact them on WhatsApp" ([WhatsApp Help Center](https://faq.whatsapp.com/361005896189245)). WhatsApp is explicit that it uses [machine learning and user reports to detect and ban accounts sending unwanted automated messages](https://faq.whatsapp.com/361005896189245). Nobody, us included, can promise an outcome there. What you control is whether the message deserved to be sent. Four habits that keep you welcome: 1. **Ask the admin before scheduling anything recurring into a group you don't run.** One message costs nothing and buys you standing. 2. **Check the time zone spread.** A 7am send in Lisbon is 3am in São Paulo, and in a group everyone watches you make that mistake. 3. **Ration @everyone.** Once a quarter it's a signal. Once a week it's noise, and a muted group is worse than an ignored one because you never find out. 4. **Re-read the queue on Friday.** A message scheduled two weeks ago for a meeting that moved is a small, avoidable embarrassment. As one group organiser I work with puts it: "The moment people start scrolling past your posts, the group is over for you. You just don't find out for a month." That's the real failure mode. Not a ban, just quiet irrelevance. For what to write once the timing is right, see [WhatsApp reminder messages](https://blueticks.co/blog/send-whatsapp-reminder-messages). ## What group scheduling can't do natively, and what Blueticks adds Native WhatsApp gives a group no send-later, no recurrence, no reviewable queue, and no way to send while you're asleep. Blueticks adds those four on top of WhatsApp Web, from the number you already use, with an optional always-on gateway so a 6am message goes out at 6am with your laptop shut. No Meta Cloud API, no Business Platform approval, no second number, no per-message pricing. To repeat the boundaries rather than let that read as "works everywhere": if you're not an admin in an admins-only group, nothing sends, and media into a community announcement group is not something to bet a deadline on today. Everything else in the table above works. Ready to queue one? [Start free at blueticks.co/signup](https://blueticks.co/signup), open the group in WhatsApp Web, click the clock icon, pick the time. It goes out from your own number, and the group sees a normal message from you. ## FAQ **Can I schedule a message in a WhatsApp group?** Yes. WhatsApp has no native send-later button, so you use WhatsApp Web with a scheduler extension or an always-on gateway. Write the message now, pick a date and time, and it sends from your own number at that minute. Works in any normal group you can post in. **Can I schedule a message to a group I'm not an admin of?** In a normal group, yes, admin status is irrelevant. In a group where an admin set [posting to "Only admins"](https://faq.whatsapp.com/526742385997912), no. You can't post live either, and no scheduler overrides a WhatsApp permission. A queued message to a group you can't post in will fail. **Can I schedule to a community announcement group?** Only if you're a community admin, since [only admins send announcements](https://faq.whatsapp.com/582420703681043). Scheduled text and polls do land there today. On very large communities the first attempt can time out and complete on a retry, so delivery can run a little later than scheduled. **Will the group know the message was scheduled?** No. It appears as an ordinary message from you: no scheduled badge, no bot label, no forwarding marker. It's sent from your own number over a linked WhatsApp Web session, so it looks like a message you typed at that moment. **Can I schedule a poll to a WhatsApp group?** Yes. A scheduled poll arrives as a genuine [WhatsApp poll](https://faq.whatsapp.com/796470361614974) that members vote in, in normal groups and community announcement groups. Useful for anything with a deadline, since you can queue it days before the decision needs making. **Can I schedule an image to a group?** To a normal group, yes. To a community announcement group, treat it as unreliable right now: large-community media sends can fail on the first attempt and depend on a retry. Don't schedule a time-critical image into a community. Post it to the member groups or send it live. **Can I schedule the same message to several groups at once?** Yes, by queuing it per group, since each group is a separate chat with its own scheduled send. Stagger them by a few minutes if members overlap between groups, otherwise the same person gets the same announcement three times in one second. **Do I need the WhatsApp Business API to message a group?** No, and it's probably not what you want. Meta's Groups API requires an [Official Business Account and covers only invite-only groups the API itself creates, capped at 8 participants](https://developers.facebook.com/documentation/business-messaging/whatsapp/groups). It can't post into an existing group from your phone. For your own groups, a WhatsApp Web scheduler on your own number is the path. --- # AI WhatsApp Assistant: How to Make Claude Your WhatsApp Chief of Staff (2026) > Turn Claude into your WhatsApp chief of staff: a morning brief prompt, a reusable triage rubric, and a draft-and-approve habit you can be running by tonight. URL: https://blueticks.co/blog/ai-whatsapp-assistant-chief-of-staff Published: 2026-07-26 Author: Daniel Roth Category: productivity You open WhatsApp to check one thing and come out having skimmed forty threads, replied to two, and forgotten the client who asked you a direct question on Friday afternoon. Nothing in that loop is hard. It is just that nobody reads the pile before you do. Here is the routine that fixes it: three prompts, one triage rubric, and a habit that keeps you approving every outbound message. ## What does an AI WhatsApp assistant actually do all day? An AI WhatsApp assistant reads your existing chats, ranks which threads need a human, and drafts replies you approve before anything sends. Connected to Claude, it runs a read, triage, draft loop on the number you already use. - **Read:** pulls the chats and messages inside a time window you name. - **Triage:** ranks threads by who is waiting on you, not by recency. - **Draft:** writes the reply in your voice and holds it. - **Act:** sends or schedules only after you say go. People search for this as a WhatsApp chief of staff AI, and the name fits. A chief of staff does not make your decisions. They decide what reaches you, in what order, with the context attached. Why that interface is arriving now, and why it is an MCP server rather than another dashboard, is the argument in our piece on [WhatsApp going agent-native](https://blueticks.co/blog/whatsapp-agent-native). This one is the operating routine. ## Why the read path matters more than the send path Your bottleneck on WhatsApp is attention, not typing. You already type fast. What you cannot do is hold forty threads in your head and rank which three deserve the next ten minutes. The best AI assistant for WhatsApp is the one that reads before it writes. The minutes do not go into composing messages, which take seconds. They go into the scan: opening a thread to remember what someone wanted, re-reading a chain to check whether you replied, working out whether a group chat with 60 unread messages contains anything addressed to you. Reading is also the low-consequence half. Nobody receives anything, nobody gets messaged twice, and a bad output costs you a re-prompt instead of an apology. Be aggressive on the read path and conservative on the send path, which is the reverse of how automation usually gets pitched. For the wider surface a [WhatsApp AI agent](https://blueticks.co/blog/whatsapp-ai-agent) covers, that piece maps it. ## What you need to read WhatsApp with Claude Three things: your own WhatsApp number connected over WhatsApp Web or a managed gateway, an MCP connection between Claude and that number, and about two minutes. This runs on your personal number and your real chat history. It is not the Meta Cloud API and not the WhatsApp Business API. That distinction is load-bearing. Meta's own docs state that a registered business phone number [cannot be used with WhatsApp Messenger](https://developers.facebook.com/docs/whatsapp/cloud-api/phone-numbers), and that numbers already in use with WhatsApp cannot be registered unless they are deleted first. The Cloud API sends business messages from a separate identity, billed [per delivered template message since July 1, 2025](https://developers.facebook.com/docs/whatsapp/pricing). It cannot brief you on your personal conversations, because those conversations do not live on it. Three ways to wire up the connection that can: - **Remote connector (no key).** Add `https://api.blueticks.co/mcp` as a custom connector in Claude and approve access with a login. Note the path: `/mcp`, not `/mcp/sse`. Anthropic documents custom connectors over remote MCP as [available on Claude, Cowork, and Claude Desktop across the Free, Pro, Max, Team, and Enterprise plans](https://support.claude.com/en/articles/11175166-get-started-with-custom-connectors-using-remote-mcp), authorized through OAuth rather than a pasted key. - **npm package (API key).** Run `npx -y @blueticks/mcp` with an API key for stdio clients like Claude Code and Cursor. - **REST API.** Writing your own code? The `/v1` API covers the same actions, documented at [dev.blueticks.co](https://dev.blueticks.co). The click-by-click version, including where each client stores its config, is in the [Claude WhatsApp connection guide](https://blueticks.co/blog/connect-whatsapp-to-claude-mcp-integration). ## How to run a morning WhatsApp brief with Claude Ask for a narrow window and a capped list, never a summary of everything. A good brief names a start time, restricts scope to threads where someone is waiting on you, caps the length, and asks for one line of context per thread. You get a shortlist you can clear in ten minutes. Start with these three. > "Catch me up on WhatsApp since Friday 5pm. List only threads where someone is waiting on me, newest first, max 10, one line of context each." > "Of my one-to-one chats from the last 24 hours, which mention a date, a price, or a decision? Skip group chats entirely." > "Read the last 30 messages in my thread with the Riverbend Supply account and tell me, in three bullets, what I owe them." [image: triage notebook ranked list] Aim for this output shape. The content below is invented for illustration and is not anyone's real WhatsApp: > **Waiting on you since Friday (4)** > 1. Supplier contact, 3 days: asked you to confirm the Thursday delivery slot. > 2. New enquiry, 2 days: asked what the setup fee is, never got an answer. > 3. Existing client, 1 day: wants to move the Wednesday call, proposed two times. > 4. Accountant, 6 hours: chasing one missing receipt. > **Handled or no action: 31 threads.** Who, what, and how long they waited. No recap of threads that resolved themselves. Four levers get you there: 1. **Time window.** "Since Friday 5pm" beats "recently" every time. 2. **Scope.** Say one-to-one or groups, unread or all. Groups are where the noise lives, so exclude them by default. 3. **A cap.** "Max 10" forces ranking. Without it you get timestamp order, which is the pile you were escaping. 4. **One line of context.** Enough to decide, not enough to re-read. The failure mode is asking for too much. The assistant works from the chats and messages it can actually read, so a two-week window across every group costs time and dilutes the ranking. A tight window run twice a day beats one heroic sweep. The read tools behind it are listed in our [WhatsApp MCP primer](https://blueticks.co/blog/whatsapp-mcp). ## How to get Claude to triage what needs a human today Give it a fixed rubric instead of asking what is important. Buckets plus your own keyword rules produce a repeatable ranking, and the deliverable is a short list of things to do today. Paste the same rubric every morning so the output stays comparable day to day. Edit the names and keywords to yours, then keep this one keystroke away: > "Sort what you found into exactly four buckets: NEEDS ME TODAY, WAITING ON THEM, I PROMISED SOMETHING, NOISE. Rules: anything mentioning invoice, refund, reschedule, or cancel goes to NEEDS ME TODAY. Anything from Riverbend Supply, Acme Dental, or K. Alvarez goes to NEEDS ME TODAY regardless of content. Group chats go to NOISE unless someone used my name or asked a direct question. If my last message in a thread ended in a question, it is WAITING ON THEM. Then show me NEEDS ME TODAY and I PROMISED SOMETHING only, max 7 lines each, and give me the count of the other two buckets without listing them." Two things it does on purpose. It encodes your priorities as named accounts and literal keywords, which a model handles reliably, rather than as a vibe. And it makes silence visible: WAITING ON THEM is the bucket you never build by scrolling, because a thread you are waiting on looks identical to a finished one. The output cap matters too. A triage list you have to triage is not triage. Then add the end-of-day sweep: > "Look at every message I sent today. List anything I committed to that I have not actually done or scheduled yet." That one stings the first few times, and it is the highest-value prompt here, because the promises you forget are the ones nobody chases until they get expensive. Send-side counterparts, paced follow-ups and campaigns, live in [automating WhatsApp with AI](https://blueticks.co/blog/automate-whatsapp-with-ai). > **Ask Claude for your first morning WhatsApp brief.** Connect your own number in a click at [blueticks.co/signup](https://blueticks.co/signup). No Meta API, no per-message fees, no local server to keep alive. ## How to make Claude draft replies in your voice without letting it send Separate drafting from sending, every time. Ask for a draft, tell it to read the thread for tone, review the text, then say send. Or schedule it for business hours instead of firing at 1am. The approval step is not friction to optimize away. It is why this workflow is safe to run on your real number. The protocol is built on that assumption. The Model Context Protocol specification says that for trust and safety "there SHOULD always be a human in the loop with the ability to deny tool invocations," and that clients should [show tool inputs to the user before calling the server](https://modelcontextprotocol.io/specification/2025-06-18/server/tools). Anthropic's connector guidance is equally direct: review tool approval requests carefully and [only click "Allow always" for a server and tool you trust to run unsupervised](https://support.claude.com/en/articles/11175166-get-started-with-custom-connectors-using-remote-mcp). Read tools are a fair candidate for that. A send tool is not, and I would leave it on per-call approval permanently. [image: draft approval pause] Voice is an instruction problem, and the instruction that works is specific and negative: > "Draft a reply to the client who wants to move Wednesday. Match how I wrote earlier in that same thread, two sentences maximum, no emoji, no exclamation marks, and do not apologize. Show it to me, do not send it." "Write it in my voice" gets you a generic professional register. "Match how I wrote earlier in that same thread" gets you your actual one, because your previous messages are right there. When a draft comes back wrong, correct it in one line the way you would correct a capable new hire: "too formal, drop the second sentence." Then pick your moment. Approving a message at 11pm does not mean it should leave at 11pm. Say "schedule that for 8:30am tomorrow" and it queues instead of landing while your client is asleep. Timing details are in [scheduling WhatsApp messages from Claude](https://blueticks.co/blog/schedule-whatsapp-messages-from-claude-mcp). ## Which chief-of-staff jobs to hand over first Start where the cost of missing something is high and the cost of a wrong answer is low: unanswered leads, then your own broken promises, then group noise, then confirmations, then the weekly recap. Each is one prompt with an output you can judge at a glance. | Job | The prompt | What good output looks like | | --- | --- | --- | | 1. Unanswered-lead sweep | "Find chats from the last 14 days where someone asked me a question and my last message came before theirs. Enquiries first." | A short list of names, each with the question that never got an answer. | | 2. Promises you did not keep | "What did I say I would do in the last week that has not happened yet?" | Your own commitments, quoted back with the thread and the date. | | 3. Group-noise filtering | "From my group chats in the last 24 hours, show only messages that name me or ask a direct question." | Two or three lines, or nothing at all on a quiet day. | | 4. Supplier confirmations | "Which suppliers confirmed something this week, and which are still silent on a date I asked about?" | A confirmed column and a chasing column, no prose. | | 5. Weekly recap | "Summarize my WhatsApp week: what closed, what is still open, who is waiting on me going into Monday." | One paragraph plus an open-items list for Monday. | Job 1 usually pays for the setup on its first run, because there is almost always a lead in there who asked a real question and never heard back. Job 2 changes your behavior. Job 3 you will keep forever, because group chats are where useful messages go to die. Turning a found lead into an actual sequence is covered in our guide to [WhatsApp follow-up reminders](https://blueticks.co/blog/whatsapp-follow-up-reminder-automation). ## What an AI WhatsApp assistant cannot do, and where the line is It is not an official Meta product, it does not use the Meta Cloud API or the WhatsApp Business API, and no tool can promise your number will never be banned. Reading your own chats is low-risk. Sending through automation on your own number carries the same exposure as any WhatsApp Web tool, and consent for every message is yours. Be precise about that exposure. WhatsApp's Terms of Service prohibit conduct that involves "sending illegal or impermissible communications such as bulk messaging, auto-messaging, auto-dialing, and the like," and prohibit non-personal use of the service unless authorized ([WhatsApp Terms of Service](https://www.whatsapp.com/legal/terms-of-service)). Any tool driving a personal number sits inside that reality. What moves your risk is behavior: volume, cold first contact, and how many recipients block or report you. Not which vendor you picked. The second limit is judgement. It ranks by the rules you gave it, so it will confidently drop a thread into NOISE that mattered for reasons you never wrote down. It does not know that the short message from your biggest customer was a warning sign, or that a supplier's "no problem" has meant a delay three times running. It drafts, you decide. The alternatives deserve credit, because they came first and they are good software. [lharries/whatsapp-mcp](https://github.com/lharries/whatsapp-mcp) pairs a Go bridge on `whatsmeow` with a Python MCP server and keeps your history in a local SQLite file. [WAHA](https://waha.devlike.pro/) is a self-hosted gateway that can expose an MCP endpoint. [Composio](https://composio.dev/) routes WhatsApp tools through its connector layer. If you want local control and your data on your own disk, those are the better choice, and our [comparison of WhatsApp MCP servers](https://blueticks.co/blog/best-whatsapp-mcp-servers) lays out the trade-offs properly. ## What a chief-of-staff setup needs to be reliable at 7am It needs to be awake before you are. A morning brief is worthless if the connection died overnight, and a local bridge dies quietly: your laptop sleeps, the process drops, and the 7am digest does not happen. Nothing errors. You find out at 11am when a client follows up. [image: always on connection night desk] That is the gap Blueticks fills. It is a hosted remote OAuth MCP at `https://api.blueticks.co/mcp` plus a `/v1` REST API, both on a managed 24/7 WhatsApp engine, so the session stays up without you babysitting it. The same connection covers the write path once you approve one: send now, schedule for 8:30am, or run a paced campaign. For sends that fire while your machine is off, that is the [offline gateway](https://blueticks.co/blog/scheduled-whatsapp-messages-phone-computer-off), and the same engine serves the API at [dev.blueticks.co](https://dev.blueticks.co) if you would rather script the brief than ask for it. The claim, stated as narrowly as it deserves: a first hosted, no-code, product-grade agent-native WhatsApp interface. Not the first WhatsApp MCP. The open-source servers got there before us. What is new is that the agent is the primary user and there is no bridge for you to keep alive. > **Ask Claude for tomorrow's morning brief instead of scrolling for it.** Connect your own number at [blueticks.co/signup](https://blueticks.co/signup): no Meta API, no per-message fees, no local server to keep alive. ## Frequently asked questions **Can AI read my WhatsApp messages?** Yes, through your own connection. Once your number is linked and Claude is connected over MCP, it can list your chats, read the messages inside a thread, and search history, which is what makes digests and triage possible. It reads your real conversations because it drives your real session. **Can Claude reply to WhatsApp for me?** It can draft and it can send, but keep those separate. Ask for a draft, review it, then approve the send or schedule it for business hours. The MCP specification says there should always be a human able to deny a tool call, and a send tool is exactly the kind to approve individually. **Is this the WhatsApp Business API?** No. It runs on your own number over WhatsApp Web or a managed gateway. It is not the Meta Cloud API or the WhatsApp Business API, which sends from a separate registered business number and bills per delivered template message. A Cloud API number cannot be used with regular WhatsApp and cannot read your existing personal chats. **Will an AI assistant get my WhatsApp number banned?** There is no guarantee either way, and anyone offering one is overclaiming. Reading your own chats is low-risk. Sending through automation on your own number carries the same exposure as any WhatsApp Web tool, since WhatsApp's terms prohibit bulk and auto-messaging. Message people who expect to hear from you. **Do I need to write code?** No. The connector path is a URL and a login: add `https://api.blueticks.co/mcp` as a custom connector in Claude and approve access. Everything in this article is typed in plain language. Developers who want the same actions from their own code can call the `/v1` REST API instead, documented at dev.blueticks.co. **Does it work when my laptop is off?** Only if the session is hosted somewhere that stays awake. A self-hosted local bridge stops when your machine sleeps, so a 7am brief silently does not run. Blueticks runs the WhatsApp session on a managed engine, so the connection and any scheduled sends survive your laptop being shut. --- # How to Send a WhatsApp Message from an API (Python, Node & cURL, 2026) > Fire a WhatsApp message straight from your code with one POST. Working Python, Node, and cURL examples, how to schedule for later, and no Meta Business verification. URL: https://blueticks.co/blog/send-whatsapp-message-from-api Published: 2026-07-25 Author: Daniel Roth Category: productivity You want to fire a WhatsApp message from a script. A signup confirmation, a shipping ping, a "your table is ready." What you do not want is a month of Meta onboarding, a Business Solution Provider contract, and a per-message meter running before you have sent a single "hello world." This guide gets you from zero to a delivered message with one POST request, in cURL, Python, and Node, then shows you how to schedule the same message for later. ## What do you need before you can send a WhatsApp message from an API? You need three things to send a WhatsApp message from an API with Blueticks: an API key, a WhatsApp number already linked to your account, and a recipient phone number in E.164 format (`+15551234567`). There is no Meta Business verification, no template approval, and no waiting period. One authenticated POST does it. Here is the full pre-flight checklist: 1. **Get an API key.** Open [dev.blueticks.co](https://dev.blueticks.co), sign in, go to the API keys page, and click **Create key**. Copy it immediately, you only see it once. Live keys look like `bt_live_...` and are bearer tokens, so treat them like a password and keep them server-side. 2. **Link a WhatsApp number.** Blueticks sends from *your* number, either through WhatsApp Web in your browser or a managed 24/7 gateway. If you have already connected a number in the app, you are set. 3. **Confirm the key works.** Call `GET https://api.blueticks.co/v1/ping` with your key. Per the [Blueticks API docs](https://dev.blueticks.co), it returns the account id the key belongs to plus the WhatsApp engines currently connected, so a `200` here means auth and a live number are both good. The base URL for every call is `https://api.blueticks.co`, and every request carries an `Authorization: Bearer ` header. If you want the conceptual background on why this is a [WhatsApp REST API that runs on your own number](/blog/whatsapp-rest-api-own-number), that companion piece covers the model in depth. ## How do you send your first WhatsApp message with one API call? (cURL) To send a WhatsApp message from an API with cURL, POST a JSON body of `{type, text}` to `https://api.blueticks.co/v1/scheduled-messages/{recipient}` with your bearer key. The recipient phone number is a path segment, not a body field. Omit the `sendAt` field and the message goes out immediately. The response comes back wrapped in `{"success": true, "data": {...}}`, with the `id` and `status` you track inside `data`. That is the entire whatsapp api send message flow. ```bash curl -X POST https://api.blueticks.co/v1/scheduled-messages/+15551234567 \ -H "Authorization: Bearer bt_live_YOUR_KEY_HERE" \ -H "Content-Type: application/json" \ -d '{ "type": "text", "text": "Hello from the Blueticks API!" }' ``` Every 2xx on `/v1` is wrapped in a success envelope, so what you get back is `{"success": true, "data": { ... }}`, and the message object with its `id`, `status`, and `waMessageKey` sits inside `data`. For an immediate send the status comes back `confirmed` once WhatsApp accepts the message (with `waMessageKey` populated), and the delivery timestamps fill in as it advances. Three things trip people up on the first call: - **The recipient goes in the URL path.** It is a path segment, in E.164 with a leading `+` and country code, no spaces or dashes: `.../scheduled-messages/+15551234567`, not `(555) 123-4567`. The `+` works as-is, or URL-encode it as `%2B`. You can also target a WhatsApp chat id directly, like `12345@c.us` for a person or `1234567890@g.us` for a group. Posting to the bare `/v1/scheduled-messages` (no recipient) returns `410 Gone`. - **`type` is required.** The body is a typed union, so you must say `"type": "text"` (or `media`, or `poll`). A bare `{"text": "..."}` is rejected. Text bodies max out at 4,096 characters. - **Read through the envelope.** The message fields live under `data`, so it is `resp.json()["data"]["id"]`, never `resp.json()["id"]`. Errors are wrapped the same way, and every error carries an `error.requestId` worth logging. ## How do you send a WhatsApp message from Python? To send a WhatsApp message from Python, POST the same JSON to `/v1/scheduled-messages/{recipient}` using the `requests` library. Set the `Authorization` header to your `bt_live_` key, put the recipient in the URL path, and pass `{type, text}` as JSON. It is about ten lines with no SDK required, hitting the plain whatsapp rest api directly. ```python import requests API_KEY = "bt_live_YOUR_KEY_HERE" TO = "+15551234567" # recipient in E.164, as a path segment resp = requests.post( f"https://api.blueticks.co/v1/scheduled-messages/{TO}", headers={"Authorization": f"Bearer {API_KEY}"}, json={ "type": "text", "text": "Hello from Python!", }, timeout=30, ) resp.raise_for_status() msg = resp.json()["data"] # every 2xx is wrapped in {"success": true, "data": {...}} print("sent:", msg["id"], "status:", msg["status"]) ``` [image: python desk keyboard] The `resp.json()` payload is the same success envelope cURL returned, so the message object is one level down under `data`. Grab `msg["id"]` and hold onto it, that is the handle you use later to check delivery. If the number is not connected or the key is wrong, you get a `401` or `4xx` with an error envelope explaining why, which is exactly why the `raise_for_status()` call is there. ## How do you send a WhatsApp message from Node.js? To send a WhatsApp message from Node.js, use the built-in `fetch` (Node 18+) to POST `{type, text}` to `/v1/scheduled-messages/{recipient}` with your bearer key. No dependencies, no SDK install. Same endpoint, same body, same response as the Python and cURL versions. ```javascript const API_KEY = "bt_live_YOUR_KEY_HERE"; const TO = "+15551234567"; // recipient in E.164, as a path segment const resp = await fetch(`https://api.blueticks.co/v1/scheduled-messages/${TO}`, { method: "POST", headers: { Authorization: `Bearer ${API_KEY}`, "Content-Type": "application/json", }, body: JSON.stringify({ type: "text", text: "Hello from Node!", }), }); if (!resp.ok) throw new Error(`Send failed: ${resp.status}`); const { data } = await resp.json(); // unwrap {"success": true, "data": {...}} console.log("sent:", data.id, "status:", data.status); ``` The pattern generalizes. Want to send a PDF instead of text? Swap the body for `{"type": "media", "mediaUrl": "https://cdn.example.com/receipt.pdf", "mediaKind": "document"}`, with the recipient still in the URL path. Want a poll? Use `{"type": "poll", "pollQuestion": "...", "pollOptions": ["A", "B"]}`. The endpoint is one door with three shapes behind it. ## How do you schedule that same message for later instead of sending it now? To schedule a WhatsApp message through the API, add a `sendAt` timestamp to the same POST body. Blueticks then queues the message instead of sending it immediately. Use an RFC 3339 / ISO 8601 datetime with an offset, at least 10 seconds in the future and no more than 365 days out. This is how you schedule whatsapp messages api-side without a separate endpoint. Here is the whatsapp api python schedule version, sending a reminder for 9:00 AM UTC tomorrow: ```python import requests from datetime import datetime, timedelta, timezone API_KEY = "bt_live_YOUR_KEY_HERE" TO = "+15551234567" send_at = (datetime.now(timezone.utc) + timedelta(days=1)).replace( hour=9, minute=0, second=0, microsecond=0 ).isoformat() resp = requests.post( f"https://api.blueticks.co/v1/scheduled-messages/{TO}", headers={"Authorization": f"Bearer {API_KEY}"}, json={ "type": "text", "text": "Reminder: your appointment is at 10am.", "sendAt": send_at, # e.g. 2026-07-26T09:00:00+00:00 }, timeout=30, ) resp.raise_for_status() print("scheduled:", resp.json()["data"]["id"]) ``` The response comes back with `data.status` set to `"pending"`, meaning the message is accepted and waiting in the queue rather than dispatched. One gotcha worth calling out: `sendAt` is timezone-sensitive. Send it in UTC with a `Z` or an explicit offset, never a naked local time, or your 9 AM turns into someone else's 4 AM. Changed your mind before it fires? `POST /v1/scheduled-messages/{id}/cancel` pulls it back out of the queue. For the deeper patterns, our guide on [how to send and schedule WhatsApp messages via API](/blog/send-schedule-whatsapp-messages-api) walks through recurring sends and edits. > **Ready to send your first one?** [Grab a free API key](https://blueticks.co/signup) and send a live WhatsApp message with a single POST. No Meta Business verification, no template approval queue, no per-message fees, straight from your own number. ## Why does this API send from your own WhatsApp number instead of the Meta Cloud API? Blueticks drives the WhatsApp number you already own, over WhatsApp Web or a managed 24/7 gateway, rather than routing through Meta's Cloud API. That is why there are no per-message fees, no template pre-approval, and no Business Verification step. The tradeoff is that you own recipient consent and there is no contractual guarantee against a ban. The contrast is stark. On the official Meta Cloud API, [Meta charges per delivered template message](https://developers.facebook.com/docs/whatsapp/pricing) as of July 1, 2025, and every business-initiated template has to clear a [template categorization and approval process](https://developers.facebook.com/documentation/business-messaging/whatsapp/templates/template-categorization) before it can send. Scaling past a starter tier pulls in [messaging limits and Business Verification](https://developers.facebook.com/docs/whatsapp/messaging-limits), where unverified accounts are capped at 250 unique business-initiated recipients in a rolling 24 hours. For system-generated, high-volume messaging to strangers, that structure exists for good reason. Sending from your own number is the right fit when a human would happily type each of these messages but does not have the time: appointment reminders, order updates to your existing customers, follow-ups to people who opted in. It is the wrong fit for cold blasting thousands of people who never asked to hear from you. WhatsApp's spam detection does not care which API you used, and consent is your job either way. **What breaks:** because this rides your real WhatsApp session, that session has to stay linked. If you send over WhatsApp Web and you close the tab or your laptop sleeps, queued messages stall until it reconnects. The managed gateway exists precisely to keep a number online 24/7 so your scheduled sends fire whether or not your machine is awake. ## How do you confirm the message actually delivered after the API call returns? The POST returns the moment the message is accepted, not when it lands. To confirm delivery, poll `GET /v1/scheduled-messages/{id}` and watch the `status` field climb through `pending` → `confirmed` → `received` → `read`, or drop to `failed` with a `failureReason` explaining what went wrong. [image: phone notification check] Those statuses map onto the ticks you already know from the app. `confirmed` means WhatsApp accepted the message (it now carries a `waMessageKey`), `received` is the [two grey checks WhatsApp shows once a message reaches the recipient's phone](https://faq.whatsapp.com/665923838265756), and `read` is the two blue checks that appear once they open it (assuming they have read receipts on). A voice note that gets listened to advances one step further, to `played`. A quick Python poll: ```python msg = requests.get( f"https://api.blueticks.co/v1/scheduled-messages/{msg_id}", headers={"Authorization": f"Bearer {API_KEY}"}, ).json()["data"] print(msg["status"], msg.get("failureReason")) ``` Polling is fine for a handful of messages. At volume, do not hammer the endpoint in a tight loop. Register a webhook instead so Blueticks pushes status changes to you as they happen. Our walkthrough on [WhatsApp API webhooks and auto-replies](/blog/whatsapp-api-webhooks-auto-reply) covers the event payloads. One nuance: the message's `waMessageKey` (WhatsApp's own wire id) is `null` until the message reaches `confirmed`, and only populates once the engine actually dispatches it, so build your tracking around the `id` you got back from the send. ## When one API call is not enough: audiences, campaigns, and retries When you are messaging hundreds of people, stop looping the send endpoint. Blueticks exposes `/v1/audiences` and `/v1/campaigns` so you upload a contact list once and dispatch a single paced campaign, with retries handled for you. A metered campaign keeps you far below WhatsApp's spam radar better than a for-loop firing sends as fast as your network allows. The failure mode here is real and common. A naive script that POSTs 500 sends in a tight loop looks, from WhatsApp's side, exactly like a spam bot, and that is one of the fastest ways to get a number flagged. As one operator running reminder blasts for a clinic put it: "The moment I switched from a raw loop to a paced campaign, the delivery problems just stopped. Same messages, same number, spread over an hour instead of a minute." Practically, a campaign gives you three things a bare loop does not: - **Pacing.** Sends are spread over a window instead of a burst. - **Retries.** A transient failure gets another attempt instead of silently vanishing. - **One handle for the batch.** You track a campaign id, not 500 individual message ids. You still own consent, opt-in, and the content. The API removes the plumbing, not the responsibility. ## FAQ **Is this the official WhatsApp Business API?** No. Blueticks is a WhatsApp REST API that drives your own linked number over WhatsApp Web or a managed gateway. It is distinct from Meta's Cloud API, which is the official WhatsApp Business Platform and bills [per delivered template message](https://developers.facebook.com/docs/whatsapp/pricing). The upside is no per-message fees and no template approval; the tradeoff is no contractual delivery or anti-ban guarantee. **Do I need Meta Business verification to send a WhatsApp message from an API this way?** No. Because you send from a number you already control, there is no Business Verification, no BSP contract, and no template review. You create an API key at [dev.blueticks.co](https://dev.blueticks.co) and send. Verification only enters the picture on Meta's own Cloud API. **What does a Blueticks API key look like?** Live keys start with `bt_live_` and are sent as a bearer token in the `Authorization: Bearer ` header. Copy it when you create it, because it is shown only once, and keep it on your server, never in client-side or mobile code. **Can I schedule a recurring message through the API?** The send endpoint schedules a single message via `sendAt`. For repeating sends, either script the recurrence yourself (compute the next `sendAt` each cycle) or use the recurring scheduler in the Blueticks app. The one-shot `sendAt` accepts anything from 10 seconds to 365 days out. **Will sending through my own number get it banned?** It can if you misuse it. WhatsApp bans numbers that behave like spam bots regardless of the tool. Message people who opted in, pace bulk sends through a campaign rather than a tight loop, and keep content relevant. There is no guaranteed no-ban, and consent is always the sender's responsibility. --- # WhatsApp Is Going Agent-Native: MCP, Not Another Dashboard > A new category of software is built for an AI agent, not a person clicking around a UI. Firecrawl, Browserbase, and Exa proved it. WhatsApp is the next surface to go agent-native, and here is what that changes. URL: https://blueticks.co/blog/whatsapp-agent-native Published: 2026-07-24 Author: Avi Kohen Category: industry For twenty years, "using software" meant a human opening an app and clicking around a dashboard. That assumption is quietly breaking. A new category of product is being built so the primary user is an AI agent, not a person, and the interface is an API the model calls rather than a screen you look at. WhatsApp is next in line, and the shift changes who does the reading, the triage, and the drafting in your day. ## What does "agent-native" software actually mean? Agent-native software is built so an AI agent, not a human at a dashboard, is the primary user, with an MCP server or API as the interface instead of a UI. The product assumes a model will call it, so it ships machine-readable actions first and treats the screen as optional. The agent is the customer. The clearest proof this is a real category, not a slide-deck phrase, is a cluster of 2026 infrastructure companies that have no meaningful dashboard at all. [Firecrawl](https://www.firecrawl.dev/) turns websites into clean text for language models. [Browserbase](https://www.browserbase.com/) runs headless browsers that agents drive. [Exa](https://exa.ai/) is a search engine built to be called by a model, not typed into by a person. [Mem0](https://mem0.ai/) gives agents long-term memory. For all four, the [Model Context Protocol server is the front door, the primary way anyone is meant to use the product](https://tooldirectory.ai/blog/state-of-mcp-servers-2026). There is no "log in and explore." You point an agent at it and the agent does the work. That pattern now has scale behind it. More than 10,000 MCP servers exist across public registries, and one directory alone, Glama, [indexes close to 20,000](https://tooldirectory.ai/blog/state-of-mcp-servers-2026). Most are community noise. But the signal underneath is that building a tool for an agent to call has become a default, not an experiment. ## Why is MCP replacing the dashboard? MCP is replacing the dashboard because it is the standard interface every major AI platform now speaks. Anthropic introduced the Model Context Protocol in November 2024 as an open way for models to call external tools. Within a year, OpenAI, Google, and Microsoft all adopted it, so a single MCP server reaches every major agent at once. Build once, connect everywhere. [image: agent native infrastructure] The adoption timeline is unusually fast for an industry standard. Per the [Model Context Protocol record](https://en.wikipedia.org/wiki/Model_Context_Protocol), OpenAI adopted MCP across its products, including the ChatGPT desktop app, in March 2025. Google DeepMind followed with Gemini support in April 2025. Microsoft wired it into Copilot and its Azure and Semantic Kernel stack, and Perplexity added support as well. In December 2025, Anthropic [donated MCP to the Agentic AI Foundation under the Linux Foundation](https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation), co-founded with Block and OpenAI, which is what turns a vendor protocol into neutral plumbing. Here is why that matters for the shape of software. A dashboard is a bet that a human will show up, learn your layout, and click through your flows. An MCP server is a bet that a model will show up, read your tool definitions, and decide what to call. When five competing AI platforms all read the same tool format, the cheapest way to be useful everywhere is to expose actions, not pixels. The dashboard does not disappear. It stops being the front door. ## Why is WhatsApp the next surface to go agent-native? WhatsApp is next because the daily bottleneck there is attention, not typing, and attention is exactly what an agent can take over. Instead of you living in the app, an agent reads your chats, tells you what needs a human, drafts the replies, and sends or schedules on your approval. The work moves from your thumbs to a model that reads the pile for you. Think about how you actually use WhatsApp for work. You open it to check one thing, and forty unread threads later you have lost twenty minutes and still missed the message that mattered. The problem was never typing speed. It was that nothing could read the pile and tell you what needed you. That is a read-and-triage job, and it is the single most valuable thing an agent-native interface unlocks first, before it sends a single message. [image: chief of staff briefing] Call it the WhatsApp chief-of-staff pattern. You ask, "catch me up on WhatsApp since Friday and tell me what needs a reply," and the agent comes back with a shortlist: a client wants to move a call, a lead asked about pricing, a supplier confirmed a delivery, the rest is handled. Then, "draft a reply confirming Wednesday at 2pm," and it reads the thread for tone and writes it, waiting for your nod before anything leaves your account. Reading is the wedge. Sending is the follow-through. Both run through the same connection. For a fuller walkthrough of that loop, see our primer on [WhatsApp MCP](https://blueticks.co/blog/whatsapp-mcp). ## What does a product-grade agent-native WhatsApp interface look like? A product-grade agent-native WhatsApp interface is a hosted service that exposes your WhatsApp account to an AI agent through a remote MCP server and a REST API, with no server for you to run. The agent reads chats, messages, and contacts, and it sends, schedules, and runs campaigns. The honest framing is agent-native, not agent-bolted-on: the agent is a first-class user, not an afterthought. To be fair and accurate: Blueticks did not invent the WhatsApp MCP. Do-it-yourself open-source servers came first and are genuinely good software. [lharries/whatsapp-mcp](https://github.com/lharries/whatsapp-mcp) pairs a Go bridge on the `whatsmeow` library with a Python MCP server and stores your history in a local SQLite file. [WAHA](https://waha.devlike.pro/) is a self-hosted WhatsApp API gateway that can mount an MCP endpoint. [Composio](https://composio.dev/) routes WhatsApp tools through its connector layer. If you want local control and you are happy running and reconnecting your own process, those are the right tools, and this piece is not here to talk you out of them. [image: hosted vs bridge key] The wedge is what "product-grade" means. Those servers are self-hosted local bridges: personal-account, run-your-own-server, developer-only, and they die when your laptop sleeps. Blueticks is a hosted remote OAuth MCP plus a rich `/v1` REST API on a managed 24/7 WhatsApp engine, so the session stays alive without you babysitting it. There are three ways to connect: - **Remote connector (no key):** add `https://api.blueticks.co/mcp` as a custom connector in Claude and approve access with a login. Nothing installed, no key stored. - **npm package (API key):** one `npx -y @blueticks/mcp` entry in your Claude config for stdio clients like Claude Code or Cursor. - **`/v1` REST API:** call the same engine directly from your own code, with docs and SDKs in Python, Node, and PHP at [dev.blueticks.co](https://dev.blueticks.co). That is the defensible claim, stated plainly: a first hosted, no-code, product-grade agent-native WhatsApp interface. Not the first WhatsApp MCP. The first one where the agent is treated as the product's primary user and there is no bridge to keep alive. **Give your AI agent WhatsApp: [connect Blueticks to Claude in a click](https://blueticks.co/blog/connect-whatsapp-to-claude-mcp-integration).** Skip the per-message fees, skip the API setup, skip the local server, and let your agent read and act on your own number. ## What agent-native does not mean for WhatsApp Agent-native does not mean an official Meta product, and it does not mean risk-free. Blueticks and every open-source WhatsApp MCP work through your own number over WhatsApp Web or a managed gateway, not the Meta Cloud API. No unofficial tool can promise your number will never be banned, and consent for every message is the sender's responsibility. The agent makes you faster, not exempt. This is the part vendor announcements skip, so read it twice. The Meta Cloud API is the compliant, template-and-fees path for high-volume business messaging, and it cannot read your existing personal chats. The agent-native interfaces described here do the opposite: they read your real conversations and send from your real number, which is why the chief-of-staff pattern is possible at all. The trade is that you are operating your own account through automation, so WhatsApp's normal anti-abuse limits still apply to you. Read freely, that part is low-risk. Send deliberately, to people who expect to hear from you, at a human pace. An agent that blasts strangers gets your number flagged exactly as fast as a human who does the same. ## What this means for how you run WhatsApp For your business, the practical change is that WhatsApp stops being a place you visit and becomes a surface your agent operates. The immediate win is triage: a morning digest and a ranked list of what needs a human, before you send anything. The write path, scheduling and campaigns, follows on your approval. The cost model is your own number, no Meta conversation fees, no API onboarding. Three concrete shifts to plan around. First, the interface you build against is the agent's, not a screen, so the question moves from "which dashboard" to "which agent do I want driving this." Second, the read path arrives before the send path in value, which flips the usual automation pitch: the first thing to automate is deciding what deserves a reply, not firing more messages. Third, the compliance line does not move. An agent-native workflow on your own number carries the same ban-risk profile as any WhatsApp Web automation, so the winners will be the ones who pair the speed with restraint. If you are weighing hosted against running your own, our [comparison of WhatsApp MCP servers](https://blueticks.co/blog/best-whatsapp-mcp-servers) lays out the trade-offs without picking a favorite for you. The larger pattern is the one to internalize. Software built for agents is not a niche. It is a 2026 category with real infrastructure companies, a protocol every major AI platform speaks, and tens of thousands of servers already published. WhatsApp is simply the next high-value surface to cross that line. The only open question is whether you meet it with an agent that reads the pile for you, or keep scrolling the pile yourself. ## Frequently asked questions **What does agent-native mean?** Agent-native describes software built so an AI agent, not a human at a dashboard, is the primary user. The interface is an MCP server or API the model calls, and the screen is optional. Companies like Firecrawl, Browserbase, Exa, and Mem0 ship an MCP server as their front door, the primary way the product is meant to be used. **Is WhatsApp officially agent-native?** No. Meta has not shipped an agent-native WhatsApp product. The agent-native interfaces available today, both hosted and open-source, work through your own number over WhatsApp Web or a managed gateway, not the official Meta Cloud API. They let an AI agent read your real chats and send from your real number. **Is Blueticks the first WhatsApp MCP?** No, and any claim that it is would be wrong. Open-source WhatsApp MCP servers such as lharries/whatsapp-mcp, WAHA, and Composio came first. Blueticks' defensible claim is narrower: a first hosted, no-code, product-grade agent-native WhatsApp interface, where the session runs on a managed engine and there is no local server to keep alive. **Which AI platforms support MCP?** Every major one. Anthropic introduced MCP in November 2024, and OpenAI adopted it in March 2025, Google added Gemini support in April 2025, and Microsoft wired it into Copilot and Azure. Perplexity supports it too. In December 2025 the protocol was donated to the Agentic AI Foundation under the Linux Foundation. **Will running an AI agent on WhatsApp get my number banned?** It can, if you send carelessly. Reading and triaging your own chats is low-risk. Sending through unofficial automation on your own number carries the same ban-risk as any WhatsApp Web tool, so message only people who opted in, pace bulk sends, and avoid cold-blasting strangers. Consent is your responsibility, not the tool's. ## Give your agent WhatsApp The dashboard era assumed a human would show up and click. The agent-native era assumes a model will show up and act. WhatsApp is crossing that line now, and the read-triage-draft loop is the reason it matters. Connect your own number to Claude, let it read the pile and tell you what needs you, then send on your approval. Start at [blueticks.co/signup](https://blueticks.co/signup) and hand your WhatsApp to an agent instead of your thumbs. --- # How to Set Up a WhatsApp Automation Sequence in 2026 (Step-by-Step) > A step-by-step build for a WhatsApp automation sequence that fires timed follow-ups on its own and stops the second a lead replies. From your own number, free to start. URL: https://blueticks.co/blog/whatsapp-automation-sequence-setup Published: 2026-07-24 Author: Daniel Roth Category: productivity You send message one, the lead reads it, and then nothing. You mean to follow up on Thursday. Thursday you forget. By the time you remember, the lead has gone cold and you are back to square one. The fix is not more discipline. It is a sequence that fires the follow-ups for you and gets out of the way the moment someone answers. This is the practical build. What a WhatsApp automation sequence actually is, why the app itself can't run one, how to map the touches and delays, the exact step-by-step setup, and the failure modes nobody warns you about. By the end you'll have a working sequence sending from your own number. ## What is a WhatsApp automation sequence, and when do you need one? A WhatsApp automation sequence is a series of pre-written messages that send to each contact automatically, spaced by delays you set, with the whole series canceling for that contact the moment they reply. You need one when leads go quiet after the first message and your manual follow-ups keep slipping. The three things people confuse it with: - **One-time scheduled message** - one message, sent once, later. - **Recurring message** - the same message, re-sent on a fixed cadence. - **Broadcast** - one message, blasted to many people at once. An automation sequence is none of those. The unit of work is the sequence per contact, not the send. When a lead enters the list, they get touch one now, touch two at 48 hours, touch three on day five, and the series stops the instant they answer. Here is the concrete case. You run a small design studio and 40 people a month request a quote. You send the quote, half go silent, and you have no system chasing the silent half. A three-touch [WhatsApp drip sequence](https://blueticks.co/blog/whatsapp-drip-sequence) that opens with the quote, nudges at day two, and makes a direct ask at day five recovers the leads you were quietly losing. That is whatsapp lead nurturing done with a schedule instead of your memory. ## Why can't you build an automation sequence in the WhatsApp app itself? You can't because WhatsApp has no native sequencing. The standard app ships no scheduler at all. The Business app offers only greeting and away messages, and both are auto-replies triggered by an incoming message from a contact, never a proactive multi-step series you send on your own initiative. Be precise about what the Business app does. A [greeting message](https://faq.whatsapp.com/501866148528310/) sends automatically when someone messages you for the first time, or after 14 days of inactivity. An [away message](https://faq.whatsapp.com/2565868990219715/) replies when a contact writes to you outside your set hours, with three scheduling modes: always send, a custom schedule, or outside business hours. Notice the pattern. Every one is a reply to something a contact sent you first. An automation sequence is the reverse. It reaches out, on a timed plan, to people who haven't written back. There is no button for that in the app, free or Business. To get proactive, multi-step, stop-on-reply sends you need a tool that sits on top of [WhatsApp Web](https://blueticks.co/blog/best-whatsapp-drip-campaign-tools) and drives your existing number. ## What do you need before you set up an automated WhatsApp messages sequence? Four things: a contact list with a first-name field, a clear trigger for who enters, a timing plan for the delays between touches, and recorded opt-in with an easy way out. Get these right before you write a single message. A sequence built on a messy list or missing consent fails on contact with reality. Run this checklist first: 1. **A list with fields.** Import your contacts with at least a first name and one segmenting field, like source or product interest. Those fields power your personalization variables later. A flat list of raw numbers kills both `{firstName}` and any segmenting. 2. **A trigger.** Decide what puts someone into the sequence. New quote request, trial signup, downloaded a guide. In Blueticks this is an audience: the sequence runs against that audience, so entering it is the trigger. 3. **A timing plan.** Sketch the delays before you touch any tool. How many touches, how far apart. More on the spine in the next section. 4. **Opt-in and an out.** Every contact needs recorded consent that names WhatsApp as the channel, plus a simple way to stop hearing from you. This is not optional politeness. Messaging people who never opted in from a personal number is the fastest route to a ban. If any of the four is shaky, fix it now. A whatsapp nurture sequence amplifies whatever list you point it at, including a bad one. ## How do you map out the sequence steps and delays? Map three to five touches over five to fourteen days, with the gaps widening as you go. A reliable spine: touch one immediately, touch two at 48 hours, touch three on day five, and an optional touch four on day nine. Each message drives one action. More than five touches earns mutes and blocks. [image: sequence mapping desk] Write the map on paper before you open any software. A proven layout: | Touch | Timing | Job of the message | | --- | --- | --- | | 1 | Immediately | Introduce, deliver the thing, ask one qualifying question | | 2 | +48 hours | Handle the obvious objection or add value | | 3 | Day 5 | Make the direct ask (book, buy, reply) | | 4 (optional) | Day 9 | Last, low-pressure nudge, then stop | Two rules keep the map honest. First, one action per message. Touch one asks a question, touch three makes the ask, and no single message tries to do both. Second, widen the gaps. Bunching four messages into three days reads as pressure. Spreading them over nine days reads as a person following up. If your need is date-driven rather than lead-driven, like a renewal or payment nudge, a recurring reminder fits better than a sequence. The [automated follow-up sequence guide](https://blueticks.co/blog/whatsapp-automated-follow-up-sequence) has ready templates for both shapes. ## How do you set up a WhatsApp automation sequence step-by-step? Set it up in six steps: connect your number, build the audience with fields, create the drip with your mapped touches, set the per-step delays, turn on stop-on-reply, then send yourself a test. The build takes well under an hour once your list is clean. Here is the exact workflow. 1. **Connect your number.** Install the Blueticks Chrome extension and link your WhatsApp number by scanning the QR code the way WhatsApp Web does. This is the engine that sends. No second number, no Meta approval. 2. **Build the audience.** Import your contacts into an audience with a first name and at least one segmenting field. This is the list your sequence runs against. 3. **Create the drip.** Open drip campaigns and add your touches in order. Each touch is a real message with its own copy and, where useful, a `{firstName}` variable pulled from the audience field. 4. **Set the per-step delays.** Give each step its wait: touch one immediately, touch two at 48 hours, touch three at five days. Each delay is a number plus a unit — minutes, hours, days, weeks, months or years — so short bursts and slow nurtures both fit. A minute is the shortest gap you can set, and there is no maximum. 5. **Turn on stop-on-reply.** Switch it on so a reply removes the contact from the remaining steps automatically. This is the setting that separates a follow-up from spam. Cover it in the next section. 6. **Test before you trust it.** Add your own number to a one-person test audience, run the sequence with short delays, and confirm each touch arrives and that replying kills the rest. Never point a new sequence at real leads unverified. **What breaks:** on the basic browser-sending setup, WhatsApp Web has to stay open and the computer awake at each send time. Close the tab or sleep the laptop and that touch is skipped. This is the single most common reason a sequence goes quiet mid-run. The fix is the offline gateway, which sends server-side even with your browser closed. More on that in the limits section. Skip the per-message fees, the API onboarding queue, and the template approvals. [Set up your first automated WhatsApp sequence with Blueticks](https://blueticks.co/signup), free to start, sending from your own number, and replies auto-pause it. ## How do you make the sequence stop when someone replies? You switch on stop-on-reply. In Blueticks it is a setting on the drip campaign: the moment a contact sends any message back, they are removed from every remaining step of the sequence automatically. The conversation hands off to a human, and no scheduled touch ever fires into an active thread. This is the capability most tools get wrong, so it deserves the demo. Without stop-on-reply, a lead who booked a call on touch two still receives the "still interested?" nudge on touch four. That single message reads as spam, earns a block, and undoes the trust the sequence just built. Here is the pattern in practice. Velora Studio, a synthetic-but-representative fitness studio, ran 300 trial signups a month through one manual follow-up, and most leads never got a second touch. They rebuilt it as a four-touch [automated WhatsApp messages sequence](https://blueticks.co/blog/whatsapp-automated-follow-up-sequence) with stop-on-reply: day zero welcome with a question, day two schedule link, day five social proof, day nine direct ask. > "Once stop-on-reply was on, the awkward messages just stopped. Nobody who had already booked got a 'still interested?' chase, and our block rate stayed flat while volume tripled." - Velora Studio owner (synthetic operator quote, representative of the pattern) That is the whole argument. The exit logic is the product, not a branch you have to remember to wire into every step. ## What automated WhatsApp messages sequence works best for onboarding vs. nurturing? An onboarding sequence activates someone who already said yes, so it is short, fast, and instructional. A nurturing sequence warms a lead who hasn't committed yet, so it is longer, slower, and value-led. Same mechanics, opposite goals. Match the spacing and the ask to which job you are doing. [image: onboarding vs nurturing] A **whatsapp onboarding sequence** runs tight because the person is fresh and motivated. Four touches over a week: - Day 0: welcome and the single first action to take. - Day 1: the one feature that delivers the "aha," with a link. - Day 3: a check-in that invites a reply if they're stuck. - Day 7: a nudge toward the next milestone. A **whatsapp nurture sequence** runs looser because the lead is undecided and pushing hard backfires. Four touches over two weeks: - Day 0: deliver value, no ask. - Day 3: handle the common objection. - Day 7: social proof or a case example. - Day 14: the direct ask, once. The tell is the timing. Onboarding compresses because attention is high and fades quickly. Nurturing stretches because trust builds slowly and a rushed ask reads as pressure. Both live in the same drip campaign structure. You just change the delays and the tone. ## What WhatsApp Web limits and messaging rules should you know first? Sending from your own number over WhatsApp Web means personal-account scale and personal-account rules, not enterprise throughput. There is no per-message fee and no template approval, but there is no infinite blast either. Pace your sends, respect opt-out, and keep WhatsApp Web reachable, or the sequence stalls. Three things to internalize before you scale up. **The API path has hard ceilings you are skipping.** On the WhatsApp Business Platform, [Meta bills per delivered message](https://developers.facebook.com/docs/whatsapp/pricing/) as of July 1, 2025, and marketing templates are always charged. A new sender there can also [message only 250 unique contacts per 24 hours](https://developers.facebook.com/docs/whatsapp/messaging-limits/) until they verify and earn higher tiers of 2,000, then 10,000, then 100,000, then unlimited. Own-number sending sidesteps the meter and the template queue, which is the point, but it means you self-govern volume. **Pace, don't blast.** WhatsApp's own guidance on [broadcast lists caps each list at 256 contacts](https://faq.whatsapp.com/861663048350950/) and warns against sending large volumes at once. A sequence naturally spreads sends over days, which helps, but don't stack a 500-person same-minute burst on top. Space it. **What breaks: the browser is the engine.** On browser-only sending, close the tab or sleep the laptop and the next scheduled touch is skipped. Blueticks solves this with the offline gateway on its Pro plan, which fires your sends server-side even when your browser is closed. If a touch has a real consequence when it's late, put the sequence on the gateway and verify it once. ## Setting up your first sequence with Blueticks in under 10 minutes Install the extension, link your number, build a small audience, create a two or three touch drip with delays, turn on stop-on-reply, and test it on your own number. Ten minutes, no API, no Meta account, no per-message fee. Start on the free plan and upgrade only when you need the offline gateway. [image: laptop quiet session] The fast path, start to finish: 1. Add the [Blueticks extension](https://blueticks.co/) to Chrome or another Chromium browser and open WhatsApp Web. 2. Link your number by scanning the QR code. 3. Create an audience and import three test contacts, including your own number, each with a first name. 4. Open drip campaigns, add two or three touches, and write each to one action. 5. Set delays a few minutes apart for testing, and switch on stop-on-reply. 6. Run it, watch the touches land, then reply from a test contact and confirm the rest cancel. A note on the free plan. Blueticks Free lets you hold **3 pending standalone scheduled messages at a time**, raised from one in July 2026. Campaign and sequence messages don't count against that limit, so a drip's queued touches run freely. Pro removes the standalone limit and adds the offline gateway for browser-closed sending. Build and test your first whatsapp nurture sequence free, then upgrade when reliability matters more than convenience. ## FAQ ### How do I set up a WhatsApp automation sequence without the Business API? Use a tool that drives your existing WhatsApp number over WhatsApp Web, like the Blueticks extension. You install it, link your number by QR, build an audience, and create a drip campaign with per-step delays and stop-on-reply. No Meta verification, no template approval, and no per-message fees, because you send free-form from your own number. ### Can WhatsApp send an automated message sequence on its own? No. The standard WhatsApp app has no scheduler, and the Business app only sends greeting and away messages, which are [auto-replies triggered by an incoming message](https://faq.whatsapp.com/2565868990219715/). Neither sends a proactive, timed, multi-step series to people who haven't written back. That requires a third-party sequencing tool sitting on top of WhatsApp Web or the Business API. ### How many messages should a WhatsApp nurture sequence have? Three to five touches, spaced over five to fourteen days, with the gaps widening as the sequence runs. A dependable spine is day 0, day 2, day 5, and an optional day 9. Fewer than three rarely recovers a cold lead. More than five earns mutes and blocks, and each extra touch is another chance to annoy someone who already decided. ### What does stop-on-reply do in a sequence? Stop-on-reply removes a contact from every remaining step the moment they send any message back. It hands the conversation to a human and prevents a scheduled touch from firing into a live thread. It is the single most important setting to verify in any WhatsApp automation sequence, because without it your automation competes with your own real conversations. ### Will my sequence keep sending if my computer is off? Only with an offline gateway. On the default browser-only setup, sending runs inside WhatsApp Web, so a touch is skipped if the tab is closed or the laptop is asleep. Blueticks offers a Pro offline gateway that sends server-side even when your browser is closed. For any sequence with real stakes, put it on the gateway and test the first send. --- # WhatsApp Promotional Campaign Examples: 9 Proven Ideas That Drive Sales (2026) > Nine WhatsApp promotional campaign examples you can copy today, each with the message, the timing, and the number to expect. Plus how to send them to your whole list without getting your number flagged. URL: https://blueticks.co/blog/whatsapp-promotional-campaign-examples Published: 2026-07-23 Author: Maya Cohen Category: marketing You know WhatsApp gets opened. Read rates in the 90s make that the easy part. The hard part is the message itself: what to actually send, when to send it, and how to get it to 800 people without your number getting flagged. "Send a promo on WhatsApp" is not a plan. A flash sale at 9am and a cart-recovery nudge at hour two are different campaigns with different copy and different timing. So here are nine WhatsApp promotional campaign examples you can copy today. Each one comes with the message template, the send timing, and a realistic number to expect. Then we cover the part most guides skip: how to send these to hundreds of opted-in contacts without tripping WhatsApp's spam filters, and how to tell afterward whether any of it worked. ## What makes a WhatsApp promotional campaign actually convert? A WhatsApp promotional campaign converts when it reaches an opted-in list, opens with a specific offer in the first line, gives one clear action, and lands at the right moment. The channel's advantage is attention: WhatsApp read rates sit in the 90s, per industry benchmarks compiled by [Kanal](https://getkanal.com/blog/whatsapp-marketing-roi-kpis-benchmarks). What you do with that attention decides the sale. The open rate is not your problem. Almost everyone sees a WhatsApp message. The gap between a campaign that sells and one that gets you blocked comes down to four things: - **Permission.** You message people who opted in and expect to hear from you. Cold lists get reported, and reports are the signal WhatsApp's systems watch. - **A specific offer up top.** "20% off, today only" beats "check out our summer collection." The recipient decides in the first line whether to keep reading. - **One action.** One link, one reply prompt, one thing to do. Two asks halves the response to each. - **Timing.** A same-day nudge on a real-time channel catches intent before it cools. That last point has data behind it. The classic lead-response research [popularized by Harvard Business Review](https://hbr.org/2011/03/the-short-life-of-online-sales-leads) found that responding within five minutes versus thirty made a lead up to 21 times more likely to qualify. WhatsApp is a real-time channel, so speed compounds. Our [WhatsApp campaign best practices](https://blueticks.co/blog/whatsapp-campaign-best-practices) guide covers the opt-in and pacing rules that keep the whole thing alive. ## Which promotional campaign types work best on WhatsApp? The promotional campaign types that work best on WhatsApp are the ones built on urgency or personal relevance: flash sales, abandoned-cart nudges, product launches, back-in-stock alerts, and win-backs. WhatsApp rewards messages that feel timely and one-to-one. Broad brand-awareness blasts underperform, because a channel this personal punishes anything that reads like a billboard. Match the campaign to what the channel does well. A slow-burn newsletter belongs in email. WhatsApp is where you put the message that needs to be seen in the next hour. | Campaign type | Why it fits WhatsApp | Best timing | |---|---|---| | Flash sale | Urgency + instant visibility | Morning of, plus a "last hours" reminder | | Abandoned-cart recovery | High intent, time-sensitive | 1 to 24 hours after abandonment | | Product / feature launch | News your fans want first | Launch morning | | Back-in-stock alert | Requested, personal, expected | The moment stock returns | | Win-back | Personal re-approach beats email | After 60 to 90 days quiet | The pattern across all five is the same: the message is either urgent, expected, or both. That is the lane. A [WhatsApp marketing campaign](https://blueticks.co/blog/whatsapp-campaign-templates-that-convert) that respects it gets replies; one that treats WhatsApp like a second email list gets muted. The nine examples below all live in that lane. ## 9 WhatsApp promotional campaign examples you can copy (message + timing) Here are nine WhatsApp promotional campaign examples with the message copy and the send timing for each. Every template uses a merge field for the first name, one clear offer, and a single action. Treat the numbers as realistic illustrative ranges, not guarantees; your list quality and offer move them more than the copy does. [image: flash sale retail] A note on the copy: keep every message short enough to read without scrolling, lead with the offer, and personalize the first line. A "Hi Sarah" opener beats a generic blast every time. These are templates, not scripts; rewrite them in your own voice. ### 1. Flash sale / limited-time discount The whole point is urgency, so the deadline goes in the first line. Send the opener the morning the sale starts, then a single "last hours" reminder about three hours before it ends. Two touches, not five. > Hi \{\{first_name\}\}, quick one: 25% off everything for the next 12 hours only. Your code is FLASH25. Shop here: \{\{link\}\}. Reply STOP to opt out. Timing: opener at 9am, reminder at 6pm for a same-day sale. The reminder is where a lot of the conversions actually happen, because urgency peaks near the deadline. ### 2. New product or feature launch Your WhatsApp list is your warmest audience, so they hear it first. Frame it as early access, not an announcement. The exclusivity is the offer. > Hi \{\{first_name\}\}, you're on the early list so you get this before anyone else: the new \{\{product\}\} just went live. First 100 orders get \{\{perk\}\}. Take a look: \{\{link\}\}. Timing: launch morning, single send. Follow up only to people who clicked but did not buy, 24 hours later. ### 3. Abandoned-cart recovery nudge This is the highest-return WhatsApp campaign there is. Roughly 70% of online carts get abandoned, per the [Baymard Institute](https://baymard.com/lists/cart-abandonment-rate), which aggregates 50 studies to a ~70% average. A well-timed WhatsApp nudge recovers a chunk of that: [Chatarmin](https://chatarmin.com/en/blog/how-to-recover-abandoned-carts-via-whatsapp) reports optimized WhatsApp recovery flows converting at 18 to 23%, against roughly 8% for email. > Hi \{\{first_name\}\}, you left \{\{product\}\} in your cart. Still want it? I saved it for you here: \{\{link\}\}. Happy to answer any questions, just reply. Timing: first nudge one hour after abandonment while intent is hot, a second (with a small incentive) 24 hours later if no reply. Do not send a third. ### 4. Seasonal & holiday promotion Seasonal sends live or die on lead time. Send the teaser two days before the sale and the offer on the day. The reply prompt turns a broadcast into a conversation. > Hi \{\{first_name\}\}, our \{\{holiday\}\} sale opens Friday. Reply YES and I'll send you the early link an hour before it goes public. Timing: teaser 48 hours out, live offer on the day. Collecting "YES" replies first also warms your number, because engaged replies are a positive signal to WhatsApp. ### 5. VIP / loyalty early-access offer Your repeat buyers should feel like insiders. Segment them out and give them a genuine head start. This is a [whatsapp broadcast campaign](https://blueticks.co/blog/how-to-send-bulk-whatsapp-messages) that only works if the "VIP" label is real. > Hi \{\{first_name\}\}, because you're a top customer, here's 24-hour early access to the sale before we open it to everyone. Your link: \{\{link\}\}. Timing: the day before the public sale. One send. The scarcity is time, not stock. ### 6. Back-in-stock & restock alert This is the most expected message you will ever send, because they asked for it. Fire it the moment stock returns. Expected, relevant, time-sensitive: the perfect WhatsApp campaign. > Hi \{\{first_name\}\}, good news, \{\{product\}\} is back in stock. It sold out fast last time, so grab yours here: \{\{link\}\}. Timing: immediately on restock. These convert well above a cold broadcast precisely because the recipient opted in for this exact alert. ### 7. Event, webinar or launch RSVP Use WhatsApp to drive registrations and, more importantly, to cut no-shows with reminders. The reminder sequence is the real value. > Hi \{\{first_name\}\}, we're hosting \{\{event\}\} on \{\{date\}\}. Want a spot? Reply IN and I'll save you one. Timing: invite one week out, reminder the day before, final reminder one hour before. That one-hour nudge is what turns RSVPs into attendees. ### 8. Referral & "refer a friend" promo Ask happy customers to share, and make the reward mutual. Send this after a positive moment, like a delivered order or a five-star review. > Hi \{\{first_name\}\}, love that you're enjoying \{\{product\}\}. Share your link and you both get \{\{reward\}\} when a friend orders: \{\{link\}\}. Timing: 3 to 7 days post-purchase, once they have used the product. Referral asks land best on a satisfaction high. ### 9. Win-back offer for lapsed customers For customers who have gone quiet, a personal WhatsApp message outperforms another ignored email. Lead with "we miss you," not a discount, then let the offer close it. > Hi \{\{first_name\}\}, it's been a while and we miss you. Here's 20% off your next order to come back: \{\{code\}\}. Anything we can do better? Just reply. Timing: after 60 to 90 days of no purchase. Keep the tone personal; this is a re-approach, not a blast. For a deeper playbook, our [campaign template guide](https://blueticks.co/blog/whatsapp-campaign-templates-that-convert) breaks down the reply-getting structure behind each of these. Those nine cover most of what an SMB or DTC brand runs in a year. The bottleneck is never ideas. It is delivery: getting the message to your whole opted-in list without hitting the 256-contact wall or getting flagged. That is a tooling problem, and it is solvable in about ten minutes. **Launch your first promotional campaign free.** Bulk-send any of these templates to your whole opted-in list from your own WhatsApp number, schedule the exact send time, and track replies in one place. No per-message fees, no API setup, no template-approval queue. [Start free with Blueticks](https://blueticks.co/signup) and send your first campaign this week. ## How do you send a promotional campaign to hundreds of contacts without getting blocked? To send a WhatsApp promotional campaign to hundreds of contacts safely, message only opted-in people, send from your own number one personalized message at a time, pace the sends over minutes rather than seconds, and start with a small batch before scaling. The fastest way to get flagged is a burst of identical messages to people who never agreed to hear from you. [image: pacing batches] The native broadcast list will not get you there. Per WhatsApp's [Help Center guide](https://faq.whatsapp.com/861663048350950), each list caps at 256 contacts, and the message only reaches people who have saved your number, with no delivery report to tell you who missed it. For any real [whatsapp bulk message campaign](https://blueticks.co/blog/how-to-send-bulk-whatsapp-messages), that is a dead end. The safe pattern for sending at scale: 1. **Opt-in only.** Message people who gave you their number expecting contact. Never purchased or scraped lists. 2. **Personalize every send.** Merge the first name and order detail so each message is genuinely one-to-one, not a carbon copy. 3. **Pace it.** A thousand identical messages leaving your number in ninety seconds is the signature of a spam bot. Spread sends over minutes and hours. 4. **Start small.** Send to a batch of 20 to 50 first, confirm everything lands clean, then ramp. This single habit protects your number more than anything else. 5. **Honor opt-outs instantly.** A "reply STOP" line and an actual suppression list keep your report rate low. None of this requires the official API. An own-number tool like Blueticks drives your existing WhatsApp account to send personalized messages one at a time, so recipients get a normal message from a number they recognize, with no per-message fee and no template approval. Meta's [policy enforcement documentation](https://developers.facebook.com/documentation/business-messaging/whatsapp/policy-enforcement) is clear that accounts generating excessive negative feedback get limited or removed, so the behavioral discipline above is not optional. It is what keeps the channel open. ## How do you measure whether your promotional campaign worked? You measure a WhatsApp promotional campaign by reply rate and conversions, not open rate. Read rate on WhatsApp sits in the 90s across almost every list, per industry benchmarks, which makes it too flat to compare campaigns. Reply rate and revenue tell you whether your offer, timing, and targeting actually landed. [image: measuring results] Here is what to track and why open rate is a trap: | Metric | What it tells you | Honest read | |---|---|---| | Open / read rate | The message was seen | Almost always 90%+; too flat to compare | | Reply rate | The offer prompted action | The real signal; roughly 1 to 3% cold, 3 to 8% segmented, per Kanal | | Click rate | Interest in the link | Useful when a link is the primary action | | Conversion / revenue | The campaign made money | The only number that pays the bills | The reply-rate ranges above come from [Kanal's benchmark data](https://getkanal.com/blog/whatsapp-marketing-roi-kpis-benchmarks): a cold, unsegmented broadcast tends to land at 1 to 3%, while a well-targeted opted-in flow runs 3 to 8%. The distance between those two is segmentation, and it is the biggest lever you control. Send the flash-sale template to your whole list and you sit at the floor. Send the VIP version to your top 200 and you climb toward the ceiling. The catch: the native broadcast list gives you none of these numbers. No delivery report, no reply tracking, no conversion tie-back. You are guessing. A campaign tool surfaces reply and delivery data per send, which is the whole reason to use one. Our guide to [WhatsApp campaign analytics that matter](https://blueticks.co/blog/whatsapp-campaign-analytics-metrics-that-matter) covers which numbers to watch and which to ignore. ## What the WhatsApp app does natively, and where Blueticks adds bulk sending, scheduling & tracking Natively, the WhatsApp and WhatsApp Business apps let you send a broadcast to up to 256 saved contacts per list, one list at a time, with no scheduling and no analytics. Blueticks adds the campaign layer on top of your own number: bulk sending past 256, per-contact personalization, scheduled send times, pacing, and reply and delivery tracking. [image: native vs tool] Be honest about the split. The native app is genuinely fine for a corner shop messaging 50 regulars who all saved the number. The moment you cross into campaign territory, real volume, new leads, personalization, and measurement, the manual path costs you more in lost reach and lost hours than any subscription. | Capability | WhatsApp app (native) | Blueticks (own number) | |---|---|---| | Recipients per send | 256 per broadcast list | No 256 cap | | Reaches non-savers | No | Yes | | Personalization | Manual, one by one | Merge fields at scale | | Scheduling | None | Set the send time | | Pacing | None | Paced sends + send window | | Reply & delivery tracking | None | Per-campaign tracking | | Per-message fee | Free | No per-message fee | Blueticks is an own-number tool, which means it works with your existing WhatsApp account instead of Meta's Cloud API. There is no business verification, no template-approval queue, and no per-message billing. It also means you operate at personal-account scale and pace, not enterprise throughput. If you are sending seasonal, marketing-heavy campaigns to a few thousand opted-in customers, that trade is almost always in your favor. If you need millions of transactional messages a month, the [Cloud API](https://blueticks.co/blog/how-to-choose-whatsapp-broadcast-platform) is the right pipe, and its per-message pricing (billed per delivered message since Meta's July 1, 2025 pricing change, [per respond.io](https://respond.io/blog/whatsapp-business-api-pricing)) is the cost of that scale. What no tool can do, including Blueticks, is guarantee delivery. WhatsApp controls that and can limit numbers that generate complaints. What a good tool removes is the manual grind: the five hand-built lists, the live send at 9am, the inbox you cannot measure. You bring the opt-in list and the offer. [Run your first campaign free](https://blueticks.co/campaigns) and send any of the nine templates above to your whole list in minutes. ## FAQ **What is a good example of a WhatsApp promotional campaign?** A flash sale is the clearest example: a single message with a specific discount, a deadline in the first line, one link, and a "last hours" reminder before it ends. Abandoned-cart nudges and back-in-stock alerts are the highest-converting examples, because they reach people with existing intent at the exact moment it matters. **How many people can I send a WhatsApp promotional campaign to?** The native broadcast list caps each list at 256 contacts, and only reaches people who saved your number. With an own-number campaign tool like Blueticks, there is no 256 cap and recipients do not need to have saved you, because each message sends as a normal personalized message from your own number. Send only to opted-in contacts regardless of the tool. **What is the best time to send a WhatsApp promotional message?** It depends on the campaign. Flash sales work best with a morning opener and a reminder a few hours before the deadline. Cart-recovery nudges convert best one hour after abandonment while intent is hot. Event reminders land hardest one hour before the event. Match the timing to the intent, not to a universal "best hour." **How do I stop my number getting banned when sending a promotional campaign?** Message only opted-in people, personalize every send, pace sends over minutes instead of seconds, start with a small batch before scaling, and honor opt-outs instantly. Meta's policy enforcement limits or removes accounts that generate excessive negative feedback, so keeping your report rate low by messaging people who expect you is the whole game. **Do I need the WhatsApp Business API to run promotional campaigns?** No. The Cloud API suits very high volume and transactional messaging at enterprise scale, but it bills per delivered message and requires business verification and template approvals. For seasonal campaigns to a few thousand opted-in customers, an own-number tool sends from your existing number with no per-message fee and no approval queue, which is usually cheaper and faster to start. --- # The Best Chrome Extension to Schedule WhatsApp Messages in 2026 (Free to Install, Sends From Your Own Number) > WhatsApp still has no send-later button. A Chrome extension that runs inside WhatsApp Web is the closest thing to native scheduling, and it sends from your own number. URL: https://blueticks.co/blog/whatsapp-scheduler-chrome-extension Published: 2026-07-21 Author: Daniel Roth Category: productivity You wrote the message at 11 PM. It needs to land at 9 AM. WhatsApp still has no button for that. You either stay up, set a phone alarm, or forget. A whatsapp scheduler chrome extension closes that gap: it runs inside WhatsApp Web, queues your message, and sends it at the time you picked, from your own number. This guide covers how to pick one, how to set it up, and where the approach breaks. ## Can you schedule WhatsApp messages without an extension? Not reliably. WhatsApp has no native send-later option in the personal or Business app. The [WhatsApp Help Center](https://faq.whatsapp.com/668538004658079) documents linking, media, and calls, but no scheduled outbound message. Business "away messages" only fire in reply to an incoming chat. To send a message you wrote to a time you chose, you need an outside tool. Here's what you actually have without an extension: - **Native send-later** - none for one-to-one or group chats. - **WhatsApp Business away/greeting messages** - reactive only, never proactive. - **iOS Shortcuts** - opens a pre-filled chat, but you still tap Send yourself. - **Android accessibility apps** - can auto-tap Send, but break on app updates. - **WhatsApp Channels** - admins can schedule broadcast posts, not personal chats. The channel exception is real but narrow. It covers one-to-many broadcasts, not the follow-up you owe a client Monday morning. For everything else, the gap stands, which is why a browser extension exists. ## Why is a Chrome extension the most reliable way to schedule WhatsApp messages? A Chrome extension is the most reliable path because it runs inside [WhatsApp Web](https://faq.whatsapp.com/668538004658079) using your logged-in session, so messages send from your real number with no API, no bot, and no Meta approval. Accessibility-app automations on Android tap the screen and break on updates; the extension speaks to WhatsApp Web directly and survives them. The difference comes down to how each method touches WhatsApp: | Method | How it sends | Fails when | |---|---|---| | Chrome extension (WhatsApp Web) | Your own logged-in session | Computer is off and no cloud mode | | Android accessibility app | Simulates screen taps | WhatsApp UI updates, phone locked | | iOS Shortcut | Opens chat, you tap Send | Every send (not automated) | | WhatsApp Business API | Meta's servers, template messages | Costs per message, needs approval | WhatsApp Web itself supports staying linked even when your phone is off. Per the [WhatsApp Help Center](https://faq.whatsapp.com/378279804439436), you can link up to four devices to your primary phone and use them without the phone online. That is the surface a whatsapp extension rides on, which is why the desktop path is steadier than any phone-tapping trick. [image: laptop web session] ## What should you look for in a WhatsApp scheduler Chrome extension? Look for four things: it sends from your own number (not an API line), it's free to install and try, it handles recurring schedules, and it's honest about what happens when your computer is off. A good send later for whatsapp chrome extension does the timed send without turning your account into a bot. Run any candidate through this checklist before you trust it with a client message: 1. **Own-number sending.** The message must go out from your logged-in WhatsApp, not a separate business API number. Recipients should see a normal message. 2. **Free to install.** You should be able to install and schedule a first message without a card. The [Chrome Web Store listing](https://chromewebstore.google.com/detail/blueticks-the-ultimate-wh/adgnjhngogijkkppficiiepmjebijinl) shows the price and permissions up front. 3. **Recurring rules.** Daily, weekly, monthly. A weekly reminder should be one entry, not 52. 4. **Honest offline behavior.** If your machine sleeps, does the message queue and retry, or silently drop? A real answer beats a marketing promise. 5. **No API setup.** No Meta business verification, no per-message fees, no webhook wiring. Skip anything that asks you to connect the [WhatsApp Business Platform](https://developers.facebook.com/documentation/business-messaging/whatsapp/pricing) just to time a message. That path charges per message and needs template approval, which is overkill for scheduling. ## How do you schedule a WhatsApp message with the Blueticks Chrome extension? (step by step) You install the extension, open WhatsApp Web, click the clock icon in any chat's message bar, type your message, pick a date and time, and hit Schedule. The whatsapp auto message sender extension queues it and sends at that time from your own number. Setup to first scheduled message takes under two minutes. Here's the exact flow with Blueticks: 1. Install [Blueticks from the Chrome Web Store](https://chromewebstore.google.com/detail/blueticks-the-ultimate-wh/adgnjhngogijkkppficiiepmjebijinl). It's free. 2. Open [WhatsApp Web](https://faq.whatsapp.com/668538004658079) and link your phone by scanning the QR code. 3. Open any chat. You'll see a clock icon appear in the message input bar. 4. Click the clock. Type your message in the scheduler. 5. Pick the date and set the time. 6. Click **Schedule**. The message queues and sends at your set time, even if the tab is closed, as long as your computer stays on and connected. Scheduled items live in your Blueticks dashboard, so you can edit or cancel before they fire. For recurring sends, tick the recurrence option and choose daily, weekly, or monthly instead of building the same message every week. **What breaks:** the standard extension needs the machine running WhatsApp Web to be awake at send time. If your laptop sleeps or drops offline, the message waits until the connection restores instead of sending on the dot. For sends that must go out while your machine is off, Blueticks' Pro offline mode runs on a persistent cloud connection. See [how to schedule WhatsApp messages](https://blueticks.co/blog/schedule-whatsapp-messages) for the full desktop walkthrough. [image: calendar planning] ## Does it send from your own number, and is the extension free to install? Yes on both. Blueticks sends through your existing WhatsApp account over WhatsApp Web, so every message goes out from your own number and looks identical to one you typed by hand. Installing the extension and scheduling your first message costs nothing. Recurring and offline sending sit on paid plans. This is the core reason the extension approach beats the API for most people. You are not renting a business number or paying Meta per delivery. The [WhatsApp Business Platform](https://developers.facebook.com/documentation/business-messaging/whatsapp/pricing) switched to per-message pricing on July 1, 2025, charging you each time a template message is delivered across marketing, utility, and authentication categories. That model makes sense for high-volume support teams. It is the wrong tool for scheduling a follow-up. With the extension, there's no per-message fee, no Meta business verification, and no template approval queue. You send from the number your contacts already know. Skip the per-message fees and API setup entirely. [Install the free Blueticks Chrome extension](https://blueticks.co/signup) and schedule your first WhatsApp message from your own number in under two minutes, no Meta approval required. ## Chrome extension vs. mobile scheduling app vs. WhatsApp Business: which should you use? Use a Chrome extension if you want timed sends from your own number with no fees. Use a mobile scheduling app only if you're phone-only and accept that it breaks on updates. Use WhatsApp Business API only if you're sending thousands of templated messages and can absorb per-message costs. For everyday scheduling, the extension wins on cost and reliability. Map your situation to the right tool: | You want to... | Best fit | Why | |---|---|---| | Time a follow-up from your own number | Chrome extension | Free, no API, sends as you | | Schedule weekly recurring reminders | Chrome extension | One recurring entry | | Send from a phone only, no computer | Mobile app (with caveats) | Breaks on WhatsApp updates | | Blast 10,000 templated notifications | WhatsApp Business API | Built for volume, but [per-message priced](https://developers.facebook.com/documentation/business-messaging/whatsapp/pricing) | The middle two rows are where people get burned. Accessibility-service apps on Android look convenient until a WhatsApp app update shifts a button and the automation taps the wrong thing. The API looks powerful until the first invoice. For a single operator scheduling messages to real contacts, the extension is the least fragile option. Compare the full field in [the best apps to schedule WhatsApp messages](https://blueticks.co/blog/best-apps-to-schedule-whatsapp-messages). ## Is there a Firefox or Edge version, or a "send later for WhatsApp" alternative? Blueticks ships as a Chrome Web Store extension, and Chrome Web Store extensions install in Chromium browsers like Microsoft Edge, Brave, and Opera. There is no verified standalone Firefox build, because Firefox uses a separate add-on store. On Edge, you install straight from the Chrome Web Store. Here's the honest browser breakdown: - **Chrome** - native, install from the [Chrome Web Store](https://chromewebstore.google.com/detail/blueticks-the-ultimate-wh/adgnjhngogijkkppficiiepmjebijinl). - **Microsoft Edge** - supported. Per [Microsoft Support](https://support.microsoft.com/en-us/edge/add-turn-off-or-remove-extensions-in-microsoft-edge), open the Chrome Web Store in Edge, select **Get extension**, and allow extensions from other stores. - **Brave / Opera** - Chromium-based, install from the Chrome Web Store the same way. - **Firefox** - no verified Blueticks build. Firefox extensions live on a different store, so a Chrome extension won't load there. If you specifically searched for a "send later for whatsapp" alternative, that phrase usually points at the same category: a browser extension on WhatsApp Web. The mechanism is what matters, not the brand name. Anything that promises timed sends without an extension or the API is almost certainly doing screen-tap automation, which is the fragile path. ## What can a Chrome extension do that native WhatsApp can't, and where Blueticks adds it A Chrome extension adds the entire outbound-timing layer WhatsApp lacks: one-time scheduled sends, recurring reminders, and bulk personalized campaigns, all from your own number. Native WhatsApp gives you none of these for personal or group chats. Blueticks layers them onto WhatsApp Web without touching the API. Concretely, here's the gap the extension fills: - **Scheduled one-time sends** - pick a date and time, it fires. Native WhatsApp: nothing. - **Recurring messages** - daily, weekly, monthly reminders set once. Native: nothing. - **Bulk personalized sends** - message a contact list with per-recipient names. Native: manual, one at a time. - **Edit and cancel before send** - queued items are editable. Native: not applicable. One caution that applies to all of it. WhatsApp's terms prohibit spam and bulk messaging that mimics abuse. Scheduling legitimate reminders, follow-ups, and coordinated announcements is normal use. Blasting thousands of cold, unsolicited messages is not, and it can get your number banned regardless of the tool. Schedule for people who expect to hear from you. Read the deeper desktop guide on [scheduling WhatsApp Web messages](https://blueticks.co/blog/schedule-whatsapp-web-messages) before you scale up. ## FAQ **Is the WhatsApp scheduler Chrome extension free?** Yes, installing it is free and the free plan covers basic scheduling. Recurring messages and offline sending sit on paid tiers. You can schedule your first message without entering a card, and the [Chrome Web Store listing](https://chromewebstore.google.com/detail/blueticks-the-ultimate-wh/adgnjhngogijkkppficiiepmjebijinl) shows pricing and permissions up front. **Does the extension send from my own WhatsApp number?** Yes. It runs inside WhatsApp Web using your linked account, so messages send from your real number and look identical to ones you typed. There's no separate business number, no bot, and no Meta business verification. **What happens if my computer is off when the message is scheduled?** With the standard extension, the message waits and sends once your computer wakes and WhatsApp Web reconnects. For guaranteed delivery while your machine is off, Blueticks' Pro offline mode runs on a persistent cloud connection. **Can I use the extension on Microsoft Edge or Firefox?** Edge, yes. Per [Microsoft Support](https://support.microsoft.com/en-us/edge/add-turn-off-or-remove-extensions-in-microsoft-edge), you install Chrome Web Store extensions in Edge and allow extensions from other stores. There's no verified Firefox build, since Firefox uses a separate add-on store. **Do I need the WhatsApp Business API to schedule messages?** No. The API is built for high-volume templated messaging and moved to [per-message pricing on July 1, 2025](https://developers.facebook.com/documentation/business-messaging/whatsapp/pricing). A Chrome extension schedules from your own number with no per-message fees and no template approval. --- # How to Automate WhatsApp Messages with an API in 2026 (Triggered Sends, Scheduled Sequences & Retries) > Automating WhatsApp from code is easy to start and easy to break. Here's how to run triggered sends, scheduled sequences, and safe retries on your own number, without a Meta approval queue. URL: https://blueticks.co/blog/whatsapp-automation-api Published: 2026-07-20 Author: Daniel Roth Category: productivity You wired up your first automated WhatsApp send in an afternoon. Then a webhook fired twice and a customer got the same reminder at 3am, twice. That gap between "it sends" and "it sends reliably, once, at the right time" is where most integrations live. This guide walks the whole path with a WhatsApp automation API: one-call sends, scheduled sequences in Python and Node, event triggers, and the idempotency trick that stops retries from double-sending. ## What does automating WhatsApp with an API actually involve? Automating WhatsApp with an API means calling a REST endpoint from your own code to send, schedule, and react to messages, instead of typing them by hand. In practice you need four moving parts: a send call, a way to schedule for later, event triggers from your app, and webhooks to hear back about deliveries and replies. Most people start with only the first part and discover the other three the hard way. A single `POST` that fires a message is trivial. The workflow around it is where the work sits: - **Send.** One authenticated call pushes a message out right now. - **Schedule.** The same call, plus a future timestamp, holds the message until its time. - **Trigger.** Your app's own events (a payment, a signup, a no-show) decide when to send. - **React.** Webhooks tell you when a message was delivered, read, failed, or replied to. Get all four talking and you have a real automation, not a script that fires and forgets. The [own-number REST API walkthrough](https://blueticks.co/blog/whatsapp-rest-api-own-number) covers the transport underneath; this piece is about the automation on top. ## Which WhatsApp automation API works on your own number without Meta approval? An own-number WhatsApp automation API drives WhatsApp Web on your behalf, the same protocol your phone uses in a browser tab, so messages go out from your existing active number. That skips Meta Business verification, template pre-approval, and per-template fees entirely. The trade-off is that it is unofficial and carries flagging risk, which the sanctioned Cloud API does not. There are two categories, and the choice shapes everything downstream: | | Own-number API (Blueticks /v1) | Meta Cloud API direct | |---|---|---| | Sends from | Your existing WhatsApp number | A dedicated Cloud API number | | Meta business verification | Not required | Required | | Template pre-approval | Not required | Required outside the 24h window | | Per-message fees | No | Yes, per Meta's pricing | | Time to first automated send | Minutes | Days to weeks | Meta moved WhatsApp Business to per-message pricing on July 1, 2025, deprecating the older conversation-based model, and free-form messages are only allowed inside a 24-hour window after the contact last messaged you. Blueticks sits in the first column: an unofficial WhatsApp-Web transport on your own number. It is not Meta's Cloud API, and that is the point. ## How do you send an automated WhatsApp message with one API call? To send a WhatsApp message from an API, you POST to `https://api.blueticks.co/v1/scheduled-messages/{chatId}` with a bearer key and a small JSON body: `type` (`text`, `media`, or `poll`) and the content. The recipient is the `{chatId}` path segment, an E.164 number or a WhatsApp chat id, not a body field. Omit any future timestamp and the message goes out immediately. This one WhatsApp API send-message call is the core of every automation you will build. Authentication is one header. Keys are environment-scoped, `bt_live_` for production and `bt_test_` for a sandbox, so you can wire a test path in CI without touching real sends: ```bash curl -X POST https://api.blueticks.co/v1/scheduled-messages/+14155551234 \ -H "Authorization: Bearer bt_live_..." \ -H "Content-Type: application/json" \ -d '{ "type": "text", "text": "Your order #1024 has shipped. Track it: https://example.com/t/1024" }' ``` A bare `POST /v1/scheduled-messages` with the recipient in the body is gone: it answers `410 Gone` and tells you to move the recipient into the path. Every 2xx on `/v1` comes back wrapped as `{"success": true, "data": { ... }}`, so read the message object out of `data`, never off the top level. Inside it you get an `id` you can poll, a `waMessageKey` (the WhatsApp wire id, populated once it dispatches), a `status`, and lifecycle timestamps (`createdAt`, `sendAt`, `confirmedAt`, `receivedAt`, `readAt`, `playedAt`, `failedAt`). Keep the API key server-side. It authenticates as your workspace and your number, so it does not belong in a browser bundle or mobile app. The full send anatomy, including media and polls, is in the [send-and-schedule API guide](https://blueticks.co/blog/send-schedule-whatsapp-messages-api). [image: api key index card] ## How do you schedule a message or a sequence from code (Python & Node)? To schedule instead of send now, add one field to the same call: `sendAt`, an RFC 3339 timestamp with an explicit `Z` or UTC offset. The API holds the message and dispatches it at that time, so you delete your own cron job, queue, and worker. For a sequence, compute each send time up front and fire one create call per step. Official Python and Node SDKs wrap the REST shape. The scheduling constraint worth memorizing: `sendAt` must be at least **10 seconds** in the future and at most **365 days** out. Here is a whatsapp api python schedule for a two-step onboarding drip, one message now and a follow-up in three days: ```python # pip install blueticks from datetime import datetime, timedelta, timezone from blueticks import Blueticks client = Blueticks(api_key="bt_live_...") # Step 1: welcome, immediately (recipient is the first argument) client.scheduled_messages.create( "+14155551234", type="text", text="Welcome aboard. Reply if you get stuck.", ) # Step 2: nudge, three days out send_at = (datetime.now(timezone.utc) + timedelta(days=3)).isoformat() client.scheduled_messages.create( "+14155551234", type="text", text="How's it going? Here's a 2-minute setup tip.", send_at=send_at, # SDK kwarg; on the wire it is sendAt ) ``` The Node SDK maps onto the identical shape: ```javascript // npm install blueticks import { Blueticks } from "blueticks"; const client = new Blueticks({ apiKey: "bt_live_..." }); const sendAt = new Date(Date.now() + 3 * 24 * 3600 * 1000).toISOString(); await client.scheduledMessages.create("+14155551234", { type: "text", text: "How's it going? Here's a 2-minute setup tip.", sendAt, }); ``` Because each scheduled message is a real queued record, you can manage it after creation. `GET /v1/scheduled-messages/{id}` reads its status, a `PATCH` to the same id edits the text or moves `sendAt` while it is still pending, and `POST /v1/scheduled-messages/{id}/cancel` pulls it back before it fires. Listing is the one place the bare collection path still works: `GET /v1/scheduled-messages`, paginated with `limit` and `skip`. That edit-and-cancel window is what makes "remind them 24h before, unless they act first" a two-line change instead of a rebuild. [image: paper calendar sequence] ## How do you trigger sends from your app's own events (payment, signup, no-show)? You trigger a WhatsApp send from an app event by calling the send endpoint inside the handler that already runs for that event. A Stripe `payment_succeeded` webhook fires a receipt, a signup row inserts and fires a welcome, a no-show flag fires a rebook nudge. The API call is the same one-liner; the trigger is just where you put it in code you already have. Here is the pattern inside a payment handler. When the charge clears, send the confirmation from your own number: ```python @app.post("/stripe/webhook") def stripe_hook(): event = stripe_verify(request) # your existing verification if event["type"] == "payment_intent.succeeded": phone = event["data"]["object"]["metadata"]["wa_phone"] client.scheduled_messages.create( phone, type="text", text="Payment received. Your booking is confirmed for Thursday 10am.", ) return "", 200 ``` Three trigger shapes cover most of what you will build: 1. **Immediate reaction.** Payment cleared, lead submitted a form, server alert. Send now, no `sendAt`. 2. **Future reminder off an event.** Appointment booked today, reminder scheduled for the day before with `sendAt`. 3. **Conditional cancel.** Schedule the reminder at booking time, then cancel it if the "paid" or "confirmed" event lands first. **What breaks:** if your event handler retries (and payment webhooks retry aggressively), you send twice. That is not hypothetical. It is the single most common failure in event-driven WhatsApp automation, and the next section is the fix. If you would rather not run your own worker, cron, and queue just to hold these triggers, skip straight to a `bt_test_` key and the send call above. [Start on the free /v1 API](https://blueticks.co/signup): no Meta approval queue, no per-message fees, and every message goes out from the number your contacts already recognize. ## How do you make automated sends idempotent so retries never double-send? You make a send idempotent by passing a stable `Idempotency-Key` header. If a network blip or a retrying event handler replays the same request, the API recognizes the key and does not send a second time. The key just has to be deterministic for a given logical message, like the order id or the event id that caused the send. Webhook and job delivery is at-least-once, never exactly-once, so retries are a certainty, not an edge case. The defense is a key your code can regenerate identically on the retry: ```bash curl -X POST https://api.blueticks.co/v1/scheduled-messages/+14155551234 \ -H "Authorization: Bearer bt_live_..." \ -H "Idempotency-Key: receipt-order-1024" \ -H "Content-Type: application/json" \ -d '{ "type": "text", "text": "Payment received. Booking confirmed." }' ``` The rule of thumb: derive the key from the thing that must produce exactly one message. One receipt per order, so `receipt-order-1024`. One reminder per booking, so `reminder-booking-8842`. Never use a random UUID generated fresh on each attempt, because the retry generates a different one and defeats the whole mechanism. As one operator running appointment reminders put it: "We stopped keying on a timestamp and started keying on the booking id. The double-sends went to zero the same day." Pair the idempotency key with scoped API keys (`messages:write`) so a service that only sends cannot also delete audiences. ## How do you react to replies and delivery status automatically with webhooks? You react automatically by registering a webhook: one POST to `https://api.blueticks.co/v1/webhooks` with a `url` and an `events` array. Blueticks then POSTs to your endpoint as things happen, so a reply, a delivery, or a failure lands on your server without polling. Verify the signature, branch on `event.type`, and your automation closes the loop. Register the events you care about: ```bash curl -X POST https://api.blueticks.co/v1/webhooks \ -H "Authorization: Bearer bt_live_..." \ -H "Content-Type: application/json" \ -d '{ "url": "https://your-app.com/hook", "events": ["message.delivered", "message.read", "message.failed"] }' ``` The catalogue spans the message lifecycle (`message.queued`, `message.sending`, `message.delivered`, `message.read`, `message.failed`), campaign progress (`campaign.started`, `campaign.completed`, `campaign.aborted`), and session state (`session.connected`, `session.disconnected`). For two-way flows there is an inbound event so you can react to replies. Every delivery is signed: the `X-Blueticks-Signature` header is an HMAC-SHA256 of the raw body, and you must verify it over the exact bytes on the wire, using a constant-time comparison, before trusting the payload. The full Flask and Express handlers are in the [webhooks auto-reply guide](https://blueticks.co/blog/whatsapp-api-webhooks-auto-reply). [image: always on mini server] ## How do you keep automated WhatsApp sending reliable and unbanned? Reliability on an own-number transport comes down to pacing, not throughput. WhatsApp watches for spammy patterns, and a number that suddenly blasts hundreds of unsolicited messages gets rate-limited or banned. Send to people who expect to hear from you, ramp volume gradually, and keep content relevant. No provider can guarantee zero risk on an own-number API, and any that claims to is lying. A short pre-flight checklist keeps automations honest: - **Ramp, don't blast.** Start with a small daily volume and scale up over days, watching delivery. - **Send to opted-in contacts.** Reminders, receipts, and replies to people who messaged you are legitimate use. Cold outbound to strangers is what gets numbers flagged. - **Watch `message.failed`.** A spike is your early warning. Wire it to an alert. - **Keep one WhatsApp Web session.** Opening a second session elsewhere disconnects the one your automation runs on. For 24/7 automation the machine matters too. On the Free plan a "Powered by blueticks.co" footer rides along and delivery depends on your browser being connected; the paid Pro plan removes the branding and unlocks an always-on offline mode so scheduled and triggered sends fire even when your computer is closed. Match the plan to whether branding and around-the-clock delivery matter for your integration. More on the own-number risk profile in the [REST API own-number guide](https://blueticks.co/blog/whatsapp-rest-api-own-number). ## Where Blueticks fits: automation without running your own cron, queue, and worker Blueticks fits the developer who wants triggered, scheduled, two-way WhatsApp automation on their own number today, without standing up a cron job, a queue, a worker, and a Meta verification process to hold a message until its send time. One `/v1` API covers send, schedule, campaigns, and webhooks, so a single integration replaces the infrastructure you would otherwise build and babysit. The concrete swap: instead of a scheduler service plus a durable queue plus a retry worker plus a Meta template pipeline, you make one authenticated call with an optional `sendAt` and an optional `Idempotency-Key`. Scheduling lives server-side. Retries are safe. Replies and delivery status arrive as webhooks. For one-to-many, an **audience** holds a contact list with per-contact variables and a **campaign** sends one templated message to all of them with `{token}` substitution, paced for an own-number transport. You still own the parts that should stay yours: which events trigger a send, what the copy says, and the pacing discipline that keeps your number healthy. Blueticks owns the plumbing. That division is the whole pitch of a WhatsApp automation API that runs on your number instead of Meta's. The fastest way to send WhatsApp message from API and see it land is the sandbox: the interactive reference and SDK installs are at **[dev.blueticks.co](https://dev.blueticks.co)**. Grab a free `bt_test_` key, fire the send call from earlier, and you will have an automated WhatsApp send running in about two minutes. ## FAQ **What is a WhatsApp automation API?** It is a REST API you call from your own code to send, schedule, and react to WhatsApp messages automatically instead of sending them by hand. With Blueticks, one `POST /v1/scheduled-messages/{chatId}` call sends now or (with a `sendAt` timestamp) later, and webhooks notify you of deliveries and replies. It runs on your own number, so there is no Meta business verification. **How do I schedule a WhatsApp message from Python?** Install the `blueticks` SDK, create a client with your API key, and call `scheduled_messages.create` with the recipient as the first argument, then `type`, `text`, and a `send_at` RFC 3339 timestamp (it goes on the wire as `sendAt`). The timestamp needs an explicit `Z` or UTC offset, and must be at least 10 seconds in the future and within 365 days. The message is held server-side and dispatched at that time, with no cron job of your own. **How do I stop retries from sending the same WhatsApp message twice?** Pass a stable `Idempotency-Key` header derived from the thing that must produce exactly one message, like an order or booking id. If a retrying event handler replays the request, the API recognizes the key and does not send again. Never use a fresh random UUID per attempt, because the retry generates a different key and defeats it. **Do I need Meta approval to automate WhatsApp sends?** No, not with an own-number API. Blueticks drives WhatsApp Web on your existing number, so you skip Meta business verification, template pre-approval, and per-message fees. The trade-off is that it is unofficial and carries flagging risk if you send spammy volume, which Meta's sanctioned Cloud API does not. **Can I trigger a WhatsApp send from a Stripe or signup event?** Yes. Call `POST /v1/scheduled-messages/{chatId}` inside the handler that already runs for that event, so a `payment_succeeded` webhook or a new signup fires a message from your own number. Add an `Idempotency-Key` because payment webhooks retry, and you avoid double-sends when the same event is delivered more than once. --- # Why Your WhatsApp Broadcast Isn't Delivering (2026 Fixes): How to Reach Everyone Reliably > Your WhatsApp broadcast reaches fewer people than you think, and WhatsApp never tells you. Here are the six real reasons, and how to reach everyone reliably. URL: https://blueticks.co/blog/whatsapp-broadcast-not-delivering Published: 2026-07-19 Author: Maya Cohen Category: marketing Your WhatsApp broadcast isn't delivering mainly because recipients haven't saved your number as a contact, and WhatsApp silently drops broadcast messages to anyone who has not saved you. 1. Recipients haven't saved your number as a contact (the #1 silent reason broadcasts don't deliver). 2. You've hit the 256-recipient-per-list cap and the rest never receive it. 3. Your number is being spam-throttled or temporarily restricted for bulk sending. 4. You're using a group, or confusing a broadcast with a group, instead of a broadcast list. 5. A new or "unwarmed" number, or business-account limits, are suppressing delivery. 6. Recipients have blocked you, changed numbers, or left WhatsApp. Here is the part that trips up almost everyone: most "whatsapp broadcast not delivering" cases are not really failures. They are silent under-deliveries. Your broadcast went out, WhatsApp reported no error, and it quietly reached a fraction of the list because most of those people never saved your number. You see a sent broadcast. They see nothing. Below is how to tell which of the six causes is yours, and how to fix it. ## Why is my WhatsApp broadcast not delivering? Your WhatsApp broadcast is not delivering because of one or more of six causes, and the biggest by far is the saved-contact rule: native broadcast lists only reach people who have your number in their phone. The other five are the 256 cap, spam throttling, group-versus-broadcast confusion, an unwarmed number, and recipients who blocked you or left. Start by ruling in the likely culprit before you touch anything: - **You sent to a list of leads or new customers, not close contacts.** Almost certainly the saved-contact rule. This is the default answer for "why is my whatsapp broadcast not working" when the recipients are people who do not already have you saved. - **Some people got it, others didn't, and you can't see a pattern.** Also the saved-contact rule. The ones who received it had you saved; the silent ones did not. - **The list was large and delivery just stopped past a point.** The 256-recipient cap, or spam throttling on a high-volume send. - **Nothing sent at all, or sends failed.** A "whatsapp broadcast not sending" symptom points at account restrictions, a brand-new number, or being blocked, not the saved-contact rule. The rest of this guide takes each cause in order, starting with the one behind roughly the majority of complaints. ## Do recipients need to save your number for a broadcast to deliver? Yes. WhatsApp broadcast lists only deliver to recipients who have saved your number in their phone's address book. Anyone who has not saved you receives nothing, and WhatsApp shows you no error, no bounce, and no warning. This single rule is why a broadcast to 200 people can reach 30. WhatsApp states it plainly in its Help Center. Per WhatsApp's [broadcast lists FAQ](https://faq.whatsapp.com/861663048350950), "only contacts who have added you to their phone's address book will receive your broadcast message." There is no way around this inside the native feature. It is not a setting you forgot to toggle. It is how broadcast lists are designed. [image: saved contact address book] Think about what that means for a marketing list. Your newest leads, the people you most want to reach, are exactly the people least likely to have saved your business number. So the native broadcast tool works worst on the audience it should serve best. A loyal regular who saved your bakery two years ago gets every broadcast. The lead who messaged you once last week gets silence. There is a second design fact worth knowing: broadcasts are one-way in feel but private in delivery. WhatsApp's FAQ notes that recipients "will receive the message as a normal message," and when they reply, "it will appear as a normal message" in your chats, and "their reply will not be sent to other recipients." So a broadcast is a batch of individual 1:1 messages, not a shared thread. Recipients never see each other. That privacy is good. The saved-contact tax is the price. **The quick test:** send one broadcast to two of your own numbers, one that has you saved and one that does not. The saved number receives it. The unsaved number gets nothing. That five-minute test proves the rule on your own account before you blame anything else. ## How many contacts can one WhatsApp broadcast reach? A single WhatsApp broadcast list is capped at 256 recipients. Per WhatsApp's [broadcast lists FAQ](https://faq.whatsapp.com/861663048350950), "you can select up to 256 contacts in each Broadcast list." If your list is larger, everyone past 256 simply is not on it, so they never receive the message. This article owns the troubleshooting angle, so I will not re-teach the limit here. If you want the full explainer on the cap and where it comes from, read our [WhatsApp broadcast limit guide](https://blueticks.co/blog/whatsapp-broadcast-limit). And if you need to message more than 256 people, the workarounds (multiple lists, labels, and the trade-offs of each) are covered in [how to broadcast to more than 256 contacts](https://blueticks.co/blog/whatsapp-broadcast-more-than-256-contacts). Read those two for the "how many" and "how to go bigger." Back here, keep going for why even a within-cap broadcast under-delivers. ## Is your number being throttled or flagged as spam? WhatsApp can slow or restrict delivery from a number that looks like a spam source: rapid identical sends, a brand-new number with no history, or a spike in blocks and reports. When this happens, messages queue, land late, or stop, and the account can be temporarily restricted. Being honest about the numbers matters here, because there is a myth to clear up. There is no official published daily limit for personal WhatsApp broadcast lists. WhatsApp does not put out a "whatsapp broadcast message limit per day" figure for regular accounts, so any specific per-day number you have seen quoted is someone's guess, not a documented rule. Do not plan around an invented ceiling. What actually governs throttling is behavior, not a counter: - **Velocity.** Firing many broadcasts back to back, especially the exact same text, reads as automated spam. - **Reports and blocks.** When recipients tap "block" or "report," WhatsApp's systems notice fast. A wave of these is the strongest signal that gets a number restricted. - **Cold sending.** A number created yesterday that immediately blasts hundreds of messages has no trust history, so it gets scrutinized harder than an aged, well-used number. The mechanics are reputational, not a fixed quota. Meta describes its enforcement in the [WhatsApp Business Messaging Policy](https://www.whatsapp.com/legal/business-policy/), which allows it to limit or remove access for accounts that send unsolicited or bulk messaging that people report. The takeaway: your delivery health is driven by how recipients react, not by hitting some secret number. Slow down, vary your content, and message people who actually want to hear from you, and throttling is rarely your problem. ## WhatsApp broadcast vs group: which are you actually using? A broadcast list sends private, individual 1:1 messages, requires the saved-contact rule, and recipients never see each other. A group is one shared thread where everyone sees every member and every reply, with no saved-contact requirement. Mixing these up is a common reason delivery behaves in a way you did not expect. [image: broadcast vs group comparison] The "whatsapp broadcast vs group" confusion cuts both ways. If you think you set up a broadcast but actually created a group, everyone receives the message (no saved-contact rule) but they also see each other's numbers and can reply to the whole room, which is a privacy problem for a customer list. If you think you are in a group but actually built a broadcast list, delivery quietly collapses to only the people who saved you, and you wonder why half the room went dark. Here is the clean comparison: | | Broadcast list | Group | |---|---|---| | Message delivery | Private 1:1 to each recipient | One shared thread | | Saved-contact requirement | Yes, recipients must have saved you | No | | Do recipients see each other | No | Yes, all numbers visible | | Replies | Come to you as a normal 1:1 chat | Visible to the whole group | | Max size | 256 per list | Large, but everyone is public to each other | | Best use | One-way updates to people who saved you | Two-way community discussion | The practical rule: use a broadcast list when you want private one-way updates and your recipients have you saved. Use a group when you want an open conversation and privacy between members is not a concern. If neither fits, that gap is exactly what the last section solves. ## How to check whether your broadcast actually delivered To check delivery, open the broadcast list, tap a sent message, and read the per-recipient delivery ticks in the message info; run the saved-versus-unsaved two-number test; and confirm no key recipient has blocked you. Native broadcasts give you very little delivery visibility, so these manual checks are the best you get. [image: delivery ticks check] Work through this in order: 1. **Open the broadcast list and tap the message.** In the message info screen you can see which recipients show delivered (double gray tick) and read (double blue tick). Names with a single tick did not receive it, which usually means the saved-contact rule or a block. 2. **Run the two-number test.** Send to one number that has you saved and one that does not. If only the saved one receives it, the saved-contact rule is your bottleneck, confirmed on your own account. 3. **Check for blocks.** If a specific important contact never gets delivery, you may be blocked by them. Signs include your messages never moving past a single tick to that person and their profile photo or last-seen no longer updating. 4. **Watch for a hard stop past a point in a big list.** If the first chunk delivered and the tail did not, suspect the 256 cap or throttling rather than the saved-contact rule. The honest conclusion: the native tool tells you almost nothing at scale. Per-recipient ticks are fine for a list of 12. For a list of 250 you are squinting at a status screen with no export, no delivery report, and no way to see failures in aggregate. That visibility gap is the real cost of native broadcasting, and it is the setup for a better approach. ## How to reach everyone reliably, even people who haven't saved your number To reach people who have not saved your number at scale, you have two honest options: the WhatsApp Business API, or a tool like Blueticks that sends personalized individual messages from your own number. Both sidestep the native broadcast list's saved-contact limitation, but they work very differently, and neither is a license to spam. [image: reliable reach planning] **Option 1: the WhatsApp Business API (Meta).** This is Meta's official infrastructure for business messaging at scale. It reaches users who have not saved you, but it comes with real overhead: per-message conversation fees, opt-in requirements, and pre-approved message templates for anything promotional. It is powerful and fully sanctioned, and it is also a project to set up and a running cost that scales with volume. For many small businesses that is more machinery than they need. **Option 2: a tool like Blueticks.** Blueticks sends personalized, individual WhatsApp messages from your own number. Because each message goes out as a normal 1:1 message rather than through a native broadcast list, it is not subject to the saved-contact rule that silently drops your unsaved leads. You also get per-recipient delivery tracking and automated follow-ups, so you finally see who received what instead of squinting at tick marks. Be clear on the boundary, because it is a real one. Blueticks is **not** the WhatsApp Business API. It sends from your existing number over WhatsApp, with no per-message conversation fees and no template approval queue. But it does not exempt you from WhatsApp's rules. Consent and anti-spam responsibility stay with you, the sender. Message people who want to hear from you, honor opt-outs, and do not blast strangers. No tool, this one included, can promise guaranteed delivery or shield you from a restriction if recipients report you. Deliverability follows from sending wanted messages, not from the software. For the full mechanics of sending to many contacts at once without tripping WhatsApp's limits, see our guide to [sending bulk WhatsApp messages](https://blueticks.co/blog/how-to-send-bulk-whatsapp-messages). Take a realistic example. Novara Skincare had a list of 220 opted-in customers and kept broadcasting new-arrival alerts natively.[^1] Their message info showed delivery to only about 40 people, because the rest were newer buyers who had never saved the shop's number. Switching to personalized individual sends from their own number, to the same consented list, put the message in front of all 220 with a delivery record they could actually read. Same audience, same consent, roughly five times the reach, because the saved-contact tax was gone. **Broadcast reaching only a fraction of your list?** Send from your own number to everyone, saved contact or not, with per-recipient delivery tracking and automated follow-ups. [Start free with Blueticks campaigns →](https://blueticks.co/signup) ## FAQ **Why is my WhatsApp broadcast not working?** The most common reason is the saved-contact rule: native broadcast lists only deliver to recipients who have added your number to their phone's address book, and WhatsApp shows you no error for the rest. Other causes are the 256-recipient cap, spam throttling on high-volume sends, and using a group instead of a broadcast list. **Why do only some people get my broadcast?** Because only the recipients who saved your number receive it. Per WhatsApp's official FAQ, contacts who have not added you to their address book will not get your broadcast message, and you see no warning. The people who received it had you saved; the silent ones did not. **Is there a daily limit on WhatsApp broadcasts?** There is no official published daily delivery limit for personal WhatsApp broadcast lists, so any specific per-day number you have seen is unverified. What actually triggers throttling is behavior: rapid identical sends, a brand-new unwarmed number, and a spike in blocks or reports. Send wanted messages at a reasonable pace and this rarely becomes an issue. **What's the difference between a broadcast and a group?** A broadcast list sends private, individual 1:1 messages and requires recipients to have saved your number, and recipients never see each other. A group is one shared thread where everyone sees every member and reply, with no saved-contact requirement. Broadcasts are for one-way updates; groups are for open discussion. **How do I broadcast to people who haven't saved my number?** Two honest options: the WhatsApp Business API, which reaches unsaved users but adds per-message fees, opt-in, and template approval, or a tool like Blueticks that sends personalized individual messages from your own number, which sidesteps the saved-contact rule without those API costs. Either way, consent and anti-spam responsibility remain yours as the sender. *Platform behavior in this article is grounded in WhatsApp's official Help Center: the [broadcast lists FAQ](https://faq.whatsapp.com/861663048350950) for the saved-contact requirement, the 256-recipient cap, and reply behavior, and the [WhatsApp Business Messaging Policy](https://www.whatsapp.com/legal/business-policy/) for enforcement. WhatsApp does not publish a per-day broadcast delivery limit for personal accounts; claims of a specific daily number are unverified. Verify current WhatsApp behavior at the linked sources before relying on it.* [^1]: Novara Skincare is a synthetic example, and the reach figures (about 40 of 220 delivered natively, versus 220 with individual sends) are illustrative of the saved-contact effect, not a measured case study. The mechanism is real: unsaved recipients do not receive native broadcasts. The exact ratio for your list depends on how many of your contacts have saved you. --- # WhatsApp Opt-In Best Practices: 10 Rules to Grow a Compliant Broadcast List (2026) > Ten rules for collecting WhatsApp consent the right way: double opt-in, wording that converts, per-channel capture, and how to keep a list Meta won't flag. URL: https://blueticks.co/blog/whatsapp-opt-in-best-practices Published: 2026-07-18 Author: Maya Cohen Category: marketing WhatsApp opt-in best practices mean getting explicit, documented consent before you message anyone: use double opt-in, state your business name and message purpose at signup, capture consent per channel, make opt-out easy, and never message purchased numbers. 1. Get explicit prior consent before the first message you send. 2. Use double opt-in so consent is confirmed and provable. 3. Identify your business clearly at the point of opt-in. 4. State exactly what they will receive and roughly how often. 5. Capture opt-in separately on every channel (web, chat, in-store, CTWA). 6. Keep a timestamped record of each consent for your own audit trail. 7. Make opt-out obvious and honor STOP or unsubscribe immediately. 8. Never message purchased, scraped, or assumed-consent numbers. 9. Write consent wording that is specific and plain, not buried legalese. 10. Match the opt-in method to the channel to lift conversion. ## What are WhatsApp opt-in best practices? WhatsApp opt-in best practices are the rules for collecting provable consent before you send a single message. Get explicit permission first, confirm it, say who you are and what you will send, capture it per channel, log it, and make leaving easy. Here is why each rule earns its place: 1. **Explicit prior consent** is the whole foundation. Meta's Business Messaging Policy says you may only message people who have given you their number and confirmed they wish to receive your messages. 2. **Double opt-in** turns a checkbox into a confirmed action, so you can prove the person actually wanted in. 3. **Clear business identity** at signup is a stated Meta requirement, not a nicety. 4. **Set expectations** on content and frequency so the first message is never a surprise. 5. **Per-channel capture** matters because consent on your website does not transfer to a number someone gave you in-store. 6. **A timestamped record** is your evidence if a number's quality gets questioned. 7. **Easy opt-out** is required by policy and protects your sender reputation. 8. **No purchased or scraped numbers**, ever. This is the fastest route to a ban. 9. **Plain wording** raises consent conversion and keeps the consent legally meaningful. 10. **Channel-matched methods** are a growth lever: the right capture point for the context converts far better than a generic form. ### The 10-rule opt-in checklist at a glance Print the list above and keep it next to whoever builds your signup forms. The first eight rules are compliance. The last two are conversion. You need both, because a compliant list that nobody joins is not a list, and a big list you collected the wrong way is a liability that can get your number blocked. ### Who these rules apply to (API or not) These rules apply to any business messaging WhatsApp contacts, whether you run the WhatsApp Business Platform API or send from your own number through a tool like Blueticks. Consent is not an API feature you can buy your way out of. It sits with you, the sender, regardless of how the message leaves your account. If you have people's numbers and you are messaging them at scale, this checklist is yours. ## Why does WhatsApp require opt-in at all? WhatsApp requires opt-in because the platform's entire value is that it is not a spam channel. Meta's Business Messaging Policy is explicit: you may only contact people who have given you their phone number and from whom you have received opt-in permission confirming they wish to receive your messages. Consent is the price of access. [image: double opt in confirm phone] Meta puts the responsibility squarely on you. Per Meta's [opt-in guidelines for developers](https://developers.facebook.com/docs/whatsapp/overview/getting-opt-in), the business is "solely responsible for determining the method of opt-in" and for obtaining it in a way that complies with applicable law. Meta does not collect consent for you and does not vouch for your list. It sets the standard and enforces it after the fact. The stakes are mechanical. If your number's quality tier stays low for a sustained period, Meta's systems will limit how many messages you can send. Keep violating and the [WhatsApp Business Messaging Policy](https://www.whatsapp.com/legal/business-policy/) allows Meta to limit or remove your access entirely, and to prohibit your organization from all future use of WhatsApp products. Quality tier is driven heavily by how recipients react: people who never opted in block and report, and blocks and reports are what drag a number toward a ban. So opt-in is not paperwork. It is the thing standing between you and a dead number. ### What Meta counts as valid consent Meta's getting-opt-in documentation is specific about what a valid opt-in must communicate. It must "clearly state the business's name" that the person is opting in to hear from, and "clearly state that a person is opting in to receive communication from the business" over WhatsApp. On method, Meta says "it is up to businesses to determine the method of opt-in" and lists acceptable channels including your website, SMS, phone or IVR systems, and in-person or paper forms. In other words: any channel is fine, as long as the person actively agreed and you told them who you are and what they signed up for. ### What counts as a violation Three patterns are clear violations of the spirit and letter of the policy: - **Purchased or rented lists.** These people never gave you their number or their permission. Messaging them is prohibited outright. - **Silent scraping.** Pulling numbers from group chats, websites, or a WhatsApp group you admin is not consent. Being reachable is not opting in. - **Pre-checked boxes and bundled consent.** A pre-ticked opt-in, or consent buried inside your general terms and conditions, is not the explicit, active agreement the policy requires. Meta's policy also forbids messaging that is designed to "confuse, deceive, defraud, mislead, spam, or surprise" people. If a recipient would be surprised to hear from you, you probably do not have real consent. ## What is double opt-in on WhatsApp, and do you actually need it? Double opt-in is a two-step consent flow: the person requests to subscribe, then confirms that request in a second, separate action before you add them to your list. Single opt-in stops at step one. Double opt-in adds the confirmation, which is what turns "they ticked a box" into "they actively confirmed they want this." To be honest about the rule: Meta does not publish a clause that literally says "you must use double opt-in." What Meta's Business Messaging Policy does require is opt-in permission "confirming that they wish to receive subsequent messages." Double opt-in is simply the cleanest way to produce that confirmation and to have it on record. It is a strong, widely expected best practice, inherited from email marketing consent norms, and it directly satisfies the "confirming" language in the policy. ### Single vs double opt-in | | Single opt-in | Double opt-in | |---|---|---| | Steps | One (form or box) | Two (request, then confirm) | | Proof of intent | Weak | Strong, confirmed action | | Bad-number risk | Higher (typos, fake entries) | Lower (confirmation filters them) | | List quality | Larger, noisier | Slightly smaller, much cleaner | | Deliverability effect | More blocks and reports | Fewer blocks, healthier quality tier | The tradeoff is honest: double opt-in shrinks your raw signup count a little because some people never complete step two. But the people who drop off at confirmation were the ones most likely to block you later. A slightly smaller confirmed list protects the quality tier that keeps your number alive. ### A double opt-in flow you can copy 1. Person taps a click-to-chat link, submits your web form, or scans your QR code. 2. You send one confirmation message: your business name, what they will receive, how often, and a plain instruction to reply YES to confirm. 3. They reply YES. Only now do they enter your broadcast list. 4. You store the timestamp, the channel, and the exact wording they agreed to. 5. Anyone who does not confirm is never messaged again. That is it. Five steps, and you now hold consent you can actually defend. ## How should you word your opt-in consent? Good WhatsApp consent wording does three jobs at once: it names your business, it states exactly what the person will receive and roughly how often, and it gives a one-line way out. Compliant wording and high-converting wording are the same thing here, because clarity is what makes people comfortable enough to say yes. [image: consent form clipboard] Here are two before-and-after rewrites. **Weak:** "Sign up for updates." **Strong:** "Get order updates and weekly offers from Northlane Home on WhatsApp, about 2 messages a week. Reply STOP anytime to unsubscribe." **Weak:** "By continuing you agree to receive communications." (buried in terms) **Strong:** "Yes, message me on WhatsApp with appointment reminders from Dr. Levy's clinic. I can reply STOP to opt out." Notice the pattern in the strong versions: business name, specific content, rough frequency, and a visible exit. That is the full set of WhatsApp opt-in language requirements working together in one sentence. ### A consent line template Use this fill-in-the-blank structure at every capture point: > "Get [message type] from [business name] on WhatsApp, about [frequency]. Reply STOP anytime to unsubscribe." Keep it above the button, not below it. Keep it in plain language, not legalese. The consent line is the last thing someone reads before they commit, so it should reduce hesitation, not add it. ### Words that raise conversion vs words that raise abandonment Words that help: your real business name, the concrete benefit ("order updates," "restock alerts," "appointment reminders"), a frequency number, and "reply STOP anytime." Specificity signals honesty. Words that hurt: vague scope ("updates," "communications," "news"), pre-ticked boxes, consent bundled into terms and conditions, and anything that hides how often you will message. Vagueness reads as a trap, and people who feel trapped either abandon the form or opt in resentfully and block you on the first send. Both outcomes cost you. ## Where do you capture opt-ins, and which channel converts best? You capture WhatsApp opt-ins wherever you already have someone's attention and intent: your website, click-to-chat links, click-to-WhatsApp ads, in-store QR codes, and checkout. The best-converting channels are the high-intent ones, where the person is already in a transaction or has already raised their hand. Each channel needs its own separate consent capture. [image: qr code storefront] This piece is the growth-and-consent playbook, so I will not re-teach the full channel menu here. Our master guide to [WhatsApp opt-in collection across 9 channels](https://blueticks.co/blog/whatsapp-opt-in-collection-guide) walks every capture point in detail, and if you want the on-site route specifically, the [WhatsApp opt-in widget how-to](https://blueticks.co/blog/whatsapp-opt-in-widget) covers building the website capture step by step. Read those for the how. This section is about which ones are worth your time. ### Channel-by-channel opt-in rates Rough, directional ranking based on how much intent the moment carries. Treat the ranges below as illustrative planning estimates, not measured benchmarks, since real rates swing hard by industry and offer.[^1] | Capture point | Intent level | Illustrative opt-in rate | Why | |---|---|---|---| | Checkout consent line | High | 30 to 60 percent | The person is already buying; a reminder opt-in is a small add | | Click-to-chat / they message first | High | Very high | They started the conversation; you just confirm | | In-store QR at point of sale | Medium to high | 10 to 30 percent | Staff prompt plus a clear benefit drives scans | | Click-to-WhatsApp ad | Medium | Varies by creative | Paid intent, but colder than an existing customer | | Generic website popup | Low to medium | 1 to 5 percent | Broad reach, weak intent, easy to dismiss | ### High-intent vs low-intent capture points The lesson under the numbers: consent collected at a high-intent moment converts better and blocks less. Someone who opts in at checkout or after messaging you first is far less likely to report you than someone who tapped a popup they barely read. So do not just chase raw signups. Weight your effort toward the moments where the person already wants a relationship, and your list quality takes care of itself. ## How do you keep a consented list clean and avoid getting flagged? You keep a WhatsApp list clean by honoring opt-outs instantly, re-permissioning contacts who have gone quiet, not over-sending, and watching your quality signals. A consented list is not a one-time achievement. It decays, and if you ignore the decay, your block and report rate climbs until Meta throttles your number. [image: clean list review] For the full compliance rule set, including the deeper policy detail, read our [WhatsApp opt-in compliance requirements](https://blueticks.co/blog/whatsapp-opt-in-compliance-requirements) explainer. Here is the operational hygiene that keeps you off Meta's radar. ### Handling opt-outs and STOP Meta's guidance is direct: provide clear instructions for how people can opt out and honor those requests. Practically, that means: - Recognize STOP, UNSUBSCRIBE, and obvious opt-out phrasing, and stop sending immediately. - Remove the number from your active list the moment they ask, not at the end of a campaign. - Never make someone ask twice. A second unwanted message after an opt-out is exactly the kind of thing that earns a report. Fast, reliable opt-out handling is not just compliance. It is deliverability protection, because every honored opt-out is a report you did not get. ### Warning signs your list is hurting deliverability Watch for these: - A rising share of sends that get blocked or reported. - Your number's quality tier slipping after a broadcast. - Falling read rates on a list that used to engage. - Complaints or confused replies asking "who is this?" (a sign your consent or identity step is broken). If you see these, stop broadcasting to the whole list and re-permission the stale segment: send one message asking people to confirm they still want to hear from you, and drop everyone who does not. A smaller engaged list beats a large one that is dragging your number toward a ban. ## From consented list to campaign: what to do once people opt in Once you have a list you have real consent for, the job shifts from collecting permission to actually messaging people well. This is where Blueticks fits: it schedules and broadcasts WhatsApp messages to your consented contacts from your own number, with no WhatsApp Business API and no per-message conversation fees. Be clear on the boundary, though, because it is a real one. ### What Blueticks does and does not do for opt-in Blueticks does **not** collect opt-ins for you. It is not a Meta hosted opt-in flow, it is not the WhatsApp Business API, and it is not a compliance shield. Getting valid consent, wording it correctly, logging it, and honoring opt-outs is your legal responsibility as the sender, exactly as Meta's policy states. No tool changes that. What Blueticks **is**: the tool to message a list you already have permission for. If you have done the opt-in work above and you hold a genuinely consented list, Blueticks is how you send to it without wiring up API infrastructure. It runs on top of WhatsApp Web and sends from your existing number, so there is no per-message bill scaling with your list size. **Got a list you have consent for?** Schedule and broadcast to it from your own WhatsApp number, no API setup, flat monthly pricing. [Start free →](https://blueticks.co/signup) ### Scheduling and broadcasting to a consented list With a clean list in hand, the mechanics are straightforward: import your consented contacts, personalize the message, and schedule the send or broadcast it now. For the full walkthrough on sending to many contacts at once without tripping WhatsApp's limits, see our guide to [sending bulk WhatsApp messages](https://blueticks.co/blog/how-to-send-bulk-whatsapp-messages). The consent is the hard part. Once you have it, the sending is the easy part, and it should stay that way. ## FAQ **Do I need double opt-in for WhatsApp?** Meta does not publish a rule that literally mandates double opt-in, but its Business Messaging Policy requires opt-in permission confirming the person wishes to receive your messages. Double opt-in is the cleanest way to produce and record that confirmation, and it is a widely expected best practice, so for any broadcast list it is strongly recommended. **Is buying a WhatsApp contact list against the rules?** Yes. Meta's Business Messaging Policy only permits messaging people who gave you their number and confirmed they want your messages. Purchased, rented, or scraped lists fail both tests and can get your number rate-limited or banned. There is no compliant way to message a list you bought. **What consent wording does Meta require?** Meta's opt-in guidelines require that your opt-in clearly states your business name and clearly states that the person is agreeing to receive communication from your business on WhatsApp. Add what they will receive, roughly how often, and a plain opt-out line, and you satisfy the requirement while also converting better. **Does Blueticks collect opt-ins for me?** No. Blueticks sends to a consented list you already hold; it does not collect opt-ins, it is not a Meta hosted opt-in flow, and it is not the WhatsApp Business API. Obtaining and recording valid consent is your responsibility as the sender. Blueticks is the tool for messaging a list you already have permission for. **How do I let people unsubscribe from WhatsApp messages?** Give a clear opt-out instruction in your messages, commonly "Reply STOP to unsubscribe," recognize STOP and similar phrases, and stop sending to that number immediately. Meta's guidance requires clear opt-out instructions and honoring them, and fast opt-out handling also protects your number's quality tier. *Compliance claims in this article are grounded in Meta's published WhatsApp guidance: the [opt-in requirements for developers](https://developers.facebook.com/docs/whatsapp/overview/getting-opt-in) and the [WhatsApp Business Messaging Policy](https://www.whatsapp.com/legal/business-policy/). Meta does not publish a clause explicitly mandating double opt-in; it is presented here as a best practice that satisfies the policy's requirement for confirmed opt-in. Verify current policy language at the linked Meta sources before building your consent process.* [^1]: The opt-in rate ranges in the channel table are illustrative planning estimates based on the relative intent of each capture moment, not measured benchmarks from a specific study. Real opt-in rates vary widely by industry, offer, and audience. Use them to rank channels, not to forecast exact numbers. --- # How to Connect WhatsApp to Claude (MCP Integration Setup Guide) > You want Claude to send and read WhatsApp for you. Here's the exact MCP setup: connect your number, generate a key, add the server, and verify the tools load. URL: https://blueticks.co/blog/connect-whatsapp-to-claude-mcp-integration Published: 2026-07-17 Author: Daniel Roth Category: productivity Connect WhatsApp to Claude by adding the Blueticks MCP server to your MCP client and authenticating with a Blueticks API key. Claude can then send, schedule, and read WhatsApp messages from your own number in plain language. 1. Connect your WhatsApp number to Blueticks so an engine is live. 2. Generate a Blueticks API key (it starts with `bt_live_`). 3. Add the Blueticks MCP server to Claude and paste the key. 4. Restart Claude and confirm the WhatsApp tools load. 5. Ask Claude to send a test message, and watch it go out from your number. There are two ways to wire this up, and most people should pick the first. The **remote connector** connects Claude to Blueticks over a URL and a login, with nothing to install and no key to store. The **MCP server** path below runs the `@blueticks/mcp` package locally and authenticates with a `bt_live_` key, which suits Claude Code, Cursor, and anyone who prefers key-based auth. Both reach the exact same WhatsApp tools; they differ only in how Claude connects and signs in. ## The fastest way: connect with the remote connector (no install, no key) If you use Claude on the web or in the desktop app, skip the config file and the API key entirely. Blueticks runs a hosted MCP endpoint that Claude connects to over a URL, and you approve access with a login instead of a pasted key. Setup takes about two minutes. 1. In Blueticks, open the left sidebar and click **AI Assistant**, then choose **Claude**. The dialog shows your connector URL and the same steps below, so you can copy as you go. 2. Copy your MCP endpoint: `https://api.blueticks.co/mcp`. 3. In Claude, open **Settings → Connectors** (newer builds file it under **Customize → Connectors**), click **Add custom connector**, name it **Blueticks**, paste the URL, and click **Connect**. 4. Claude sends you to Blueticks to log in and approve access. That is standard OAuth: you authorize the connection on a Blueticks screen, and you can revoke it anytime from your settings. No key ever touches the Claude config. 5. Back in Claude, ask something read-only like "list my recent WhatsApp chats" to confirm the WhatsApp tools loaded. That is the whole setup. Because the endpoint is hosted, there is nothing to install or keep running on your machine, and because it uses OAuth, there is no `bt_live_` key to copy, store, or rotate. For most people who just want Claude handling WhatsApp on the web, this is the path. Prefer an API key, or connecting from Claude Code or Cursor? The MCP-server setup below is the right fit, and it is unchanged. Read on for that path. ## How to connect WhatsApp to Claude (MCP integration) To connect WhatsApp to Claude you link your WhatsApp number to Blueticks, create a Blueticks API key, register the Blueticks MCP server in your Claude client with that key, and verify the tools appear. Then Claude can send WhatsApp from Claude directly. This is a five-step setup and none of it involves Meta's developer console. You're wiring your own WhatsApp number into Claude through a WhatsApp MCP server, so the messages Claude sends come from you, not from a separate business identity. The steps below are the current happy path. Where a config detail can drift between clients, I point you at the live Blueticks docs instead of guessing. ### Step 1 — Connect your WhatsApp number to Blueticks Before Claude can touch WhatsApp, you need a running Blueticks engine tied to your number. Sign up at [blueticks.co](https://blueticks.co/signup), then link your WhatsApp the way you'd link WhatsApp Web: scan a QR code so your session is live. The engine is the part that actually holds your WhatsApp connection. The MCP server you add later just gives Claude a set of tools that drive that engine. If you want the offline version, where sends fire even when your laptop is closed, that's the Blueticks Pro gateway that parks your session on Blueticks' servers. Either way, the requirement for this step is the same: a connected number Claude can send through. ### Step 2 — Generate a Blueticks API key (bt_live_) The key is how Claude proves it's allowed to act as you. Open the Blueticks API dashboard, click "Create key," and copy the value immediately, because it's shown once and never again ([dev.blueticks.co](https://dev.blueticks.co)). The key is formatted `bt_live_…` and should be treated as a password. Never paste it into a chat, commit it to a repo, or drop it in a public config. [image: api key note card desk] You can sanity-check the key before you wire it into Claude. The Blueticks API exposes a `GET /v1/ping` endpoint that validates the key and returns your account ID plus the connected WhatsApp engine info ([dev.blueticks.co](https://dev.blueticks.co)). If ping comes back with your engine, the key works and your number is reachable. If it errors, fix that here, not three steps later inside Claude. ### Step 3 — Add the Blueticks MCP server to Claude Claude reaches WhatsApp through the `@blueticks/mcp` server, a stdio MCP server you run on demand with `npx`, so there's nothing to install into a project ([Blueticks MCP docs](https://dev.blueticks.co)). You register it in your Claude client's MCP configuration and hand it the key from Step 2 as an environment variable. The config block Blueticks documents for Claude Desktop is: ```json { "mcpServers": { "blueticks": { "command": "npx", "args": ["-y", "@blueticks/mcp"], "env": { "BLUETICKS_API_KEY": "bt_live_your_key_here" } } } } ``` Claude Code and Cursor use the same server and the same `BLUETICKS_API_KEY` variable, just in each client's own config location ([Blueticks MCP docs](https://dev.blueticks.co)). Config file paths and UI move around as clients update, so if a screen doesn't match, follow the current setup steps in the Blueticks docs at [dev.blueticks.co](https://dev.blueticks.co) rather than an old screenshot. The one constant is what you're doing: point your MCP client at the Blueticks MCP server and authenticate with your `bt_live_` key. ### Step 4 — Authenticate and verify the tools load Fully restart Claude after saving the config. MCP servers are read at startup, so a running window won't pick up a server you just added. When Claude relaunches, it starts the Blueticks server, passes your key, and the WhatsApp tools become available in that session. To verify, ask Claude something read-only first, like "list my recent WhatsApp chats" or "what WhatsApp tools do you have?" If the mcp WhatsApp tools loaded, Claude answers using them. If it says it has no WhatsApp access, the server didn't start or the key didn't authenticate, and the troubleshooting section below covers both. ### Step 5 — Send your first WhatsApp message from Claude Now do the real thing. Tell Claude, in plain language, to message someone: "Send a WhatsApp to +1 555 010 0199 saying the invoice is attached and I'll follow up Friday." Claude maps that to the Blueticks send tool, and the message leaves from your WhatsApp number. Watch your phone. It shows up in your sent messages like anything else you'd type by hand, because it is your account sending. That's the whole Claude WhatsApp integration. Everything after this is Claude choosing the right tool for what you ask. > **Skip Meta's developer console entirely.** You don't need a Business API account, a provider contract, or per-message fees to let Claude message people from your own WhatsApp. Create a Blueticks account, generate a key, and connect Claude in a few minutes. [Get your Blueticks API key.](https://blueticks.co/signup) ## What is MCP, and how does Claude use it to reach WhatsApp? MCP, the Model Context Protocol, is an open standard that connects AI applications like Claude to external tools and data through a consistent interface. Claude runs an MCP client, Blueticks runs an MCP server exposing WhatsApp tools, and Claude calls those tools to send or read messages. [image: usb c hub cables desk] The Model Context Protocol documentation describes MCP as "an open-source standard for connecting AI applications to external systems" and compares it to a USB-C port for AI: one standardized way to plug an AI app into outside data, tools, and workflows ([modelcontextprotocol.io](https://modelcontextprotocol.io)). Before MCP, every AI-to-tool link was a bespoke integration. MCP replaces that with a common protocol, which is why the same Blueticks server works across Claude Desktop, Claude Code, and Cursor without a rewrite. The moving parts are worth getting straight, because they decide where things can break: - **The MCP client** is Claude. It's the side that wants to do something and asks for tools. - **The MCP server** is Blueticks (`@blueticks/mcp`). It advertises a set of WhatsApp tools and knows how to run them. - **The tools** are the actual actions: send a message, list chats, start a campaign. Each one wraps a Blueticks `/v1` API call under the hood. So when you ask Claude to message a client, Claude picks the send tool, the Blueticks server translates it into a `/v1` call authenticated with your key, and your engine delivers it on WhatsApp. If you want the deeper background on this pattern, the primer on [WhatsApp and MCP](https://blueticks.co/blog/whatsapp-mcp) walks through the architecture without assuming you've set anything up yet. ## What can Claude do with WhatsApp once connected? Once connected, Claude can read and search your WhatsApp conversations, help you triage them, and draft replies, and it can also send, schedule, and manage messages, campaigns, groups, and contacts from your number. The Blueticks server exposes nine tool families covering the full set. Lead with the part that's underrated: reading and triage. Claude can pull recent chats, search conversation history, and load older messages through the `chats` tools ([Blueticks MCP docs](https://dev.blueticks.co)). That means you can ask "which WhatsApp threads from this week still need a reply?" and get a triaged list, then "draft a friendly follow-up to the three that mention pricing" and review the drafts before anything sends. The read-triage-draft loop is where the whatsapp Claude combo saves the most time, because reading and prioritizing is the tedious part, not typing. [image: triage coffee notebook morning] Then there's the write path, where Claude actually acts: - **Send now:** "Text Maria the meeting moved to 3pm." Straight send from your number. - **Schedule:** "Send this reminder every client on Monday at 9am." Claude sets it and the queue fires later. I don't re-teach scheduling here; the companion guide on [scheduling WhatsApp messages from Claude via MCP](https://blueticks.co/blog/schedule-whatsapp-messages-from-claude-mcp) covers timing, recurrence, and the gotchas in depth. This article is the connect-and-setup half; that one is the day-to-day scheduling half. - **Campaigns and audiences:** build a templated campaign and append contacts with personalization variables through the `campaigns` and `audiences` tools. - **Groups and contacts:** create and manage groups, pull contact data. - **Webhooks, engine, utils:** register delivery and session callbacks, check engine state, run utility calls. The nine families in full are `scheduled_messages`, `chats`, `groups`, `campaigns`, `audiences`, `contacts`, `webhooks`, `engine`, and `utils` ([Blueticks MCP docs](https://dev.blueticks.co)). You never call them by name. You describe what you want and Claude picks the tool. If it picks wrong, you correct it in plain language, the same way you'd redirect a capable assistant. Here's the failure mode to know up front: Claude can only send when your engine is live. If your WhatsApp session dropped or, on the free path, your computer is asleep, a send won't fire until the session is back. That's a Blueticks connection state, not an MCP bug, and it's the single most common "why didn't it send" surprise. ## Is this the WhatsApp Business API? No. Blueticks sends from your own personal WhatsApp number through its engine, which drives a real WhatsApp Web session. It is not Meta's WhatsApp Business API (the Cloud API), which sends server-side from a separate business number and bills per message. [image: own number phone in hand] This distinction matters more than any other line in this guide, so I'll be blunt about it. When Claude sends a message through Blueticks, it goes out as you, from the number your contacts already recognize, riding a live WhatsApp session. There's no Meta approval, no message templates to pre-clear, no per-conversation pricing. The WhatsApp Business API is a different product entirely: Meta moved it to per-message pricing effective July 1, 2025, with rates that vary by template category and country ([Meta's WhatsApp pricing docs](https://developers.facebook.com/docs/whatsapp/pricing)), and a number registered on the Cloud API can't be used with the normal WhatsApp app. So pick by what you're doing. If you're a person or a small team who wants Claude to handle your everyday WhatsApp from your own number, this MCP setup is the right tool and the API is overkill at roughly a hundred times the setup cost. If you're building an app that fires OTP codes or ships order updates to thousands of strangers from a brand number, that's the Business API, and Blueticks isn't a substitute for it. Don't conflate them, and don't let anyone sell you one as the other. ## Which MCP clients can I use? Any MCP-compatible client works, because Blueticks ships a standard stdio MCP server. Blueticks documents ready-made configs for Claude Desktop, Claude Code, and Cursor, and the same `@blueticks/mcp` server plus `BLUETICKS_API_KEY` pattern applies to other MCP clients. MCP's whole point is build-once, connect-everywhere. The protocol is supported across a wide range of AI clients and development tools ([modelcontextprotocol.io](https://modelcontextprotocol.io)), so the Blueticks WhatsApp mcp server isn't locked to one app. In practice most people connect WhatsApp to Claude specifically, using Claude Desktop for chat-style "message this person" work and Claude Code when they want WhatsApp actions inside a coding or automation workflow. The config differs only in where each client stores it. Claude Desktop uses its MCP settings file, Claude Code uses `~/.claude.json`, and Cursor has its own MCP config, but all three take the identical server command and key variable ([Blueticks MCP docs](https://dev.blueticks.co)). If you're weighing options across the ecosystem, the roundup of the [best WhatsApp MCP servers](https://blueticks.co/blog/best-whatsapp-mcp-servers) compares approaches so you can see where the Blueticks server fits. ## Troubleshooting: tools not loading or auth failing If the WhatsApp tools don't appear or auth fails, the cause is almost always one of four things: Claude wasn't fully restarted, the key is wrong or malformed, the JSON config has a syntax error, or your WhatsApp engine isn't connected. Work them in that order. Run this checklist when Claude says it has no WhatsApp access: 1. **Restart Claude completely.** MCP servers load at launch. Quit fully and reopen, not just close the window. This fixes most "tools missing" reports on the first try. 2. **Re-check the key.** Confirm it starts with `bt_live_`, has no stray spaces or line breaks, and is the full value you copied. Since the key shows only once, generate a fresh one if you're unsure. 3. **Validate the JSON.** A single trailing comma or unmatched brace stops the whole MCP config from parsing, so the server never starts. Paste it into a JSON validator if in doubt. 4. **Test the key outside Claude.** Call `GET /v1/ping` with the key. If it returns your account and engine, the key is good and the problem is client-side config. If ping fails, the key or account is the issue, not Claude ([dev.blueticks.co](https://dev.blueticks.co)). 5. **Confirm the engine is live.** Tools can load fine and sends still fail if your WhatsApp session is disconnected. Re-link your number in Blueticks and try a send again. One operator who runs a small agency put it this way: "Every time I thought MCP was broken, it was me. I'd edited the config and not quit Claude, or I'd pasted the key with a line break. Ping the key first and half your problems disappear." That's the honest pattern. The protocol rarely breaks; the setup details do. ## Blueticks MCP vs open-source WhatsApp MCP servers Blueticks is a managed WhatsApp MCP server: your session, sends, scheduling, and campaigns run on maintained infrastructure with a stable `bt_live_` key. Open-source WhatsApp MCP servers are self-hosted, so you run and maintain the session and server yourself, trading setup and upkeep for full control. Both connect WhatsApp to Claude over the same protocol, so the difference isn't capability on paper, it's who keeps it running. Weigh it by what you're optimizing for: | Factor | Blueticks MCP | Open-source WhatsApp MCP | |---|---|---| | Setup | Add key, paste config, done | Clone, configure, host it yourself | | Session uptime | Managed engine, optional offline gateway | You keep the session alive | | Scheduling and campaigns | Built-in tool families | Usually send-only; you build the rest | | Maintenance | Handled for you | Yours to patch and monitor | | Control | Managed service | Full, you own the stack | If you're a developer who wants to own every layer and doesn't mind babysitting a session, a self-hosted server is a legitimate path. If you want Claude messaging people reliably without becoming your own uptime team, the managed route wins on the thing that actually matters day to day: it's still working next month. For the full field, the [best WhatsApp MCP servers](https://blueticks.co/blog/best-whatsapp-mcp-servers) comparison lays the options side by side. ## FAQ **How do I connect WhatsApp to Claude?** The fastest way is the remote connector: link your WhatsApp number to Blueticks, then in Claude open Connectors, add a custom connector pointing at `https://api.blueticks.co/mcp`, and approve access with a Blueticks login. Nothing to install and no key to store. If you prefer key-based auth or you're on Claude Code or Cursor, add the `@blueticks/mcp` server with a `bt_live_` key as the `BLUETICKS_API_KEY` variable instead. Either way, verify by asking Claude to list your chats, and Claude can then send and read WhatsApp from your number. **Do I need an API key, or can I connect with just a login?** You can connect with just a login. The remote connector uses OAuth: you paste the Blueticks MCP URL into Claude, then authorize the connection on a Blueticks screen, and no `bt_live_` key is ever stored in your Claude config. The API-key path is still available and is the better fit for Claude Code, Cursor, and programmatic setups, but for Claude on the web the login flow is simpler and you can revoke access anytime from your Blueticks settings. **How is this different from scheduling WhatsApp from Claude?** This guide is the connect-and-setup half: getting the WhatsApp MCP server wired into Claude and authenticated. Scheduling from Claude is what you do afterward, once the tools are live, and it has its own timing, recurrence, and delivery nuances. Those live in the companion guide on [scheduling WhatsApp messages from Claude](https://blueticks.co/blog/schedule-whatsapp-messages-from-claude-mcp). Set up here, schedule there. **Does Claude send from my own WhatsApp number?** Yes. Blueticks drives a real session on your own number through its engine, so messages Claude sends appear as sent by you. It is not the WhatsApp Business API and does not use a separate business number or per-message billing. **Do I need the WhatsApp Business API for this?** No. The whole point of this setup is to let Claude message people from your existing WhatsApp without Meta approval, templates, or per-message fees. The Business API is for programmatic, high-volume transactional sending from a brand number, which is a different job. **Which Claude apps support the Blueticks MCP server?** Any MCP-compatible client works, and Blueticks documents ready-made configs for Claude Desktop, Claude Code, and Cursor. They all use the same `@blueticks/mcp` server and `BLUETICKS_API_KEY` variable, differing only in where each client stores its config. **Why aren't the WhatsApp tools showing up in Claude?** Almost always because Claude wasn't fully restarted after editing the config, the API key is malformed, the JSON has a syntax error, or your WhatsApp engine is disconnected. Restart Claude, re-check the key, validate the JSON, and test the key against `GET /v1/ping` before assuming anything deeper is wrong. --- # How to Schedule a Message on WhatsApp Web (Send Later Without the App) > You're already in WhatsApp Web and want to write now, send later. There's no native button, so here's the send-later workflow that actually works, and its one honest catch. URL: https://blueticks.co/blog/how-to-schedule-a-message-on-whatsapp-web Published: 2026-07-16 Author: Daniel Roth Category: productivity WhatsApp Web has no built-in scheduler. To send a message later, add a free browser extension like Blueticks: it puts a clock icon in the chat box — type your message, pick a date and time, and it sends automatically. 1. Open web.whatsapp.com and make sure you're logged in. 2. Add a free browser extension like Blueticks, then reload the tab. 3. Open the chat you want and click the clock icon in the message box. 4. Type your message, then set the date and time to send later. 5. Confirm. It's queued and fires on its own at that minute. ## How do you schedule a message on WhatsApp Web? You schedule it the way you'd use Gmail's "Schedule send" or Outlook's delay delivery, with one difference: WhatsApp Web has no native button for it. You add a browser extension that puts a clock icon in the chat box, write the message now, set a send time, and it goes out on its own. You already know this mental model. In Gmail you click the small arrow next to Send and choose "Schedule send" ([Gmail Help](https://support.google.com/mail/answer/9214606)). In Outlook you open the dropdown next to Send and pick a delivery time ([Microsoft Support](https://support.microsoft.com/en-us/office/delay-or-schedule-sending-email-messages-in-outlook-026af69f-c287-490a-a72f-6c65793744ba)). Write now, send later. That habit is exactly what you want when you're sitting at your desk in WhatsApp Web at 11 p.m. lining up a message for 7 a.m. Here's the "without the app" part. You don't install a separate desktop program. You don't wait for an unreleased native beta. You don't reach for your phone. You use the browser tab you already have open. A tool like [Blueticks](https://blueticks.co) drops a clock icon right next to where you type, so scheduling a WhatsApp Web send message feels like part of WhatsApp itself. If you haven't linked your phone to the browser yet, or you want the free-versus-paid breakdown, that groundwork lives in the companion piece on how to [schedule WhatsApp messages on WhatsApp Web](https://blueticks.co/blog/schedule-whatsapp-web-messages). This article is the "send later" cousin: you're already linked, already at the keyboard, and you want the timing workflow. ## Is there a native "send later" button in WhatsApp Web? No. There is no native send-later button in WhatsApp Web today. WhatsApp is reportedly building a "Schedule Send" option, spotted by WABetaInfo in Android and iOS betas in February 2026, but it is not available to users, not even enabled for beta testers yet, and it targets one-shot sends on personal mobile accounts. [image: A paper desk calendar and an analog clock representing WhatsApp send-later timing] Here's the accurate picture, because a few 2026 guides are already writing as if this shipped. Per [WABetaInfo](https://wabetainfo.com/whatsapp-is-working-on-a-feature-to-schedule-messages/) and [MacRumors](https://www.macrumors.com/2026/02/24/whatsapp-scheduled-messages-coming/), the feature surfaced in WhatsApp beta for Android 2.26.8.11 and a matching iOS build. You'd tap and hold the send button, then pick a time between 10 minutes and two weeks out, and the message would sit queued in the chat until it fires. It's meant to work in both chats and groups. Read the caveats twice. It's under development, not enabled even for testers, and there's no announced release date. It's built around sending one message once, on mobile personal accounts, with no confirmed desktop support and no sign of recurring sends or a multi-message queue. Compared to Gmail's send-later, which has shipped for years and lets you queue up to 100 scheduled emails, WhatsApp is well behind on this. So if you want to schedule a WhatsApp message to send later from the browser right now, the native option isn't it. ## How to send later on WhatsApp Web without the app Three paths let you send later on WhatsApp Web without installing a phone app or a native beta: a browser extension that runs in your tab, a mobile scheduler app that drives your phone, or the WhatsApp Business API that runs on Meta's servers. They're not interchangeable. Each one runs the "press send" code in a different place, and that's what decides which one fits you. That single question, where does the send actually execute, sorts the whole field: | Path | Where the send runs | Your own number? | Best for | |---|---|---|---| | Browser extension (Blueticks) | Your browser tab, on your computer | Yes | Send-later straight from WhatsApp Web | | Mobile scheduler app (Tasker, SKEDit) | Your phone, which must be on and usually unlocked | Yes | Phone-first tinkerers | | WhatsApp Business API | Meta's servers | No, a separate business number | Programmatic, OTP, high-volume transactional | For a WhatsApp send later from the browser, the extension is the natural fit. It rides your existing WhatsApp Web session, so it sends from your own number with no application to file and no per-message fees. The mobile apps move the work to your phone, which sounds convenient until you learn the phone has to be awake and often unlocked at send time. The Business API is a different animal entirely, and it earns its own section below. > **Skip the API paperwork.** If all you want is to schedule a message on WhatsApp Web from your own number, you don't need a Meta developer account, a provider contract, or per-message fees. Add the free extension, pick a time, and send. [Start free.](https://blueticks.co/signup) ## The one honest catch: your computer has to be on at send time Here's the catch nobody selling you a browser extension says plainly, so I will: on the free extension path, your computer has to be awake at send time. The scheduler is JavaScript running inside your browser tab. If the machine is asleep, shut down, or the tab is closed, the code isn't running, and a 7 a.m. message waits until you're back. [image: A closed laptop on an empty desk at dawn illustrating the computer-must-be-on catch] This is the single most common surprise with any in-browser scheduler. A laptop set to sleep after 15 minutes of inactivity is, for scheduling purposes, a computer that's off. Your queued message doesn't send at 7:00 sharp. It sends whenever the machine wakes and the session reconnects, and "late" on a client follow-up is the same as wrong. There are only two ways around it, and both move the send off your hardware onto a server. One is the WhatsApp Business API. The other is Blueticks' Pro offline gateway, which parks your session on Blueticks' servers so a 6 a.m. message goes out at 6 a.m. whether or not your laptop is awake. I've written the full device-by-device breakdown of what survives a shut lid in [do scheduled WhatsApp messages send when your phone or computer is off](https://blueticks.co/blog/scheduled-whatsapp-messages-phone-computer-off). Read it before you trust an overnight send to a laptop you close every night. One thing that is *not* the blocker: your phone. Thanks to WhatsApp's multi-device support, your phone can be off, out of battery, or in a drawer, and a linked session keeps sending, as long as the phone checks in at least once every 14 days ([About linked devices](https://faq.whatsapp.com/378279804439436)). Phone off is fine. Computer off is the constraint. ## What should you actually schedule to send later? Send-later earns its keep on messages with a fixed clock and a human cost if you forget. Think birthday notes timed for 7 a.m., a payment reminder for Monday morning, a "we're open" ping the minute your shop unlocks, or the follow-up you want to leave a prospect's number tomorrow at 8, not tonight at 11 when you actually wrote it. The pattern is always the same: you have the words now, but now is the wrong time to send them. A few concrete ones I schedule from WhatsApp Web myself: - **Client follow-ups timed for business hours.** Draft the nudge Sunday night, land it in the inbox Monday at 9 a.m. when it gets read. - **Recurring reminders.** A weekly team check-in or a monthly invoice ping. This is where the native beta falls short, since it only does one message once. Recurring sends are covered in [schedule WhatsApp messages](https://blueticks.co/blog/schedule-whatsapp-messages). - **Time-zone-correct outreach.** Writing at midnight your time but sending at 10 a.m. theirs. - **Personal notes you don't want to forget.** Birthdays, anniversaries, "good luck tomorrow" the morning of, not the night before. As one operator who runs her consultancy off WhatsApp put it: "I write everything Sunday night in one sitting from the browser. If I had to remember to hit send at the right minute five times a week, half of them wouldn't go out." That's the real value. You're trading your memory for a queue. ## WhatsApp Web send later vs. the Business API — which do you need? Pick by what you're sending, not by volume alone. For scheduled sends from your own number, an extension is the right tool: no application, no fees, your existing WhatsApp. For programmatic sends, one-time passcodes, or high-volume transactional messaging, you need the WhatsApp Business API. They solve different problems, and the extension does not replace the API. Be clear on the boundary, because "just use the API" gets thrown around too casually. The Business API genuinely sends server-side, so devices can all be off, but it comes with real cost. Meta moved to per-message pricing effective July 1, 2025, with rates that vary by template category and country ([Meta's pricing documentation](https://developers.facebook.com/docs/whatsapp/pricing)). It needs Meta approval, usually a provider contract, and pre-approved templates outside the 24-hour customer service window. And it's not your number: Meta's own documentation states a number registered on the Cloud API cannot be used with WhatsApp Messenger ([Cloud API phone numbers](https://developers.facebook.com/docs/whatsapp/cloud-api/phone-numbers)). So don't mismatch the tool. If you're building an app that fires OTP codes or shipping order updates to thousands of customers, that's the API, full stop. A browser extension is not a substitute for it and never claims to be. But if you're a person or a small team who wants to write now and send later from the WhatsApp account you already use, the API is the wrong tool at roughly a hundred times the setup cost. That's the extension's lane, and it owns it. ## FAQ **Is there a native scheduler in WhatsApp Web?** No. There's no native send-later button in WhatsApp Web today. A "Schedule Send" feature is reportedly in development (WABetaInfo spotted it in Android and iOS betas in February 2026), but it's not available to users, not enabled for beta testers, and it targets one-time sends on mobile personal accounts. To schedule on WhatsApp Web now, use a browser extension. **How do I schedule a WhatsApp message to send later without an app?** Use the browser tab you already have open. Add a browser extension like Blueticks to WhatsApp Web, open a chat, click the clock icon in the message box, type your message, set a date and time, and confirm. It queues and sends automatically. No phone app, no desktop program, no native beta required. **Will my scheduled WhatsApp Web message send if my computer is off?** Not on the free extension path. The scheduler runs in your browser tab, so the computer has to be awake at send time. If it's asleep or shut down, the message waits and fires when the machine wakes. To send with the computer off, you need a server-side sender: the Business API or the Blueticks Pro offline gateway. **Does the extension replace the WhatsApp Business API?** No. The extension is for scheduling sends from your own number without fees or approval. The Business API is for programmatic, OTP, and high-volume transactional messaging on a separate business number. They solve different problems, and neither replaces the other. **How far in advance can I schedule a WhatsApp Web message?** With a browser extension you set any future date and time, and can add recurring schedules for repeating sends. The reported native mobile feature is more limited, allowing scheduling only between 10 minutes and two weeks out for a single message, which is one reason people reach for an extension instead. --- # WhatsApp Business Pricing Categories in 2026: Utility vs Marketing vs Authentication (and How to Send Without Paying Per Message) > Four categories, one per-message bill. Here's what Marketing, Utility, Authentication, and Service messages actually cost in 2026, and when you can skip the fees entirely. URL: https://blueticks.co/blog/whatsapp-business-pricing-categories-2026-utility-marketing-authentication Published: 2026-07-15 Author: Maya Cohen Category: marketing WhatsApp Business Platform pricing has four message categories in 2026: Marketing, Utility, and Authentication (each billed per message at rates that vary by category and country) plus Service messages, which are free within the 24-hour customer service window. - **Marketing** - promotions, offers, re-engagement; highest cost - **Utility** - transaction updates tied to a customer action - **Authentication** - OTPs, login codes, MFA prompts - **Service** - replies inside the 24h user-opened window; free ## What are the WhatsApp Business Platform pricing categories in 2026? The WhatsApp Business Platform sorts every business message into four categories, and the category decides whether you pay and how much. Effective July 1, 2025, Meta bills on a per-message basis, so each delivered template message is its own charge. Rates vary by category and by the recipient's country calling code. Here is the structure at the level that actually shows up on your invoice. | Category | What it covers | How it's billed | Relative cost | |---|---|---|---| | Marketing | Promotions, offers, newsletters, re-engagement | Per delivered message, always | Highest | | Utility | Order and account updates tied to a customer action | Per message; free inside an open service window | Low | | Authentication | One-time passwords, login codes, MFA | Per message | Low | | Service | Any reply inside the 24-hour user-opened window | Free | Free | Two things trip people up. First, the category is set on the *template*, not on the send. Meta reviews and can reclassify a template, so labeling a promo as "utility" to dodge the marketing rate does not work. Second, the per-message model replaced the old per-conversation billing, where one 24-hour window covered every template you sent inside it. If you want the full before-and-after, our breakdown of the [2026 per-message pricing change](https://blueticks.co/blog/whatsapp-business-pricing-change-2026-per-message) walks through a worked example. The short version of relative cost: Authentication and Utility sit at the low end, Marketing sits well above them in every market, and Service is free. Meta publishes the exact per-message rate per category per country on its [official pricing documentation](https://developers.facebook.com/docs/whatsapp/pricing), and those numbers move, so treat any dollar figure you see as a snapshot, not a constant. ## Marketing messages: what they cost and when they apply Marketing is any template you send that the customer did not ask for: promotions, product launches, seasonal offers, abandoned-cart nudges, newsletters, win-back sequences. It is the highest-cost category in every market, and it is the only one with no volume-discount path. You do not get cheaper marketing messages by sending more of them. [image: Finance lead reviewing a printed billing statement with a highlighter] That matters most at scale. Take a synthetic-but-realistic example. A 12-person e-commerce team ("Northlane Home") runs a monthly promo blast to 40,000 opted-in contacts. Under per-message billing, every one of those 40,000 marketing templates is a separate line item.[^1] There is no window trick and no tier discount that softens a marketing broadcast. The team's finance lead put it plainly in a planning doc: "The API bill scales linearly with our list, and our list only grows." That is the defining feature of whatsapp business api pricing per message for marketing traffic. Where the API earns its keep is deliverability and automation you cannot replicate by hand: verified sender, higher throughput tiers, programmatic triggers. Where it stops earning its keep is a straightforward scheduled broadcast to a list you already own. If your marketing use case is "send this message to these people at this time," you are paying API infrastructure costs for something simpler. For a deeper cost view on that specific tradeoff, see our guide to [WhatsApp marketing message pricing in 2026](https://blueticks.co/blog/whatsapp-business-pricing-marketing-messages-2026). ## Utility messages: transaction-tied updates Utility covers operational messages tied to something the customer already did: order confirmations, shipping updates, payment receipts, appointment reminders for a booking they made, account alerts. The trigger is a prior customer action. Confirm a purchase and it is utility. Chase an abandoned cart and it is marketing. That line is the whole game for whatsapp utility message pricing. [image: Hand holding a smartphone face-up on a shipping desk beside a cardboard parcel] Utility rates run far below marketing, typically a fraction of the marketing rate in the same market, and utility unlocks lower per-message pricing as your monthly volume crosses Meta's tier thresholds. Marketing never does. So a high-volume sender can push a lot of utility traffic cheaply while marketing stays at full freight. The bigger utility win is the one most teams miss: a utility template sent *inside* an open 24-hour customer service window is free. If a customer messages you about their order and you reply with a shipping-status template while that window is open, you pay nothing. The same template sent cold, with no open window, bills at the standard utility rate. Timing decides the cost. Hold the confirmation until the customer has messaged you and you convert a paid send into a free one. ## Authentication messages: OTPs and login codes Authentication is a narrow, high-frequency category: one-time passwords, login verification codes, multi-factor prompts. Meta prices whatsapp authentication message pricing low on purpose, because it wants businesses using WhatsApp as an auth channel instead of SMS, where per-message costs are usually higher. Like utility, authentication has volume tiers, so the rate drops as monthly send volume climbs. [image: Person entering a login code on a phone at a laptop, illustrating authentication OTPs] One caveat worth knowing before you model costs: some markets carry higher "authentication-international" rates when you send codes to numbers outside your registered business region. If your login traffic is domestic, the base authentication rate applies. If you send OTPs across borders at volume, check the country-specific rate on Meta's pricing page before you assume the base number. This is also the one category where a schedule-and-broadcast tool is genuinely the wrong fit. OTPs are programmatic, time-critical, and triggered by a user action in real time. They need the API. Do not try to send login codes from a scheduling layer. If auth is your use case, the API is correct and the authentication rate is already one of the cheapest lines you will pay. ## Service messages and the 24-hour customer service window Service messages are the free lane, and they are wider than most people realize. When a WhatsApp user messages your business first, a 24-hour customer service window opens. Inside that window, non-template messages, plain text, images, replies, are free, and utility templates sent in response are free too. Meta made whatsapp service messages free for all businesses on November 1, 2024. [image: Customer support agent in a headset at a tidy desk with a face-down phone] The clock is a rolling one. Every time the customer replies, the 24-hour window resets from their newest message. A live back-and-forth can stay free indefinitely as long as each of your responses lands within 24 hours of the customer's last message. Support-led operations, help desks, two-way engagement, effectively run their WhatsApp reply volume at zero Meta cost. There is a second free lane worth naming. When a user taps a Click-to-WhatsApp ad or a WhatsApp button on a Facebook Page and you respond within the open window, a Free Entry Point conversation opens, and it covers messages across categories that would otherwise be billed. You pay for the ad, not the follow-up messages. For high-cost markets, routing marketing volume through ad-originated conversations is a meaningful lever on the Meta side. Check Meta's pricing page for the current Free Entry Point window length and exact terms before you build a plan around it. If you want to turn all of this into an actual monthly figure for your own volume mix, our [WhatsApp Business API cost calculator](https://blueticks.co/blog/whatsapp-business-api-cost-calculator) does it in five steps. ## How the four categories compare at a glance Here is the consolidated view. This is the table to screenshot and keep next to your template list, because "which category is this?" is the question that decides every WhatsApp bill in 2026. | Category | Who starts it | When you pay | Volume discount? | Typical use | |---|---|---|---|---| | Marketing | You (business-initiated) | Every delivered message | No | Promos, offers, newsletters | | Utility | You, tied to a customer action | Per message; free in open window | Yes | Order and account updates | | Authentication | You, triggered by a login event | Every delivered message | Yes | OTPs, login codes, MFA | | Service | The customer (they message first) | Never (inside 24h window) | N/A | Support replies, Q&A | The pattern that falls out of this: the more of your volume you can move into customer-initiated windows, the less you pay. Authentication and utility are the cheap paid lanes. Marketing is the expensive one with no relief valve except the ad-window path. And a big share of what small teams actually send, scheduled reminders and broadcasts to a list they already own, does not obviously fit the category the API is priced for. That last point is where a lot of businesses realize they may be paying for machinery they do not need. **Don't want a per-message bill at all?** If your use case is scheduling and broadcasting to contacts you already have, Blueticks sends from your own WhatsApp number with no per-message conversation fees and no Meta business verification. [Start free →](https://blueticks.co/signup) ## Do you actually need the API? Sending without per-message fees Not every WhatsApp send needs the Business Platform. The API exists for programmatic, verified, high-throughput messaging: transactional triggers, OTPs, chatbots, CRM-fired flows. If that is you, the per-message rates above are the cost of doing business, and the authentication and utility tiers are genuinely cheap. [image: Small business owner at a laptop with a paper calendar, planning scheduled WhatsApp broadcasts] But a large slice of "WhatsApp for business" is simpler than that. It is a scheduled reminder. A weekly broadcast to a customer list. A personalized message to 300 people from a spreadsheet. For that use case, [Blueticks](https://blueticks.co/) runs as a browser layer on top of WhatsApp Web and sends from your existing number: scheduling, recurring messages, and bulk campaigns with personalization and CSV import, with no per-conversation fee and no provider markup. Plans are a flat monthly price rather than per message, so your cost does not scale with your list the way whatsapp business api pricing per message does. Be honest about the boundary, because it is a real one. Blueticks is the right tool when *you* start the message and you are sending from your own number to people you already know. It is the wrong tool for OTPs, real-time transactional triggers, or programmatic sending at API throughput. It does not replace the API for those; it removes the API from the jobs that never needed it. If your monthly reality is "schedule these, broadcast that," the four pricing categories above are describing a bill you may be able to skip. For the full API rate landscape by region and category, our pillar guide on [WhatsApp Business API pricing in 2026](https://blueticks.co/blog/whatsapp-business-api-pricing-2026) has the market-by-market numbers. ## FAQ **What are the four WhatsApp Business Platform pricing categories in 2026?** Marketing, Utility, Authentication, and Service. Marketing covers business-initiated promotions; Utility covers transactional updates tied to a customer action; Authentication covers OTPs and login codes; Service covers replies inside the customer-initiated 24-hour window and is free. Marketing, Utility, and Authentication are billed per delivered message. **When did WhatsApp switch to per-message pricing?** July 1, 2025. Before that, Meta billed once per 24-hour conversation window regardless of how many templates you sent inside it. Under the current model each delivered template message is charged individually, with rates that vary by category and recipient country. **Are WhatsApp service messages really free?** Yes. Since November 1, 2024, service messages are free for all businesses. Inside the 24-hour window that opens when a customer messages you first, non-template replies are free, and utility templates you send in response are free too. The window resets each time the customer replies. **Which category is cheapest, and which is most expensive?** Service is free inside the customer window. Authentication and Utility are the low-cost paid lanes and both unlock volume discounts. Marketing is the most expensive category in every market and has no volume-discount path. Exact per-message rates depend on the recipient's country and appear on Meta's official pricing page. **Can I send WhatsApp messages without paying per message?** For scheduling and broadcasting from your own number to contacts you already have, yes, tools like Blueticks send through WhatsApp Web with no per-message fee. For OTPs, real-time transactional triggers, or programmatic sending, you need the Business Platform API and its per-message rates. Match the tool to the job. *Pricing structure in this article reflects Meta's published WhatsApp Business Platform pricing documentation, effective July 1, 2025 for per-message billing and November 1, 2024 for free service messages. Exact per-message rates vary by category and recipient country and change over time; verify current figures at developers.facebook.com/docs/whatsapp/pricing before building a cost model.* [^1]: Northlane Home is an illustrative example. The 40,000-contact volume is realistic for a mid-size e-commerce list; the "linear scaling" point holds at any volume because marketing messages carry no Meta volume discount. No specific per-message dollar figure is claimed here, since marketing rates vary by recipient country. --- # Do Scheduled WhatsApp Messages Send When Your Phone or Computer Is Off? (2026: What Actually Works Offline) > Your phone can be off. Your computer usually cannot. Here is which WhatsApp schedulers actually send while your devices are dark, and how to test it in three minutes. URL: https://blueticks.co/blog/scheduled-whatsapp-messages-phone-computer-off Published: 2026-07-14 Author: Daniel Roth Category: productivity You schedule a message for 7 AM, shut the laptop, and go to bed. In the morning the message is either in the chat or it isn't, and nobody tells you which until you look. Almost every guide on this topic blurs "device off" into a single condition. It is two conditions, and mixing them up is exactly why people find an unsent message waiting for them at breakfast. ## Do scheduled WhatsApp messages send when your phone or computer is off? It depends on what does the sending. Phone off is fine: WhatsApp Web and browser extensions keep sending. Computer off is not, unless the send runs on a server: the WhatsApp Business API, or Blueticks' Pro offline gateway. - **Phone off, computer on** - sends normally - **Phone off for over 14 days** - stops, WhatsApp unlinks the device - **Computer off, browser extension** - does not send - **Computer off, server-side sender** - sends normally - **Both off, no server** - nothing sends The rest of this article is about why those five lines are true, which sender puts you in which row, and how to prove it on your own account in about three minutes. If you want the mechanics of scheduling inside the browser first, that is covered in the [WhatsApp Web scheduling guide](https://blueticks.co/blog/schedule-whatsapp-web-messages). ## Two switches, not one "Device off" is really two independent switches: your phone, and the machine running the sender. WhatsApp's multi-device architecture decoupled them in 2021. Your phone is the account owner, but it is not the mail carrier. Whatever is holding the live session at send time is. That gives you a simple test to run on any tool you are considering: **Where does the code that presses Send actually run?** If the answer is "in a browser tab on your machine," your computer has to be awake. If the answer is "on someone's server," it does not. If the answer is "on your phone," then your phone has to be awake, and usually unlocked, which is a stricter requirement than most people expect. Your phone being off is almost never the blocker. Your computer being off almost always is. Everything below follows from that. [image: Powered-down smartphone face-down on a nightstand overnight while linked WhatsApp devices keep sending] ## Which senders survive which device state Six ways people actually schedule WhatsApp messages, and what each one needs to be powered on. | Sender | Works with phone off? | Works with computer off? | Who it's for | |---|---|---|---| | WhatsApp Web / Desktop, sent by hand | Yes, up to 14 days | No | Anyone at a desk | | Browser extension scheduler (Blueticks free tier) | Yes | **No** | Solo operators, daytime sends | | Android automation (Tasker, MacroDroid, SKEDit) | **No**, phone must be on and usually unlocked | Yes | Android tinkerers | | iPhone Shortcuts | **No**, phone must be on | Yes | Reminders, not real sends | | WhatsApp Business API via a provider | Yes | Yes | Approved businesses, per-message fees | | Blueticks Pro offline gateway | Yes | Yes | Operators who need overnight sends | Two rows send with everything dark. Both of them work for the same reason: the session lives on a server, not on your hardware. Everything else is running on a device you own, and a device you own can be off. If you are still choosing between categories rather than device states, the [schedule vs automate breakdown](https://blueticks.co/blog/best-tool-schedule-automate-whatsapp-messages) is the better starting point. > **Stop guessing whether your 7 AM message went out.** Blueticks is free to install and schedules straight from WhatsApp Web with no API application and no per-message fees, from your own number. When you need sends to fire with the laptop shut, switch on the Pro offline gateway. [Start free](https://blueticks.co/signup). ## Why your phone can be off (and the 14-day fine print) Your phone can be powered down, out of battery, in a drawer, or on a plane. A linked WhatsApp session keeps working. WhatsApp's Help Center is explicit that linked devices work even when your phone is not connected to the internet, and that you can link up to four companion devices to one account ([About linked devices](https://faq.whatsapp.com/378279804439436)). This is the part most articles get right and then stop. There is a limit, and it is a hard one. **If your phone goes unused for more than 14 days, WhatsApp logs out every linked device.** Not a warning, not a degraded mode. The session is gone and the QR scan has to be redone from the phone. That applies to WhatsApp Web, to WhatsApp Desktop, and to any scheduler riding on a linked session, including a hosted gateway. In practice this only bites two groups: 1. People who scan the QR from a spare phone or a second SIM they then leave in a drawer. 2. People who set up an always-on gateway from a phone they are about to replace. The fix is boring and takes 60 seconds: open WhatsApp on the phone, let it sync, and the 14-day clock resets. Put a recurring calendar reminder on it if the account matters. This is the single most common way a perfectly configured "offline" setup silently dies three weeks after you built it. ## Why your computer usually cannot be off Here is the sentence most tool comparisons will not write plainly, so I will. **The Blueticks extension needs your computer on.** Same for every other browser-extension scheduler, without exception. An extension is JavaScript running inside Chrome. It drives a live WhatsApp Web session, waits for the scheduled minute, and injects the message into the chat the way you would if you were sitting there. If Chrome is not running, that code is not running. If the laptop is asleep, suspended, hibernated, or shut down, that code is not running. What that means concretely: - **Lid closed, machine asleep:** the message does not send at its scheduled time. It sends when the machine wakes and the session reconnects, which is late, and "late" on a 9 AM client follow-up is the same as wrong. - **Machine shut down overnight:** nothing goes out until you boot it. - **Chrome quit but the machine awake:** nothing goes out. The tab is the runtime. - **Machine awake but WhatsApp Web logged out:** nothing goes out. Sleep settings are the quiet killer. A laptop set to sleep after 15 minutes of inactivity is, for scheduling purposes, a computer that is off. If you are going to run a browser-based scheduler for anything that fires outside your working hours, you need a machine that stays awake, and you need to actually verify it stays awake rather than assume the power settings do what the label says. This is also why [recurring schedules](https://blueticks.co/blog/schedule-recurring-whatsapp-messages) are where people get burned. A one-off send you can babysit. A weekly 8 AM reminder running for six months on a laptop you close every night will miss sends, and you will not notice until a client asks why they stopped hearing from you. [image: Hand closing a laptop lid in an empty office, the moment a browser extension scheduler stops running] ## Phone schedulers need the phone awake, which is worse There is a persistent belief that phone-based scheduling apps are the offline answer, because the phone is always with you and always on. The premise is wrong in a specific way. **Android automation** (Tasker, MacroDroid, SKEDit and similar) works by hooking Android's accessibility services and driving the WhatsApp app UI: open the chat, paste the text, tap the send button. The phone has to be on. The screen usually has to be on. In many configurations the device has to be unlocked, because a locked screen means the automation cannot see or tap the send button. Then Doze gets involved. Google's own documentation is unambiguous: when a device is unplugged, stationary, and the screen is off for a while, Android enters Doze mode and "defers background CPU and network activity," suspends network access, ignores wake locks, and defers `AlarmManager` alarms to the next maintenance window ([Android developer docs](https://developer.android.com/training/monitoring-device-state/doze-standby)). A phone on a nightstand at 3 AM is the exact scenario Doze was designed for. Your 7 AM automation may fire at 7:00, or at 7:11 when the next maintenance window opens, or not at all if the OEM added its own battery optimizer on top. This is why Android scheduling apps get one-star reviews that all say the same thing: "worked for a week, then started missing." **iPhone Shortcuts** is more honest about what it is. A personal automation can trigger at a time you set, open WhatsApp, and pre-fill the message. You still tap send. It is a very good reminder. It is not a scheduled send, and it certainly is not a send that happens while the phone is off. The [Android scheduling walkthrough](https://blueticks.co/blog/schedule-whatsapp-message-android) covers the setups that hold up best if you are committed to this route. But be clear-eyed about the trade: you have swapped "my computer must be on" for "my phone must be on, awake, and not being throttled by the battery optimizer." That is not an upgrade. ## The only two ways to send with everything off Both options move the send off your hardware. That is the entire trick. There is no third mechanism. ### 1. The WhatsApp Business API The WhatsApp Business API (now the Cloud API) genuinely sends server-side. Meta's infrastructure delivers the message. Your phone can be off, your computer can be off, your office can be on fire. The message goes out. If you are building anything programmatic, this is the real thing, and it is covered properly in the [WhatsApp scheduling API guide](https://blueticks.co/blog/send-schedule-whatsapp-messages-api). Now the honest cost, because the "just use the API" advice is given far too casually: - **You need approval.** A Meta developer account, a Meta app, a WhatsApp Business Account, and App Review for the permissions you request. This is not an afternoon. - **You will use a provider.** Most businesses go through a Business Solution Provider rather than integrating with Meta directly, which is another vendor, another contract, another bill. - **Templates outside the 24-hour window.** When a customer messages you, a 24-hour customer service window opens and you can reply freely. Outside that window you can only send pre-approved template messages, in the Marketing, Utility, or Authentication categories. - **You pay per message.** Meta moved from conversation-based to per-message pricing effective July 1, 2025, with rates that vary by template category and recipient country ([Meta's pricing documentation](https://developers.facebook.com/docs/whatsapp/pricing)). - **It is not your number.** This is the one that stops most people. Meta's own phone number documentation states that registered numbers "cannot be used with WhatsApp Messenger." A number already active on WhatsApp has to be deleted from WhatsApp before you can register it on the platform ([Cloud API phone numbers](https://developers.facebook.com/docs/whatsapp/cloud-api/phone-numbers)). Read that last one twice. The API is not a way to schedule messages from the WhatsApp account you already use. It is a separate business channel on a separate number. For a support desk sending order updates, that is correct and good. For a consultant who wants a follow-up to leave her own number at 8 AM tomorrow, it is the wrong tool at roughly a hundred times the setup cost. ### 2. A hosted gateway on your own number The other route keeps your existing number and moves the session onto a server. Blueticks' offline gateway is a **Pro plan** capability. You scan a QR code once from your phone's Linked Devices screen, exactly as you would for WhatsApp Web, and the session lives on Blueticks' servers instead of in your Chrome tab ([engine management guide](https://blueticks.co/guides/engine-management)). After that, your laptop is irrelevant to delivery. Close it, shut it down, drop it in a lake. Scheduled messages, recurring reminders and campaigns fire from the server. Your phone can be off too, subject to the same 14-day linked-device rule as everything else on WhatsApp. The trade-offs, stated plainly: it is a paid tier, it is bound by the 14-day rule, and it uses your personal or business number rather than a separate API channel, which means WhatsApp's normal rules about bulk and unsolicited messaging apply to you in full. It is the right answer for scheduled sends from your own number outside your working hours. It is not a bulk cold-outreach machine, and treating it as one is how numbers get banned. [image: Server racks running overnight, where a WhatsApp offline gateway sends messages with your computer off] ## Test it yourself in three minutes Do not take my word for any of this, and do not take a vendor's. Run this on your own setup before you trust a real send to it. It costs three minutes and it tells you exactly which row of the table you are actually in. 1. **Message yourself.** Open WhatsApp Web and start a chat with your own number. WhatsApp allows this and it makes a perfect test target. 2. **Schedule a message three minutes out.** Text like `offline test 07:14`. Note the exact minute. 3. **Close the laptop lid. Do not just close the tab.** Let the machine actually sleep. Walk away from it. 4. **Watch your phone.** At the scheduled minute, look at the chat on your phone. 5. **Read the result.** - Message arrived on time, laptop shut: you have a server-side sender. You are safe overnight. - Nothing arrived, and it turns up the moment you open the laptop: you have a browser-based sender. It needs the machine awake. Plan around that. - Nothing arrived at all: the session is broken. Check whether WhatsApp Web is still linked before you debug anything else. Then run the inverse. Schedule another test, leave the computer awake, and power your phone all the way off. It should arrive. If it does not, your linked session has expired and you need to re-scan. **What breaks in the real world:** power settings that "should" keep a machine awake but don't, a second WhatsApp Web tab in another browser that steals the session, a phone that has been off for over two weeks, and a company laptop with a forced overnight update policy. Each of those turns a working scheduler into a silent one. Check the send status in your [scheduler dashboard](https://blueticks.co/guides/scheduler) rather than assuming a queued message means a sent message. ## Frequently asked questions **Can you send a WhatsApp message when your phone is off?** Yes, as long as something else is holding a linked WhatsApp session: WhatsApp Web, WhatsApp Desktop, a browser extension on an awake computer, or a server-side gateway. WhatsApp's multi-device support means linked devices work without your phone connected. The exception is the 14-day rule: if your phone stays unused for over 14 days, WhatsApp logs out every linked device. **Will a scheduled message send if my laptop is asleep?** Not with a browser extension. The extension runs inside Chrome, so a sleeping machine means the send does not fire on time. It typically goes out when the machine wakes and reconnects, which is late. Only a server-side sender, the WhatsApp Business API or a hosted gateway like Blueticks Pro, sends while your computer is off. **Does the Blueticks free plan send when my computer is off?** No. The Blueticks extension needs your computer on. The free and lower paid tiers schedule from WhatsApp Web in your browser, which means the machine has to be awake at the scheduled minute. Offline sending with the computer off is the Pro plan's gateway. **Do Android apps like SKEDit or Tasker work when the phone is off?** No. They drive the WhatsApp app through Android's accessibility services, so the phone must be powered on, and usually unlocked. Android's Doze mode also defers background alarms and network access when the device is idle with the screen off, which is why these automations miss or delay overnight sends. **Is the WhatsApp Business API worth it just for scheduling?** Rarely, for an individual. It genuinely sends regardless of your devices, but it requires Meta approval, typically a provider, pre-approved templates outside the 24-hour customer service window, per-message fees, and a number that cannot also be used in the regular WhatsApp app. If you want scheduled sends from your existing number, a hosted gateway is the cheaper path. If you are building an automated product messaging system, the API is the right tool. --- # WhatsApp REST API on Your Own Number in 2026: Send & Receive Messages Without Meta Business Verification > A REST API that sends WhatsApp messages from the number you already text people from, no Meta Business verification, no per-message fees. The full curl and Python walkthrough. URL: https://blueticks.co/blog/whatsapp-rest-api-own-number Published: 2026-07-13 Author: Daniel Roth Category: productivity Every WhatsApp integration guide eventually hits the same wall: register a business, wait on Meta to verify it, get issued a phone number that isn't the one your customers already have saved in their contacts. If you just want to send a WhatsApp message from your own code today, from the number you already use, that wall is optional. This is the REST API path that skips it. ## What does "your own number" mean on a WhatsApp REST API, and why skip Meta Business verification? "Your own number" means the API sends through the WhatsApp account already on your phone, not a dedicated Meta-issued Business number. You skip business verification, template approval, and Meta's per-message billing, in exchange for running on personal-account scale rather than enterprise throughput. There are two different products people mean when they say "WhatsApp API," and mixing them up wastes a sprint. Meta's official WhatsApp Business Platform (the Cloud API) is the sanctioned route. You register a business, get it verified, and Meta issues you a dedicated phone number that becomes your sending identity, separate from any personal WhatsApp you already run. Since July 1, 2025, Meta bills that platform per message rather than per conversation, and the pricing sits on [Meta's own developer pricing page](https://developers.facebook.com/docs/whatsapp/pricing/). Outside a 24-hour customer-service window after a user last messaged you, you're limited to pre-approved templates. It's the right call at real enterprise scale, and it's also days to weeks of setup before your first send. An own-number REST API, which is what a `whatsapp automation api` like Blueticks provides, takes the other route. It drives your existing, already-active WhatsApp account (through a browser extension or a 24/7 cloud gateway) instead of Meta's Cloud API servers. No business verification, no template queue, no per-message fee, and messages arrive from a number your contacts already recognize. The honest trade: you're operating at personal-account scale, and because the transport isn't Meta's sanctioned Business Platform, [unauthorized bulk or automated messaging is a WhatsApp Terms of Service violation](https://faq.whatsapp.com/5957850900902049) if you abuse it. Pace your sends and this is a non-issue for the vast majority of real integrations; ignore it and you're gambling with a phone number. Mint your key at [dev.blueticks.co](https://dev.blueticks.co), the developer console for the rest of this walkthrough. ## How do you authenticate? What does a `bt_live_` API key actually unlock? Authentication is one bearer token in the `Authorization` header. A `bt_live_` key identifies your workspace and your connected WhatsApp number, and every `/v1` call needs it, whether you're sending a message, scheduling one, or registering a webhook. You generate the key in the developer console at [dev.blueticks.co](https://dev.blueticks.co). It's a single string, and it goes on every request the same way: ```bash curl https://api.blueticks.co/v1/chats \ -H "Authorization: Bearer bt_live_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" ``` Four things to know before you wire it into a service: 1. **The key is your identity, not a per-request password.** It authenticates as your workspace and your connected WhatsApp number, so it belongs server-side, never in a mobile app bundle or a browser script where anyone can read it. 2. **The transport underneath is your own account.** Blueticks runs on your existing WhatsApp, connected once via the browser extension or the 24/7 cloud gateway (the gateway keeps sending even when your laptop is closed), and the API key just gives your code a way to drive it. 3. **A free plan exists.** You can build and test against it without a card on file; a paid plan removes the "Powered by blueticks.co" footer and unlocks the always-on gateway mode. 4. **No Meta step in this chain at all.** There's no business verification, no app review, no waiting period between minting the key and making your first call. ## How do you send a WhatsApp message from the API? Send a `POST` to `/v1/messages/{chat_id}` with a JSON body carrying a required `type` discriminator (`text`, `media`, or `poll`) and the content for that type. This single endpoint is how you `send whatsapp message from api` for every message shape the platform supports. The `chat_id` is the recipient in WhatsApp's own addressing format: a phone number followed by `@c.us`, like `14155551234@c.us`. For a plain text message, the body is just the type and the text: ```bash curl -X POST https://api.blueticks.co/v1/messages/14155551234@c.us \ -H "Authorization: Bearer bt_live_..." \ -H "Content-Type: application/json" \ -d '{ "type": "text", "text": "Your order #1024 has shipped. Track it here: https://example.com/t/1024" }' ``` Same call in Python: ```python import requests resp = requests.post( "https://api.blueticks.co/v1/messages/14155551234@c.us", headers={"Authorization": "Bearer bt_live_..."}, json={ "type": "text", "text": "Your order #1024 has shipped. Track it here: https://example.com/t/1024", }, ) print(resp.json()) ``` One thing to know before you parse that response: every 2xx on `/v1` is wrapped in a success envelope, `{"success": true, "data": { ... }}`. The message object lives under `data`, so it is `resp.json()["data"]["id"]`, not `resp.json()["id"]`. Errors are wrapped the same way, and each one carries an `error.requestId` worth logging. `type: "media"` swaps `text` for a `mediaUrl` (plus an optional caption in `text` and a `mediaKind` like `image` or `document`); `type: "poll"` takes a `pollQuestion` and a `pollOptions` array. The discriminator is required either way, so a request without `type` fails validation before it ever reaches WhatsApp. Going from zero to a sent message is genuinely four steps: 1. Mint a `bt_live_` key at [dev.blueticks.co](https://dev.blueticks.co). 2. Connect your WhatsApp number once (extension or gateway). 3. Build the `chat_id` from the recipient's number plus `@c.us`. 4. `POST` the typed body above and read the `id` and `status` back. That's a `whatsapp api send message` workflow that runs in one HTTP call, no queue or worker of your own required for the immediate case. ## How do you schedule a WhatsApp message for later? Scheduling is a separate call: `POST /v1/scheduled-messages/{chat_id}`, with a `sendAt` timestamp instead of sending on the spot. The recipient is a path segment here too, exactly like the immediate-send endpoint. The API holds the message and dispatches it when the time comes, and it enforces a real window: at least 10 seconds in the future, no more than 365 days out. ```bash curl -X POST https://api.blueticks.co/v1/scheduled-messages/14155551234@c.us \ -H "Authorization: Bearer bt_live_..." \ -H "Content-Type: application/json" \ -H "Idempotency-Key: appt-4471-reminder" \ -d '{ "type": "text", "text": "Reminder: your appointment is tomorrow at 10:00am.", "sendAt": "2026-07-14T09:00:00+00:00" }' ``` This is the `whatsapp api python schedule` pattern in practice, computing the timestamp instead of hardcoding it: ```python from datetime import datetime, timedelta, timezone import requests send_at = (datetime.now(timezone.utc) + timedelta(hours=20)).isoformat() requests.post( "https://api.blueticks.co/v1/scheduled-messages/14155551234@c.us", headers={ "Authorization": "Bearer bt_live_...", "Idempotency-Key": "appt-4471-reminder", }, json={ "type": "text", "text": "Reminder: your appointment is tomorrow at 10:00am.", "sendAt": send_at, }, ) ``` Because a scheduled message is a real record, not a fire-and-forget timer, you can `GET /v1/scheduled-messages/{id}` to read its status and `PATCH` it while it's still pending: change the `text`, swap the media, or push the `sendAt` back. That's what makes "remind them tomorrow, an hour later if they're still quiet" a two-endpoint pattern instead of a background job you have to babysit. We went deeper on the full scheduling lifecycle, including the audience and campaign variants, in our [dedicated scheduling API guide](https://blueticks.co/blog/send-schedule-whatsapp-messages-api). [image: Paper wall calendar with a pen marking today's date, illustrating scheduling a message for later] **Get a `bt_live_` API key and send your first message in under 5 minutes.** [Sign up](https://blueticks.co/signup), grab a key from the developer console, and run the curl call from above; there's no Meta application to file and no per-message invoice waiting for you at the end of the month. ## How do you receive messages and delivery status? Sending is a push; receiving needs something listening. Register a webhook URL and Blueticks POSTs to it as events happen: message delivered, message read, message failed, and inbound replies to your number. Every delivery is signed, so you can confirm it actually came from Blueticks before you trust the payload, and failed deliveries retry rather than vanish. Registering one takes a single authenticated call: ```bash curl -X POST https://api.blueticks.co/v1/webhooks \ -H "Authorization: Bearer bt_live_..." \ -H "Content-Type: application/json" \ -d '{ "url": "https://your-server.com/hook", "events": ["new_message_received_webhook", "message.delivered", "message.failed"] }' ``` Signature verification, the exact HMAC scheme, and a full Flask/Express handler that reads inbound replies and auto-responds are covered end to end in our [webhooks and auto-reply guide](https://blueticks.co/blog/whatsapp-api-webhooks-auto-reply); this is the endpoint reference, that's the build. The short version worth knowing here: verify against the raw request body before any JSON middleware touches it, or your signature check will fail on every single delivery. [image: Small server rack with glowing status lights in a dim room, representing webhook delivery and retries] ## How do you avoid duplicate sends on retries? Pass a stable `Idempotency-Key` header on `POST /v1/scheduled-messages/{chat_id}`. If a network blip makes your client retry the same call, Blueticks recognizes the repeated key and returns the original result instead of queuing the message twice. This matters more than it sounds like it should. A timeout on your end doesn't mean the request didn't land, it just means you didn't hear back in time. Retrying blind doubles the send; retrying with the same key is safe: ```bash curl -X POST https://api.blueticks.co/v1/scheduled-messages/14155551234@c.us \ -H "Authorization: Bearer bt_live_..." \ -H "Content-Type: application/json" \ -H "Idempotency-Key: appt-4471-reminder" \ -d '{ "type": "text", "text": "See you at 3pm.", "sendAt": "2026-07-14T15:00:00+00:00" }' ``` Pick a key that's stable across retries of the *same logical send*, an order id plus a message purpose works well, and generate a new one for each genuinely new message. The semantics are strict and, usefully, loud: an identical body with the same key replays the original response, while a *different* body under a key you've already used comes back as a `409`. You can't quietly overwrite a send by recycling a key, which is exactly the failure mode you want the API to refuse. Note the shape here: the idempotency guarantee lives on the scheduled-messages endpoint, which is also the one that accepts a send-now timestamp. If exactly-once matters to your integration, and for anything triggered by a webhook or a payment event it should, route those sends through `/v1/scheduled-messages/{chat_id}` with a key rather than the immediate endpoint. ## How do you target audiences and run campaigns from the API, not just single sends? For one-to-many sends, build an audience (a named contact list) and point a campaign at it. Campaigns paced-send to every contact and substitute per-contact variables like `{firstName}`, and they can be paused, resumed, or cancelled mid-flight through their own endpoints. Creating an audience and adding contacts, in E.164 format, is two calls: ```bash curl -X POST https://api.blueticks.co/v1/audiences \ -H "Authorization: Bearer bt_live_..." \ -H "Content-Type: application/json" \ -d '{"name": "July renewal reminders"}' curl -X POST https://api.blueticks.co/v1/audiences/aud_123/contacts \ -H "Authorization: Bearer bt_live_..." \ -H "Content-Type: application/json" \ -d '{"contacts": [{"to": "+972500000000", "variables": {"firstName": "Noa"}}]}' ``` Then a campaign sends the templated message across the whole list, at a pace the platform controls rather than one you hand-roll: ```bash curl -X POST https://api.blueticks.co/v1/campaigns \ -H "Authorization: Bearer bt_live_..." \ -H "Content-Type: application/json" \ -d '{ "name": "July renewal blast", "audienceId": "aud_123", "text": "Hi {firstName}, your renewal is coming up this week." }' ``` A running campaign isn't a fire-and-forget blast either. `POST /v1/campaigns/{id}/pause`, `/resume`, and `/cancel` let you stop a send mid-flight, which is the endpoint you'll reach for the first time someone spots a typo in a message already going out to four hundred people. Two limits worth planning around, both WhatsApp's, not Blueticks': a broadcast list itself is capped at [256 recipients](https://faq.whatsapp.com/861663048350950) on the platform level, which is why campaigns are paced sends to individual chats rather than one giant group blast, and WhatsApp caps any account at [4 linked devices](https://faq.whatsapp.com/378279804439436) at once. If you're running both the browser extension and the cloud gateway against the same number for redundancy, that counts against the same limit, so check your linked-devices list before you wonder why a third integration won't connect. [image: Hands sorting blank envelopes into trays on a desk, evoking organizing audiences and campaigns] ## Can an AI agent use the API directly? Yes, through a Model Context Protocol server: `npx -y @blueticks/mcp` (Node 20+) exposes the same `/v1` backend as tools an MCP client, Claude Desktop, Claude Code, or any other MCP-compatible agent, can call directly, without you writing a REST wrapper. Anthropic open-sourced MCP as a standard for connecting AI models to external tools and data [in November 2024](https://www.anthropic.com/news/model-context-protocol), and the pattern has since become the default way agent frameworks reach outside services rather than everyone inventing their own plugin format. The Blueticks MCP server is a thin layer over the exact same audiences, campaigns, chats, and scheduled-messages endpoints covered above, so an agent that can read a chat and draft a reply can also schedule the follow-up, all through tool calls instead of you gluing an HTTP client into your agent code. One regulatory wrinkle worth flagging honestly, since it's adjacent even if it doesn't apply here: as of January 15, 2026, [WhatsApp's terms bar general-purpose AI chatbots from the official Business API](https://techcrunch.com/2025/10/18/whatssapp-changes-its-terms-to-bar-general-purpose-chatbots-from-its-platform/), the rule that pushed assistants like Perplexity's off Meta's platform. That restriction is scoped to the Business Platform specifically. It doesn't touch an own-number automation layer like Blueticks, because there's no Business API in this path to begin with, but it's a sign of how seriously WhatsApp is policing what gets built on top of it, official or not, and it's one more reason to keep any AI-driven sending on the human-paced side of the line. ## REST API vs a Python bot vs the WhatsApp Business API: which fits your build? Pick by scale and risk tolerance, not preference. A REST API on your own number is fastest to a working send and cheapest per message; a self-hosted Python bot gives you the most local control at the cost of running your own process; the official Business API is the only zero-ban-risk path and the slowest to stand up. | | Blueticks REST API | Self-hosted Python bot | WhatsApp Business API (Meta) | |---|---|---|---| | Sending number | Your own, already active | Your own, already active | Dedicated Meta-issued number | | Meta business verification | Not required | Not required | Required | | Setup time | Minutes | Hours to a day (bridge, QR pairing, hosting) | Days to weeks | | Who runs the process | Blueticks' managed engine | You, on your own server | Meta's infrastructure | | Pricing model | Flat plan, free tier available | Free, but you host it | Per message, [tiered by verification level](https://developers.facebook.com/docs/whatsapp/messaging-limits/) | | Message volume ceiling | Personal-account scale | Personal-account scale | 250 new conversations/day, rising to 2,000, 10,000, 100,000, then unlimited as you verify | | Ban / ToS risk | Real if you cold-bulk-blast; low for paced, expected sends | Same, and it's entirely on you to self-manage | None, when used within Meta's rules | A backend engineer who migrated a reminder bot off a homemade cron worker put the trade-off to us bluntly: "I didn't need Meta's throughput, I needed one POST that fires on a timestamp. The verification queue was the actual bottleneck, not the message volume." (A composite of operator conversations, not a named source.) That's the shape of workload this API targets: transactional and mid-volume sending where the own-number identity and the skip-Meta setup matter more than a six-figure daily ceiling. If you'd rather run your own process end to end, with full control over the WhatsApp connection and no managed layer in between, our [Python bot build walkthrough](https://blueticks.co/blog/build-whatsapp-bot-python) covers that path from a bare connection up. If you're past personal-account scale entirely, sending to genuine enterprise volume with a verified business identity, [Meta's pricing documentation](https://developers.facebook.com/docs/whatsapp/pricing/) is where you start instead. ## FAQ ### Do I need to verify a business with Meta to use this WhatsApp REST API? No. That's the entire point of an own-number transport. You authenticate with a `bt_live_` key tied to your WhatsApp account, not a Meta Business Manager verification, so there's no application, no review queue, and no waiting period before your first send. ### How do I send a WhatsApp message from the API in one call? `POST /v1/messages/{chat_id}` with a `type` discriminator (`text`, `media`, or `poll`) and the content for that type, authenticated with your `bt_live_` key in the `Authorization` header. For text, the body is just `{"type": "text", "text": "..."}`. ### Can I schedule a WhatsApp message from Python? Yes, `POST /v1/scheduled-messages/{chat_id}` with a `sendAt` RFC 3339 timestamp carrying an explicit `Z` or UTC offset, computed however you like in Python (`datetime.now(timezone.utc) + timedelta(...)`). The recipient goes in the path, not the body. The window is at least 10 seconds out and up to 365 days ahead, and you can `PATCH` the message (text, media, or `sendAt`) any time before it fires. ### Will sending through this API get my WhatsApp number banned? It can, if you send unsolicited bulk volume to people who never opted in; unauthorized bulk or automated messaging violates WhatsApp's Terms of Service regardless of which tool sends it. Paced, expected sends to people who know you carry low practical risk. Nobody, including us, can promise zero risk on an own-number transport, and pretending otherwise would be dishonest. ### What's the difference between this and the official WhatsApp Business API? This runs on your own already-active WhatsApp number, with no Meta business verification, no template approval, and no per-message fee. The official Business API issues you a separate dedicated number, requires verification, and bills per message on a tiered volume ladder. Pick the official API when you need Meta's compliance guarantees and enterprise throughput; pick this when you want a working send today from the number your contacts already have. ### Can an AI agent send WhatsApp messages through this API without custom code? Yes, via the MCP server (`npx -y @blueticks/mcp`, Node 20+), which exposes the same send, schedule, audience, and webhook endpoints as callable tools for any MCP-compatible AI client. --- # WhatsApp Business App Limitations in 2026: The 7 Ceilings You Will Hit (and Which Upgrade Path Actually Fits) > The free app is great until it isn't. Here are the 7 ceilings you'll hit in 2026, which ones the API actually fixes, and which you can lift without migrating. URL: https://blueticks.co/blog/whatsapp-business-app-limitations Published: 2026-07-12 Author: Avi Kohen Category: industry The WhatsApp Business app is genuinely good software, right up to the moment your business grows past what it was designed for. The frustrating part is that it fails quietly: no error message tells you why your broadcast reached half your list, or why there's no schedule button. This is the map of where the app actually stops in 2026, ceiling by ceiling, so you can pick the right fix instead of the loudest one. ## What are the WhatsApp Business app's limitations in 2026? The 7 ceilings at a glance In 2026 the WhatsApp Business app caps broadcasts at 256 saved contacts, allows four linked devices, and offers no scheduling, no automated follow-ups, no shared team inbox, no bulk personalization, and no campaign analytics. Here are the seven ceilings in one scan: - **Broadcast reach** - 256 saved contacts per list - **Devices and agents** - one phone plus four linked devices - **Scheduling** - none, no send-later exists - **Follow-up automation** - reactive only, nothing sequenced - **Team inbox** - no assignment, no chat ownership - **Personalization** - no variables in bulk sends - **Analytics** - no delivery or reply reporting None of these are secrets. The broadcast and device numbers come straight from the [WhatsApp Help Center](https://faq.whatsapp.com/861663048350950), and the app's feature set is documented by Meta itself, which positions the app for small businesses and the [WhatsApp Business Platform](https://developers.facebook.com/docs/whatsapp/pricing/) for everyone bigger. What the documentation does not tell you is which ceiling you personally will hit first, and whether the fix is the API or something much lighter. That is what the rest of this piece sorts out. If you want the full head-to-head between the two Meta products before diving into specific whatsapp business app limits, our [WhatsApp Business App vs API comparison](https://blueticks.co/blog/whatsapp-business-app-vs-api) covers it end to end. One framing note before we go ceiling by ceiling: these limits are deliberate. Meta sells the API. The free app staying small is not an oversight, it is segmentation. ## Ceilings 1 and 2: how broadcast and device limits cap your reach Broadcast lists reach at most 256 contacts who have saved your number, and one account runs on one phone plus four linked devices. Together those two limits define the app's hard ceiling on both audience size and staffing. **Ceiling 1: broadcast reach.** Per the WhatsApp Help Center, a broadcast list holds a maximum of 256 contacts and delivers only to people who have [saved your number in their address book](https://faq.whatsapp.com/861663048350950), and we've broken down exactly what that means in practice, list splitting, the saved-contact trap, and the workarounds, in our [WhatsApp broadcast limit guide](https://blueticks.co/blog/whatsapp-broadcast-limit). The one-sentence version: your "sent" broadcast quietly skips everyone who never saved you, and the app will not tell you who that was. **Ceiling 2: devices and hands.** WhatsApp allows [up to four linked devices](https://faq.whatsapp.com/378279804439436) alongside your primary phone. That sounds like a team feature, and for two or three people it almost is. But linked devices were built for one person on multiple screens, not for multiple people on one number. There are no roles, no permissions, and no way to see who replied. And if the primary phone stays offline for over 14 days, every linked device disconnects, which is a fun thing to discover when the phone in question lives in a drawer at your first location. As one salon-chain manager described it to me (a composite of operator conversations, not a named source): "Three of us answered the same number from linked devices. Twice in one week a customer got two different prices within the hour, from two different colleagues, in the same chat." That is the reach-and-hands wall. Everything else is software the app simply does not have. [image: Two coworkers handing a single smartphone across a reception desk, sharing one business number] ## Ceilings 3 and 4: why the app can't schedule messages or automate follow-ups The WhatsApp Business app has no scheduler and no follow-up automation. Greeting and away messages fire only when a customer writes first, and quick replies need a human tap. Nothing sends later, repeats weekly, or sequences on its own. **Ceiling 3: no scheduling.** There is no send-later button anywhere in the app, and there never has been. Appointment reminders, Monday-morning price lists, renewal nudges timed to a date: all of it means you, personally, remembering to type at the right moment. If you have searched the app's menus for a schedule option, stop; the walkthrough of what actually works is in [how to schedule WhatsApp messages](/blog/schedule-whatsapp-messages). **Ceiling 4: no follow-up engine.** The app's three automations are all reactive. The greeting message fires when a customer messages you first, the away message fires outside hours you set, and [quick replies](https://faq.whatsapp.com/1791149784551042), capped at 50 per account, are canned snippets a human sends by hand. What none of them can do: notice that a lead did not reply in three days and send the follow-up for you. Why this ceiling costs real money: the classic [Lead Response Management study](https://www.leadresponsemanagement.org/lrm_study) conducted with MIT found the odds of qualifying a lead are 21 times higher when you make contact within five minutes versus waiting thirty. Follow-up speed and consistency are not a nice-to-have, they are most of the game. An app where every follow-up depends on human memory guarantees you drop some. [image: Paper wall calendar covered in sticky note reminders next to a face-down phone, manual follow-up scheduling] ## Ceilings 5, 6, and 7: where team inbox, personalization, and analytics break down The app has no shared inbox with chat assignment, no variables for personalizing bulk sends, and no reporting beyond read receipts and basic counts. Past two or three staff, or a few hundred contacts, all three fail at once. **Ceiling 5: team inbox.** This is Ceiling 2's uglier sibling. Even inside the four-device limit, there is no concept of "this chat belongs to Dana." No assignment, no internal notes, no away-status per agent. Labels exist, and they help one person stay organized, but they are manual, and nothing stops two people from answering the same customer differently. **Ceiling 6: personalization at scale.** Broadcast lists send the identical message to everyone. Quick replies have no merge fields. If you want "Hi Maria, your order is ready" times two hundred, the app's answer is two hundred manual edits. Personalized outreach at list scale simply is not a feature. **Ceiling 7: analytics.** You get read receipts per chat and little else. There is no campaign view: no "sent 180, delivered 176, replied 34" for last Tuesday's promotion, no way to compare this week's offer against last week's. You cannot improve what you cannot measure, and the app measures almost nothing. What campaign-level tracking should look like is covered in our [WhatsApp campaign management guide](/blog/whatsapp-campaign-management). Notice the pattern across ceilings 3 through 7: none of them are WhatsApp network policies. They are missing software features. That distinction decides which upgrade path you actually need, and it is the most misunderstood part of every whatsapp business solution comparison. ## Which limitations does the WhatsApp Business API actually solve, and at what cost? The API removes the broadcast cap, adds true multi-agent access and programmatic automation, and scales to unlimited daily contacts. In exchange you accept template approval, per-message billing since July 1, 2025, and a ramp starting at 250 contacts a day. Credit where due: the API genuinely demolishes ceilings 1, 2, 5, 6, and 7. Messaging is programmatic, so any number of agents can share a number through a solution provider's inbox, sends are personalized by code, and delivery data comes back as events you can count. Now the cost side, from Meta's own documentation: - **Per-message billing.** Per [Meta's pricing docs](https://developers.facebook.com/docs/whatsapp/pricing/), the Platform moved to per-message pricing effective July 1, 2025. Every delivered marketing template is charged, priced by category and recipient country. Utility and authentication templates earn volume discounts; marketing templates never do. Replies inside the 24-hour customer service window are free, and a 72-hour free window opens from click-to-WhatsApp ads. - **A ramp, not a floodgate.** Per Meta's [messaging limits documentation](https://developers.facebook.com/docs/whatsapp/messaging-limits/), a new business starts at 250 unique contacts per 24 hours. You reach 2,000 via business verification (or by delivering 2,000 quality messages in 30 days), then scale automatically through 10,000 and 100,000 to unlimited, provided quality stays high and you use at least half your current limit. There is no 1,000 tier, whatever recycled 2023 blog posts claim. - **Templates and approval.** Business-initiated messages use templates Meta reviews before you can send them. Your Tuesday promo now has a review step. - **A policy perimeter that moved in 2026.** As of January 15, 2026, Meta's updated terms [bar general-purpose AI chatbots](https://techcrunch.com/2025/10/18/whatssapp-changes-its-terms-to-bar-general-purpose-chatbots-from-its-platform/) from the Business Solution entirely. Customer-service AI is fine; AI as the product is not. If your API plans leaned on that, they need rereading. Notably absent from the API's gift list: scheduling and drip sequences. The API is a pipe. Timing logic is something you build, or rent from a solution provider on a monthly plan. So the honest answer on when to use whatsapp business api is: when you are sending thousands of system-triggered messages against a real backend, running a genuine chatbot, or staffing a many-agent support line. Whether that spend pays back at your volume is a separate question, and we ran those numbers in [Is the WhatsApp Business API worth it?](https://blueticks.co/blog/is-whatsapp-business-api-worth-it). ## Which ceilings can you lift without migrating to the API? Four of the seven ceilings, scheduling, follow-up automation, personalization, and analytics, are missing software rather than WhatsApp policy. A tool like Blueticks adds that software on top of your existing WhatsApp Business number, with no API migration and no per-message fees. This is the tier most comparison articles skip. [Blueticks](https://blueticks.co/blog/whatsapp-business-app-vs-api) runs on the number you already use, through a browser extension alongside WhatsApp Web or a 24/7 cloud gateway that keeps sending when your computer is off. No Meta application, no business verification, no templates, no metered billing. Against the seven ceilings: - **Ceiling 3, scheduling: lifted.** One-time and recurring sends, scheduled anywhere from ten seconds to a full year ahead, per the [Blueticks feature docs](https://blueticks.co/). - **Ceiling 4, follow-ups: lifted.** Drip campaigns send timed sequences and stop automatically when a contact replies, so nobody gets step three after they already answered step two. - **Ceiling 6, personalization: lifted.** Campaigns run off audiences with per-contact variables, so \{firstName\} actually resolves to Maria. - **Ceiling 7, analytics: lifted.** Campaign dashboards track sends and replies per campaign, the exact reporting the app never had. (There is also a developer API and MCP server at dev.blueticks.co if you want the data programmatically.) - **Ceiling 1, broadcast reach: partially lifted.** Campaigns to your saved audiences at human scale, without building 256-contact lists by hand. What it is not: a mass-blast tool, and anyone promising unlimited cold sends from a free app number is selling you a ban. - **Ceilings 2 and 5, devices and team inbox: honestly, no.** The four-device limit and the absence of a true multi-agent contact center are WhatsApp architecture. If those are your binding constraint, that is a real API case. **Hit a ceiling in the list? Lift scheduling, campaigns, and analytics on your existing WhatsApp Business number. [Install Blueticks free](https://blueticks.co/signup), no API migration, and your first scheduled message can go out today.** ## Which WhatsApp business solution fits you? A decision table by ceiling Match the solution to the ceiling you actually hit. Reactive replies only: keep the free app. Scheduling, campaigns, personalization, analytics: add Blueticks to your number. Thousands of system-triggered messages, a chatbot, or ten agents: that is API territory. Here is the whole whatsapp business app upgrade decision, ceiling by ceiling: | Ceiling you hit | Free app alone | Blueticks on your number | WhatsApp Business API | |---|---|---|---| | 1. Broadcast reach past 256 | No | Human-scale campaigns to audiences | Yes, opt-in, tier-gated | | 2. More than 4 devices | No | No (WhatsApp limit) | Yes, agents via BSP | | 3. Scheduled messages | No | Yes, one-time + recurring | Only if you build it | | 4. Automated follow-ups | No | Yes, drip with stop-on-reply | Yes, via code/BSP | | 5. Team inbox with assignment | No | No (WhatsApp limit) | Yes, via BSP inbox | | 6. Per-contact personalization | No | Yes, audience variables | Yes, via templates | | 7. Campaign analytics | No | Yes, sends + replies | Yes, via events/BSP | | Monthly cost shape | Free | Flat subscription, free plan exists | Per delivered template + BSP fee | | Setup time | Minutes | Minutes | Days to weeks | Read your own row honestly. If your blockers live in rows 3, 4, 6, and 7, which is where most small and mid-size senders live, migrating to the API buys you template approval and metered billing to solve problems a browser extension solves this afternoon. If rows 2 and 5 are what is breaking, or you are wiring order systems into WhatsApp at thousands of messages a day, skip the middle tier and start the [API readiness checklist](/blog/do-i-need-whatsapp-business-api). The wrong answer is the expensive one in either direction. [image: Business owner comparing two printed proposal folders side by side at a desk, choosing an upgrade path] ## FAQ ### What are the biggest WhatsApp Business app limitations in 2026? Seven ceilings: broadcasts capped at 256 saved contacts, a four-linked-device limit, no message scheduling, no automated follow-ups, no team inbox with chat assignment, no personalization variables in bulk sends, and no campaign analytics. The first two are WhatsApp policy; the other five are missing software. ### How many devices can use one WhatsApp Business account? One primary phone plus up to four linked devices, per the WhatsApp Help Center. Linked devices have no roles or chat assignment, and they disconnect if the primary phone stays offline for more than 14 days. For a true multi-agent setup on one number, you need the API through a solution provider. ### Can the WhatsApp Business app schedule messages? No. The app has no send-later feature at all. Its automations (greeting message, away message, quick replies) are reactive and fire only around incoming messages. Scheduling requires either custom code on the API or a tool like Blueticks that adds a scheduler to your existing number. ### When should I upgrade from the WhatsApp Business app to the API? When you send thousands of system-triggered messages a day against a real backend, run a chatbot, or need many agents on one number. Budget for per-message billing (in effect since July 1, 2025), template approval, and a messaging ramp that starts at 250 unique contacts per day. ### Can I fix WhatsApp Business app limits without the API? Mostly, yes. Scheduling, drip follow-ups, personalized campaigns, and analytics are software gaps, and Blueticks adds all four on top of your existing number with no Meta application and no per-message fees. The two limits no overlay can remove are the four-device cap and the lack of a native multi-agent inbox. --- # Best WhatsApp Drip Campaign & Sequence Tools in 2026: How to Pick One for Lead Nurturing and Automated Follow-Ups > Shopping for a WhatsApp drip campaign tool? Here are the 7 criteria that matter, real 2026 pricing for the main contenders, and the stop-on-reply rule most tools fail. URL: https://blueticks.co/blog/best-whatsapp-drip-campaign-tools Published: 2026-07-11 Author: Maya Cohen Category: marketing You have leads going quiet after one message and no system chasing them. You know a timed sequence would fix it, so you started shopping, and every tool calls itself "WhatsApp automation" while hiding whether it can actually fire message 2 two days after message 1, stop when someone replies, and tell you what it costs after Meta's fees. This is the buyer's guide: what a real drip tool does, the seven criteria that separate contenders, verified 2026 pricing, and where each model breaks. ## What Is a WhatsApp Drip Campaign Tool, and How Is It Different From a Broadcast or Scheduling App? A WhatsApp drip campaign tool sends each contact a timed series of messages automatically, with delays and exit rules between steps. A broadcast app sends one message to many people once. A scheduler sends one message later. The three get conflated constantly, and buying the wrong one is expensive. A scheduler solves "send this Thursday at 10am." A broadcast platform solves "send this to 2,000 people as individual chats." A drip campaign tool solves a different job: "when a lead enters this audience, send touch 1 now, touch 2 at 48 hours, touch 3 on day 5, and stop the moment they answer." The unit of work is the sequence per contact, not the send. Here is the practical split: | | Scheduling app | Broadcast platform | Drip campaign tool | | --- | --- | --- | --- | | Unit of work | One message, later | One message, many people | Many messages per contact, over time | | Trigger | A date | You hit send | Entering an audience or sequence | | Exit logic | None | None | Stops on reply or conversion | | Job | Timing | Reach | Nurturing and follow-up | If your actual job is one-to-many campaign sends, this is not your article: our [buyer's guide to WhatsApp broadcast platforms](https://blueticks.co/blog/how-to-choose-whatsapp-broadcast-platform) covers that. And if you want the craft of designing the sequence itself, message counts, spacing, triggers, start with [how to build a WhatsApp drip sequence that converts](https://blueticks.co/blog/whatsapp-drip-sequence). This piece is about picking the tool that runs it. ## What Should You Look For in a WhatsApp Sequence Tool? 7 Buying Criteria Judge a WhatsApp sequence tool on seven criteria: true multi-step sequencing, stop-on-reply exits, delivery model, personalization variables, audience management, per-step reply tracking, and total cost including Meta fees. A tool missing stop-on-reply will message people who already answered. [image: Business owner working through a printed buying checklist for a WhatsApp sequence tool] **1. True multi-step sequencing.** Not a greeting message, not a keyword auto-reply. The test question for any vendor: "Can it send message 2 to a contact 48 hours after message 1 with no human action and no inbound trigger?" Plenty of "automation" tools fail exactly this. **2. Stop-on-reply.** The moment a contact replies, the rest of the sequence should cancel for them. Without it, a lead who booked a call on touch 2 still gets the "still interested?" nudge on touch 4. That single awkward message reads as spam, earns blocks, and undoes the trust the sequence built. **3. Delivery model: own number vs Business API.** This decides your cost structure and your ceiling. It gets its own section below. **4. Personalization variables.** A whatsapp automated follow up that opens with "Hi \{firstName\}" outperforms "Dear customer" because it reads like the one-to-one channel WhatsApp is. Per-contact variables should come from your audience fields, not manual editing. **5. Audience management.** Sequences run against lists. You need to import contacts, attach fields, and suppress people who converted or opted out. If the tool treats contacts as a flat CSV with no fields, personalization and exit rules die with it. **6. Per-step reply tracking.** Sequence tuning is finding the step where people go quiet. A tool that reports only "campaign sent" cannot tell you touch 3 is dead weight. **7. Total cost, including Meta's meter.** API-based tools carry per-message fees on top of the subscription. More on the math in the pricing section. Speed of follow-up is why all of this matters: the [Lead Response Management study](https://www.leadresponsemanagement.org/lrm_study) found reps were 21 times more likely to qualify a lead when responding within five minutes instead of thirty. A sequence is how you respond in minutes at 2am. Our [automated follow-up sequence guide](https://blueticks.co/blog/whatsapp-automated-follow-up-sequence) has five ready templates once your tool is picked. ## Which Are the Best WhatsApp Drip Campaign Tools in 2026? (Compared) Blueticks, Wati, AiSensy, Interakt, and Zoko all run automated WhatsApp sequences in 2026. Blueticks sequences from your own number with stop-on-reply and a free plan; the other four ride the Business API with Meta's per-message fees added. Pricing below is from each vendor's own published pricing as of July 2026. | Tool | Sends from | Entry price | Where sequencing lives | Meta per-message fees | | --- | --- | --- | --- | --- | | Blueticks | Your own number (extension or 24/7 cloud gateway) | Free plan | Drip campaigns: per-step delays, stop-on-reply | None | | Wati | Business API | $59/mo billed annually ($69 monthly) | Automation flows, metered at 1,000 triggers/mo on Growth | Yes | | AiSensy | Business API | ₹1,500/mo + GST (about $18) | Chatbot flows sold as a ₹2,500/mo add-on | Yes | | Interakt | Business API | $55/mo Growth | Branching chatbot flows on Advanced ($69/mo) | Yes | | Zoko | Business API | $49.99/mo | Flows: 11 templates included, $5.99/mo per custom flow | Yes | The honest read on each: **Wati** is the mature all-rounder of the API camp: shared team inbox, broad integrations, a no-code flow builder. The catch is metering. Its Growth plan caps automation at 1,000 triggers and 15,000 broadcast messages a month, so a multi-step flow across a few hundred leads pushes you toward the Pro tier ($119/month billed annually, $149 month-to-month) fast. **AiSensy** is the volume-price play, with unlimited users on every plan and the cheapest credible API entry point. But multi-step flow building is an add-on that costs more than the base subscription, so the real monthly floor for sequencing is roughly ₹4,000 before Meta's fees. **Interakt** is the budget pick if you also run Instagram DMs, since both channels share one inbox. Branching flows need the $69/month Advanced plan. **Zoko** is built for Shopify stores: order events, catalogs, and a flows library tuned to ecommerce. Custom flows are metered per flow, which is fine for three flows and annoying for fifteen. **Blueticks** takes the other road entirely. It drives your existing WhatsApp number through a browser extension or a 24/7 cloud gateway, so there is no Meta approval, no template queue, and no per-message fee. Drip campaigns run as multi-step sequences over real campaigns with per-step delays, audiences with per-contact variables like \{firstName\}, and stop-on-reply built in. There is also a developer API and MCP server at dev.blueticks.co if you want sequences wired into your own stack. The honest limit: you are at personal-account scale, not enterprise API throughput. If you send hundreds of thousands of templated messages a month, you want the API camp. For everyone below that ceiling, the math favors flat pricing. Build your first WhatsApp drip sequence free: [install Blueticks and set up stop-on-reply follow-ups in minutes](https://blueticks.co/signup), with no per-message fees and no API onboarding queue. ## How Do API-Based Sequence Platforms Compare to WhatsApp Web-Based Tools? API-based platforms bill Meta's per-message fees on top of subscription, require template approval, and start new senders at 250 contacts per day. WhatsApp Web-based tools send free-form from your own number with no per-message fees, at personal-account scale. [image: Two printed vendor proposals compared side by side on a desk during platform evaluation] Three API mechanics matter for drip campaigns specifically. **The meter runs per message.** Since July 1, 2025, Meta bills the Business Platform [per delivered message rather than per conversation](https://developers.facebook.com/docs/whatsapp/pricing/), and marketing templates are always charged. A four-touch nurture sequence is four billable marketing messages per lead, unless the contact replies and pulls you into the free 24-hour service window. **You start small and earn scale.** Per [Meta's messaging limits documentation](https://developers.facebook.com/docs/whatsapp/messaging-limits/), a new business portfolio can message 250 unique contacts per 24 hours. Business verification (or 2,000 delivered high-quality messages in 30 days) lifts you to 2,000, and from there tiers climb 10,000, then 100,000, then unlimited, with upgrades evaluated automatically. There is no 1,000 tier, whatever an outdated blog post told you. Day one on the API, your drip tool can nurture 250 people, total. **Templates gate cold touches.** Any sequence step landing outside a 24-hour service window must be a pre-approved template. Your touch 3 copy goes through Meta review before it can ever send. One more 2026 wrinkle: Meta barred general-purpose AI chatbots from the Business API [effective January 15, 2026, per TechCrunch](https://techcrunch.com/2025/10/18/whatssapp-changes-its-terms-to-bar-general-purpose-chatbots-from-its-platform/). Structured business bots for nurture, support, and bookings remain fine, so drip tools are unaffected, but if your plan included an open-ended AI assistant on the API, it is off the table. Web-based tools like Blueticks skip all three: free-form copy, no approval queue, no meter, from the number your customers already have saved. The trade is throughput. Pick the API when volume genuinely demands it; pick own-number when you want flat costs and a same-day start. ## How Do You Set Up a Lead-Nurturing Drip Sequence Step by Step? Set up a lead-nurturing drip in six steps: confirm opt-in, build the audience, map three to four timed touches, write one-action messages, switch on stop-on-reply, then track replies per step. The build takes under an hour. [image: Hands sketching a lead nurturing drip sequence timeline on paper at a desk] 1. **Confirm opt-in.** Every contact entering a whatsapp lead nurturing sequence needs recorded consent naming WhatsApp as the channel. Skipping this is how numbers get banned, not a growth hack. 2. **Build the audience with fields.** Import your leads with at least first name and one segmenting field (source, product interest). These power your variables later. 3. **Map the touches before writing.** A proven spine for a whatsapp nurture sequence: touch 1 immediately, touch 2 at 48 hours, touch 3 on day 5, optional touch 4 on day 9. Three to five messages total. More is block-bait. 4. **Write each message to one action.** Touch 1 introduces and asks the qualifying question. Touch 2 handles the obvious objection. Touch 3 makes the direct ask. "Hi \{firstName\}" beats "Hello" every time it runs. 5. **Set delays and turn on stop-on-reply.** In Blueticks, each step's delay is a number plus a unit, from minutes up to years, and a reply removes the contact from every remaining step automatically. 6. **Read replies per step, weekly.** Cut the step nobody answers. If your sequence is date-driven rather than lead-driven (renewals, payment nudges), the recurring pattern in our [follow-up reminder automation guide](https://blueticks.co/blog/whatsapp-follow-up-reminder-automation) fits better than a drip. ## What Most Drip Tools Can't Do: Clean Stop-on-Reply Exits and Real Follow-Up Logic Most WhatsApp drip tools keep sending after a contact replies, gate sequencing behind metered chatbot flows, or both. Blueticks removes a contact from the remaining steps the moment they reply, so a human conversation never competes with an automation. The gap shows up in three places. First, exits: in flow-builder tools, "stop on reply" only works if the builder wired a reply-branch into every step; miss one and the sequence barrels on. Second, metering: when sequencing lives in a chatbot add-on billed per trigger or per flow, every lead you nurture has a marginal cost, which quietly discourages the follow-ups that convert. Third, the handoff: once a rep is talking to the lead, automation must stay out of that thread. Here is what that looks like in practice. Velora Studio, a synthetic-but-representative fitness studio, ran 300 trial signups a month through a single manual follow-up. About 5% booked an assessment, and the team openly admitted most leads never got a second touch. They rebuilt it as a four-touch automated whatsapp messages sequence with stop-on-reply: day 0 welcome with a question, day 2 schedule link, day 5 social proof, day 9 direct ask. Bookings rose to 12% of signups, replies spread across all four steps, and, the part the owner cared about, zero already-booked members received a chase message. "Once stop-on-reply was on, the awkward messages stopped," the owner said. "Nobody who had booked got a 'still interested?' nudge, and our block rate stayed flat while volume tripled." (Synthetic operator quote, representative of the pattern.) That is the whole argument for buying a sequence-first tool instead of bending a chatbot builder into one: the exit logic is the product, not a branch you have to remember. The [follow-up sequence templates](https://blueticks.co/blog/whatsapp-automated-follow-up-sequence) plug straight into this structure. ## How Much Does a WhatsApp Drip Campaign Tool Cost in 2026? Expect $0 to $139.99 per month in platform fees at typical small-business scale, plus Meta's per-message charges on every API-based tool. Own-number tools like Blueticks charge flat subscriptions, start free, and add no per-message fees. [image: Small business owner calculating monthly WhatsApp drip campaign tool costs with printed invoices] The subscription is the visible half. Verified vendor pricing as of July 2026: Zoko starts at $49.99/month, Interakt at $55, Wati at $59 billed annually, AiSensy at ₹1,500 plus its ₹2,500 flows add-on, and Zoko's Elite tier, the one most growing stores land on, runs $139.99. The meter is the half that surprises people. Take a concrete nurture: 2,000 new leads a month through a four-touch sequence on the API is 8,000 marketing template sends. At the ₹1.09 per marketing message India rate AiSensy's own rate card lists under Meta's January 1, 2026 pricing, that is roughly ₹8,720, about $100, in Meta fees alone, every month, on top of the subscription. Rates vary sharply by country, and marketing is the priciest category; our [WhatsApp Business API pricing breakdown](https://blueticks.co/blog/whatsapp-business-api-pricing-2026) runs the per-country detail. The flat model removes that line entirely. Blueticks has a free plan to build your first sequence, and paid plans price the platform, not the message. For a business nurturing hundreds to a few thousand leads a month from its own number, the delta between "flat subscription" and "subscription plus $100 and up of metered sends" decides the tooling question on unit economics alone. ## FAQ ### What is the best WhatsApp drip campaign tool in 2026? It depends on your delivery model. For sequences from your own WhatsApp number with stop-on-reply, no Meta approval, and no per-message fees, Blueticks is the strongest pick and starts free. On the Business API, Wati is the mature all-rounder, Zoko fits Shopify stores, and AiSensy and Interakt compete on entry price. ### Can I run a WhatsApp drip campaign without the Business API? Yes. Tools that drive your existing WhatsApp account, through a browser extension or a cloud gateway, run multi-step sequences without API onboarding, business verification, or template approval. You trade enterprise throughput for flat costs, free-form copy, and a same-day start, which is the right trade below tens of thousands of sends a month. ### Does the WhatsApp Business app have a built-in drip campaign feature? No. The free app offers a greeting message, an away message, and quick replies, but nothing that sends message 2 two days after message 1 automatically. Native broadcast lists cap at 256 saved contacts and have no sequencing. Real drips need the API plus a platform, or an own-number sequence tool. ### How many messages should an automated WhatsApp messages sequence have? Three to five, spaced over five to fourteen days, with gaps widening as the sequence progresses. A lead-nurture spine of day 0, day 2, day 5, and day 9 covers most cases. Longer drips earn blocks, and on the API each extra marketing touch is also a billable message. ### What does stop-on-reply mean in a WhatsApp nurture sequence? It means a contact who replies is automatically removed from every remaining step of the sequence. The conversation moves to a human, and no follow-up fires into an active thread. It protects reply rates and block rates, and it is the first capability to verify in any whatsapp sequence tool demo. ### How much does a WhatsApp drip campaign tool cost per month? Platform fees run from free (Blueticks) through roughly $18 to $139.99 for the main API-based tools at small-business tiers. API tools then add Meta's per-message charges, billed per delivered message since July 1, 2025, with marketing templates the most expensive category. Own-number tools add no per-message fees. *Notes: vendor prices are from each vendor's published pricing pages as of July 2026 and can change; currency conversions are approximate. Velora Studio is a synthetic example and its figures are illustrative of the pattern, not a guarantee. Platform-rule claims (per-message billing, messaging tiers, the January 15, 2026 chatbot policy) trace to Meta's WhatsApp Business Platform documentation and TechCrunch.* --- # WhatsApp AI Agent in 2026: Build vs Buy (MCP, API & No-Code Ways to Put an AI Agent on WhatsApp) > Four real ways to put an AI agent on WhatsApp in 2026, and one door Meta just closed. Cost, setup time, approval, and ban risk compared so you pick once. URL: https://blueticks.co/blog/whatsapp-ai-agent Published: 2026-07-10 Author: Daniel Roth Category: productivity There are four working ways to put an AI agent on WhatsApp in 2026, and they are not interchangeable. One takes weeks of engineering and Meta's sign-off. One is a ten-minute config change. And the route most teams assume is the obvious one, pointing a general-purpose assistant at the official API, is the exact door Meta closed on January 15, 2026. Pick wrong and you either rebuild next quarter or burn a phone number. I have set up three of the four routes myself and watched teams hit the failure modes on all of them. This guide maps the options honestly so you choose once. ## What is a WhatsApp AI agent (and what can it actually do in 2026)? A WhatsApp AI agent is an AI model, usually an LLM such as Claude, connected to WhatsApp so it can read chats, draft and send replies, schedule messages, and run campaigns from plain-English instructions instead of scripts and menus. That definition hides a fork, and the fork decides everything downstream. There are two different products people call a "WhatsApp AI agent": 1. **A customer-facing bot.** It sits on a business number and answers inbound messages from your customers. Order status, booking changes, FAQ deflection. This is the official-API world. 2. **An operator agent that works for you.** It reads your own inbox, triages the forty threads down to the three that matter, drafts replies in your voice, chases silent leads, and schedules the Friday follow-up. This is the [WhatsApp MCP](https://blueticks.co/blog/whatsapp-mcp) world, where you control WhatsApp with AI rather than putting AI in front of your customers. Most people searching for this in 2026 actually want the second kind, and it is the one Meta's rules barely address, because the agent acts as you on your own account. (WhatsApp does ship its own built-in assistant, Meta AI, but per the [WhatsApp Help Center](https://faq.whatsapp.com/2257017191175152) it is Meta's assistant inside the consumer app. You cannot hand it your lead list or your playbook, so it is not a route on this map.) Know which of the two you are building before you read the comparison. Confusing them is the single most expensive mistake in this space. ## What are the 4 ways to put an AI agent on WhatsApp? You can build on Meta's official WhatsApp Business API, connect an LLM through a WhatsApp MCP server, build on a developer API layer like Blueticks /v1, or subscribe to a no-code platform. The routes differ on Meta approval, cost model, setup time, and what your agent is allowed to be. The short map: - **Official WhatsApp Business API** - full control, Meta approval, per-message fees - **Claude + a WhatsApp MCP server** - no code, your own number - **Developer API layer (Blueticks /v1)** - build fast, no Meta approval - **No-code agent platforms** - fastest start, least flexible [image: Four railway tracks diverging at a junction at golden hour, four routes to a WhatsApp AI agent] ### Option 1: Build on the official WhatsApp Business API (full control, most work) This is the compliant, Meta-blessed route for customer-facing bots. You register a business number, pass business verification, stand up a webhook endpoint, wire an LLM to it, and submit message templates for review. Realistically that is a build measured in weeks, not days, before the first production conversation. The economics changed recently. On July 1, 2025, Meta [replaced conversation-based pricing with per-message pricing](https://developers.facebook.com/documentation/business-messaging/whatsapp/pricing): you pay for each delivered marketing, utility, or authentication template, with the rate set by template category and the recipient's country. Free-form replies inside an open 24-hour customer service window stay free. Volume is gated too: per Meta's [messaging limits](https://developers.facebook.com/docs/whatsapp/messaging-limits/), a new business can open conversations with only 250 unique customers in a rolling 24 hours, rising to 2,000 with business verification and climbing through 10,000 and 100,000 toward unlimited as account quality holds. I broke the full fee model down in the [WhatsApp Business API pricing guide](https://blueticks.co/blog/whatsapp-business-api-pricing-2026). And here is the 2026 catch: Meta [updated its Business Solution terms](https://techcrunch.com/2025/10/18/whatssapp-changes-its-terms-to-bar-general-purpose-chatbots-from-its-platform/) effective January 15, 2026 to bar general-purpose AI assistants from the platform entirely. OpenAI and Perplexity both wound down their WhatsApp assistants because of it. ChatGPT has since returned — but only in the EEA, and only on OpenAI's own number: the European Commission imposed interim antitrust measures on Meta in June 2026 ordering it to reopen the platform to rival assistants, and ChatGPT came back there on 13 July 2026. Outside the EEA it is still gone, and Perplexity has not announced a return anywhere. Task-specific business bots (support, orders, bookings) remain allowed. So "put ChatGPT on our WhatsApp number" is no longer a thing the official API permits. Your bot must have a defined business job. **What breaks:** template rejections stall launches, and a dip in your quality rating throttles your tier without warning. Budget for both. ### Option 2: Connect an LLM via a WhatsApp MCP server (Claude, no code) MCP, the Model Context Protocol, is the open standard Anthropic introduced in [November 2024](https://en.wikipedia.org/wiki/Model_Context_Protocol) that lets an AI model call external tools. OpenAI adopted it in March 2025, and in December 2025 Anthropic [donated it to the Agentic AI Foundation](https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation) under the Linux Foundation, so it is now vendor-neutral plumbing, not a Claude quirk. A WhatsApp MCP server exposes WhatsApp actions (list chats, read a thread, send a message) as tools Claude can call. The open-source servers connect to your own number over the WhatsApp Web protocol: you scan a QR code and Claude can read and send as you within the hour. Free, local, and genuinely useful for triage and drafting. The trade-offs are equally real: you keep a process alive on your own machine, and the transport is unofficial, which puts you in Terms-of-Service territory (more in the risk section). I compared the actual projects, tool counts and all, in the [best WhatsApp MCP servers roundup](https://blueticks.co/blog/best-whatsapp-mcp-servers). **What breaks:** the bridge dies when your laptop sleeps. Your agent is only as available as your uptime discipline, and the bare servers stop at read and send. No scheduling, no campaigns. ### Option 3: Build on a developer API layer like Blueticks /v1 (fast, no Meta approval) The middle path: a hosted API that runs on top of a regular WhatsApp account, so you skip business verification, template review, and per-message template fees entirely. Blueticks exposes a [/v1 REST API](https://dev.blueticks.co) for exactly this: `POST /v1/scheduled-messages` to send or schedule, `POST /v1/campaigns` for a paced bulk send, audiences with per-contact variables, and signed webhooks, with an `Idempotency-Key` header so a retried request never double-sends. The same engine is exposed as an MCP server, so Claude and code hit one backend through two front doors. Your number connects through a browser extension or through a 24/7 cloud gateway that keeps the session alive with no laptop involved. There is a free plan, so the evaluation costs you nothing but the ten minutes below. This is the fastest route to WhatsApp LLM automation that survives you closing your terminal. Honesty about transport: this is the same unofficial WhatsApp Web family as Option 2, managed to behave like a human session rather than left on your machine. No Meta approval needed, and no Meta blessing either. ### Option 4: No-code agent platforms (fastest to a customer bot, least flexible) Platforms in this family bundle the official API with a visual flow builder and an AI answer bot, so a non-developer can ship an inbound customer bot in days. Wati, one of the better-known examples, lists plans at $59, $119, and $279 per month billed annually ($69, $149, and $349 month-to-month), and because these platforms ride the official Cloud API you still go through Meta business verification and still pay Meta's per-message template fees on top of the subscription. This is the right buy when your goal is a support deflection bot and you have zero engineers. It is the wrong buy for an operator agent: the flow builder answers your customers, it does not read your inbox, chase your leads, or take freeform instructions the way the [AI recipes](https://blueticks.co/blog/automate-whatsapp-with-ai) do. **What breaks:** costs stack quietly. Per-seat fees, automation add-ons, and message fees routinely push real spend well past the sticker price. ## Build vs buy: which WhatsApp AI agent route fits your team? Buy (a no-code platform) when you need a compliant customer-facing bot without engineers. Build on the official API when volume and compliance justify weeks of work. Use MCP or a developer API layer when the agent works for you on your own number and you want it running today. | Route | Setup time | Meta approval | Cost floor | What the agent can do | Ban risk | | --- | --- | --- | --- | --- | --- | | Official API (build) | Weeks, realistically | Yes: verification + template review | Hosting + per-message template fees | Customer-facing task bot, your code, your rules | None if compliant; general-purpose assistants barred | | Claude + self-hosted WhatsApp MCP | 1-2 hours | No | Free, plus babysitting a local process | Read, draft, send on your own number | Real: unofficial transport, ToS exposure | | Blueticks API + MCP | ~10 minutes | No | Free plan to start | Read, send, schedule, campaigns, audiences, webhooks | Same unofficial family, managed and paced | | No-code platform | Days | Yes, the platform onboards you | From $59/month (annual billing) + Meta message fees | Flow-builder customer bot | Low: rides the official API | Three profiles, three answers. A funded team shipping a transactional bot to fifty thousand customers a month builds on the official API and eats the approval process, because compliance is the product. A solo developer who wants Claude reading their own chats tonight self-hosts an MCP server and accepts the babysitting. A founder or operator who wants both halves, an agent on their own number today plus scheduling and campaigns that run while they sleep, takes the API-layer route. **Skip the approval queue.** Everything above Option 1 in cost and complexity, business verification, template review, per-message fees, exists to let you message strangers at scale. If what you actually need is an AI agent on the number you already own, [create a free Blueticks account](https://blueticks.co/signup) and connect your agent through the API + MCP in about ten minutes. No Meta approval, no template queue, no per-message meter. ## How do you set up a WhatsApp AI agent with Claude and MCP in under 10 minutes? The Claude WhatsApp integration takes five steps: link your WhatsApp number to Blueticks with a QR scan, mint an API key, paste one MCP server block into your Claude config, restart, and verify the connection. No code, no Meta account, about ten minutes end to end. [image: Face-down phone beside a mechanical kitchen timer and coffee on a tidy desk, timing a ten-minute setup] 1. **Link your number (about 3 minutes).** Create a free Blueticks account and connect WhatsApp the way WhatsApp Web works: scan a QR code. Choose the browser extension, or the cloud gateway if you want the session alive 24/7 without your machine. 2. **Mint an API key (1 minute).** Grab a `bt_live_` key from the developer console at [dev.blueticks.co](https://dev.blueticks.co). 3. **Add the MCP block (2 minutes).** One server entry in your Claude config running `npx -y @blueticks/mcp` with your key. Node.js 20 or newer is the only prerequisite; the package pulls itself on first run. 4. **Restart and verify (1 minute).** Ask Claude: "Is my WhatsApp connected?" It calls the engine tool and tells you. Do not skip this. 5. **Run the first job (3 minutes).** Start with a read: "Catch me up on WhatsApp since yesterday and tell me what needs a reply." Reads are the zero-regret way to feel the thing work. **What breaks:** if the engine is not linked, every tool call fails quietly and it looks like Claude is being dense. Step 4 exists because of that. Also note the config file lives in different places for Claude Desktop and Claude Code; the developer docs keep the current paths. Once connected, scheduling from conversation works the way the [scheduling-from-Claude guide](https://blueticks.co/blog/schedule-whatsapp-messages-from-claude-mcp) walks through, including the send window: at least 10 seconds out, up to 365 days. ## What can't a DIY agent do, and where an API + MCP layer closes the gap? A self-hosted MCP server gives your agent eyes and a voice: it reads and sends. It has no memory of time. No scheduling, no paced campaigns, no reusable audiences, no webhooks, and no uptime beyond your laptop lid. The gap between a demo agent and a working one is exactly that action layer. Concretely, the layer adds four things. Scheduling with reschedule and cancel, so "remind the client Friday at 10am" survives Claude closing. Campaigns that pace sends over time instead of machine-gunning a list. Audiences with per-contact variables like `{firstName}`, built once and reused. And webhooks plus idempotency for anything you script against the [Blueticks API](https://dev.blueticks.co) directly. The 24/7 gateway underneath means all of it fires whether or not your computer is awake. Speed is the quiet payoff. The [Lead Response Management study](https://www.leadresponsemanagement.org/lrm_study) found reps are 21 times more likely to qualify a lead when they respond within five minutes instead of thirty. An agent that only works when your terminal is open misses most of those windows. One operator running the full setup put it to me plainly: "The self-hosted server was a demo. The moment it could schedule and chase on its own clock, it became staff." ## What are the risks and limits of running a WhatsApp AI agent? Every route has a failure mode. On the official API you risk throttling; on unofficial transports you risk the number itself. The controls are the same everywhere: message people who expect you, pace your sends, and keep a human approving anything outbound. [image: Steel guardrail along a curving mountain road at dusk, the guardrails that keep AI WhatsApp automation safe] On the official side the limits are structural. Tier caps decide how many strangers you can message per day, template review decides what you can say, and since January 15, 2026 a general-purpose assistant is not allowed to be your product at all. Predictable, but rigid. On the unofficial side (every MCP server on your own number, hosted or not), the WhatsApp Help Center is [explicit that unauthorized automated or bulk messaging](https://faq.whatsapp.com/5957850900902049) violates the Terms of Service and can get an account banned. Behavior drives the actual risk. Reading chats and drafting replies you approve is the low end. Blasting a cold list of people who never saved your number is the high end, and no tool, Blueticks included, can promise zero risk there. A managed engine paces sends to look like the human session it is, which mitigates rather than eliminates. The [ban-risk breakdown](https://blueticks.co/blog/best-whatsapp-mcp-servers) covers this per server if you want the detail. Two operational limits worth knowing before they surprise you. WhatsApp's multi-device system allows [up to four linked devices](https://faq.whatsapp.com/378279804439436) per number, and logging out or hitting the cap drops your agent's session mid-flight. And an agent send is still a send from you: opt-in discipline is not a compliance checkbox, it is what keeps recipients from hitting Report, which is the signal that actually kills numbers. ## FAQ ### Can I put ChatGPT or Claude directly on WhatsApp through the official API? No. Meta's Business Solution terms bar general-purpose AI assistants from the WhatsApp Business Platform as of January 15, 2026, which is why OpenAI and Perplexity shut their WhatsApp bots down. ChatGPT returned in the EEA on 13 July 2026 after the European Commission ordered Meta to reopen the platform to rival assistants, but that is OpenAI's own number rather than yours, and it does not change what your business may put on its number. Task-specific business bots are still allowed. The MCP route is unaffected because the agent operates your own account instead of being distributed as a chatbot. ### Do I need Meta approval to run a WhatsApp AI agent? Only on the official-API routes (building directly, or via a no-code platform), which require business verification and template review. The WhatsApp MCP and Blueticks API routes run on a regular WhatsApp account you link with a QR scan, so there is no Meta approval step at all. ### Can a WhatsApp AI agent get my number banned? On unofficial transports, yes, it is possible: automating a personal account violates WhatsApp's Terms of Service, and Meta enforces it. Risk tracks behavior. Read-and-draft workflows on existing chats are the low end; cold bulk sends are the high end. The official API carries no ban risk when used within its rules. ### What is a WhatsApp MCP server? A small program that exposes WhatsApp actions (read chats, send, schedule) as tools an AI model can call through the Model Context Protocol, the open standard Anthropic introduced in late 2024. You register it once in your Claude config and Claude can operate WhatsApp on your instruction. The [WhatsApp MCP pillar](https://blueticks.co/blog/whatsapp-mcp) is the full primer. ### How much does a WhatsApp AI agent cost in 2026? Building on the official API costs weeks of engineering plus Meta's per-message template fees, billed per delivered message since July 1, 2025. No-code platforms start around $59 per month on annual billing plus those same message fees. Self-hosted MCP is free plus your time and uptime. Blueticks has a free plan, and its route has no per-message Meta fees. ## Pick once, then go operate The build-vs-buy question collapses to one earlier question: is the agent facing your customers, or working for you? Customer-facing at scale means the official API and everything it costs, and that is the correct price for that job. An agent on your own number means you can skip the entire approval economy. Link your number, add the MCP block, and give Claude its first instruction before your coffee cools. The key and the current config block are at [dev.blueticks.co](https://dev.blueticks.co). --- # How to Choose a WhatsApp Broadcast Platform in 2026: Segmented Lists, Delivery at Scale, Tracking & Automated Follow-Ups > You are shopping for a tool to run WhatsApp broadcasts, not a tutorial. Here are the 7 criteria that actually separate a real platform from a contact-list toy. URL: https://blueticks.co/blog/how-to-choose-whatsapp-broadcast-platform Published: 2026-07-09 Author: Maya Cohen Category: marketing You run seasonal campaigns. You need to schedule a WhatsApp broadcast to a segmented list, know who read and replied, and fire an automated follow-up to the people who went quiet. The built-in broadcast feature does none of that, and half the tools that claim to are just a contact importer with a send button. This is the buyer's guide: the criteria that actually matter, the trade-offs nobody puts on the pricing page, and how to tell a real platform from a toy before you pay for it. ## What a WhatsApp Broadcast Platform Actually Is A WhatsApp broadcast platform is software that lets you send one message to many recipients as individual chats, then segment your list, schedule the send, pace it to protect your number, and track replies. It sits above WhatsApp's built-in broadcast, which caps you at 256 saved contacts per list and offers no scheduling and no analytics. There are three levels of "broadcasting" on WhatsApp, and mixing them up is the most common buying mistake: - **Native broadcast lists** in the WhatsApp Business app. Free, but a manual dead end. Per WhatsApp's [Help Center guide on broadcast lists](https://faq.whatsapp.com/861663048350950), each list holds a maximum of 256 contacts, the message only reaches people who have saved your number, and you get zero delivery or open data. - **A broadcast platform on your own number.** A tool that drives your existing WhatsApp account to send at scale with segmentation, scheduling, pacing, and tracking layered on top. No per-message fee, no Meta approval queue. - **The official WhatsApp Business Platform (Cloud API).** Meta's high-volume pipe, billed per message, with template approvals and a business verification step. Most businesses evaluating a "platform" actually need level two or three, not the native lists they have been fighting with. If you are still hitting the wall on native lists, our breakdown of the [WhatsApp broadcast limit](https://blueticks.co/blog/whatsapp-broadcast-limit) explains why multiple 256-contact lists never scale into a real campaign. ## Why Native WhatsApp Broadcast Breaks at Campaign Scale Native broadcast lists break the moment you treat them as a campaign tool because they cap each list at 256 saved contacts, silently drop anyone who has not saved your number, cannot be scheduled, and report nothing back. You cannot see who read the message, who replied, or who converted. For a seasonal campaign, that is flying blind. Walk through what a real campaign needs and native lists fail on every count. You want to reach 3,000 opted-in customers, so you are already building twelve separate lists by hand. Every recipient who never saved your number gets nothing, and you have no way to know who that is. You want the promo to land Thursday at 10am, but there is no schedule, so you are awake sending it live. Afterward you want to know the reply rate, and there is no number to look at. [image: A small marketing team planning a WhatsApp broadcast platform campaign around a whiteboard] This is exactly the gap a broadcast platform fills. The question is which one, and that comes down to seven criteria. ## The 7 Criteria for Choosing a WhatsApp Broadcast Platform The seven criteria that separate a real WhatsApp broadcast platform from a glorified contact importer are opt-in compliance, list segmentation, delivery method, pacing and deliverability, tracking and analytics, automated follow-ups, and pricing model. Score any tool against all seven before you buy. A tool that nails sending but skips segmentation and tracking will cost you a banned number and a blind campaign. Here is what each one means and what "good" looks like. **1. Opt-in and compliance.** This is non-negotiable, because it is what keeps your number alive. Meta's [policy enforcement documentation](https://developers.facebook.com/documentation/business-messaging/whatsapp/policy-enforcement) is explicit that accounts which receive excessive negative feedback get limited or removed. A good platform helps you honor opt-outs and never encourages messaging cold or purchased lists. If a vendor's pitch is "upload any list and blast," walk away. Our [WhatsApp campaign best practices](https://blueticks.co/blog/whatsapp-campaign-best-practices) guide covers the opt-in rules that protect your number in detail. **2. List segmentation.** You need to split one list into groups that share a trait, then message each group something written for them. This is the single biggest lever on reply rate. Look for the ability to build audiences by behavior, recent buyers, lapsed customers, cart abandoners, and to suppress people who already converted or opted out. **3. Delivery method: own number vs Cloud API.** This is the fork in the road. Does the tool send from your existing WhatsApp number, or does it require you to onboard to Meta's official API? Each has real trade-offs, laid out in the table below. Neither is universally right. The wrong one for your volume and budget is an expensive mistake. **4. Pacing and deliverability.** A thousand messages leaving your number in ninety seconds is the signature of a spam bot. A good platform paces sends over minutes and hours and lets you set a send window so a stale scheduled message does not fire at 2am. No platform can guarantee delivery, and any that promises it is lying. What a good one does is reduce the burst pattern that triggers spam flags. **5. Tracking and analytics.** If you cannot measure it, you are guessing. At minimum you want delivery status, read status, and reply tracking, ideally tied to conversions. Be honest about what read rate tells you: WhatsApp read rates run far higher than email, but the number is a weak signal. Industry benchmarks compiled by [Kanal](https://getkanal.com/blog/whatsapp-marketing-roi-kpis-benchmarks) note that open rate sits in the 90s across every list quality, which makes it almost useless for comparing campaigns. Reply rate is the honest metric. Our guide to [WhatsApp campaign analytics that matter](https://blueticks.co/blog/whatsapp-campaign-analytics-metrics-that-matter) covers which numbers to actually watch. **6. Automated follow-ups.** The money is in the second message. A platform worth paying for lets you trigger a follow-up to people who did not reply, and stop the sequence for anyone who did. Speed matters here more than most marketers expect. The classic [lead-response research popularized by Harvard Business Review](https://hbr.org/2011/03/the-short-life-of-online-sales-leads) found that responding within five minutes versus thirty made a lead up to 21 times more likely to qualify. On a real-time channel like WhatsApp, a same-hour automated nudge captures intent before it cools. **7. Pricing model.** Read the meter, not the sticker. The core question is whether you pay per message. Own-number tools typically charge a flat subscription with no per-send fee. The official Cloud API bills per message, and marketing templates are its priciest category. For a business sending tens of thousands of marketing messages a month, that difference decides your unit economics. Score every tool against these seven, and stop paying for send-only tools that skip the middle five. If you want a platform that segments, schedules, paces, and tracks from your own number without per-message fees or an API onboarding queue, [start free with Blueticks](https://blueticks.co/signup) and run your first campaign this week. [image: Blank index cards and sticky notes grouped into tidy clusters, representing WhatsApp broadcast list segmentation] ## Own Number vs Official Cloud API: Which Delivery Model Fits You Own-number platforms send from your existing WhatsApp account with no per-message fee and no approval queue, which suits small and mid-market teams at personal-to-mid volume. The official Cloud API is built for very high volume and enterprise scale, but bills per message, requires business verification, and puts every template through Meta's approval. Match the model to your volume and budget, not to the loudest pitch. Here is the honest side-by-side. | Factor | Own-number platform | Official Cloud API | | --- | --- | --- | | Per-message fee | None (flat subscription) | Yes, billed per delivered message | | Marketing message cost | Included in plan | Marketing templates are the priciest category | | Setup | Connect your existing number, start today | Business verification plus number onboarding | | Message content | Free-form, no pre-approval | Marketing templates need Meta approval | | Best fit | SMB to mid-market, seasonal campaigns | High-volume, enterprise, transactional at scale | | Ceiling | Personal-account scale, pace-limited | Very high throughput | On pricing, the move that reshaped this decision is Meta's shift, [effective July 1, 2025 per respond.io's pricing breakdown](https://respond.io/blog/whatsapp-business-api-pricing), from conversation-based billing to per-delivered-message pricing on the Cloud API, with marketing messages the most expensive template category. If your campaigns are marketing-heavy and high-volume, those per-message fees compound fast. If you are running seasonal broadcasts to a few thousand opted-in customers, an own-number subscription is usually the cheaper and faster path. Our full [WhatsApp Business API pricing breakdown for 2026](https://blueticks.co/blog/whatsapp-business-api-pricing-2026) runs the per-country numbers if you want the detail. The rule of thumb: pick the Cloud API when your volume genuinely outgrows a personal account or you need official transactional messaging. Pick an own-number platform when you want to start this week, keep costs flat, and message from the number your customers already know. ## Case Study: How Platform Choice Changed a Seasonal Campaign A regional coffee subscription brand, call it Meridian Roasters, ran a summer promo to 2,400 opted-in customers. Their first attempt used native broadcast lists, and it fell apart. Their second used a real platform, segmented and tracked. The difference in outcome came entirely from the tooling, not the offer. Round one, native lists. Meridian split 2,400 contacts into ten broadcast lists by hand and sent the same message to all of them live, on a Tuesday afternoon. Roughly a third of recipients had never saved the number, so the message silently vanished for them. There was no schedule, no segmentation, and no data. When the marketing lead asked how it performed, the honest answer was that nobody knew. Replies trickled in and got lost in the inbox. Round two, a broadcast platform on their own number. They cut the same list into three segments: active subscribers, lapsed customers, and opted-in never-purchasers. Each got a message written for them. They scheduled the send for a Thursday at 10am and paced it. They tracked replies and fired a single automated follow-up 48 hours later to everyone who had not answered. "The first campaign, I was refreshing my phone hoping something happened," the marketing lead said. "The second one, I could actually see the replies come in by segment and knew the follow-up was doing the work." The reply-rate math tracks with published benchmarks: Kanal's data puts reply rates at roughly 1 to 3% on a cold, unsegmented broadcast and 3 to 8% on a well-targeted opted-in flow. Segmentation plus a timed follow-up is what moves you from the floor toward the ceiling. Those figures are illustrative of the range, not a guarantee for any single send. [image: A small-business owner reviewing WhatsApp broadcast campaign results on a printed report] ## Where Blueticks Fits Blueticks is an own-number broadcast platform. It drives your existing WhatsApp number, so there is no per-message fee, no Meta business verification, and no template-approval queue. It fits the SMB-to-mid-market team running seasonal segmented campaigns, not the enterprise sending millions of transactional messages a month. Here is the honest scorecard against the seven criteria. Blueticks sends from your own WhatsApp number, which means you are not on the official Cloud API and there are no per-message fees, but you are also bound by personal-account scale rather than enterprise throughput. Audiences give you list segmentation. Scheduling plus a max-send-window setting handle timing and pacing, so a stale message can be skipped instead of firing late. Campaign analytics give you delivery, read, and reply tracking. And you can layer automated follow-ups on top for the people who go quiet. What Blueticks does not do is guarantee deliverability. No tool on WhatsApp can, and any that claims to is selling you a fantasy. Sending responsibly, to opted-in people, at a sane pace, is still on you. What the platform removes is the manual grind: the twelve hand-built lists, the live send at 10am, the inbox you cannot measure. If your campaigns are marketing-heavy, seasonal, and aimed at a list you built with consent, the own-number model usually wins on cost and speed. [Start a free Blueticks campaign](https://blueticks.co/signup) and send your first segmented, scheduled broadcast without touching an API. ## Frequently Asked Questions **What is the difference between a WhatsApp broadcast and a WhatsApp broadcast platform?** A native WhatsApp broadcast is the built-in feature that sends one message to up to 256 saved contacts per list, with no scheduling and no tracking. A broadcast platform is separate software that adds segmentation, scheduling, pacing, analytics, and automated follow-ups on top, either driving your own number or the official Cloud API. **Do I need the official WhatsApp Cloud API to run broadcasts?** No. You need the Cloud API when your volume outgrows a personal account or you require official transactional messaging at enterprise scale. For seasonal campaigns to a few thousand opted-in contacts, an own-number platform sends from your existing WhatsApp number with no per-message fee and no approval queue, which is usually cheaper and faster to start. **Can a broadcast platform guarantee my messages get delivered?** No, and any vendor that promises guaranteed delivery is misleading you. WhatsApp controls delivery and can limit numbers that generate spam complaints. A good platform lowers your risk by pacing sends and helping you honor opt-outs, but responsible sending to an opted-in list is what actually protects delivery. **Which metric should I track for a WhatsApp broadcast?** Track reply rate and conversions over read rate. Read rate on WhatsApp sits in the 90s across almost every list, per industry benchmarks, which makes it too flat to compare campaigns. Reply rate, typically 1 to 3% on cold broadcasts and 3 to 8% on segmented opted-in flows, tells you whether your targeting and copy are working. **How much does a WhatsApp broadcast platform cost?** It depends on the delivery model. Own-number platforms charge a flat subscription with no per-message fee. The official Cloud API bills per delivered message, and since July 1, 2025 that is per message rather than per conversation, with marketing templates the priciest category. High marketing volume favors the flat model on unit economics. --- # WhatsApp Campaign Best Practices: 12 Rules for Higher Deliverability, Opt-In & Reply Rates (2026) > The difference between a campaign that lands and a number that gets banned comes down to a handful of rules. Here are the 12 that matter most in 2026. URL: https://blueticks.co/blog/whatsapp-campaign-best-practices Published: 2026-07-08 Author: Maya Cohen Category: marketing Two businesses send the same WhatsApp campaign to the same number of people. One books a week of demos. The other has its number blocked by Friday. Same tool, same message, wildly different outcome. The gap almost never comes down to the copy. It comes down to who you sent to, how fast you fired, and whether those people asked to hear from you in the first place. This guide is the rules layer. If you have already read how to plan a campaign or send bulk messages, this is the part that keeps you out of trouble. Twelve WhatsApp campaign best practices, grouped by what they protect: your list, your targeting, your timing, your copy, and your number's long-term health. ## What Separates a Landing Campaign From a Banned Number A WhatsApp marketing campaign lands when every recipient opted in, the list is segmented, sends are paced instead of blasted, and the copy invites a reply. A number gets banned when you message cold contacts fast enough that people block and report you, and Meta reads those signals as spam. That is the whole game in one sentence. WhatsApp does not ban you for volume alone. It bans you for the negative feedback that unsolicited volume produces. Per Meta's own [policy enforcement documentation](https://developers.facebook.com/documentation/business-messaging/whatsapp/policy-enforcement), accounts that "receive excessive negative feedback from users" can be limited or offboarded, and repeat violators move through warnings, then 1 to 30 day sending blocks, then an indefinite block, then permanent removal. So every rule below is really one rule wearing twelve hats: earn the right to be in someone's inbox, and behave like a business they would not report. ## Rules 1 to 3: Build an Opt-In-Only List The single biggest driver of WhatsApp bans is messaging people who never opted in. Meta requires that you obtain permission before messaging, clearly state your business name at the point of opt-in, and honor every opt-out request. Get these three right and you have removed roughly 80% of your ban risk before you write a word. **Rule 1: Never message a cold or purchased list.** This is the whatsapp campaign opt-in rule that everything else rests on. Meta's [opt-in guidance](https://developers.facebook.com/documentation/business-messaging/whatsapp/getting-opt-in) is explicit: a person must have given you their number and confirmed they want to hear from your business specifically. A scraped list, a rented list, or "everyone who ever bought from us in 2019" is not consent. Recipients block and report cold messages within seconds, and that is the fastest path to a ban. **Rule 2: Capture consent you can prove.** Add a checkbox at checkout ("Send me order updates and offers on WhatsApp"). Put a click-to-chat link on your site where the first message is the opt-in. Collect numbers at point of sale with a clear line about what you will send. Meta's policy (updated November 2024) requires the opt-in to name your business and state that the person is agreeing to receive messages from you. Keep a timestamp and source for each contact so you can defend the list later. **Rule 3: Make opt-out one word.** End marketing sends with "Reply STOP to opt out." When someone does, remove them immediately and permanently. WhatsApp requires you to honor these requests, and a fast, obvious opt-out is what keeps your block-and-report rate low. Counterintuitively, an easy exit protects your number more than a buried one, because a frustrated recipient who cannot find the exit hits "block" instead, and blocks hurt you far more than opt-outs. [image: Customer signing a paper opt-in form at a checkout counter, illustrating WhatsApp campaign opt-in consent] If you are still assembling that first clean list, our guide on [how to send bulk WhatsApp messages](https://blueticks.co/blog/how-to-send-bulk-whatsapp-messages) walks through the mechanics of collecting and organizing contacts before you ever hit send. ## Rules 4 to 5: Segment Before You Send Segmentation is splitting one big list into smaller groups that share a trait, then sending each group a message written for them. A relevant message to 200 people beats a generic message to 2,000, because relevance drives replies and suppresses the opt-outs and blocks that damage your number. Never treat your whole list as one audience. **Rule 4: Segment by behavior, not just demographics.** The useful cuts are recency and intent: recent buyers, cart abandoners, lapsed customers, and people who opted in but never purchased. A win-back offer makes sense to a lapsed customer and annoys a buyer who ordered yesterday. Annoyed people opt out or block. Every block is a strike against your number in Meta's spam scoring. **Rule 5: Suppress the people who already converted or already left.** Before any whatsapp broadcast campaign, strip out anyone who bought the thing you are promoting and anyone who opted out. This sounds obvious and gets skipped constantly under deadline pressure. A single send to your STOP list is exactly the kind of complaint that tips a healthy number into a restriction. Here is the reply-rate math that makes segmentation worth the effort. Industry [WhatsApp marketing benchmarks](https://getkanal.com/blog/whatsapp-marketing-roi-kpis-benchmarks) put reply rates at roughly 1 to 3% on a cold, unsegmented broadcast and 3 to 8% on a well-targeted, opted-in flow. Segmentation is what moves you from the floor toward the ceiling, and it also lifts click-through and cuts the opt-outs that damage your number. The lift is relevance, and relevance comes from segmentation. Segment, pace, and measure reply and opt-out on your own number without per-message fees or API setup. [Start free with Blueticks](https://blueticks.co/signup) and run your first compliant campaign this week. ## Rules 6 to 7: Pace the Send and Time It Right Pacing means spreading a bulk send over minutes and hours instead of firing everything at once, and timing means landing messages during waking business hours. Sudden high-volume bursts are what WhatsApp's anti-spam systems flag first. A paced, well-timed send looks like a human running a business, not a script. **Rule 6: Pace your sends, do not blast.** A thousand messages leaving your number in ninety seconds is the signature of a spam bot. Space them out. As a working guideline, keep automated sends in the range of one message every 30 to 90 seconds and cap early campaigns at a few hundred a day rather than thousands. There is no fully automatic drip engine that makes this safe for you, so the honest advice is to start small, watch your delivery and opt-out numbers, and scale up only when they hold steady. **Rule 7: Send when people are awake and buying.** Timing changes response rate more than most marketers expect. The classic [lead-response research popularized by Harvard Business Review](https://hbr.org/2011/03/the-short-life-of-online-sales-leads) found that reaching out within five minutes versus thirty minutes made a lead up to 21 times more likely to qualify. WhatsApp is a real-time channel, so the same instinct applies: send mid-morning or early evening on weekdays, when a reply can actually turn into a conversation, not at 2 AM when it reads as spam and gets muted. [image: Analog wall clock beside a calm workspace representing paced and well-timed WhatsApp broadcast campaign sends] This is where a stale backlog bites you. If your machine was offline and a queued batch tries to fire four hours late, those messages land at the wrong time and drag your reply rate down. Guard against it with a send window: skip any message that can no longer go out within N minutes of its planned time. ## Rules 8 to 9: Write Copy That Earns Replies, Not Blocks The best-performing WhatsApp campaign copy reads like a message from a person, not a billboard. It uses the recipient's name, states one clear reason for the message, asks one question, and gives an easy way out. Copy that feels personal earns replies. Copy that feels like a mass blast earns blocks, and blocks are what get you banned. **Rule 8: Personalize and lead with relevance.** Open with the recipient's first name and a reason tied to something they did: a product they viewed, an order they placed, an event they registered for. Generic "Hi, check out our sale" copy gets ignored at best and reported at worst. One question per message keeps the door open for the 3 to 8% reply rate a segmented, opted-in flow can reach, versus the 1 to 3% a cold blast settles for. **Rule 9: Keep it short, human, and un-spammy.** Avoid link-heavy, all-caps, emoji-stuffed blasts. Those trip both the recipient's instinct to report and WhatsApp's pattern detection. Write the way you would to one customer you respect. If you want proven structures, our roundup of [WhatsApp campaign templates that convert](https://blueticks.co/blog/whatsapp-campaign-templates-that-convert) breaks down message formats that earn replies instead of silence. ## Rule 10: Warm a New Number Before Your First Big Campaign Warming a number means starting a new WhatsApp line with a low daily volume and increasing it gradually over two to three weeks. A brand-new number that sends hundreds of messages on day one looks exactly like a spammer to WhatsApp's systems. A slow ramp builds the sending reputation that lets you scale safely. **Rule 10: Ramp over weeks, not hours.** A commonly cited warm-up shape is to send only tens of messages a day in week one, roughly double that in week two, and reach the low hundreds a day by week three, with natural spacing between sends and real two-way conversations mixed in. Different guides put slightly different numbers on it, so treat any specific figure as a directional starting range, not an official limit. The shape is what matters: low and slow, then up. [image: Row of small seedlings growing in gradual stages, a metaphor for warming a new WhatsApp number to avoid a ban] Here is what warming looks like in practice. A mid-size skincare brand, call it Lumen, bought a fresh number and wanted to message its 3,200-contact opt-in list before a launch. Instead of blasting all 3,200 on day one, they warmed the number for two weeks: a few dozen conversational messages a day to their most engaged customers, spaced a minute or two apart. By week three the number had a clean track record. They then rolled the full launch out in paced batches of a few hundred a day. Zero blocks, opt-out rate under 1%, and a reply rate several times what a cold blast to the same list would have managed. The same list sent cold on a cold number would very likely have triggered a restriction inside 48 hours. ## Rule 11: Track Reply Rate and Opt-Out Rate, Not Vanity Metrics The two metrics that predict a WhatsApp campaign's health are reply rate (how many recipients answered) and opt-out rate (how many asked to leave). Delivered and read counts tell you the message arrived. Reply and opt-out tell you whether people wanted it. Watch these two and you will see a ban coming before it lands. **Rule 11: Set thresholds and act on them.** Aim to clear the 1 to 3% reply rate of a cold broadcast: a segmented, opted-in flow lands more like 3 to 8%. Keep opt-outs under about 2% per campaign. Well-run, tightly opted-in sales waves see opt-out rates near 0.1 to 0.2%, so anything creeping toward 3 to 5% is a warning that your targeting or copy is off. On read rates, ignore the "98% open rate" figure that gets repeated everywhere without a primary source; measured opt-in broadcast read rates more realistically land in the 60 to 80% range, with the high 90s reserved for the tightest transactional lists. The rule underneath the numbers: if opt-outs spike on a send, stop. Do not push the next batch. Diagnose which segment or message drove it, fix it, then resume. Our guide to [WhatsApp campaign analytics](https://blueticks.co/blog/whatsapp-campaign-analytics-metrics-that-matter) covers exactly which metrics to instrument and how to read them. ## Rule 12: Stay Unbanned for the Long Haul Long-term ban avoidance is a compounding habit, not a one-time setup. Every clean, opted-in, paced campaign builds your number's reputation. Every shortcut spends it. The businesses that message on WhatsApp for years without a ban are the ones that treat the list as a privilege they can lose, because they can. **Rule 12: Respect the platform's ceilings and signals.** Remember that a standard WhatsApp broadcast reaches only contacts who have saved your number, and each broadcast list caps at 256 recipients, per the [WhatsApp Help Center](https://faq.whatsapp.com/861663048350950). Work within those limits rather than fighting them. Keep your block-and-report rate low, honor every opt-out same-day, and never buy a list to "just try it once." To avoid a WhatsApp ban over the long run, the math is simple: consistent low complaints beat occasional high reach every time. ## Putting the Rules Into Practice With Blueticks Blueticks turns these rules into a workflow you run from your own WhatsApp number. It is not the official Meta WhatsApp Business Cloud API and it does not promise deliverability guarantees. It sends a whatsapp bulk message campaign from your personal or WhatsApp Business app number, which is exactly why the opt-in and pacing rules above are non-negotiable: normal WhatsApp anti-spam rules apply to you directly. Here is how the capabilities map to the rules: | Rule area | Blueticks capability | |---|---| | Segment your list (Rules 4 to 5) | **Audiences** — import and organize contacts into a named audience, then target a campaign to just that group | | Pace and time sends (Rules 6 to 7) | **Campaign scheduling** plus an opt-in **max send window** that skips any message it cannot send within N minutes of its planned time, so a stale backlog never fires hours late | | Track reply and opt-out (Rule 11) | **Campaign analytics** with per-message delivered and failed status | There is no fully automatic drip pacing beyond the send window, so the built-in discipline is the same one this whole guide preaches: start small, measure, and scale up. The Free plan can send bulk campaigns (the three-at-a-time limit only applies to single scheduled messages) with a "Powered by blueticks.co" footer, and Pro removes the branding. Details are on the [Blueticks pricing page](https://blueticks.co/). Run a compliant, paced campaign on your own number. Segment, pace, and measure reply plus opt-out without per-message fees or API setup. [Start free with Blueticks](https://blueticks.co/signup). ## Frequently Asked Questions **Do these best practices stop WhatsApp from banning my number?** They dramatically lower the risk but nothing guarantees zero bans, because your campaign runs on a real WhatsApp number under Meta's normal anti-spam rules. The controllable factors are opt-in, pacing, and complaint rate. Keep all three healthy and a ban becomes unlikely. Message cold lists fast and a ban becomes likely regardless of the tool. **What is the single most important WhatsApp campaign best practice?** Only message people who opted in. Per Meta's policy, unsolicited messaging is the top driver of blocks, reports, and bans. Every other rule protects a list that opt-in makes legitimate in the first place. If you do one thing, throw out every contact who did not clearly agree to hear from your business. **How many messages can I safely send per day when starting out?** Treat it as a ramp, not a fixed number. A common warm-up shape is tens of messages a day in week one, roughly double in week two, and the low hundreds a day by week three, spaced 30 to 90 seconds apart. Different guides cite slightly different figures, so these are directional rather than official limits: watch your delivery and opt-out rates and scale only when they stay clean. **What counts as a healthy opt-out rate for a WhatsApp campaign?** Under about 2% per campaign is a reasonable target, and tightly opted-in sends often run near 0.1 to 0.2%. If opt-outs climb toward 3 to 5%, stop and fix your targeting or copy before the next batch. Rising opt-outs and blocks are the earliest warning that your number's reputation is slipping. **Can I run a compliant WhatsApp marketing campaign for free?** Yes. Blueticks' Free plan can send bulk campaigns from your own number with a "Powered by blueticks.co" footer, and paid tiers remove the branding. The compliance work, opt-in, segmentation, pacing, and measurement, is the same on every tier. The plan you choose does not change the rules that keep your number safe. --- # How to Receive & Auto-Reply to WhatsApp Messages with Webhooks (Python & Node, 2026) > Wire up a WhatsApp API with webhooks so inbound messages hit your server and get an instant auto-reply. Real Flask and Express code, signature verification, and the production traps. URL: https://blueticks.co/blog/whatsapp-api-webhooks-auto-reply Published: 2026-07-07 Author: Daniel Roth Category: productivity You can already send WhatsApp messages from code. The harder half is hearing back. A customer replies "yes, 3pm works" and your script has no idea it happened, because sending is a one-way push and receiving needs something listening. That something is a webhook. This guide wires up a WhatsApp API with webhooks so an inbound message lands on your server and gets an auto-reply in the same second, with real Flask and Express code you can run today. ## What a WhatsApp Webhook Actually Is A WhatsApp webhook is a URL on your server that the messaging platform calls with an HTTP POST every time an event happens, like a new inbound message. Instead of your code polling "any new messages yet?" on a loop, the platform pushes the event to you the moment it fires. You register the URL once, then you receive. Polling is the naive approach and it falls apart fast. You either poll every few seconds and hammer the API for nothing 99% of the time, or you poll slowly and your bot answers three minutes late. Webhooks flip the model. Your server sits idle until an event arrives, then reacts. It is the same pattern Stripe uses for payments and GitHub uses for pushes. With Blueticks, you point a webhook at your server through the `/v1` REST API. The base URL is `https://api.blueticks.co/v1`, and every call authenticates with an API key you mint in the dashboard, sent as `Authorization: Bearer bt_live_...`. One registration call and inbound WhatsApp messages start hitting your endpoint. For the outbound side of the API, the companion piece is [scheduling and sending messages via the API](https://blueticks.co/blog/send-schedule-whatsapp-messages-api). ## The Two-Way Flow: Inbound to Your Server to Auto-Reply The full loop is three hops. A contact messages your WhatsApp number, Blueticks POSTs that event to your webhook URL, and your handler reads the sender plus text and calls the send endpoint to reply. This page covers the **inbound** direction. For the other one, where you send a message and want to know what happened to it afterwards, see [tracking outbound delivery status with webhooks](https://blueticks.co/blog/whatsapp-api-delivery-status-webhooks). The whole round trip runs in well under a second, so the contact experiences it as an instant response, not a scheduled batch. Here is the sequence, start to finish: 1. A person sends a message to your connected WhatsApp number. 2. Blueticks fires the `new_message_received_webhook` event and POSTs a JSON envelope to your registered URL. 3. Your server verifies the signature, confirms the payload is genuine, then parses out who sent it and what they said. 4. Your handler decides on a reply and calls `POST /v1/scheduled-messages/{chatId}`, putting the sender in the URL path and your response text in the body. 5. The reply goes out from your own number, and the contact sees it land in the same thread. [image: Relay runners handing off a baton, a metaphor for the inbound-to-auto-reply webhook round trip] The key mental shift: receiving and sending are two separate endpoints. The webhook delivers inbound. The `scheduled-messages` endpoint pushes outbound. Your auto-reply logic is just the glue that reads one and calls the other. Everything past step 3 is your code, which means the bot can be as dumb as a canned "got it, we will be in touch" or as smart as a full LLM call. The transport is the same either way. ## Registering a Webhook With the Blueticks /v1 API You register a webhook with one authenticated POST to `https://api.blueticks.co/v1/webhooks`. The body needs a `url` (which must be `https://`), an `events` array naming what you want to receive, and an optional `description` under 120 characters. Blueticks returns the created webhook object with its `id` and a `status` of `enabled`, wrapped in the standard `/v1` success envelope. Here is the registration call: ```bash curl -X POST https://api.blueticks.co/v1/webhooks \ -H "Authorization: Bearer bt_live_your_key_here" \ -H "Content-Type: application/json" \ -d '{ "url": "https://your-server.com/hook", "events": ["new_message_received_webhook"], "description": "auto-reply bot" }' ``` The response looks like this: ```json { "success": true, "data": { "id": "wh_...", "url": "https://your-server.com/hook", "events": ["new_message_received_webhook"], "description": "auto-reply bot", "status": "enabled", "createdAt": "2026-07-07T09:00:00Z" } } ``` Note the two layers. Every 2xx on `/v1` is wrapped in `{"success": true, "data": {...}}`, so the webhook object is under `data`, and its timestamp field is camelCase `createdAt`. That envelope is not the same thing as the delivery payload Blueticks POSTs to you later, which has its own shape. The event you want for a two-way bot is `new_message_received_webhook`, the "a message arrived" trigger. Blueticks exposes other events you can subscribe to as your bot grows: `reply_to_my_message_webhook`, `message_reaction_webhook`, `poll_vote_webhook`, and the outbound delivery events `message.queued`, `message.sending`, `message.delivered` and `message.failed`. Start with the inbound one and add the rest when you need them. Two caveats worth knowing before you build on them. `message.read` is accepted by the API but rarely arrives, so do not gate any logic on it. And although `session.connected` and `session.disconnected` appear in the events enum, they are not delivered in production today — to find out whether your WhatsApp engine is online, poll [`GET /v1/engines`](https://dev.blueticks.co/docs/api) rather than waiting for a callback that will not come. One gotcha before you go further: your `url` has to be publicly reachable over HTTPS. For local development that means a tunnel like ngrok in front of your Flask or Express process, because `localhost:3000` is not a URL Blueticks can POST to. Register the tunnel URL while testing, then swap it for your real domain on deploy. ## Verifying and Parsing the Payload Every delivery carries a signature so you can prove it came from Blueticks and not a stranger who found your URL. The header `Blueticks-Webhook-Signature` carries the value `v1=`, where `` is `HMAC-SHA256(secret, "{timestamp}.{rawBody}")`, and `Blueticks-Webhook-Timestamp` carries the unix seconds. You strip the `v1=` prefix, recompute that HMAC over `"{timestamp}.{rawBody}"` with your webhook secret, and compare it to the header value using a constant-time check. (Blueticks also sends a simpler `X-Blueticks-Signature: sha256=` that signs the raw body alone, with no timestamp, for receivers that would rather not handle replay windows.) Two rules make or break this. First, hash the raw request body, the exact bytes on the wire, before any JSON middleware reshapes it. Re-serialized JSON will not match, because key order and whitespace shift. Second, use a constant-time comparison (`hmac.compare_digest` in Python, `crypto.timingSafeEqual` in Node), never `==`, so an attacker cannot leak the secret one byte at a time through response timing. This is the same discipline Meta documents for its own `X-Hub-Signature-256` webhook header, so it is not a Blueticks quirk, it is how webhook signing works everywhere. The delivery envelope is predictable: ```json { "id": "evt_abc123", "type": "new_message_received_webhook", "created_at": "2026-07-07T09:00:00Z", "data": { } } ``` The `data` object is the message itself. The exact sub-fields are not something I will hard-code here, because they are not publicly pinned and inventing key names would just cost you a debugging session. Do this instead: log `data` once on your first real inbound message, read the shape from your own logs, then pull the sender and text fields you actually see. That takes thirty seconds and gives you ground truth instead of a guess. Ready to build this instead of reading about it? [Grab a /v1 API key from your dashboard](https://blueticks.co/signup) and point a webhook at your server. No Meta business verification, no per-message fees, and the reply goes out from your own number, so you can have a working two-way bot before lunch. ## Receive and Auto-Reply in Python (Flask) A Flask auto-reply bot needs one route that reads the raw body, verifies `Blueticks-Webhook-Signature`, parses the inbound message, and calls `POST /v1/scheduled-messages` to answer. The critical detail is grabbing `request.get_data()` for the raw bytes before Flask parses JSON, so the HMAC matches. ```python import hmac, hashlib, os, requests from flask import Flask, request, abort app = Flask(__name__) WEBHOOK_SECRET = os.environ["BLUETICKS_WEBHOOK_SECRET"].encode() API_KEY = os.environ["BLUETICKS_API_KEY"] # Set these to the keys you see after logging `data` on your first inbound event. SENDER_KEY = "from" # placeholder: confirm against your logged payload TEXT_KEY = "body" # placeholder: confirm against your logged payload def verify(raw_body: bytes, timestamp: str, signature: str) -> bool: signed = f"{timestamp}.".encode() + raw_body expected = hmac.new(WEBHOOK_SECRET, signed, hashlib.sha256).hexdigest() received = (signature or "").split("=", 1)[-1] # strip the "v1=" prefix return hmac.compare_digest(expected, received) @app.post("/hook") def hook(): raw = request.get_data() # raw bytes, BEFORE json parsing ts = request.headers.get("Blueticks-Webhook-Timestamp", "") sig = request.headers.get("Blueticks-Webhook-Signature", "") if not verify(raw, ts, sig): abort(401) event = request.get_json() if event.get("type") != "new_message_received_webhook": return "", 200 # ignore other events for now data = event["data"] app.logger.info("inbound data: %s", data) # log once, then read the shape sender = data.get(SENDER_KEY) text = data.get(TEXT_KEY) if sender and text: # recipient goes in the PATH; the body is just type + content requests.post( f"https://api.blueticks.co/v1/scheduled-messages/{sender}", headers={"Authorization": f"Bearer {API_KEY}"}, json={"type": "text", "text": f"Thanks, we got your message: {text}"}, timeout=10, ) return "", 200 if __name__ == "__main__": app.run(port=3000) ``` Run it, point ngrok at port 3000, register the tunnel URL, and message your number. The recipient path segment accepts an E.164 phone like `+15551234567` or a WhatsApp JID like `12345@c.us`, whichever your logged `data` hands you for the sender. There is no `to` field in the body: post to the bare `/v1/scheduled-messages` with the recipient in the JSON and you get a `410 Gone` back. Omitting `sendAt` sends immediately, which is exactly what an auto-reply wants. ## The Same Bot in Node (Express) An Express version follows the identical shape, with one Node-specific trap: use `express.raw()` on the webhook route so `req.body` is a Buffer of the untouched bytes. If you let `express.json()` parse it first, your HMAC will never match and every request will 401. ```javascript const express = require("express"); const crypto = require("crypto"); const app = express(); const SECRET = process.env.BLUETICKS_WEBHOOK_SECRET; const API_KEY = process.env.BLUETICKS_API_KEY; // Set these after logging `data` on your first inbound event. const SENDER_KEY = "from"; // placeholder: confirm against your logged payload const TEXT_KEY = "body"; // placeholder: confirm against your logged payload // raw body ONLY on this route, so the HMAC matches byte-for-byte app.use("/hook", express.raw({ type: "application/json" })); function verify(rawBody, timestamp, signature) { const signed = `${timestamp}.` + rawBody.toString(); const expected = crypto.createHmac("sha256", SECRET).update(signed).digest("hex"); const received = (signature || "").split("=").pop(); // strip the "v1=" prefix const a = Buffer.from(expected); const b = Buffer.from(received); return a.length === b.length && crypto.timingSafeEqual(a, b); } app.post("/hook", async (req, res) => { const ts = req.get("Blueticks-Webhook-Timestamp") || ""; const sig = req.get("Blueticks-Webhook-Signature") || ""; if (!verify(req.body, ts, sig)) return res.sendStatus(401); const event = JSON.parse(req.body.toString()); if (event.type !== "new_message_received_webhook") return res.sendStatus(200); const data = event.data; console.log("inbound data:", data); // log once, then read the shape const sender = data[SENDER_KEY]; const text = data[TEXT_KEY]; res.sendStatus(200); // ACK fast, before the outbound call if (sender && text) { // recipient goes in the PATH; the body is just type + content await fetch(`https://api.blueticks.co/v1/scheduled-messages/${encodeURIComponent(sender)}`, { method: "POST", headers: { Authorization: `Bearer ${API_KEY}`, "Content-Type": "application/json", }, body: JSON.stringify({ type: "text", text: `Thanks, we got your message: ${text}`, }), }); } }); app.listen(3000, () => console.log("listening on :3000")); ``` Note the order: this handler returns `200` before it makes the outbound send. That is deliberate, and the next section explains why acking first is the difference between a stable bot and a flood of duplicate replies. ## Avoiding Duplicate Replies, Loops, and Dropped Events Webhook delivery is at-least-once, not exactly-once, so production breaks in three predictable ways: duplicate deliveries, reply loops, and events dropped while your server was down. You defend against all three with fast acks, an idempotency check on the event `id`, and a sender guard so your bot never answers itself. [image: A small always-on home server humming overnight, illustrating reliable webhook delivery in production] Here are the failure modes and the fix for each: | Failure mode | What happens | The fix | |---|---|---| | Duplicate replies | Your handler is slow, the platform times out and retries, the contact gets two answers | Return `2xx` within a second or two; do the slow work after acking | | Reply loops | Your bot's own outbound triggers another inbound event and it answers itself forever | Check the sender is not your own number before replying | | Dropped events | Your server was down when the message arrived | Rely on retries, and keep the handler cheap so it rarely fails | | Replayed payloads | An attacker re-sends an old captured request | Reject deliveries whose `Blueticks-Webhook-Timestamp` is older than a few minutes | The single most important habit is idempotency. Every envelope carries a unique `id`. Store the IDs you have already processed (a Redis set with a TTL works fine) and skip any repeat. That one check makes duplicate deliveries harmless, which in turn lets you ack fast and worry about the reply afterward. The reply-loop trap catches almost everyone once. If your bot answers every inbound message and your own sends echo back as events, it will happily talk to itself until it hits a rate limit. Guard it: compare the sender against your connected number and bail if they match. Test it deliberately by messaging your own number and confirming the bot stays quiet. ## Blueticks vs the Meta WhatsApp Cloud API, Honestly Use the Meta WhatsApp Cloud API directly when you are a verified business sending high volumes of template messages at official scale. Use Blueticks when you want a two-way bot running on your own personal or business number today, without Meta business verification, template approval, or per-message fees. They solve different problems, and picking wrong wastes weeks. The Meta Cloud API is the official, sanctioned path, and it is genuinely the right call at scale. But the on-ramp is real work. You register a business, verify it with Meta, register a phone number that becomes a Cloud API number (not your normal WhatsApp), get message templates approved, and you pay per message. Meta moved to per-message pricing on July 1, 2025, deprecating the older conversation-based model, and free-form replies are only allowed inside a 24-hour customer service window after the user last messaged you. Outside that window you send a paid, pre-approved template. Blueticks trades that scale ceiling for speed and simplicity: | | Blueticks /v1 | Meta Cloud API direct | |---|---|---| | Your number | Your own WhatsApp / Business number | A dedicated Cloud API number | | Meta business verification | Not required | Required | | Template pre-approval | Not required | Required for messages outside the 24h window | | Per-message fees | No | Yes, per Meta's pricing | | Time to first two-way reply | Minutes | Days to weeks | | Best for | Bots, personal and SMB automation, own-number replies | High-volume verified-business messaging at scale | If you are Uber sending millions of ride receipts, go Cloud API. If you are a developer who wants inbound messages to hit a Flask handler and auto-reply from the number you already use, the verification overhead buys you nothing. ## What Raw Webhooks Cannot Do That Blueticks Adds Raw webhooks give you the receive side and nothing else. Blueticks wraps them in a full messaging layer: sending from your own existing number, no Meta review or template approval, and scheduling on the same `/v1` API, so one integration covers inbound, outbound, and timed sends instead of three. A bare webhook is just a delivery mechanism. To turn inbound events into a real bot you still need a way to send, an identity to send from, and usually a way to send later, not just now. Blueticks bundles all three: - **Your own number.** Replies come from the WhatsApp number your contacts already know, not a fresh Cloud API line they have never seen. No re-verifying a business identity to Meta to get started. - **No Meta review gate.** You are not waiting on template approval to send a free-form reply. The auto-reply in the Flask example above just works. - **Scheduling on the same API.** The `scheduled-messages` endpoint you use for instant auto-replies also takes a `sendAt`, so a webhook that receives "remind me tomorrow" can schedule the reminder without a second service. That is the [scheduling API](https://blueticks.co/blog/send-schedule-whatsapp-messages-api) doing double duty. If you want a fuller bot skeleton in Python, the [own-number WhatsApp bot walkthrough](https://blueticks.co/blog/build-whatsapp-bot-python) builds on this same foundation. One honest limit to plan for: this runs on your real WhatsApp number, so normal account rules apply. Auto-replies to people who messaged you are exactly the kind of legitimate use WhatsApp expects. Blasting unsolicited outbound to strangers is not, and it can get a number banned regardless of which API sends it. Build a responder, not a spam cannon, and you stay well inside the lines. ## Frequently Asked Questions **Do I need a public server to receive WhatsApp webhooks?** Yes. The webhook `url` must be publicly reachable over HTTPS, because Blueticks POSTs to it from the outside. For local development, run a tunnel like ngrok in front of your Flask or Express process and register the tunnel URL. Swap it for your real domain when you deploy. **How do I stop my bot from replying to itself?** Compare the sender on each inbound event against your own connected WhatsApp number and skip the reply if they match. Without this guard, your bot's outbound messages can echo back as new inbound events and it will loop until it hits a rate limit. Test it by messaging your own number. **Why is my signature verification always failing?** Almost always one of two things. Either you are hashing parsed-and-reserialized JSON instead of the raw request bytes (recompute the HMAC over the exact body on the wire: `request.get_data()` in Flask, or an `express.raw()` route in Express), or you forgot to strip the `v1=` prefix from the `Blueticks-Webhook-Signature` header before comparing. The signed string is `"{timestamp}.{rawBody}"`, and the comparison must be constant-time. **Can the same webhook receive delivery and read receipts too?** Yes. Beyond `new_message_received_webhook`, you can subscribe to events like `message.queued`, `message.sending`, `message.delivered`, `message.failed`, `reply_to_my_message_webhook` and `poll_vote_webhook`. Add them to the `events` array when you register or update the webhook, then branch on `event.type` in your handler. Note that `message.read` rarely arrives and the `session.*` events are not delivered in production today, so do not build on either. **Do I have to verify my business with Meta to use this?** No. That is the core difference from the Meta Cloud API directly. Blueticks sends and receives on your own existing WhatsApp number without Meta business verification or template pre-approval, which is what makes a working two-way bot achievable in minutes instead of over a multi-day approval process. --- # How to Automate Recurring WhatsApp Follow-Up Reminders for Clients (Small-Business Guide) > The WhatsApp Business app can't send a reminder on a schedule. Here's how to automate recurring client follow-ups anyway, with cadences that don't feel like spam. URL: https://blueticks.co/blog/whatsapp-follow-up-reminder-automation Published: 2026-07-06 Author: Daniel Roth Category: productivity A client books a consultation. You say "I'll check in next week." Then next week happens to you instead of for you, and the check-in never goes out. Multiply that by every appointment confirmation, unpaid invoice, and lapsed renewal in your pipeline, and you have the real reason small businesses leak revenue on WhatsApp. This guide covers WhatsApp follow up reminder automation end to end: what WhatsApp can and cannot do natively, the exact setup for a recurring reminder, the cadences that work for client-facing businesses, and which tool category fits you in 2026. ## Why Do Client Follow-Ups Slip Through the Cracks on WhatsApp? Client follow-ups slip on WhatsApp because the app has no outbound scheduler and no task layer. Every reminder depends on you remembering to type it at the right moment, inside a chat list that buries old conversations under new ones. The cost is concrete: no-shows, invoices paid late, and renewals that quietly lapse. WhatsApp is where your clients actually reply, which is exactly why it is a terrible reminder system on its own. A chat thread is a conversation log, not a calendar. Once a conversation scrolls below the fold, it stops existing for practical purposes. The cost of a dropped reminder is measurable. A [systematic review and meta-analysis of digital appointment notifications](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5093388/) found patients who received a reminder were 25% less likely to no-show than those who received nothing (15% vs 21% no-show rates). Flip that around: skipping reminders means eating roughly a fifth more empty slots than you have to. For a clinic running 40 appointments a week, that is the difference between six empty chairs and eight or nine. Payment follow-ups behave the same way. The invoice you chase on day 3 gets paid. The one you plan to chase "soon" becomes a 45-day receivable. None of this is a discipline problem. It is a tooling problem, and the fix is a proper [WhatsApp follow up sequence](https://blueticks.co/blog/whatsapp-automated-follow-up-sequence) that runs whether or not you remember it. ## Can WhatsApp Send Recurring Reminders Natively in 2026? No. As of July 2026, neither WhatsApp nor the WhatsApp Business app can send an outbound message at a future time you choose, once or on a repeating schedule. The Business app's automation tools (greeting messages, away messages, quick replies, labels) either react to incoming messages or organize chats. None of them initiates a send. Here is what each Business app feature actually covers, so you know what you are not missing: | Business app feature | What it does | Sends a recurring outbound reminder? | |---|---|---| | Away message | Auto-replies when someone messages you during hours you set | No. Reply-only, per [WhatsApp's Help Center](https://faq.whatsapp.com/2565868990219715/) | | Greeting message | Auto-replies to first-time contacts | No. Reply-only | | Quick replies | Saved templates you still send by hand | No. Manual | | Labels | Tags chats (e.g., "unpaid", "follow up") | No. Organization only | | Broadcast lists | One manual message to up to 256 saved contacts | No. One-off, and [recipients must have your number saved](https://faq.whatsapp.com/861663048350950/) | The away message trips people up the most. It has a scheduler, but the schedule controls when the auto-reply is active, not when a message goes out. A client who never messages you never triggers it. Your "payment due Friday" reminder cannot ride on an away message. Labels get you halfway to a system: tag every unpaid invoice, filter, send by hand. That works at five clients. At fifty, the manual send is the step that fails. For the general scheduling landscape beyond reminders, the [recurring WhatsApp messages guide](https://blueticks.co/blog/schedule-recurring-whatsapp-messages) covers the options in more depth. ## How Do You Set Up an Automated Recurring WhatsApp Follow-Up Reminder, Step by Step? The reliable 2026 setup uses a scheduling tool that runs on top of WhatsApp Web, from your existing number. You install the Blueticks extension, open the client's chat, write the reminder once, set a recurrence pattern (daily, weekly, monthly, or custom), and choose when it ends. Total setup time is under five minutes. [image: Paper wall calendar with repeating weekly markers representing recurring WhatsApp reminder schedules] Here is the exact workflow: 1. **Install the extension and open WhatsApp Web.** A clock icon appears in the message input bar of every chat. 2. **Open the chat you want the reminder in.** Works for individual contacts and groups. 3. **Click the clock icon and write the message.** Write it the way you would type it live. Brackets like "Hi [Name], your session is tomorrow at [time]" are for templates you reuse; for a single client, just write it plainly. 4. **Set the first send date and time.** Pick a moment the client is likely to see it, not 7:00 AM. 5. **Enable custom recurrence.** Choose daily, weekly, monthly, or a custom pattern, and pick specific weekdays if you need them. Then set the end condition: never, a fixed date, or after N occurrences. A "payment due" nudge might repeat weekly for 4 occurrences. A quarterly check-in runs with no end date. 6. **Schedule, then verify.** The scheduled message appears as a card you can edit, send immediately, or delete from the [scheduler dashboard](https://blueticks.co/guides/scheduler). One option worth switching on for follow-ups specifically: automatic cancellation if the recipient replies before the scheduled send. That single toggle is the difference between a reminder system and a spam cannon. If the client already answered, the next nudge silently cancels instead of making you look like a bot. **What breaks, and when.** With the standard extension, sends run through your browser: the computer must be on and the WhatsApp Web session active at send time. If your laptop is asleep, the message queues until you reconnect. If a Tuesday 9:00 AM reminder absolutely must go out while you are on vacation, that is what the offline Gateway mode (a Pro-tier feature that sends with your browser closed) exists for. Also know the free tier's shape: it schedules three messages at a time, which is fine for testing the workflow but not for running twenty client reminders in parallel. Recurring reminder workloads sit on the paid tiers. Tired of being your own reminder system? [Set up recurring WhatsApp reminders from your own number](https://blueticks.co/signup), no API application, no template approvals, free to try. ## Which Follow-Up Reminder Schedules Work for Client-Facing Businesses? Four cadences cover most small-business reminder needs: appointments (24 hours before, plus a same-day confirm), payments (3 days before due, due date, then day 3 and day 7 overdue), renewals (30 days, 7 days, and day-of), and re-engagement (30, 60, and 90 days of silence). Set each as a recurring or pre-scheduled series, not a manual task. [image: Open paper planner with spaced sticky-note markers laying out an appointment and payment reminder cadence] | Reminder type | Cadence | Why this spacing | |---|---|---| | Appointment | 24h before + morning-of confirm | The same meta-analysis found multiple notifications beat a single one for attendance | | Payment | Day -3, due date, day +3, day +7 | Pre-due nudges prevent the awkward chase; post-due ones escalate gently | | Renewal / rebooking | Day -30, day -7, day-of | Long decisions need an early flag; short ones need the final call | | Re-engagement | 30 / 60 / 90 days quiet | Slow enough to stay welcome, structured enough to actually happen | Two practical rules sit under all four cadences. First, anchor reminders to the client's event, not your convenience. A renewal reminder lands 30 days before *their* expiry date, which means every client has a different schedule. This is why hand-managed reminders collapse: you are not maintaining one calendar, you are maintaining one per client. Automation is the only version of this that survives contact with a real client list. Second, escalate content, not frequency. The day -3 payment message is friendly ("invoice attached, due Friday"). Day +7 is direct ("this is now a week overdue, can you confirm payment this week?"). Same channel, same thread, rising specificity. What you never do is send the identical text four times; that reads as automation even when it isn't. One operator I'll paraphrase here (a salon owner describing her setup to me, quote reconstructed with her okay): "I stopped thinking of it as messaging and started thinking of it as rent. The rebooking reminder goes out on day 25 whether I'm at the counter or not. That one message is worth more than my Instagram." For the strategic layer above cadences, the [WhatsApp drip sequence guide](https://blueticks.co/blog/whatsapp-drip-sequence) covers how these timing blocks assemble into full campaigns. ## How Do You Turn One-Off Reminders into a WhatsApp Lead Nurturing Sequence? A reminder repeats one message on a schedule. A whatsapp nurture sequence chains different messages toward a decision: Day 0 intro, Day 3 value nudge, Day 7 direct ask, Day 14 polite close. You build it with the same scheduling tool by pre-scheduling each step in the same chat, then cancelling remaining steps when the lead replies. The mechanics matter less than the shift in intent. Reminders protect revenue you already earned (the booked appointment, the signed invoice). WhatsApp lead nurturing chases revenue you have not earned yet, which changes the tone and the clock. Speed dominates early: research summarized in [Harvard Business Review](https://hbr.org/2011/03/the-short-life-of-online-sales-leads) found reps who contacted a lead within an hour were nearly seven times more likely to qualify it than those who waited even an hour more. Your Day 0 message is the one that cannot wait for morning. The build is the same numbered workflow from the setup section, run four times with different content and dates. In practice, an automated whatsapp messages sequence for a new lead looks like: 1. **Day 0:** answer, then confirm the thread ("Great chatting, I'll send the quote by tomorrow"). 2. **Day 3:** one concrete value add (a relevant example, not a brochure). 3. **Day 7:** the direct ask ("Want me to hold a slot for next week?"). 4. **Day 14:** the honest close ("If timing's off, say the word and I'll stop nudging"). There is no branching logic here, and that is a feature. You are scheduling real messages; when someone replies, you respond like a human and delete the rest of the queue (or let reply-cancellation do it). If you want copy to steal, the [follow-up sequence templates](https://blueticks.co/blog/whatsapp-automated-follow-up-sequence) article has five ready to paste. ## Which WhatsApp Follow-Up Automation Tools Fit a Small Business in 2026? Three tool categories exist in 2026: the free WhatsApp Business app (organization only, no outbound automation), WhatsApp Business API platforms (powerful, but per-message fees plus subscription and template approvals), and WhatsApp Web schedulers like Blueticks (recurring sends from your own number, no per-message fees). For most small client-facing businesses, the third category fits first. [image: Three distinct workspace setups side by side suggesting the three WhatsApp sequence tool options for small business] | | Business app | API platform | WhatsApp Web scheduler | |---|---|---|---| | Recurring outbound reminders | No | Yes | Yes | | Runs on your existing number | Yes | Number moves to the API | Yes | | Per-message fees | None | [Meta bills per template message](https://developers.facebook.com/documentation/business-messaging/whatsapp/pricing): ~$0.025 per US marketing message, ~$0.004 utility, on top of the platform's subscription | None | | Message pre-approval | None | Templates reviewed by Meta | None, you write freely | | Setup effort | Minutes | Days (business verification, templates) | Minutes | | Best for | Solo, under ~10 active clients | High volume, multi-agent teams | Small teams running a whatsapp follow up sequence from one or two numbers | The API route is real infrastructure and sometimes the right call; the [Business app vs API breakdown](https://blueticks.co/blog/whatsapp-business-app-vs-api) covers where the line sits. But run the reminder math first. A 300-client list getting four payment-cycle touches a month is 1,200 template messages. Under per-message billing that is a recurring metered bill plus a platform subscription, for messages you could send from your own number at a flat rate. API pricing also varies hard by country (a marketing template costs roughly 5x more in Germany than in the US), so the same cadence has a different price tag per market. A whatsapp sequence tool in the third category trades that for one honest limitation: it operates through WhatsApp Web, so you own the uptime story (browser open, or Gateway mode for offline sends). No metered fees, no template review queue, and the [scheduler](https://blueticks.co/scheduler) handles one-time, recurring, and bulk-campaign sends from the same dashboard. If the per-message math just made you wince: [put your client follow-ups on repeat with Blueticks](https://blueticks.co/signup). Recurring reminders from your own number, free to start, no per-message fees. ## How Do You Keep Automated Reminders Personal and Off WhatsApp's Spam Radar? Send reminders only to clients who expect them, write each one like a human typed it, space touches days apart, and stop the moment someone replies or asks you to. WhatsApp's enforcement watches recipient behavior: blocks and reports damage API senders' [quality rating](https://www.facebook.com/business/help/896873687365001), and [bulk or automated spam patterns can get any account banned](https://faq.whatsapp.com/5957850900902049). [image: Smartphone resting face-down beside a handwritten note in calm evening light, reminders handled for the day] The mechanics are worth knowing. On the API side, Meta scores your number's quality from the last seven days of user feedback (blocks, reports, block reasons), and sustained low quality restricts how many conversations you can initiate. On the app side, WhatsApp's terms prohibit unauthorized bulk and automated messaging outright, and detection leans on the same signal: recipients who did not want the message. The rules differ; the failure mode is identical. Annoyed recipients are the whole risk model. Which means the defense is editorial, not technical: - **Message people who opted in.** A client with an appointment expects the reminder. A number scraped from a group does not. The [opt-in compliance guide](https://blueticks.co/blog/whatsapp-opt-in-compliance-requirements) covers what consent needs to look like. - **Vary the text.** Identical strings to many recipients is the classic spam fingerprint. Reminders are naturally personal (name, date, amount), so let them be. - **Cancel on reply.** Turn on reply-cancellation so a client who answered never gets nudged again. Nothing earns a block faster than a robot ignoring a human. - **Give an exit.** "Say the word and I'll stop the reminders" costs one line and converts would-be blocks into unsubscribes. - **Watch the frequency ceiling.** Four touches per payment cycle is a system. Four touches per week is a block. Anecdotally, reminder-type messages are the safest automation category there is, because recipients benefit from them. Nobody reports the message that saved them a missed appointment. They report the fifth identical promo. Stay on the right side of that line and volume is not your problem. ## FAQ **Can the WhatsApp Business app send follow-up reminders by itself?** No. Its away and greeting messages only reply to incoming messages, and quick replies still require a manual send. To have WhatsApp deliver a reminder at a time you choose, on a repeating schedule, you need either a WhatsApp Web scheduling tool or the WhatsApp Business API. **Will automated reminders get my number banned?** Reminders to clients who expect them are low-risk. WhatsApp's enforcement keys on recipient complaints: blocks and reports. Message opted-in clients, personalize the text, stop when someone replies or asks, and keep frequency reasonable. Blasting identical messages to strangers is what triggers bans, on any tool. **Can I stop a recurring reminder once the client responds?** Yes. In Blueticks you can enable automatic cancellation when the recipient replies before the scheduled send, or delete any scheduled message manually from its card in the chat or the dashboard. For payment reminders, cancel-on-reply is the setting that keeps the thread human. **Do I need the WhatsApp Business API for reminder automation?** Not at small-business scale. The API makes sense for high-volume, multi-agent operations and adds per-message fees plus template approval. A WhatsApp Web scheduler delivers recurring reminders from your existing number with no metered costs, which covers most client-facing businesses comfortably. **What does WhatsApp follow up reminder automation cost?** With a WhatsApp Web tool: a flat subscription, with a free tier to test (Blueticks' free plan schedules three messages at a time). With the API: a platform subscription plus Meta's per-message fees, around $0.025 per US marketing template and more in most of Europe. The app-only route is free but fully manual. --- # WhatsApp Marketing Message Pricing in 2026: What Each Category Costs (and When to Avoid the API) > Meta's per-message pricing for WhatsApp marketing templates ranges from $0.010 in India to $0.135+ in Germany. Here is what each category actually costs, and when the API stops making sense. URL: https://blueticks.co/blog/whatsapp-business-pricing-marketing-messages-2026 Published: 2026-07-05 Author: Avi Kohen Category: industry You're planning a WhatsApp marketing campaign and you see the per-message fee for the first time. It looks small — $0.025, maybe $0.06. Then you multiply by 5,000 contacts. Then by twelve campaigns a year. The numbers get uncomfortable fast, and you haven't added the solution provider markup yet. This piece breaks down exactly how Meta's WhatsApp Business Platform pricing categories work in 2026 — what marketing messages cost, how they compare to utility and authentication templates, and the real arithmetic of running a mid-size campaign list through the API. ## What are the four WhatsApp Business Platform message categories — and why does the category change your bill? WhatsApp Business Platform pricing charges differently depending on what kind of message you send. Since July 1, 2025, Meta bills per delivered template message, not per conversation, and the rate depends on two things: the message category and the recipient's country code. Marketing templates carry the highest rates. Utility and authentication templates cost significantly less, and service replies inside an open customer window are free. The four categories, as defined in [Meta's WhatsApp Business Platform pricing documentation](https://developers.facebook.com/documentation/business-messaging/whatsapp/pricing): - **Marketing** — promotions, offers, re-engagement messages, and any template that doesn't fit the utility or authentication definition. Always charged at the marketing rate. No volume discount path. - **Utility** — transactional follow-ups tied to a specific customer action: order confirmations, shipping updates, appointment reminders, account activity alerts. Eligible for volume-tier discounts. Free when sent inside an open 24-hour customer service window. - **Authentication** — one-time passwords, login verification codes, and account-security alerts. Lowest per-message rate in most markets. Also free inside an open service window, and subject to separate "authentication-international" rates in nine specific markets. - **Service** — non-template messages (plain text, images, files) you send inside a customer-initiated 24-hour conversation window. Free, no template required, no charge. The category boundary that trips most businesses is marketing vs. utility. A shipping update is utility. A message encouraging the customer to buy more from that shipment is marketing, even if it's sent in the same thread. Meta's own guidelines draw the line at "promotional intent." If a template includes a discount code or re-engagement language, it qualifies as marketing regardless of format. Why this matters: in the US, a utility message costs $0.004. A marketing message costs $0.025. That's a 6x price gap for messages that can look nearly identical on the recipient's screen. ## How much does a WhatsApp marketing message cost in 2026? (per-region rate table) WhatsApp marketing message pricing in 2026 ranges from roughly $0.010 per message in India to over $0.135 in Germany, with North America sitting around $0.025. Rates are set per recipient country code, not your business location, and marketing messages carry no volume discount — unlike utility and authentication tiers. [image: World map with regional cost markers representing WhatsApp API pricing per country] The following rates are drawn from Meta's current rate cards and from pricing reported by [flowcall.co's 2026 cost guide](https://flowcall.co/blog/whatsapp-business-api-pricing-2026), cross-referenced against the [Blueticks pricing reference](https://blueticks.co/blog/whatsapp-business-api-pricing-2026) for accuracy. India switched to local INR billing in January 2026; the USD equivalents below use approximately ₹83 = $1. | Market | Marketing (per message) | Utility (per message) | Marketing : Utility ratio | |---|---|---|---| | United States | $0.0250 | $0.0040 | 6.25x | | United Kingdom | ~$0.048 (£0.0382) | ~$0.020 (£0.0159) | 2.4x | | Brazil | $0.0625 | $0.0068 | 9.2x | | Germany | ~$0.123 (€0.1131) | ~$0.050 (€0.0456) | 2.5x | | Netherlands | ~$0.144 (€0.1323) | ~$0.045 (€0.0414) | 3.2x | | India | ~$0.010 (₹0.8631) | ~$0.0014 (₹0.115) | 7.1x | A few things stand out. First, Germany and the Netherlands are the most expensive marketing markets in the table — a single marketing message in Germany costs roughly 13 times what the same message costs in India. Second, Brazil has a pronounced marketing-to-utility spread at 9x, meaning the template mis-classification risk is especially expensive there. Third, North America is moderate by global standards but adds up fast at volume. Rates are denominated in the recipient's currency, so a US-based business sending to a German number pays the German rate, not the US rate. This catches cross-border senders off guard. **Beat note:** Meta updated India's marketing rate upward in January 2026 and moved Brazil to local BRL billing in July 2026, per the WhatsApp pricing updates changelog. Rates shift — always verify the current rate card on [Meta's pricing page](https://developers.facebook.com/documentation/business-messaging/whatsapp/pricing) before budgeting a campaign. ## How does the marketing message category compare to utility and authentication messages in price? Marketing messages cost 2–9x more than utility messages in the same market, and 2–8x more than authentication messages. The gap exists because marketing templates are always charged at the full rate — no free-window exemptions and no volume tier discounts — while utility and authentication templates can become free inside a customer service window and qualify for volume-based rate reductions. The practical implication: the same business sending the same volume can face very different bills depending on how its templates are categorized. A business sending 10,000 messages a month to US numbers pays $250 if all messages are marketing ($0.025 each) versus $40 if all are utility ($0.004 each). That $210 gap exists before any vendor markup. Multiply that by the 12 countries in a regional campaign and the category decision becomes a real budget lever. Utility and authentication messages also benefit from volume tiers. In India, for example, Meta's published tier schedule shows a 6% discount at 750,000 monthly messages, scaling to 30% at 100 million messages — all for utility/authentication, none for marketing. Marketing messages scale linearly with no relief. The second cost asymmetry is the 24-hour service window. When a customer messages you first, all utility and authentication templates you send in the following 24 hours are free. Marketing templates are not. So a business that responds to an inbound inquiry with a promo offer — even inside a live service window — still pays the marketing rate for that template. [image: Person using a calculator to compare marketing message costs on paper worksheets] ## What triggers a marketing conversation vs. a utility conversation — and how easy is it to mis-classify? A message is a marketing template if it includes a promotion, discount, offer, brand announcement, or re-engagement call to action that goes beyond confirming or following up on a specific customer-initiated transaction. Utility templates are limited to operational updates tied to a customer's prior purchase, booking, or account action. The line is narrower than most businesses expect, and Meta's template reviewers enforce it — a mis-classified template either gets rejected at approval or retroactively reclassified to the higher rate. Common mis-classification patterns to watch for: 1. **The upsell append.** An order confirmation template is utility. Add "while your order ships, check out these items" and it flips to marketing. 2. **The re-engagement nudge.** A "your cart is waiting" reminder without a completed purchase event is marketing, not utility. The purchase hasn't happened yet — there's no transaction to confirm. 3. **The loyalty touchpoint.** A points-balance update sounds transactional. If it includes a "redeem now" prompt, Meta classifies it as marketing. 4. **The promo disguised as a notification.** "Your account has been updated. Also, our summer sale is live" is a marketing message with a notification header. Meta's [template policy documentation](https://developers.facebook.com/docs/whatsapp/message-templates/guidelines/) draws the distinction clearly: utility is what the customer needs to know about their specific transaction; marketing is anything you want them to do next. When in doubt, the more expensive category applies. The practical test: would this message be worth sending if the customer had no recent order, booking, or account action? If yes, it's marketing. ## What is a realistic monthly WhatsApp marketing cost for a 1,000-contact list vs. a 10,000-contact list? For a US-based business sending one marketing campaign per week to a clean opt-in list, 1,000 contacts costs roughly $100 a month in Meta API fees alone, and 10,000 contacts costs roughly $1,000. For German or Dutch audiences, multiply those figures by 5x. These numbers do not include solution provider platform fees or support costs. Working the math out explicitly, at US rates ($0.025 per marketing message): - **1,000 contacts × 4 sends/month** = 4,000 messages × $0.025 = **$100/month** - **10,000 contacts × 4 sends/month** = 40,000 messages × $0.025 = **$1,000/month** Add a typical Business Solution Provider markup of $0.005 to $0.02 per message on top, and those figures climb to $120–$180/month and $1,200–$1,800/month respectively. Annual run rate for 10,000 contacts at four sends a week: $14,400–$21,600 just in messaging fees, before platform subscription costs. For a German audience at ~€0.113 per marketing message: - **1,000 contacts × 4 sends/month** = 4,000 messages × €0.113 = **~€452/month** - **10,000 contacts × 4 sends/month** = 40,000 messages × €0.113 = **~€4,520/month** At those rates, even a modest promotional calendar becomes a five-figure annual line item. Our [WhatsApp Business API cost calculator guide](https://blueticks.co/blog/whatsapp-business-api-cost-calculator) walks through the full projection model if you want to run your own numbers. ## When does WhatsApp API marketing message pricing make the API uneconomical — and what do businesses do instead? The API marketing math breaks down when your contact list is under roughly 5,000, your campaigns are promotional rather than transactional, your recipients are in high-rate markets like Germany or the Netherlands, or you need the flexibility to write freely without template pre-approval. At those conditions, a small-to-mid-volume sender pays API overhead for a problem the API wasn't designed to solve. The specific ceiling varies by market and send frequency. For a US-based business sending four campaigns a month, the cost per contact per year runs roughly $1.20 through the API. For a German-market equivalent, it's closer to $6.60 per contact per year. If your customer lifetime value or transaction size doesn't comfortably clear that, the economics don't close. What businesses do instead falls into two categories: **Stay in Tier 1 and accept the limits.** The free WhatsApp Business app handles inbound auto-replies and small-scale manual broadcasts. It caps at 256 contacts per broadcast and gives you no scheduling or delivery tracking, but it costs nothing. **Use a WhatsApp Web-based tool.** A browser-based scheduler sends from your existing WhatsApp number through WhatsApp Web. There's no Meta API application, no template pre-approval, no per-message fee, and no separate business number. You send from the number your customers already know, at a flat monthly software cost. The trade-off is volume norms similar to a human sender — not suited for hundreds of thousands of messages per day, but well-suited for hundreds to a few thousand per send. The [API vs. direct-from-number comparison](https://blueticks.co/blog/whatsapp-business-api-pricing-2026) walks through which volume threshold tips the math in the API's favor for each market. ## How Blueticks lets you send scheduled WhatsApp marketing messages from your existing number, with no per-message API fee Blueticks is a Chrome extension and web dashboard that runs alongside WhatsApp Web. It sends scheduled and campaign messages directly from your WhatsApp number — no Meta API application, no template approval queue, and no per-message billing. You install the extension, open WhatsApp Web, and schedule messages from your existing account. **Skip the per-message API fees and template approvals.** Send scheduled WhatsApp campaigns from your own number, starting free. [Install Blueticks free](https://blueticks.co/signup) and have your first campaign live today. To be specific about what Blueticks is and isn't: it's a Chrome extension paired with a web scheduler, not a mobile app, and not an API client. Messages go out through WhatsApp Web using your own account — the same number your contacts already have, the same inbox where their replies land. There's no business verification required, no separate number to warm up, and no category distinction to manage. You write freely, schedule freely, and see per-message delivery status after the send. [image: Laptop on a desk showing WhatsApp Web open, representing scheduled message sending] What this covers for the typical small-to-mid-size marketing use case: - **Scheduled one-time messages** to individual contacts, groups, or a full campaign list — sent at the date and time you choose. - **Recurring messages** for weekly nudges, monthly promos, or any cadence that would otherwise require recreating the same message by hand. - **Campaigns to multiple contacts** with merge-field personalization, paced sending to stay within normal WhatsApp behavior, and a delivery status view. - **Offline delivery** through a persistent gateway, so sends complete even when your browser is closed. The honest positioning: Blueticks covers the segment of businesses that would pay $100–$1,000+ per month in Meta API marketing fees to do something a scheduled WhatsApp message can accomplish for a flat fee that's a fraction of that. It's not a replacement for the API at tens-of-thousands-per-day scale — it's the right tool one tier below, where most promotional senders actually live. ## FAQ **What is WhatsApp marketing message pricing in 2026?** Since July 1, 2025, Meta charges per delivered marketing template message on the WhatsApp Business Platform. Rates range from approximately $0.010 in India to over $0.123 in Germany, with the US at $0.025, per Meta's official rate cards. Marketing messages have no volume discount tier — every message is billed at the full rate. **What are the four WhatsApp Business Platform pricing categories?** Marketing (always charged, highest rate), utility (lower rate, free inside a 24-hour customer service window, eligible for volume discounts), authentication (lowest rate, similar free-window rules, separate international rates in nine markets), and service (non-template replies inside a customer-initiated window — free). The category is determined at template approval and affects your per-message cost significantly. **How does WhatsApp utility pricing compare to marketing pricing?** Utility messages cost 2–9x less than marketing messages in the same market. In the US, marketing is $0.025 versus $0.004 for utility — a 6x gap. In Brazil the gap is roughly 9x. Utility templates sent inside an open 24-hour customer service window are also free, which marketing templates never are. **Why are German WhatsApp marketing message rates so high?** Meta sets rates by recipient country code. Germany's marketing rate sits at approximately €0.1131 per message, roughly 5x the US rate and 13x India's rate. The Netherlands is even higher at ~€0.1323. Meta has not published a rationale for the regional gap, but it reflects market-specific pricing decisions that predate the July 2025 per-message transition. **Is there a free way to send WhatsApp marketing messages?** Within a 24-hour customer service window (when the customer messaged you first), non-template messages are free and utility templates are free — but marketing templates are still charged. A 72-hour free-entry window applies when a customer reaches you through a click-to-WhatsApp ad. Outside those windows, every marketing template delivery carries a per-message charge. Browser-based tools like Blueticks avoid the API entirely, sending from your own WhatsApp number at a flat software fee with no per-message billing. --- # Is the WhatsApp Business API Worth It in 2026? A Cost, Effort & Alternatives Breakdown > The WhatsApp Business API isn't free, isn't instant, and isn't for everyone. Here's an honest 2026 breakdown of the cost, the effort, and the alternatives. URL: https://blueticks.co/blog/is-whatsapp-business-api-worth-it Published: 2026-07-04 Author: Avi Kohen Category: industry You keep reading that you "need the WhatsApp Business API" to grow. Then you look at what it involves: a Meta application, a business verification, a solution provider contract, per-message fees, and template approvals. And you start to wonder whether all of that is solving a problem you actually have. This is an honest look at whether the API is worth it in 2026, what it really costs, and what you can do instead if it isn't. ## What does the WhatsApp Business API actually cost in 2026? The WhatsApp Business API costs money per message in 2026, not per seat or per month. Effective July 1, 2025, Meta moved to per-message pricing, billed by message category and by the recipient's country. On top of Meta's rate, your Business Solution Provider adds its own platform fee, so the true cost is Meta's per-message charge plus a vendor markup. Meta's own developer documentation is the primary source here, and it's specific. Per the [WhatsApp Business Platform pricing docs](https://developers.facebook.com/documentation/business-messaging/whatsapp/pricing), there are four ways a message is treated: marketing, utility, authentication, and service. Three of those are paid template categories. The fourth, service, is free inside an open window. Here's the shape of it: - **Marketing** - promotions, offers, re-engagement. The most expensive category, roughly $0.01 to $0.14 per message depending on country. - **Utility** - order updates, receipts, appointment reminders tied to a transaction. Much cheaper than marketing, and free when sent inside an open 24-hour service window. - **Authentication** - one-time passcodes and login codes. Priced low, with a separate higher rate in nine markets for cross-border codes. - **Service** - your non-template replies to a customer inside the 24-hour window. Free. Two free windows matter for your bill. When a customer messages you first, a 24-hour customer service window opens, and your non-template replies inside it cost nothing. And when a customer reaches you through an ad that clicks to WhatsApp or a Page call-to-action, a 72-hour free-entry window opens where any message you send is free. The catch is that none of this includes the vendor. The API has no consumer-facing app. You reach it through a Business Solution Provider, and that provider charges a monthly platform fee, a per-message markup, or both on top of Meta's rate. So when you compare **whatsapp business api vs app pricing**, remember the app is a free download and the API is a metered utility with a middleman. [image: Hands reviewing printed cost figures and a calculator, evaluating WhatsApp Business API pricing] ## Who is the WhatsApp Business API genuinely worth it for? The API is worth it when you send high volumes of automated, transactional messages that a human can't send by hand. Think thousands of order confirmations, shipping updates, appointment reminders, or login codes per day. At that scale, per-message pricing is cheaper than staff time, and the automation and integration the API provides pays for itself. The clearest fits share a few traits. You have a real system to connect it to, like an e-commerce backend, a booking platform, or a CRM that fires events. You need messages to send programmatically, triggered by an order or a signup, not typed by a person. And you have the volume to justify the setup, because verification and integration are a real project, not an afternoon. A logistics operator sending 10,000 delivery notifications a day is the textbook case. So is a bank sending authentication codes, or a retailer running large opt-in marketing broadcasts through an approved template. As one operations lead running a mid-size online store put it: "We didn't move to the API because we wanted to. We moved because a human physically could not send 4,000 shipping updates before noon." If that's you, the answer to **is whatsapp business api worth it** is yes. The cost is real, but it maps to volume you already have. For everyone below that line, the math gets shakier. A solo consultant, a local clinic, a coaching business, or a small agency sending a few dozen to a few hundred messages a day rarely clears the bar. You'd pay setup effort and per-message fees to automate a volume you could handle from your own number. ## When should you NOT use the WhatsApp Business API? You should not use the WhatsApp Business API when your volume is low, your messages are personal, or you just want to schedule and send from your own number. If you send a few dozen or a few hundred messages a day, need conversational back-and-forth, or don't have a system to integrate, the API's cost and setup outweigh the benefit. This is the core of knowing **when to use whatsapp business api**. Concrete signals you're on the wrong side of the line: 1. **You'd be sending mostly one-to-one, personal messages.** The API shines at templated, automated sends. A real conversation from your own number doesn't need it. 2. **You have no backend to trigger messages.** The API's value is programmatic sending. Without an order system, CRM, or app firing events, you're paying for a pipe you'll fill by hand anyway. 3. **Your number matters to your brand.** API messages go out from a separate business number that customers may not recognize. If replies land on a number nobody watches, you've broken the conversation. 4. **You want it running this week.** Business verification, a solution provider contract, and template approvals take days to weeks. That's fine for a platform migration and painful for a small team that just wants Monday's reminders to go out. 5. **Marketing templates are your main use.** Marketing is the priciest category and, per Meta's docs, does not earn the volume discounts that utility and authentication messages do. Sending promos through the API can get expensive fast. If two or more of those describe you, the API is effort and cost you don't need to take on. [image: Small cafe owner using a phone behind the counter] ## What can the free WhatsApp Business app not do (the limitations pushing people to the API)? The free WhatsApp Business app can't schedule outbound messages, can't broadcast beyond a 256-contact limit, can't run on multiple agents cleanly, and offers no true automation for messages you choose to send. These **whatsapp business app limitations** are exactly what push growing businesses to consider the API in the first place. Here's what the app actually gives you, and where it stops: | What you want to do | Free WhatsApp Business app | Needs more | |---|---|---| | Auto-reply to inbound messages (greeting/away) | Yes | No | | Save quick-reply templates you send by hand | Yes | No | | Schedule a message to send later | No | Yes | | Broadcast to a large audience | Broadcast lists cap at 256 recipients | Yes | | Recurring reminders | No | Yes | | Programmatic, event-triggered sends | No | API | The most common misread is the app's automation. Greeting messages and away messages are real, but they are reactive. They fire only when someone messages you first. The app has no native scheduler and no way to send an outbound message at a time you pick. If you've searched for a "schedule" button in WhatsApp Business, that's why you couldn't find it. There isn't one. Our [WhatsApp Business App vs API breakdown](https://blueticks.co/blog/whatsapp-business-app-vs-api) walks through the full feature gap. So people hit a wall. They outgrow the free app's manual limits but don't have the volume or the backend to justify the API. That gap is where most small businesses actually live. **Skip the API application and the per-message fees.** If what you really need is to schedule and broadcast from your own WhatsApp number, you can [start free with the Blueticks Chrome extension](https://blueticks.co/signup) and have scheduled messages going out today, with no verification, no solution provider, and no metered billing. ## Is there a middle ground between the app and the API? Yes. There's a large middle ground between the free app and the full API: browser-based scheduling tools that run alongside WhatsApp Web and send from your existing number. They add scheduling, recurring messages, and multi-contact campaigns without Meta verification, per-message pricing, or a separate business number. For most small and mid-size senders, this is the right tier. The three-tier reality of **whatsapp business solution comparison** looks like this: - **Tier 1 - Free WhatsApp Business app.** Great for inbound auto-replies and a personal-scale conversation load. No scheduling, no real broadcasting, no outbound automation. - **Tier 2 - Browser-based scheduler.** Sits on top of WhatsApp Web, so you keep your own number and your existing chats. Adds scheduled sends, recurring messages, and campaigns to multiple contacts. No API, no verification, no per-message fee. - **Tier 3 - WhatsApp Business API.** Programmatic, high-volume, integrated. Worth the cost and setup only when you're sending thousands of automated messages against a real system. Most guides jump straight from Tier 1 to Tier 3 because the vendors writing them sell Tier 3. That skips the tier where most businesses belong. If you send scheduled reminders, weekly nudges, or a few hundred campaign messages a day from a number your customers already know, Tier 2 covers you at a fraction of the effort. Our [readiness checklist before you apply for the API](https://blueticks.co/blog/do-i-need-whatsapp-business-api) helps you confirm which tier you're actually in. ## How Blueticks lets you schedule and send from your own number without the API Blueticks is a Chrome extension and web dashboard that runs alongside WhatsApp Web, so you schedule and send messages from your own WhatsApp number without touching the API. There's no Meta application, no business verification, no solution provider, and no per-message billing. You install the extension, open WhatsApp Web, and a scheduling control appears right in your chats. To be clear about what Blueticks is and isn't: it's a Chrome extension plus a web dashboard. There's no separate mobile app to install, and it doesn't route your messages through the WhatsApp Business API. It works with your existing WhatsApp account through WhatsApp Web, which is why your number, your chats, and your history stay exactly where they are. What that gets you in the middle tier: - **Scheduled one-time messages** to any contact, group, or community, sent at a date and time you pick. - **Recurring messages** for reminders and nudges you'd otherwise recreate every week. - **Campaigns to multiple contacts** with per-recipient personalization, without exporting anyone into a separate platform. - **Offline delivery** through a persistent gateway, so scheduled sends can go out even when your computer is closed. Because it's your own number, replies come straight back into your normal WhatsApp inbox. No customer confusion about an unfamiliar business number, and no free-entry-window math to chase. You're not managing message categories or template approvals, you're just sending WhatsApp messages on a schedule. This is the practical answer for the businesses stuck between "the free app can't do it" and "the API is overkill." You get the scheduling and broadcasting that pushed you to look at the API in the first place, without the cost structure or the setup that made you hesitate. [image: Open laptop and smartphone on a tidy desk representing scheduling WhatsApp from your own number] ## Which WhatsApp Business solution should you pick? (a quick decision guide) Pick the free app if you only need inbound auto-replies. Pick a browser-based scheduler like Blueticks if you need to schedule, broadcast, or run recurring messages from your own number at small-to-mid volume. Pick the WhatsApp Business API only if you send thousands of automated, event-triggered messages against a real backend system. That's the whole **which whatsapp business solution** decision in three lines. A quick way to place yourself: | Your situation | Best fit | |---|---| | A handful of inbound chats, want an auto-reply | Free WhatsApp Business app | | Want to schedule messages or send weekly reminders | Browser-based scheduler (Blueticks) | | Running campaigns to a few hundred contacts from your own number | Browser-based scheduler (Blueticks) | | Thousands of automated order/shipping/OTP messages daily | WhatsApp Business API | | Integrating WhatsApp into an e-commerce or CRM backend | WhatsApp Business API | The honest read for 2026: the API is a genuinely good product for the businesses it's built for, and an expensive detour for the ones it isn't. If your real need is scheduling and sending on your own terms, you don't need to apply for anything. You need a scheduler. ## FAQ **Is the WhatsApp Business API free?** No. The app is free, but the API is billed per message. Since July 1, 2025, Meta charges by message category and recipient country, and your solution provider adds its own fee on top. Service replies inside the 24-hour customer window are free, per Meta's pricing docs. **Do I need the WhatsApp Business API just to schedule messages?** No. The API is built for high-volume automated sending against a backend system. To schedule and send from your own number, a browser-based tool like the Blueticks Chrome extension does it without any API, verification, or per-message fee. **What's the difference in whatsapp business api vs app pricing?** The free WhatsApp Business app costs nothing to download and use, but can't schedule or broadcast at scale. The API has no upfront license but meters every marketing, utility, and authentication template you send, plus a vendor markup. One is free and limited, the other is powerful and metered. **Can I send from my own WhatsApp number without the API?** Yes. Tools that run alongside WhatsApp Web, like Blueticks, send from your existing number and keep your chats and history intact. The API instead routes messages through a separate business number set up during verification. **When should a small business actually move to the API?** When manual and scheduled sending can no longer keep up, typically thousands of automated, event-triggered messages a day tied to a real system. Below that, the setup effort and per-message cost usually outweigh the benefit, and a scheduler is the better fit. --- # Best Tool to Schedule and Automate WhatsApp Messages in 2026 (Schedule vs Automate, Compared) > Scheduling and automating WhatsApp are two different jobs. Here's what each one means, why the app can't do either, and the fastest reliable way to do both. URL: https://blueticks.co/blog/best-tool-schedule-automate-whatsapp-messages Published: 2026-07-03 Author: Daniel Roth Category: productivity You want a message to go out at 8 AM without you being awake for it. Or you want the same reminder to fire every Monday, forever, without touching it. Those are two different jobs, and most "WhatsApp automation" guides blur them together, then point you at a tool that does neither well. This piece separates scheduling from automation, shows why WhatsApp itself does almost none of it, and compares the real options so you can pick one and move on. ## What's the difference between scheduling and automating WhatsApp messages? Scheduling means you pick a message and a time, and it sends once at that time. Automating means the message sends on a rule or a repeat, like every Friday or after a first reply, without you setting each send. Scheduling is a single timed send. Automation is a standing instruction. Most people who search "automate whatsapp messages" actually want a mix of both. Here's the split in plain terms: - Schedule - one message, one future time, sends once. - Recurring schedule - one message, a repeat pattern (daily, weekly, monthly). - Follow-up automation - a message that fires based on a prior send or a reply. - Bulk send - the same message to many contacts, at a chosen time. You can want just one of these. A freelancer scheduling a 9 AM good-morning to a client needs the first row. A gym owner sending a weekly class reminder needs the second. A shop chasing quote replies needs the third. Knowing which row you're in tells you which tool to pick, because no single native feature covers all four. ## Can you schedule or automate WhatsApp messages natively (and why the app falls short)? No. Neither WhatsApp nor WhatsApp Business has a native "send later" scheduler, and neither lets you set an outbound message to fire at a time you choose. WhatsApp Business adds greeting, away, and quick-reply tools, but those only react to incoming messages. There is no button to send your own message at 8 AM tomorrow. That surprises people, so let me be specific about what the Business app actually gives you. Per the WhatsApp Help Center, a greeting message goes out automatically to anyone who messages you for the first time, or who messages again after 14 days of silence. An away message auto-replies when someone contacts you outside hours you set. Quick replies are saved templates you fire by typing a shortcut like `/hours`. Notice the pattern: all three wait for the other person to message first. They are inbound auto-replies. None of them can send a fresh outbound message on a clock. [image: Sticky note reminder on a wooden desk beside a face-down phone, hinting at scheduled WhatsApp messages] So when you search "does whatsapp have scheduled messages," the honest answer is that the app has reactive automation and zero proactive scheduling. If you want to auto send a WhatsApp message at a specific time, or run any recurring or follow-up sequence, you're leaving the native app. The only real choices are an Android automation app, the WhatsApp Business Platform (the API), or a browser tool that runs on top of WhatsApp Web. ## What should the best WhatsApp schedule-and-automate tool actually do? The best tool to schedule WhatsApp messages should send from your own number, run one-time and recurring schedules, handle follow-ups, do bulk sends with personalization, and not require code or a per-message contract. It should send even when you're not watching, and it should be honest about what breaks. Anything that only fakes a reminder isn't a scheduler. Use this as a checklist when you compare options: | Capability | Why it matters | |---|---| | Sends from your existing number | No new business number, no re-verifying contacts | | One-time scheduling | The 8 AM send you won't be awake for | | Recurring schedules | Weekly reminders you set once | | Follow-up automation | Chase non-repliers without watching the chat | | Bulk with personalization | One campaign, many contacts, first name filled in | | No code, no API onboarding | You start today, not next month | | Sends unattended | The message goes out even if you've closed the tab | A tool that hits every row is rare. Most cover two or three. The gaps below are where people get burned, so weigh them against the row you actually need. [Set your first auto-send from your own number in under a minute](https://blueticks.co/signup) instead of onboarding a whole API. Skip the per-message fees, skip the second business number, and keep sending as yourself. ## How do the main ways to automate WhatsApp messages compare (Android automation apps vs WhatsApp Business API vs a browser tool)? Three approaches dominate. Android automation apps (Tasker, MacroDroid, SKEDit) drive the app through accessibility permissions. The WhatsApp Business Platform (the Cloud API) sends programmatically but bills per message and needs developer setup. A browser extension runs inside WhatsApp Web and sends from your existing number with no code. Each wins for a different user. Here's the trade-off laid out: | Approach | Setup | Cost model | Best for | Main risk | |---|---|---|---|---| | Android automation apps | Accessibility permissions, per-message macros | Free / cheap | One phone, light personal use | Breaks on WhatsApp app updates; phone must be on and unlocked | | WhatsApp Business Platform (API) | Developer onboarding, a provider, template approval | Per-message billing | High-volume, coded systems | Cost and complexity; new number; templates need pre-approval | | Browser extension (WhatsApp Web) | Install, open WhatsApp Web | Free tier + paid plans | Individuals and small teams who want it working today | Needs a machine online at send time (unless offline mode) | The API deserves a note on cost, because "automate WhatsApp messages" content often waves at it as if it were free. It isn't. Meta moved the WhatsApp Business Platform to per-message pricing on July 1, 2025. Each marketing, utility, or authentication template you send is billed by category and country. A marketing template to a US number runs about $0.025 a message at published rates. Customer-initiated service messages inside the 24-hour service window are free, and messages sent within 72 hours of someone tapping a Click-to-WhatsApp ad are free too, per Meta's pricing docs. But a cold scheduled reminder to 500 people is 500 billed marketing templates. For a solo user or a small shop, that's a lot of overhead for "send this at 8 AM." Android apps are free but fragile. They lean on accessibility services, and WhatsApp ships app updates that quietly move buttons the macro was tapping. When that happens the automation silently stops, usually the week you needed it most. ## How do you auto-send a WhatsApp message at a specific time — reliably? The reliable way to auto send a WhatsApp message at a specific time is a WhatsApp automation extension running on WhatsApp Web: open the chat, set the message, pick the date and time, and it sends from your own number at that moment. No API, no new number, no manual tap at send time. The one requirement is a browser session that's online when the clock hits. The workflow with the Blueticks extension looks like this: 1. Install the extension and open [WhatsApp Web](https://blueticks.co/blog/schedule-whatsapp-web-messages) in Chrome. 2. Open the chat you want, individual or group. 3. Click the clock icon that appears in the message bar. 4. Type your message. 5. Pick the date and set the exact time. 6. Click Schedule. The message queues and sends at the time you set, from your number, showing up in the recipient's chat like anything else you typed. There's no "sent via a tool" label. You can edit or cancel it before it fires. **What breaks:** this path needs a machine online at send time. If your laptop is asleep or offline, the message waits for the connection to come back rather than sending on the dot. For anything time-critical, either use a machine that stays on, or turn on Blueticks' offline gateway mode, which runs the session on a persistent cloud connection so the send happens whether your browser is open or not. And don't open WhatsApp Web in a second tab or a second browser at the same time. WhatsApp allows one active web session, and opening another can knock out the one holding your queue. ## How do you automate recurring and follow-up WhatsApp messages without the API? You automate recurring WhatsApp messages by scheduling one message with a repeat pattern, and you automate follow-ups by scheduling a later message conditioned on the first. A browser extension does both without the API: set a weekly or monthly recurrence once, or queue a "still interested?" follow-up dated a few days out. You write it once; the tool handles every future send. For a recurring message, the steps add one checkbox to the schedule flow: 1. Open the scheduler on the chat. 2. Write the message. 3. Set the first send date and time. 4. Turn on custom recurrence. 5. Choose daily, weekly, monthly, or a custom interval. 6. Schedule it. That covers the Monday standup nudge, the monthly invoice reminder, the daily check-in. You can pause or cancel any of them from the dashboard without deleting the pattern. See the full walkthrough on [recurring WhatsApp messages](https://blueticks.co/blog/schedule-recurring-whatsapp-messages) for edge cases like skipping a single occurrence. Follow-ups are the other half of how to send automated WhatsApp messages that feel human. Instead of a blast, you queue a second message a few days after the first, so a non-replier gets one gentle nudge on schedule. One operator I spoke to runs quote follow-ups this way: "I schedule the quote, then a two-line follow-up three days later. If they've already replied, I cancel it. My reply rate on quotes went up without me babysitting the chat." That's automation doing what it should, quietly, on your terms. [image: Paper weekly planner marked with recurring reminders next to a coffee cup on a desk] ## Which tool should you pick? (best pick by use case: personal reminders, small-business follow-ups, bulk campaigns) Pick by the job. For personal reminders and timed one-off sends, a browser extension on WhatsApp Web is the simplest reliable option. For small-business follow-ups and recurring nudges, the same extension with recurrence and offline mode covers it. For very high-volume, coded, multi-country campaigns, the WhatsApp Business Platform (the API) is the built-for-scale answer, at per-message cost. Matched to the four jobs from the top of this piece: - **Personal reminders / timed sends** - Browser extension. You want one-time scheduling from your own number, no billing, no setup. An Android app can work for a single phone, but it breaks on updates. - **Small-business follow-ups and recurring** - Browser extension with recurrence plus offline gateway. You set weekly reminders once and queue follow-ups that fire without you. - **Bulk campaigns to a list** - Extension bulk send for hundreds to low thousands from your number with personalization, or the API if you're at real scale with a dev team and a budget for per-message fees. - **Coded, event-driven systems at scale** - The API, full stop. If a message needs to fire from your backend when an order ships, that's API territory. One reality check on bulk. WhatsApp broadcast lists in the app cap at 256 contacts, must have your number saved to receive anything, and aren't supported on WhatsApp Web at all, per the Help Center. That's why "just use a broadcast list" falls apart past a small circle. A scheduling tool that sends individual messages sidesteps the broadcast-list rules, but you still owe your recipients real consent. See [the best apps to schedule WhatsApp messages](https://blueticks.co/blog/best-apps-to-schedule-whatsapp-messages) for a ranked breakdown by use case. ## What native scheduling and automation can't do — and how Blueticks adds it Native WhatsApp can't send an outbound message at a time you choose, can't repeat one on a schedule, and can't chase a non-replier. It only auto-replies to inbound messages. Blueticks adds the missing outbound layer: one-time scheduling, recurring sends, follow-ups, and bulk campaigns, all from your existing number inside WhatsApp Web, with no API and no code. Blueticks is a Chrome extension plus a web dashboard. There's no mobile app, and it doesn't ask you to spin up a second business number or wait on template approvals. You install it, open WhatsApp Web, and a clock icon shows up in every chat's message bar. From there you get the whole outbound set the app is missing: schedule a single message, set a recurrence, queue a follow-up, or send a personalized campaign to a list. The offline gateway mode keeps sends running when your browser is closed, which is the piece the plain extension approach can't promise on its own. Where the API charges per marketing template and asks for developer setup, this sends as you, from your number, on the free tier for basic scheduling, with paid plans for recurrence, offline delivery, and higher volume. It won't replace a coded, backend-triggered system at massive scale. For the person who just wants messages to go out on time, and to stop doing it by hand, it's the shortest path. [image: Closed laptop on a desk in evening light representing WhatsApp messages sending unattended] ## FAQ ### Can you automate WhatsApp messages without coding or the Business API? Yes. A WhatsApp automation extension that runs on WhatsApp Web schedules one-time, recurring, and follow-up messages from your existing number with no code and no API onboarding. Android automation apps also work on a single phone, though they rely on accessibility permissions and can break when WhatsApp updates its app. The API is only necessary for high-volume, backend-triggered systems. ### What's the best free tool to schedule WhatsApp messages? The Blueticks extension has a free plan that covers basic one-time scheduling from your own number, which handles most personal and light business use. Recurring schedules, follow-ups, offline delivery, and higher-volume sending sit on paid tiers. Android apps like SKEDit are also free but depend on accessibility services and an unlocked, powered-on phone at send time. ### Is automating WhatsApp messages against WhatsApp's rules? Using automation for legitimate messaging, reminders, follow-ups, coordinated announcements to people who expect to hear from you, is normal use. WhatsApp's terms prohibit bulk unsolicited messaging and spam-like behavior. Scheduling a client reminder is fine. Blasting thousands of cold messages to people who never opted in can get your number banned, whether you send them by hand or on a schedule. ### Does scheduling a message tip off the recipient that it was automated? No. A scheduled or automated message lands in the recipient's chat exactly like one you typed in the moment. There's no badge, timestamp difference, or "sent via" note. It arrives from your number as a normal message. ### Can I schedule the same message to lots of contacts at once? Yes, with a bulk-capable tool. A scheduling extension sends individual personalized messages to each contact at your chosen time, which avoids WhatsApp's 256-contact broadcast-list cap and its rule that recipients must have saved your number. You still need genuine consent from everyone on the list. --- # WhatsApp Campaign Software: How to Send & Track Bulk WhatsApp Campaigns (2026) > How WhatsApp campaign software actually works: segment, send, track, and follow up on bulk campaigns without paying per-message API fees or wiring up the Business API. URL: https://blueticks.co/blog/whatsapp-campaign-software Published: 2026-07-02 Author: Maya Cohen Category: marketing You have a list of 800 customers and a promo that expires Friday. WhatsApp gets a 98% open rate. Email gets 20%. So why is sending that promo to 800 people on WhatsApp so painful? Because the WhatsApp Business app caps broadcast lists at 256, silently drops messages to anyone who hasn't saved your number, and gives you zero reporting once you hit send. And the "official" fix, the WhatsApp Business API, means per-message fees and a setup project. This is the gap WhatsApp campaign software fills. Here is how it works, how to run a campaign end to end, and how to pick the right tool for your volume. ## What is WhatsApp campaign software (and what job does it do)? WhatsApp campaign software is a tool that sends one message to many recipients at once, personalizes it per contact, and shows the delivery status of each send. It replaces manual broadcast lists with a managed send you can schedule, segment, and measure, so a bulk WhatsApp campaign behaves like an email campaign instead of 40 copy-pastes. The confusion usually starts here: people assume "campaign software" means the WhatsApp Business API. It does not have to. There are two categories, and they solve the same four jobs at very different cost and complexity levels. We compare them in detail below. ### The four jobs: segment, send, see what happened, follow up Every tool worth paying for does these four things. If it only does the second one, it is a blaster, not campaign software. - **Segment a list** - group contacts by tag, label, source, or spreadsheet column so the right message reaches the right people. - **Send the broadcast** - deliver one personalized message to the whole segment, paced so it stays deliverable. - **See what happened** - per-message send and delivery status, plus reads that show as WhatsApp's own blue ticks and replies that come to your WhatsApp inbox. - **Trigger follow-ups** - schedule a reminder or a second-touch to non-repliers without re-sending to everyone. Miss any one of these and you are back to guessing. A blast with no tracking is a campaign you can't measure, and a campaign you can't measure is a campaign you can't improve. [image: segmented contact list planning] ## How do you run a bulk WhatsApp campaign, step by step? Run a bulk WhatsApp campaign in four steps: build and segment your recipient list, write and personalize the message, send it paced across the list to protect deliverability, then watch delivery status and let reads and replies come back through WhatsApp so you can follow up. The whole flow takes under 15 minutes once your list is ready. Here is each step in practice. ### Step 1 - build and segment your recipient list Start with a clean list. Import contacts from a spreadsheet, a CRM export, or tags you already keep. Then segment: "customers who bought in the last 90 days," "trial users," "VIP." A tighter segment beats a bigger one every time, because relevance is what keeps your reply rate up and your block rate down. One WhatsApp-specific gotcha to plan around: in the plain Business app, broadcast recipients only receive your message if they have saved your number. Campaign software that sends through your own WhatsApp account inherits the same reality for cold lists, so warm your audience first or lead with opt-in. If you are wrestling with the 256-per-list cap, [our WhatsApp broadcast limit guide](https://blueticks.co/blog/whatsapp-broadcast-limit) covers how to move past it cleanly. ### Step 2 - write the message (and personalize it) Write like a person, not a press release. Lead with the value, keep it under 4 lines, and use one clear call to action. Then personalize: `Hi {{first_name}}, your {{plan}} renews Friday` reads completely differently from a generic blast, and recipients can tell. Personalization is not cosmetic. Merge fields let one campaign feel like 800 individual messages, which is the entire reason WhatsApp beats a bulk email in reply rate. Pull the personalization values straight from your spreadsheet columns; [scheduling a bulk send from a spreadsheet](https://blueticks.co/blog/bulk-schedule-whatsapp-messages-from-spreadsheet) walks through mapping those fields. ### Step 3 - send the bulk campaign and pace it to stay deliverable Do not fire 800 messages in 30 seconds. WhatsApp's spam systems read a sudden identical-message spike as automation, and that is how numbers get flagged. Good campaign software staggers sends with a delay between each message and lets you schedule the whole run for a sensible send-time. Pacing is also a strategy lever. A promo that lands at 10 a.m. local time outperforms the same promo at 2 a.m. If you want the send to go out while you are asleep, [scheduling WhatsApp messages](https://blueticks.co/blog/schedule-whatsapp-messages) is the cluster to read. Start small, watch the first batch land, then scale, especially on a fresh number. [image: laptop desk morning send] ### Step 4 - watch delivery status, reads, and replies This is the step manual broadcasts can't do at all. After the send, campaign software shows the per-message delivery status (which went out, which failed); reads then show as WhatsApp's own blue ticks in each chat, and replies come straight to your WhatsApp inbox. That turns a fire-and-forget blast into something you can actually follow up on, message by message. Replies are the gold. WhatsApp campaigns generate inbound conversations that email never does, and speed matters: the MIT / InsideSales Lead Response Management study found firms that follow up within 5 minutes are 21x more likely to qualify a lead than those who wait 30 minutes. Route those replies to a human fast. ## Do you need the WhatsApp Business API to send campaigns? No. You need the WhatsApp Business API only at high volume or for automated transactional messaging at scale. For most promotional campaigns to a few hundred or a few thousand contacts, a WhatsApp Web based tool sends from your existing number with no API application, no per-message fee, and no template pre-approval. The API is a real product with real strengths: verified green-tick branding, unlimited scale, and official Meta support. But it comes with cost. Since July 1, 2025, Meta bills the API per message, and marketing templates run from roughly $0.0094 per message in India to over $0.12 in Germany, with the US around $0.025, per Meta's WhatsApp Business Platform pricing. On a 5,000-recipient US campaign that is about $125 per send, every send, plus the setup and a Business Solution Provider markup on top. For a lot of small and mid-size teams, that math does not clear. A WhatsApp Web tool sends the same campaign from the same number you already use, at a flat software price. The tradeoff: it is your personal or Business-app number, so you respect the same volume norms a human would. Send your first bulk WhatsApp campaign free, with no Business API setup and no per-message fees, straight from WhatsApp Web. [Start free on Blueticks](https://blueticks.co/signup) and send from your own number in under 15 minutes. ## WhatsApp campaign software compared: API platforms vs. WhatsApp Web tools API platforms and WhatsApp Web tools both send bulk campaigns, but they differ on cost, scale, and setup. API platforms charge per message and require a Meta application and template approval; WhatsApp Web tools charge a flat software fee and send from your existing number with no approval. Pick by volume: API for tens of thousands, WhatsApp Web for hundreds to low thousands. | Factor | WhatsApp Business API platforms | WhatsApp Web campaign tools | |---|---|---| | Per-message cost | ~$0.0094 to $0.12+ per marketing message (Meta, effective Jul 2025) | None; flat software fee | | Setup | Meta application, phone verification, template approval | Connect your existing WhatsApp; minutes | | Sending number | New API-registered number | Your current WhatsApp / Business number | | Template approval | Required before each new marketing template | Not required; write freely | | Best volume | Tens of thousands+ | Hundreds to low thousands | | Personalization | Yes, via template variables | Yes, via merge fields | | Delivery status + reads | Yes (delivery/read webhooks) | Per-message send status in-app; reads via WhatsApp's blue ticks | | Green-tick verified brand | Yes | No | The honest read: if you send 50,000 utility messages a day, the API is built for you. If you send a weekly promo to 900 customers, a WhatsApp Web tool does the job for a fraction of the cost and none of the setup. Most teams reading a "campaign software" guide are in the second bucket. ## What can the WhatsApp Business app's broadcast lists NOT do, and how Blueticks adds it? The WhatsApp Business app's broadcast lists cap out at 256 contacts per list, only reach recipients who have saved your number, can't be sent from WhatsApp Web, and give you no per-recipient send status. Campaign software like Blueticks removes the 256 cap, sends from WhatsApp Web, personalizes per recipient, and shows the send status of each message. Here is the concrete gap. In the plain app you build a 256-person list by hand, hit send, and get nothing back: no per-recipient status, no read count, no way to see who replied without opening 256 chats. And you have to do it from your phone. Blueticks closes each of those gaps. It sends bulk WhatsApp message campaigns from WhatsApp Web on your existing number, past the 256-per-list ceiling, with merge-field personalization, paced sending to protect deliverability, and per-message send status after the send (reads still show as WhatsApp's blue ticks, and replies land in your inbox). You can schedule the whole campaign for a specific send-time or set it recurring. If you are on the Free plan, campaigns still go out, appended with a small "Powered by blueticks.co" footer; Pro removes the footer. The 256-cap workaround itself is covered in depth in [the broadcast limit article](https://blueticks.co/blog/whatsapp-broadcast-limit). [image: small business owner phone reply] ## WhatsApp promotional campaign examples that convert The WhatsApp promotional campaigns that convert best are time-bound and personal: flash-sale alerts, back-in-stock notices, cart-recovery nudges, appointment reminders, and re-engagement messages to lapsed customers. Each works because it lands in an app people read within minutes and invites a one-tap reply, not a click into a landing page. A few patterns worth stealing: - **Flash sale, tight window.** "48 hours only" plus a personalized product line. Urgency + relevance is the whole play. - **Back-in-stock.** Notify the exact people who asked. Near-100% relevance, high reply rate. - **Cart recovery.** A single nudge 2 hours after abandonment beats a 4-email drip in reply speed. - **Appointment / renewal reminder.** Utility framing, low block risk, high open. - **Win-back.** "We miss you, here's 15% off" to customers dormant 90+ days. Here is a case-study spine to make it concrete. **Cedar & Fern, a mid-size home-goods retailer, tried a WhatsApp campaign for a weekend flash sale.** They segmented 1,200 past buyers, personalized each message with the customer's first name and last-purchased category, and scheduled the send for Saturday 10 a.m. Result: 94% delivered, 68% read within the first hour, and 11% replied to ask about stock, which their team converted at roughly 4x their usual email promo. As their marketing lead put it: *"The replies were the surprise. Email gives you clicks. WhatsApp gave us conversations we could actually close."* (Illustrative composite; numbers reflect a realistic WhatsApp-campaign range.) ## How do you measure whether a WhatsApp campaign worked? Think about a WhatsApp campaign on five numbers: delivery rate (reached / sent, which your send status shows directly), read rate (the blue ticks you can see per chat), reply rate (replies / delivered, gauged from your inbox), click or conversion rate (the action you wanted), and revenue per send. Delivery status tells you the message went out; replies and conversions tell you it worked. Benchmarks to anchor against: WhatsApp marketing messages see 85% to 98% open rates versus roughly 20% for email, per widely cited 2025 industry data. So a read rate under 70% is a signal, usually a cold list (unsaved numbers) or bad send-time, not a bad offer. Treat replies as your real engagement signal, because a reply on WhatsApp is a live conversation, and tie conversions back to the send with a per-campaign tag or link so you can attribute revenue per send, not just vanity opens. ## FAQ **What is WhatsApp campaign management?** WhatsApp campaign management is the practice of planning, segmenting, sending, and measuring bulk WhatsApp campaigns, then following up on replies. Campaign software handles the mechanics: it groups your contacts, personalizes and paces the send, and shows the send status of each message so you can act on the results. **How do you run a WhatsApp campaign without the Business API?** Use a WhatsApp Web campaign tool that sends from your existing number. You import and segment your list, write a personalized message, schedule a paced send, and see per-message delivery status (with reads and replies coming back through WhatsApp), all without a Meta API application, template approval, or per-message fees. It suits campaigns of a few hundred to a few thousand recipients. **Is sending bulk WhatsApp messages allowed?** Yes, when recipients expect to hear from you (opt-in, existing customers) and you pace sends to look human. WhatsApp bans unsolicited spam and flags sudden bursts of identical messages, so segment tightly, warm your list, stagger the send, and start small on a new number to stay deliverable. **What are good WhatsApp promotional campaign examples?** Flash-sale alerts, back-in-stock notices, cart-recovery nudges, appointment or renewal reminders, and win-back messages to lapsed customers. Time-bound, personalized, one-CTA messages convert best because WhatsApp is read within minutes and invites a direct reply. **How many contacts can I send a WhatsApp campaign to?** The WhatsApp Business app's broadcast lists cap at 256 contacts per list, and only reach people who saved your number. Campaign software removes the per-list cap so you can send one paced campaign to your whole segment from WhatsApp Web, with per-message send status. **How much does WhatsApp campaign software cost?** It depends on the model. WhatsApp Business API platforms charge per message, roughly $0.0094 to $0.12+ per marketing message as of Meta's July 2025 pricing, plus provider fees. WhatsApp Web tools charge a flat software fee with no per-message cost; Blueticks has a Free plan (with a "Powered by blueticks.co" footer) and a Pro plan that removes it. --- # How to Automate WhatsApp with AI in 2026: Claude + MCP Recipes (No Code) > You describe the workflow in plain English, and Claude runs it on your own WhatsApp number. Four real recipes for automating WhatsApp with AI, plus the honest limits nobody mentions. URL: https://blueticks.co/blog/automate-whatsapp-with-ai Published: 2026-07-01 Author: Daniel Roth Category: productivity You already know the parts of WhatsApp that eat your day. The follow-up you meant to send Thursday. The forty threads you scroll every morning to find the two that need you. The list of leads you keep telling yourself you'll message "later." None of it is hard. It's just constant, and it doesn't fit in a keyboard. The shift in 2026 is that you can hand most of it to an AI assistant by describing what you want in a sentence. Not a chatbot builder, not a visual flow canvas, not a Meta Business account. You say "follow up with everyone who hasn't replied, one message a minute," and Claude does it on your own number. This guide is four working recipes for that, plus the failure modes I've watched people hit. Every recipe maps to a real tool, and I'll flag the moment any of them stops being frictionless. ## What does it mean to automate WhatsApp with AI, and what do you actually need? Automating WhatsApp with AI means an assistant like Claude reads your chats, drafts replies, and sends or schedules messages on your behalf, driven by plain-English instructions instead of a form or a script. You need your existing WhatsApp number connected to Blueticks and the Blueticks MCP added to Claude, which you authorize with a quick login or an API key. No coding, no Meta verification. The connective tissue is MCP, the Model Context Protocol, the open standard Anthropic introduced in late 2024 that lets an AI model call external tools through one shared interface. The Blueticks MCP server exposes WhatsApp actions, reading, sending, scheduling, campaigns, audiences, contacts, groups, and webhooks, as tools Claude can pick from. You type intent; Claude chooses the tool. There is nothing to wire up between them. What it is not: a second number, a way around WhatsApp's rules, or an always-on bot that decides on its own to message people. It runs on the number you already use, over WhatsApp Web transport, and it acts when you tell it to. That distinction matters, and I'll come back to it in the safety section. For the full tool inventory and the read-first philosophy, the [WhatsApp MCP pillar](/blog/whatsapp-mcp) is the source of truth. ## Step 1: Connect Claude to your WhatsApp number in about 2 minutes Connecting takes about two minutes. Link your WhatsApp number to Blueticks by scanning a QR code the way WhatsApp Web works, then connect Claude. The quickest way is the remote connector: add `https://api.blueticks.co/mcp` as a custom connector in Claude and approve access with a login, with nothing to install and no key to store. If you'd rather use an API key, or you're on Claude Code, paste one `@blueticks/mcp` server block into your Claude config instead; the package pulls itself on first run, so Node.js 20 or newer is the only prerequisite. I'm keeping this short on purpose, because the exact file paths differ between Claude Desktop and Claude Code and they change over time. The version-correct config block, where the file lives on your OS, and how to mint a `bt_live_` key all live in the [Blueticks developer docs](https://dev.blueticks.co). Follow those for the precise commands. The full walkthrough is also in the [MCP pillar](/blog/whatsapp-mcp), so I won't re-teach it here. [image: link number desk] One check before you run any recipe: your WhatsApp engine has to be linked first, the same connection that powers Blueticks scheduling in the app. Ask Claude "is my WhatsApp connected?" and it calls the engine tool and tells you. If it says no, the recipes below will fail quietly. Fix the link before you build anything on top of it. ## Recipe 1: Turn a list of leads into a paced follow-up sequence from one sentence You paste a list of numbers and describe the sequence, and Claude builds a reusable audience, sends a personalized first touch, then reads for replies so you can follow up only with the people who went silent. It runs as a paced campaign, not a burst, so the sends spread out over time instead of firing all at once and flagging your number. Here's the exact flow. You tell Claude: > "Create an audience called July Leads from these numbers, then run a campaign: 'Hi \{firstName\}, thanks for the demo request. Want me to send times this week?' Space the sends out." Claude builds the audience with a per-contact `{firstName}` variable, drafts the message, shows it to you, and on your approval schedules a paced campaign against the list. Two or three days later, the follow-up is a second sentence: > "Read the July Leads threads. Who hasn't replied? Make an audience of just those people and send them a one-line nudge." That second step leans on the read path, which is real: Claude lists and reads the threads, tells you who's silent, and you approve a fresh audience of non-responders. You stay in the loop because you're the one confirming the segment. This is not an autonomous "chase everyone forever" bot. It's a human-in-the-loop follow-up you drive in two sentences instead of a spreadsheet and an afternoon. **What breaks:** if you skip the read-and-confirm step and just re-blast the whole list, you'll message people who already replied. Always let Claude read for replies first, then approve the trimmed audience. ## Recipe 2: Build a lightweight WhatsApp AI agent that triages and drafts replies The most useful "agent" isn't one that sends on its own. It's one that reads your pile, ranks what needs a human, and writes the reply for your approval. With the MCP connected, Claude lists and searches your chats, reads the messages inside any thread, looks up contacts, and turns all of it into a triage list plus drafts you sign off on before anything leaves your account. [image: morning triage coffee] The daily driver is one prompt: > "Catch me up on WhatsApp since yesterday and tell me what needs a reply." Claude comes back with a shortlist: a client wants to move a call, a lead asked about pricing, a supplier confirmed a delivery, the rest is handled. You pick one and say "draft a reply confirming Wednesday at 2pm." Claude reads the thread for tone, writes it in your voice, and waits. Nothing sends until you say go. Every action here runs on read-only tools, so this half of the workflow carries essentially zero ban risk. You can run it all day. This matters more than it sounds. The MIT Lead Response Management study found you're 21 times more likely to qualify a lead when you respond within five minutes instead of thirty. The threads that decide deals are the ones buried under group chatter. An agent that surfaces them the moment you sit down is the difference between catching that window and missing it. As one operator running this loop told me, "I used to spend the first hour of my day reading WhatsApp. Now Claude reads it and I spend ten minutes deciding." For the four highest-value read prompts, see the [chief-of-staff section of the pillar](/blog/whatsapp-mcp). ## Try it on your own number: create a free Blueticks account You can read the recipes all day, but the point is to run one. Create a free Blueticks account, link your existing WhatsApp number, add the MCP to Claude, and you can connect and run your first automation in about five minutes, on the number you already use, no Meta verification and no card. The Free plan is enough to feel it. You can link your number, run the read-and-triage loop from Recipe 2, schedule messages, and even run bulk campaigns. Free sends carry a "Powered by blueticks.co" footer and cap single scheduled messages at three at a time; Pro removes the branding and adds offline sending so your laptop doesn't have to stay awake. Start free, then decide. Grab your key and the config block at [dev.blueticks.co](https://dev.blueticks.co) and point Claude at your inbox. ## Recipe 3: Run a plain-English campaign or drip and let AI pace it safely You describe the audience and the message, and Claude runs a paced bulk campaign with pause, resume, and cancel control, all in plain English. Because it's a real campaign and not a loop of individual sends, the messages spread out over time instead of machine-gunning your contacts, which is exactly what keeps your number healthy on a bulk send. Say you're announcing early access: > "Run a campaign to my Early Access audience: 'Hi \{firstName\}, early access opens Monday. Want me to reserve your spot?' Pace it over the next hour." The `{firstName}` token resolves per recipient, so each person gets a message addressed to them, not a generic blast. You keep control by asking: "pause the Early Access campaign," "resume it," "cancel it." Same for a light drip, a first message now and a nudge scheduled a few days out for people who haven't replied, which is Recipe 1's shape reused. [image: paced campaign outdoor] **What breaks:** pacing is a tool, not a guarantee. If you point a campaign at a list of strangers who never opted in, spacing the sends won't save you. WhatsApp's anti-abuse system watches patterns, and a cold list gets flagged regardless of how slowly you send it. Use campaigns for people who expect to hear from you, and start with a small batch before you scale. The mechanics of paced campaigns from Claude are covered in the [scheduling-from-Claude guide](/blog/schedule-whatsapp-messages-from-claude-mcp). ## Recipe 4: Schedule natural-language reminders and recurring nudges You tell Claude what to send and when, in relative time, and it anchors "tomorrow at 9am" to your actual timezone before queuing the send. Scheduling is a first-class capability, not a workaround, so you can list, reschedule, or cancel anything you've queued just by asking. The everyday version is the follow-up you'd otherwise forget: > "Schedule a WhatsApp to this client Friday at 10am asking if they've had a chance to review the proposal." Claude checks your current date, time, and timezone first, drafts it, and on approval queues it for that exact moment. The queue stays conversational: "show me my scheduled messages," "move the client message to 11am," "cancel it." Under the hood the send has to land at least 10 seconds in the future and within 365 days, the same window the underlying API enforces. For a standing nudge, a Monday-morning team check-in, you can schedule each week's instance as you go, or set up native recurring scheduling inside the Blueticks app for a truly repeating send. **What breaks:** a freshly queued message has no WhatsApp delivery key until it actually dispatches, so read receipts populate a moment after it fires, not the instant you schedule it. Ask Claude to check status rather than assuming a queued message already went out. ## How do you keep AI WhatsApp automation safe? Ban-risk, rate limits, and human-in-the-loop The core rule is simple: the MCP reads and sends as you, on your real number, so every WhatsApp rule that applies to you still applies through Claude. Reading is low-risk and you can do it constantly. Sending is where judgment matters. Message only people who expect to hear from you, pace bulk sends through campaigns, and keep the draft-before-send step so nothing dispatches without your nod. Three honest limits worth internalizing: - **This runs over WhatsApp Web, not Meta's Cloud API.** That's what makes it no-code and free of per-template fees, but it also means you're under WhatsApp's normal anti-abuse limits, not inside a Meta-blessed channel. No unofficial tool, Blueticks included, can promise zero ban risk. Behave like a careful human and the risk stays low. - **The session is tied to a linked device.** WhatsApp's multi-device mode links up to four devices to your number. If you log out on your phone, remove that device, or hit the four-device cap, the session drops and queued sends stop. - **Claude acts on your instruction, not its own.** This is not an always-on autonomous agent deciding to message people for you. It schedules and sends when you tell it to, or when you set up a campaign on a schedule you defined. Control stays with you by design. "No verification" is not "no rules." The honest version of this pitch is that you trade Meta's compliance overhead for personal responsibility over how you send. ## Automate with AI + MCP vs. building on the WhatsApp Business API: which should you pick? Pick the AI-plus-MCP path when you want to read and operate your own existing number with a personal feel and near-zero setup. Pick the official WhatsApp Business Platform (Cloud API) when you need Meta-verified, template-based messaging at very high volume with formal opt-in management. They solve different problems, and most small teams start on the first. | | Automate with AI + Blueticks MCP | WhatsApp Business Platform (Cloud API) | | --- | --- | --- | | Reads your chats | Yes, that's the core use | No, it's outbound-focused | | Sends from | Your own connected number | A Meta-registered business number | | Message format | Free-form, as you'd type it | Pre-approved templates for outbound | | Setup | Config block plus a key | Business verification and app review | | Per-message cost | No Meta conversation fee | Metered per conversation by Meta | | Best for | Founders, small teams, triage, personal outreach | Enterprises, high-volume transactional flows | Neither one lets you spam. The Cloud API enforces templates and opt-in at the platform level; the MCP runs through your personal account, so WhatsApp's anti-abuse limits apply to you directly. Meta's own developer documentation is clear that the Cloud API requires business verification and an approved template flow before you can message at scale, which for a solo operator is a multi-day gate. Many teams start on the MCP and move to the Cloud API only when outbound volume forces it. ## What Blueticks adds that a raw MCP server can't Most of the open-source WhatsApp MCP servers only read and send. They have no scheduling, no campaigns, and no reusable audiences, and they need a developer to stand up a local process that dies the moment your laptop sleeps. What Blueticks adds is the whole action half of these recipes, running on a hosted engine you don't babysit. Concretely, the Blueticks MCP is the one that also gives Claude first-class scheduling (the `send_at` window, reschedule, cancel), paced campaigns with pause and resume, and audiences with per-contact variables like `{firstName}`. Developers get the identical capabilities without Claude in the loop by calling the same `/v1` REST API directly, `POST /v1/scheduled-messages` to send or schedule, `POST /v1/campaigns` for a paced send, `POST /v1/webhooks` for signed event callbacks, with an `Idempotency-Key` header so a retry never double-sends. The MCP and the API are two front doors to one engine. The comparison of the [open-source options against Blueticks](/blog/schedule-whatsapp-messages-from-claude-mcp) walks through exactly which tools each server exposes. ## FAQ **Can I really automate WhatsApp with AI without writing code?** Yes. The whole path is plain English: you connect the Blueticks MCP to Claude with one config block and an API key, then describe what you want. Claude picks the right tool and acts on your approval. Developers can drop to the `/v1` REST API, but it's optional. **Does it use my own WhatsApp number or a separate business number?** Your own number. Reading and sending both run through your existing WhatsApp session via the Blueticks engine, over WhatsApp Web transport, so recipients see a normal message from you. You link it once by scanning a QR code. **Will automating WhatsApp with AI get my number banned?** Not if you behave like a human. Reading is low-risk. For sending, message opted-in contacts, pace bulk sends through campaigns, and start small. It runs on your real number under WhatsApp's normal rules, so no unofficial tool can promise zero risk. **Do I need Meta Business verification?** No. That's the point of the own-number path. You skip verification, template pre-approval, and per-template fees. The trade-off is that you carry the flagging and Terms-of-Service risk the official Cloud API doesn't. **Is Claude an autonomous agent that messages people on its own?** No. It acts on your instruction or on a campaign schedule you defined, and it shows you the draft and recipient count before sending. The control and the final approval stay with you. ## Start automating your WhatsApp with AI today Stop treating WhatsApp like a job you clock into every morning. Link your number, add the MCP to Claude, and try the one sentence that runs Recipe 2: "catch me up on WhatsApp and tell me what needs a reply." Then let it draft the answers while you decide. Create a free account and get the setup and your API key at [dev.blueticks.co](https://dev.blueticks.co), and run your first automation in about five minutes on the number you already use. --- # How to Build a WhatsApp Bot in Python on Your Own Number (No Meta Verification, 2026) > A working WhatsApp bot in Python, on the number you already use, without Meta Business verification. Send, receive replies over a webhook, auto-reply to keywords, and schedule messages, with runnable code and the failure modes nobody mentions. URL: https://blueticks.co/blog/build-whatsapp-bot-python Published: 2026-06-30 Author: Daniel Roth Category: productivity You want a WhatsApp bot. Something that answers "PRICE" with your price list, fires a reminder at 9am, and pings you when a customer replies. You sit down to build it in Python and hit the same wall everyone hits: the official path wants you to register a business with Meta, verify it, provision a separate number, and get message templates approved before you can send a single line of text. That's a lot of process for a bot that just needs to talk to people from the number you already use. This guide builds the bot the other way. A WhatsApp bot in Python, running on your existing number, over a plain REST API, with no Meta verification step. Every code sample below runs against the live API. I'll also be straight about what this approach can't do, because there are real trade-offs. ## What a Python WhatsApp bot can actually do (and what it can't) A Python WhatsApp bot can send messages, receive incoming messages through a webhook, auto-reply based on what the sender writes, and schedule messages for a future time. It runs on your own number over a REST API. What it can't promise is the unlimited, guaranteed-delivery, broadcast-at-scale behavior of a verified business platform. Here's the honest split between the two halves. What you get: - **Outbound sends.** Order confirmations, alerts, reminders, follow-ups. Fire on any event in your backend. - **Inbound handling.** A webhook tells your code when someone messages your number back, so the bot can react to replies, not just blast. - **Keyword auto-replies.** Match on the text a sender sends ("HOURS", "STOP", an order number) and respond. - **Scheduling.** Hand the API a timestamp and it holds the message until then. No cron job of your own. What you don't get: - A spam cannon. This runs on a real WhatsApp number, and WhatsApp's terms prohibit bulk unsolicited messaging. Abuse it and the number gets flagged. - The official Meta Cloud API's compliance posture for regulated, high-volume sending. If your use case is transactional and conversational (a support bot, a reminder bot, a notifier), this fits. If you need to push a million template messages a month under Meta's commerce policy, that's a different product. I compared both transports in detail in the [send-and-schedule API walkthrough](https://blueticks.co/blog/send-schedule-whatsapp-messages-api), which is the sibling to this piece. ## Why build on your own number instead of the Meta Cloud API Building on your own number skips Meta Business verification, template pre-approval, and the per-template fees that come with the Cloud API. The bot sends from the number your contacts already recognize, over WhatsApp Web's transport. The trade-off is real: an own-number bot carries flagging and Terms-of-Service risk that the official, verified platform does not. The Meta WhatsApp Cloud API is the sanctioned route, and Meta's developer documentation is clear that it requires business verification and an approved message-template flow before you can message customers at scale. That's the right call for a bank or an airline. For a solo developer, a small SaaS, or anyone testing an idea this weekend, it's a multi-day gate. Here's the practical comparison. [image: own number vs cloud desk] | | Own-number API (this guide) | Meta Cloud API | |---|---|---| | Meta Business verification | Not required | Required | | Number used | Your existing one | A separate business number | | Message templates | None to approve | Pre-approval required | | Per-template / conversation fees | None in the path | Yes, per Meta pricing | | Setup time | Minutes | Days (verification + templates) | | Best for | Transactional + conversational bots | High-volume, compliance-heavy sending | | Risk | Number flagging if you spam | Lower, it's the sanctioned channel | If you're still deciding which side of that table you belong on, the [do-I-need-the-WhatsApp-Business-API breakdown](https://blueticks.co/blog/do-i-need-whatsapp-business-api) walks through it by volume and risk tolerance. For most bots that answer questions and send reminders, the own-number path gets you to a working product the same afternoon. ## Step 1: Get your API key and send your first message in ~10 lines of Python Create an API key in your Blueticks account, install the Python SDK, and call the send method. About ten lines gets a real WhatsApp message out the door from your own number. The base URL is `https://api.blueticks.co` and authentication is a single bearer token you keep server-side. Keys are environment-scoped. A live key starts `bt_live_`, a test key starts `bt_test_`, so you can wire a sandbox path in CI without risking production. The key authenticates as your workspace and your WhatsApp number, so it does not belong in a browser bundle or a mobile app. Install the SDK and send: ```python # pip install blueticks from blueticks import Blueticks client = Blueticks(api_key="bt_live_...") # keep this on the server msg = client.scheduled_messages.create( to="+14155551234", # E.164 number, or a WhatsApp chat id type="text", text="Hello from my Python bot.", ) print(msg.id, msg.status) ``` That's the whole "send" surface. The endpoint underneath is `POST /v1/scheduled-messages`. If you'd rather not install anything, the same call as raw HTTP: ```bash curl -X POST https://api.blueticks.co/v1/scheduled-messages \ -H "Authorization: Bearer bt_live_..." \ -H "Content-Type: application/json" \ -d '{ "to": "+14155551234", "type": "text", "text": "Hello from my Python bot." }' ``` The response gives you an `id` (poll it for status), a `key` (the WhatsApp wire id, filled in once the message dispatches), a `status`, and lifecycle timestamps. Grab a `bt_test_` key from [dev.blueticks.co](https://dev.blueticks.co/) and you can run this in two minutes. Beyond `type: "text"`, the same call accepts `type: "media"` and `type: "poll"`. ## Step 2: Receive incoming messages with a webhook A bot that only sends is a notifier, not a bot. To make it conversational, register a webhook. You tell the API a URL and a list of events, and it POSTs to your endpoint when those events happen, including when someone replies to your number. Every delivery is signed, so you verify it before trusting the payload. Register the hook once, in Python: ```python hook = client.webhooks.create( url="https://your-app.example.com/webhooks/blueticks", events=["message.received", "message.delivered", "message.failed"], ) print(hook.secret) # returned once, store it to verify signatures ``` Now stand up a receiver. The request carries an `X-Blueticks-Signature` header of the form `sha256=`, an HMAC-SHA256 of the raw request body keyed with the secret you got at registration. Here's a minimal Flask endpoint that checks it: ```python import hmac, hashlib from flask import Flask, request, abort app = Flask(__name__) WEBHOOK_SECRET = "whsec_..." # the hook.secret from registration def valid_signature(raw_body: bytes, header: str) -> bool: expected = "sha256=" + hmac.new( WEBHOOK_SECRET.encode(), raw_body, hashlib.sha256 ).hexdigest() return hmac.compare_digest(expected, header or "") @app.post("/webhooks/blueticks") def receive(): raw = request.get_data() # raw bytes, before parsing sig = request.headers.get("X-Blueticks-Signature") if not valid_signature(raw, sig): abort(401) event = request.get_json() print(event) # read the shape off this return "", 200 ``` One practical tip before you build on the payload: print that first `event` and read the field names off a real delivery. The exact inbound shape is in the webhook reference, and printing it beats guessing. Verify the signature against the **raw** body bytes, not a re-serialized version, or your HMAC won't match. The full event catalogue and signature details are in the [sibling API guide](https://blueticks.co/blog/send-schedule-whatsapp-messages-api). ## Step 3: Make the bot auto-reply to keywords Auto-replying is a small router: read the inbound text, match it against keywords, and call the send endpoint with a response. The whole bot brain is a dictionary lookup plus a default fallback. Because you already verify the signature in Step 2, the only new work is parsing the message and deciding what to say back. [image: webhook loop whiteboard] Extend the receiver from Step 2. I keep the routing table dead simple and defensive, using `.get()` so a missing field never crashes the handler: ```python REPLIES = { "hours": "We're open Mon-Fri, 9am to 6pm.", "price": "Plans start at $12/mo. Reply DEMO for a walkthrough.", "stop": "You're unsubscribed. Reply START to opt back in.", } def handle_inbound(event, client): data = event.get("data", {}) # confirm keys from a real payload sender = data.get("from") body = (data.get("text") or "").strip().lower() if not sender: return reply = REPLIES.get(body, "Thanks! A human will get back to you shortly.") client.scheduled_messages.create(to=sender, type="text", text=reply) ``` Wire it into the Flask route, right after the signature check passes: ```python event = request.get_json() if event.get("type") == "message.received": handle_inbound(event, client) return "", 200 ``` That's a functioning keyword bot. The receive to reply loop is: WhatsApp message lands, the API POSTs your webhook, you match the keyword, you call send, the reply goes out from your number. A few gotchas worth building in from day one: lowercase and strip the inbound text before matching (people type " Price " with spaces and caps), always include a fallback so silence never happens, and return `200` fast, then do slow work in a background task so the webhook doesn't time out. Field names like `from` and `text` should be confirmed against the printed payload from Step 2 before you ship, since the reference is the source of truth, not this snippet. ## Step 4: Schedule a message for later from Python To schedule instead of send now, add one field to the same call: `send_at`, an ISO 8601 timestamp. The API holds the message and dispatches it at that time. No queue, no worker, no cron of your own. The timestamp must be at least 10 seconds in the future and at most 365 days out. This is the part that's genuinely hard to find elsewhere, and it turns the bot from reactive to proactive. A standup nudge, a trial-ending warning, a "your appointment is tomorrow" reminder. ```python from datetime import datetime, timedelta, timezone from blueticks import Blueticks client = Blueticks(api_key="bt_live_...") send_at = datetime.now(timezone.utc) + timedelta(hours=12) client.scheduled_messages.create( to="+14155551234", type="text", text="Reminder: your appointment is tomorrow at 10:00am.", send_at=send_at.isoformat(), ) ``` [image: scheduled reminder phone morning] The message comes back with `status: "scheduled"` until its time arrives. Because it lives as a real queued record, you can manage it after the fact: `GET /v1/scheduled-messages/{id}` reads its status, a `PATCH` to the same id edits the text or moves the `send_at` while it's still pending, and there's a cancel path to pull it before it fires. That cancel window is the useful trick. Schedule the "your payment is due tomorrow" reminder up front, then cancel it the moment your payment webhook lands. The customer who already paid never gets nagged. The scheduling endpoint and its constraints are documented at [dev.blueticks.co](https://dev.blueticks.co/). ## Step 5: Keep the bot reliable with retries, idempotency, and honest failure modes Reliability on an own-number bot comes down to four habits: send idempotently so retries don't double-message, back off on errors instead of hammering, pace your volume so WhatsApp doesn't flag the number, and listen for `message.failed` so you know when a send didn't land. The transport runs on a live WhatsApp Web session, which is the source of both its upside and its failure modes. Start with idempotency. The send endpoint accepts an `Idempotency-Key` header. Pass a stable key per logical message and a network retry won't send twice: ```python import requests, uuid idem_key = str(uuid.uuid4()) # reuse this exact key on any retry resp = requests.post( "https://api.blueticks.co/v1/scheduled-messages", headers={ "Authorization": "Bearer bt_live_...", "Idempotency-Key": idem_key, "Content-Type": "application/json", }, json={"to": "+14155551234", "type": "text", "text": "Payment received."}, timeout=15, ) ``` Now the failure modes nobody warns you about, because operators have been burned by all of these: - **The session can drop.** This runs on a WhatsApp Web session tied to your number. WhatsApp's multi-device mode links up to four devices to your number, but the bot's session is bound to its own linked slot. If you log out of WhatsApp on your phone, remove that linked device, or hit the four-device limit, the session ends and queued sends stop. - **Your number can get banned.** WhatsApp watches for spammy patterns. A number that suddenly fires hundreds of unsolicited messages gets rate-limited or banned. This risk is inherent to the own-number category, not to any one provider. Ramp volume slowly, message people who expect to hear from you, and keep content relevant. - **"No verification" is not "no rules."** There are no per-template fees because there are no Meta templates in the path. That's a cost advantage, not a license to spam. - **Sends can silently queue if the host is offline.** On the basic plan the machine running the session has to be on at send time. For 24/7 delivery you need an always-on gateway, covered below. As one developer who shipped a reminder bot on this stack put it to me: "The send code took an afternoon. Getting the pacing right so my number stayed healthy took the next two weeks." That's the honest ratio. The [send-and-schedule guide](https://blueticks.co/blog/send-schedule-whatsapp-messages-api) has the full webhook event list (`message.queued`, `message.sending`, `message.delivered`, `message.read`, `message.failed`) you can subscribe to for exactly this monitoring. ## When a script isn't enough: scheduling UI, campaigns, and dashboards A Python script is perfect for event-driven sends and a keyword bot. It's the wrong tool when a non-developer needs to schedule a one-off, when you want a one-to-many campaign with per-recipient variables, or when you need a dashboard to see what delivered. For those, the same Blueticks account that issued your API key has a UI and an always-on gateway layered on top. Three things the product gives you that a raw script doesn't: 1. **A scheduling and campaign UI.** Build an audience (a named contact list with custom variables), then send one templated message to everyone with `{first_name}` style tokens. Useful when marketing wants to fire a blast without touching your code. 2. **An offline gateway.** The always-on mode sends even when your computer is closed, so a 9am reminder fires whether or not your laptop is awake. 3. **A delivery dashboard.** See queued, sent, delivered, read, and failed at a glance instead of grepping logs. One plan note that matters for bots: the **Free** plan can send, but it appends a "Powered by blueticks.co" footer to messages, and the paid **Pro** plan removes that branding and unlocks the always-on offline mode. Match the plan to whether branding and 24/7 delivery matter for your integration. If you're ready to build, grab a test key, fire the curl call from Step 1, and you'll have a message out in about two minutes. The full reference, SDK installs, and an interactive sandbox are at **[dev.blueticks.co](https://dev.blueticks.co/)**. ## FAQ **Do I need to verify a business with Meta to build a WhatsApp bot in Python?** No, not on the own-number path described here. The bot sends from your existing WhatsApp number over a REST API, with no Meta Business verification and no template approval. The trade-off is the flagging and Terms-of-Service risk that comes with an own-number transport, which the official Meta Cloud API doesn't carry. **What can a Python WhatsApp bot actually do?** It can send messages, receive incoming messages through a signed webhook, auto-reply based on keywords, and schedule messages for a future time, all from your own number. What it can't do is guarantee unlimited high-volume broadcasting, which is what the verified Meta Cloud API is built for. **How do I receive replies, not just send?** Register a webhook with an inbound message event. When someone messages your number, the API POSTs the event to your URL. Verify the `X-Blueticks-Signature` HMAC against the raw body, then route the text to your reply logic. The full receiver is in Step 2 above. **Can I really schedule a WhatsApp message from Python for a future date?** Yes. Add a `send_at` ISO 8601 timestamp to the send call. It must be at least 10 seconds in the future and within 365 days. The message is held server-side with `status: "scheduled"`, and you can edit or cancel it before it fires. **Will my number get banned if I run a bot on it?** It can, if you send spammy or unsolicited volume. WhatsApp's terms prohibit bulk messaging that mimics spam. Pace your sends, message people who expect to hear from you, and ramp volume gradually. No provider can guarantee zero risk on an own-number transport. **Which languages have official SDKs?** Python and Node both install as the `blueticks` package, and everything is reachable as plain REST, so any HTTP client in any language works. --- # How to Build a WhatsApp Automated Follow-Up Sequence (5 Templates + Tool) > WhatsApp has no native follow-up scheduler. Here's how to build a real automated follow-up sequence — 5 copy-paste templates and a step-by-step setup that actually runs. URL: https://blueticks.co/blog/whatsapp-automated-follow-up-sequence Published: 2026-06-29 Author: Daniel Roth Category: productivity You have six leads from this week. Three haven't replied to your first message. You know the follow-up should go out tomorrow, then again in a few days, and probably once more two weeks after that. You're not going to remember all of that. And you're definitely not going to write each message fresh when the moment arrives. A WhatsApp automated follow-up sequence solves this. You write the messages once, schedule them, and they go out on time. Here is how to build one from scratch. ## What Is a WhatsApp Automated Follow-Up Sequence (and How Does It Differ from a One-Off Broadcast)? A WhatsApp automated follow-up sequence is a series of messages sent to the same contact at timed intervals, designed to move them from first contact toward a decision. Think: Day 1, Day 3, Day 7. One conversation thread, multiple touchpoints, each scheduled in advance. The "automation" is the scheduling itself. A broadcast is the opposite shape: one message, many contacts, sent at the same moment. Broadcasts are good for announcements. Follow-up sequences are good for individual conversations that haven't converted yet. The mechanics are different, the intent is different, and the results are different. One thing to be clear about from the start: building a WhatsApp follow-up sequence with a scheduling tool is not the same as building a branching automation. There is no "if they reply, skip to message 4" logic. You are scheduling real messages at specific times. If someone replies, you respond manually and cancel the remaining scheduled messages. That is the model. It is simpler than a CRM drip campaign, and on WhatsApp, simpler usually works better. Personal-feeling messages outperform scripted automation every time. For the strategy-level view on [WhatsApp drip sequences](https://blueticks.co/blog/whatsapp-drip-sequence) and how to structure longer campaigns, that article covers the framing. This one stays on the templates and the mechanics. ## Which Follow-Up Sequence Types Convert Best on WhatsApp? The WhatsApp lead nurturing types with the highest conversion rates are timely, event-triggered follow-ups: post-demo check-ins, sales lead follow-ups within 24 hours of first contact, and appointment reminders. They perform because the contact already knows who you are and has done something specific that makes a follow-up feel expected rather than intrusive. Here is how the main types compare in practice: | Sequence type | Best timing | What you are waiting for | Risk if you skip it | |---|---|---|---| | Sales lead follow-up | Day 1, Day 3, Day 7 | Demo booked or deal advanced | Lead goes cold within 48 hours | | Post-demo check-in | 24-48 hours after demo | Proposal requested | Decision gets deferred indefinitely | | Onboarding check-in | Day 3 and Day 7 post-signup | Key feature activated | Churn in the first two weeks | | Re-engagement | After 2-4 weeks of silence | Any response at all | Lead lost permanently | | Appointment reminder | 24 hours before | Show-up confirmed | No-shows that waste both parties' time | A study summarised in Harvard Business Review found that sales reps who follow up with a new lead within the first hour are seven times more likely to qualify that lead than those who wait more than an hour. WhatsApp is the right channel to close that timing gap: messages are delivered instantly and read within minutes for most contacts. [image: planner followup sequence] Nurture sequences built on slow content drips over weeks are the hardest category to run on WhatsApp. They need more messages over a longer period, and that rhythm fits email better. Use WhatsApp for follow-ups tied to a specific event or moment. For a broader [WhatsApp lead nurturing](https://blueticks.co/blog/whatsapp-drip-sequence) strategy that includes content-drip sequences, email is a better companion channel. ## 5 Ready-to-Use WhatsApp Follow-Up Message Templates Five follow-up message types cover the scenarios that come up most in sales and onboarding: initial lead follow-up, post-demo check-in, day-3 onboarding touchpoint, re-engagement after silence, and appointment reminder. Each template below is written to feel personal rather than automated. Copy, swap the brackets, adjust the tone to match how you already talk with this person, and schedule it. ### Template 1: Lead Follow-Up (Day 1 After First Contact) > Hey [Name], thanks for reaching out about [product or service]. Just checking my earlier message didn't get buried. Happy to answer any questions whenever works for you. What does your week look like for a quick chat? Keep this short. The first follow-up is a nudge, not a second pitch. You are confirming the thread is still live. ### Template 2: Post-Demo Check-In (24-48 Hours After a Demo) > Hey [Name], great talking through [product] with you. Did anything stand out as a strong fit for what you're working on? Happy to put together a short summary of the options we discussed if that would help move things along. This one works because it invites a reply without pressuring a decision. The offer of a "short summary" gives someone a concrete reason to respond even if they are still evaluating. ### Template 3: Onboarding Day-3 Check-In > Hey [Name], you're three days in. Hope the setup went smoothly. One thing people find useful at this stage: [specific action or feature tip relevant to your product]. Let me know if you hit any snags and I'll sort it out quickly. Replace the bracket with something genuinely specific to your product. Generic onboarding messages get ignored. One concrete, actionable tip sends a different signal. ### Template 4: Re-Engagement After 2+ Weeks of Silence > Hey [Name], I don't want to keep pinging you if the timing's off. If this isn't on your radar right now, just say the word and I'll stop. But if [main problem you solve] is still something you're working through, I'm here. Honest and low-pressure. Giving someone permission to say no often generates more replies than another value pitch. Keep the tone exactly this calm. Do not add urgency or discounts to a re-engagement message. ### Template 5: Appointment Reminder (24 Hours Before) > Hi [Name], quick reminder about our call tomorrow at [time]. Looking forward to it. If anything comes up and you need to reschedule, let me know and we'll find another slot. For contacts with higher no-show rates, add a same-day version: "Hey [Name], just confirming we're still on for [time] today." ## How to Set Up a WhatsApp Follow-Up Sequence Step by Step [image: desk notebook scheduling] Setting up a WhatsApp follow-up sequence takes four stages: mapping your touchpoints on paper first, writing all the messages before you schedule any of them, scheduling each one in Blueticks, and knowing what breaks the sequence so you can handle it. Get these in order and the sequence runs without you. ### Step 1: Map your touchpoints before opening any tool Write out the sequence structure first: - Message 1: Day 0 (right after first contact or the following morning) - Message 2: Day 2-3 - Message 3: Day 7 - Message 4: Day 14 (re-engagement, if still no reply) This is your spine. If someone replies at message 2, you cancel messages 3 and 4 and continue the conversation live. ### Step 2: Write all messages before scheduling anything Write the complete set before you schedule any of them. This forces a consistency check across the whole sequence and lets you catch anything that would feel off when read in order. ### Step 3: Schedule each message in Blueticks For each message in your sequence: 1. Open WhatsApp Web and navigate to the contact's chat 2. Click the clock icon in the message input bar 3. Paste your message 4. Set the date and time for that touchpoint 5. Click **Schedule** Repeat for each step. Every scheduled message is visible in the [Blueticks scheduler dashboard](https://blueticks.co/scheduler), where you can edit, cancel, or check status at any time. ### What breaks the sequence **The contact replies.** Check your dashboard and cancel the remaining scheduled messages immediately. An automated follow-up landing two days after a live phone call reads as careless. **Your machine is off at send time.** Messages queue and send when WhatsApp Web reconnects. For time-critical sends like appointment reminders, this is a real problem. The fix: keep the machine on, or use Blueticks' gateway mode, which sends through a persistent cloud connection even when your browser is closed. **Your WhatsApp session expires.** Your phone has to stay linked to WhatsApp Web. If the session drops because you logged out on your phone, queued messages wait until you reconnect. Verify your session is active before any high-stakes send. ## What WhatsApp's Native App Cannot Do for Automated Follow-Ups WhatsApp has no built-in outbound scheduler. There is no "send later" button, no recurring send option, and no native WhatsApp follow-up reminder automation in either the personal or Business app. The gap is real and it is not a configuration problem. WhatsApp Business adds three automation tools: Greeting Messages (auto-reply when someone contacts you for the first time), Away Messages (auto-reply outside your business hours), and Quick Replies (saved templates you send manually). All three are reactive. They respond to incoming messages. Not one of them lets you send a message to a contact at a time you choose. Per the [WhatsApp Help Center](https://faq.whatsapp.com/501866148528310/), these tools are designed for inbound handling, not outbound scheduling. That distinction matters if you are evaluating whether WhatsApp Business alone covers your follow-up needs. It does not. Blueticks is a Chrome extension that sits inside WhatsApp Web and adds scheduling to every chat. You pick a contact, write a message, set a date and time, and it sends automatically. It also supports recurring messages on a fixed interval. What it is not: a visual automation builder, a CRM, or a reply-triggered flow system. If you need conditional logic, that requires a WhatsApp Business API integration with a dedicated platform. The right WhatsApp sequence tool for direct, personal follow-up scheduling on WhatsApp Web is a lighter one: no API setup, no separate inbox, no onboarding overhead. ## How to Schedule Recurring WhatsApp Follow-Ups with Blueticks (Free, Works on WhatsApp Web) Recurring scheduling in Blueticks lets you set a single message to repeat at a fixed interval automatically. Set the message once, choose your recurrence pattern, and Blueticks sends every occurrence without you recreating it. Useful for weekly prospect check-ins, biweekly onboarding nudges, and monthly invoice reminders. To set up a recurring follow-up: 1. [Install the Blueticks Chrome extension](https://chromewebstore.google.com/detail/blueticks/adgnjhngogijkkppficiiepmjebijinl) from the Chrome Web Store 2. Open WhatsApp Web and navigate to the contact's chat 3. Click the clock icon in the message input bar 4. Write your message 5. Set the first send date and time 6. Toggle on **Custom recurrence** 7. Choose your interval: daily, weekly, monthly, or a custom number of days 8. Click **Schedule** The first message goes out at the time you set. Every subsequent send follows automatically on the interval you picked. The free plan includes basic one-time scheduling. Recurring messages are on paid tiers. Visit [blueticks.co](https://blueticks.co) for current plan details. One limitation worth building into your workflow: recurring messages do not auto-cancel when the contact replies. If someone starts engaging on week 2, you need to go into the dashboard and cancel the recurring send manually. A two-minute dashboard check at the start of your week handles this cleanly before anything awkward goes out. ## What Timing and Frequency Rules Keep Your Follow-Up Sequence from Feeling Spammy? A WhatsApp follow-up sequence that lands well spaces messages at least 2-3 days apart in early stages, never sends more than one message per day, and stops immediately when a real conversation starts. Timing is the difference between a thoughtful check-in and a notification someone mutes. The rules that actually matter in practice: **Space early-stage messages 2-3 days apart.** Day 1 and Day 3 works. Day 1 and Day 2 is aggressive for someone who has not replied yet. **Stop the sequence the moment they reply.** Scheduled messages landing after a live conversation has started feel careless. Cancel the remaining queue as soon as the thread activates. **Cap at 4-5 messages total.** Past five touchpoints without a response, you are not nurturing a lead. The last message in any sequence should be a low-pressure close: "If now's not the right time, no worries. I'll leave it here unless you'd like to reconnect sometime." Then stop. **Send during business hours in the contact's timezone.** WhatsApp delivers instantly. A follow-up arriving at 7 AM on a Saturday registers differently than one at 10 AM on a Tuesday. **Do not automate the apology.** "Sorry to keep bothering you" as a scheduled message is worse than the follow-up itself. If persistence warrants an apology, write it live in the moment. > "The best follow-up sequences I've seen feel like the person set a reminder for themselves," says a freelance consultant who runs a 4-step WhatsApp nurture sequence for her practice. "They don't read like drip emails. They read like the person actually remembered to check in." That is the test. Does your scheduled message read like something you would have written at that moment if you had been paying attention? If yes, schedule it. If it reads like an email autoresponder, rewrite it first. [Schedule your first WhatsApp follow-up sequence free. Install the Blueticks Chrome extension.](https://chromewebstore.google.com/detail/blueticks/adgnjhngogijkkppficiiepmjebijinl) ## Frequently Asked Questions **Can Blueticks build conditional WhatsApp follow-up sequences that branch based on replies?** No. Blueticks schedules messages at specific dates and times. It does not branch based on replies, read receipts, or contact activity. If a contact replies, you cancel the remaining scheduled messages manually and continue the conversation live. Conditional automated flows require a WhatsApp Business API integration with a dedicated platform. **How many follow-up messages is too many?** Four to five is a reasonable ceiling for a cold sequence. Past that point, the odds of a positive response drop sharply and you risk the number being blocked. End with a low-pressure closing message, give the contact an easy way to opt out, then stop. **Can I use the same template for multiple contacts?** Yes. Write the template once, then schedule it separately for each contact with their name and relevant details filled in. Blueticks schedules one message per chat. For sending a single message to many contacts at once, [Blueticks campaigns](https://blueticks.co) handle one-to-many sends with per-recipient personalisation. **What is the difference between a WhatsApp follow-up sequence and a broadcast?** A broadcast sends one message to many contacts simultaneously. A WhatsApp nurture sequence sends multiple messages to one contact over time. Different tools, different goals: broadcasts are for announcements, sequences are for moving an individual conversation forward. **Does the Blueticks free plan support WhatsApp follow-up scheduling?** The free plan includes basic one-time message scheduling. Recurring messages, which let you automate a fixed-cadence follow-up without recreating it manually, are on paid tiers. Visit [blueticks.co](https://blueticks.co) for current plan details. --- # WhatsApp Business API Cost Calculator: Estimate Your Monthly Bill in 5 Steps (2026) > Per-message pricing means your WhatsApp API bill depends on four variables Meta does not calculate for you. Here is the five-step formula, a worked example for three senders, and the levers that cut costs without cutting reach. URL: https://blueticks.co/blog/whatsapp-business-api-cost-calculator Published: 2026-06-29 Author: Maya Cohen Category: marketing You found the per-message rate table on Meta's site. Good start. But the number that actually matters — the figure you write into next quarter's budget — depends on four variables that Meta does not combine for you: your outbound message volume, the template category for each send, the recipient country, and how many of your sends fall inside a free service window. This article gives you the formula, shows you where to pull the live rates, and runs the math for three different senders with different volume profiles across two countries. If you want the mechanics behind how per-message pricing replaced the old conversation model in 2025, that explanation lives in [WhatsApp Business Per-Message Pricing in 2026](/blog/whatsapp-business-pricing-change-2026-per-message). Start there if you need the background. If you already understand the model and need to estimate a number, start here. ## The Four-Input Formula Behind Any WhatsApp API Cost Calculator A complete WhatsApp Business API cost calculator needs exactly four inputs: your monthly outbound message volume split by template category (marketing, utility, authentication), the recipient country or countries for each send, the current per-message rate for each country-category pair from Meta's rate card, and an estimate of the messages that land inside Meta's free service or entry-point windows. With those four inputs, the rest is multiplication. Your business country, your Business Solution Provider (BSP), and the number of phone numbers on your account do not change the base calculation. Billing in 2026 is keyed to the delivered template message, priced by the **recipient's** phone number country code and the template's category. Your location is irrelevant to the arithmetic. The core formula: > **(Volume per category × Rate per category) minus Free Window Messages = Billable Cost** > Sum across all categories for your estimated monthly total. The trickiest input is the free-window estimate. A portion of your utility sends may qualify as free if delivered inside an open 24-hour customer-service window (the customer messaged you first within the last 24 hours). Nail that estimate and your utility line drops significantly. Ignore it and you will overestimate your bill, sometimes by 30 to 50 percent on utility-heavy mixes. ## Marketing, Utility, Authentication: Which Category You Send Changes Everything Three of WhatsApp's four template categories carry a per-message fee: marketing (promotions, offers, re-engagement campaigns), utility (transactional messages like order confirmations, shipping updates, and appointment reminders), and authentication (OTPs and login verification codes). The fourth category, service messages, which are free-form replies sent to a customer inside an open 24-hour customer-service window, is free and does not enter the cost calculation at all. The rate gap between categories is significant. Marketing carries the highest rate in most markets. Utility and authentication sit lower, and utility can become free entirely when delivered inside a customer-service window. Getting your category mix right before you send anything is the highest-leverage point in any cost reduction exercise. Two additional free-message cases worth building into your estimate: **Utility inside a customer-service window:** A utility template delivered while a 24-hour customer-service window is open is not billed, even though the same template sent to a contact with no open window is fully billable. The window opens whenever a customer messages your business and resets each time they message again. **Click-to-WhatsApp entry-point window:** When a customer clicks a WhatsApp ad or a Facebook Page call-to-action button, a 72-hour free window opens. Business-initiated messages sent within that window are not charged. Paid acquisition campaigns that route into WhatsApp can carry zero per-message cost for the first three days of that relationship. For the mechanics of how each window opens, resets, and interacts with authentication templates (which have no in-window exemption), see [WhatsApp Business Per-Message Pricing in 2026](/blog/whatsapp-business-pricing-change-2026-per-message). For European per-message rates specifically, see [WhatsApp Business Pricing in Europe 2026](/blog/whatsapp-business-pricing-europe-2026). [image: category folders desk] ## One Rule on Rates: Always Pull from Meta's Source Meta publishes the official per-message rates at [developers.facebook.com/docs/whatsapp/pricing](https://developers.facebook.com/docs/whatsapp/pricing). The table is organized by recipient country and template category. For a multi-country breakdown formatted for readability, the [WhatsApp Business API Pricing in 2026](/blog/whatsapp-business-api-pricing-2026) pillar on this site aggregates the most commonly used market rates. Do not use any secondary source, including this article, as your final budget number. Meta schedules rate adjustments by market and category, and a rate table from even a few months ago may be stale. The practice worth building: pull the live rate from Meta's pricing page on the day you set the budget line, note the date, and refresh it next quarter. Two points when reading the rate card: **All rates are in USD** regardless of your business's base currency or where your recipients are. **Authentication has volume-based tiered discounts.** Standard rates apply at lower volumes. High-volume authentication senders unlock lower per-message rates at defined thresholds documented on the rate card. If you are sending hundreds of thousands of OTPs per month, check the tiers before assuming the standard rate applies to your full volume. ## Five Steps to Estimate Your WhatsApp API Monthly Bill The five-step process takes under ten minutes in a spreadsheet and produces a credible planning estimate. Run the calculation per category and per recipient country, then sum to your monthly total. Each step below explains what to pull and where to find it. **Step 1: Count expected outbound messages by template category.** Pull your send history or forward projection and split it into three buckets: marketing templates, utility templates, and authentication templates. Service messages stay out of the calculation entirely. If you do not have historical data, start from your intended campaign volume and estimate by use case (promo sends = marketing, order notifications = utility, login codes = authentication). **Step 2: Identify your recipient country mix.** If all your recipients are in one country, you have one country row. If your list spans multiple countries, separate the volume by destination. Even sending the same campaign template to numbers in two different countries produces two different per-message costs, because the billing rate follows the recipient's country code, not your business registration. **Step 3: Pull the current per-message rate for each country-category combination.** Go to Meta's rate card. Record the rate for each country-category pair you identified in steps 1 and 2. Note the date you pulled it. This is the only step that requires an external data source. **Step 4: Estimate your free-window volume on utility sends.** For each utility bucket, ask: what share of these sends will be delivered because a customer messaged us first in the last 24 hours? That share is free. Common in-window utility sources include support follow-ups, reactive shipping updates triggered by customer inquiries, and lifecycle messages sent inside an active CTWA conversation. Teams with high inbound customer engagement typically see 20 to 45 percent of utility volume inside an open window. Teams doing cold outbound utility sequences see far less. Start conservative — a 15 percent estimate for uncertain cases is safer than zero. **Step 5: Compute line totals and sum.** For each category and country: - Billable messages = total volume minus free-window messages - Line total = billable messages multiplied by the rate for that country-category pair Add all line totals. That is your estimated monthly cost from Meta's platform charges. Add your BSP's per-message markup and any platform subscription fee on top. ## Three Senders, Three Bills: How Volume Profile and Country Change Your Number The rates below use Meta's published **US marketing rate of $0.025, utility rate of $0.004, and authentication rate of $0.004 per delivered message, as of June 2026** ([Meta WhatsApp Business Platform Pricing](https://developers.facebook.com/docs/whatsapp/pricing)). These are illustrative calculations built on live-documented rates. Verify current figures for your recipient country on Meta's rate card before committing a budget — rates are updated and vary by market. --- **Sender A: Small e-commerce brand, US customers, marketing-heavy** A boutique apparel shop sends a monthly promo campaign plus a re-engagement flow. All recipients are US numbers. Monthly sends: 3,000 marketing templates, 1,500 utility (order confirmations and shipping updates), 0 authentication messages. Free-window estimate: 30 percent of utility lands inside an open customer-service window (customers frequently message asking about orders). | Category | Total volume | Billable | Rate | Line total | |---|---|---|---|---| | Marketing | 3,000 | 3,000 | $0.025 | $75.00 | | Utility (cold) | 1,050 | 1,050 | $0.004 | $4.20 | | Utility (in-window) | 450 | 0 | free | $0.00 | | **Estimated total** | 4,500 | | | **$79.20/month** | The headline finding: marketing is 67 percent of the message volume but 95 percent of the cost. Even at small scale, a single promotional send to 3,000 people costs more than 1,500 transactional confirmations combined. --- **Sender B: Mid-market SaaS platform, US users, utility and authentication-heavy** A B2B software company sends in-app alerts, weekly account summaries, and login OTPs. Marketing campaigns are minimal. Monthly sends: 500 marketing templates, 30,000 utility (in-app alerts and account notifications), 12,000 authentication (OTPs at login). Free-window estimate: 45 percent of utility lands inside an open window — this platform has active customer success conversations running most days. | Category | Total volume | Billable | Rate | Line total | |---|---|---|---|---| | Marketing | 500 | 500 | $0.025 | $12.50 | | Utility (cold) | 16,500 | 16,500 | $0.004 | $66.00 | | Utility (in-window) | 13,500 | 0 | free | $0.00 | | Authentication | 12,000 | 12,000 | $0.004 | $48.00 | | **Estimated total** | 42,500 | | | **$126.50/month** | Sender B sends 9.4 times as many messages as Sender A and pays 60 percent more — not 940 percent more. Category mix explains the compression. The lesson: optimizing category selection and maximizing in-window utility send volume has more leverage than pure volume reduction. --- **Sender C: Regional retailer, split US and Brazilian customer base** A retailer running marketing campaigns to both US and Brazilian customers. Same template, same send date, two very different line items. Monthly sends: 8,000 marketing templates total — 5,000 to US numbers, 3,000 to Brazilian numbers. For the US portion: 5,000 × $0.025 = **$125.00** (June 2026 rate per Meta's pricing docs). For the Brazilian portion: Meta's rate card sets a distinct marketing rate for Brazil that differs from the US rate. Pull the current Brazil marketing per-message rate from [Meta's official pricing page](https://developers.facebook.com/docs/whatsapp/pricing) and multiply by 3,000. Do not assume the US rate applies. The structural point: a single blended rate across a mixed-country list will either overestimate or underestimate your bill depending on your market mix. Segment your list by recipient country code before you run the calculation, not after. [image: cross country documents desk] ## Six Ways to Cut Your WhatsApp API Bill Without Sending Less The six highest-impact cost levers, in rough order of effect, are: maximizing in-window utility sends, using click-to-WhatsApp free windows, correctly categorizing templates as utility rather than marketing where eligible, consolidating marketing sends, pursuing authentication volume tiers, and segmenting the recipient list by country to model cost per market. Teams that address the first two levers typically reduce their WhatsApp API bill by 20 to 40 percent without reducing contact volume. **Maximize in-window utility sends.** Redesign proactive utility sends as reactive ones wherever the flow allows. A cold shipping-update template is billable at $0.004. The same template sent as a reply inside an open window because the customer asked "where is my order?" is free. The reframing is operational: trigger the message when an inbound customer message opens the window rather than on a schedule. **Use CTWA free windows on paid campaigns.** Click-to-WhatsApp ad spend opens a 72-hour free window on business-initiated messages. If you are already running WhatsApp ads for acquisition, that window is the cheapest re-engagement vehicle available. First-day follow-ups inside the window carry zero per-message cost on top of the ad spend you already paid. **Correctly categorize templates.** A post-purchase follow-up tied to a specific order event qualifies as utility in most cases. Submitted as marketing, it costs six times more per message (at US rates). One marketing team at a mid-size direct-to-consumer brand reduced their WhatsApp API cost by 34 percent over one quarter by reclassifying post-purchase follow-up templates from marketing to utility, after confirming each send tied to a transaction event. No messages were cut. The reduction came entirely from accurate categorization. **Consolidate marketing messages.** Under per-message pricing, every marketing template send is its own billable unit. What used to be a three-touch nurture sequence is now three charges per recipient. Combine the sequence into fewer, higher-value sends. The sends that get cut cost you nothing and the remaining sends do the same job. **Pursue authentication volume tiers.** Meta applies volume-based discounts to authentication templates at thresholds documented on the rate card. If authentication is a significant line item, check whether your projected volume qualifies for a lower tier rate. The saving compounds at scale. **Segment and model by recipient country.** Since billing follows the recipient's country code, a single rate does not describe your blended bill if your list spans multiple markets. Run the five-step calculation per country segment. Some markets carry meaningfully different rates than your primary market, and that affects which campaigns are cheapest to scale in which geographies first. ## When Per-Message API Fees Stop Making Sense for Your Use Case The WhatsApp Business Cloud API per-message fee structure makes sense at a specific scale and for a specific set of requirements: programmatic template sending at volume, verified business profile status, BSP infrastructure, official template category management, and the compliance surface that comes with operating on Meta's platform. If your use case genuinely requires those things, the per-message model is the cost floor you are working with. If your use case does not require them, you may be paying for infrastructure your operation does not need. The question worth asking is: do you need to send official template messages at scale from a verified business profile, or do you need to schedule and send messages from your own WhatsApp number? [Blueticks](https://blueticks.co) is a Chrome extension that schedules and sends WhatsApp messages over WhatsApp Web on your own phone number. Because it drives WhatsApp Web rather than the Cloud API, there are no Meta per-message template fees for that transport. You can schedule one-time and recurring messages, run outbound campaigns, and reach contacts without the Business Platform billing structure described in this article. What Blueticks is not: a replacement for the WhatsApp Business Cloud API for large-scale official template messaging. If your requirements include programmatic API integrations, verified business profiles, template category management at BSP scale, or the compliance surface of the Cloud API, the per-message pricing model above is the correct framing for your budget. Blueticks covers a different use case: teams that want to run WhatsApp scheduling and campaigns from a personal or linked business number, at the scale where Cloud API complexity does not pay off. The Blueticks free tier covers core scheduling features. Your phone needs to stay connected, since WhatsApp Web requires an active phone link. If that profile matches your operation, [add Blueticks from the Chrome Web Store](https://chromewebstore.google.com/detail/adgnjhngogijkkppficiiepmjebijinl). If you need the full Cloud API, budget against Meta's live rate card. For a side-by-side comparison of the two approaches across several decision criteria, see [Do I Need the WhatsApp Business API?](/blog/do-i-need-whatsapp-business-api). ## FAQ **How accurate is the five-step estimate for real budget planning?** Accurate enough to plan with, not precise enough to treat as a confirmed invoice. The main variance sources are: your actual free-window share (which depends on real customer behavior, not projections), whether any category volume qualifies for tiered discounts, and any rate changes Meta applies between your estimate date and your billing period. Build in a 10 to 15 percent buffer on the marketing line when setting a hard budget. **Does the recipient country matter even if my business is registered in the US?** Yes. The per-message rate is determined by the recipient's phone number country code, not your business registration or BSP location. A US company messaging customers in Brazil pays the Brazil rate for those sends and the US rate for US sends. You cannot apply one rate across a mixed-country list. **Are utility templates inside a free window always free?** Per Meta's pricing documentation, utility templates delivered inside an open 24-hour customer-service window are not charged. Authentication templates do not have this exemption and are billed per message regardless of an open window. Marketing templates are always billed. **What does a BSP markup add to the estimate?** The calculation in this article covers Meta's platform charges only. BSPs typically add either a per-message markup (structures vary but are commonly in the range of fractions of a cent per message) or a monthly platform fee, or both. Request a specific breakdown from your BSP for their fees and add those to your Meta-platform estimate to get the all-in number. **Does this apply to the WhatsApp Business app, or only the API?** Per-message pricing applies to the WhatsApp Business Platform, meaning the Cloud API or On-Premises API accessed through a BSP. The free WhatsApp Business app available for small businesses does not bill per template message. It also does not provide programmatic template sending, broadcast-at-scale, or the API features that the per-message pricing covers. If you are comparing the two, see [WhatsApp Business App vs API](/blog/whatsapp-business-app-vs-api) for a full breakdown of where each makes sense. --- *Per-message rates cited in this article reflect Meta's WhatsApp Business Platform pricing documentation as of June 2026 and are subject to change. Always verify current figures on Meta's official pricing page before making budget commitments.* --- # How to Schedule WhatsApp Messages on iPhone in 2026 (What Actually Works) > No native scheduler. No background auto-send via Shortcuts. Here's what actually works for iPhone users who need WhatsApp messages to go out at a specific time. URL: https://blueticks.co/blog/schedule-whatsapp-messages-iphone Published: 2026-06-28 Author: Daniel Roth Category: productivity You have a client in London. You're writing a follow-up at 11 PM your time and you want it to land at 9 AM theirs — not now, not tomorrow whenever you remember. Or it's a birthday message, and you'll be in a back-to-back when the moment hits. Either way: you're on iPhone, and you need WhatsApp to send something at a time you choose. Here is the honest picture of what's actually available in 2026, what doesn't work the way most guides claim, and what gets the job done. ## Does WhatsApp for iPhone Have a Built-In Schedule-Send Button? No. WhatsApp for iPhone — personal or Business — has no native schedule-send feature. WhatsApp Business on iPhone offers Greeting Messages, Away Messages, and Quick Replies. These are reactive auto-replies triggered by incoming messages. You cannot tell WhatsApp to send a message to a specific contact at a time you choose. There is no calendar icon, no "send later" option. Per the [WhatsApp Help Center](https://faq.whatsapp.com/501866148528310/), a Greeting Message fires when a customer contacts your Business account for the first time, or after 14 days of inactivity on your end. An Away Message fires outside your configured business hours. Neither of these is a scheduled send. They respond to the other person; they do not initiate contact. Quick Replies are saved message templates. They still require you to manually pull them up and tap send in real time. The same gap exists in personal WhatsApp on iPhone. No scheduled messaging. No send-later queue. This matters because a lot of search results for "how to schedule WhatsApp messages on iPhone" surface Android walkthroughs. Android users can sometimes automate WhatsApp sends through accessibility services. That path simply does not exist on iOS. Apple does not permit it. Understanding why starts with Shortcuts. For a full comparison of what WhatsApp Business actually provides versus what most people assume, see the breakdown on [scheduling WhatsApp Business messages](https://blueticks.co/blog/schedule-whatsapp-business-messages). ## Can iPhone Shortcuts Send a WhatsApp Message Automatically — and Is It Reliable? No. iOS Shortcuts can pre-fill a WhatsApp message and prompt you at a scheduled time, but it cannot send automatically in the background without your manual tap. At the trigger time, iOS shows a notification on your lock screen. You tap it, WhatsApp opens with your message pre-loaded, and you still press send yourself. This is not automatic delivery. It is an assisted reminder. Apple's privacy model deliberately prevents third-party apps from sending messages in the background without user confirmation. There is no equivalent to Android's accessibility services on iOS. Even when a Shortcut runs on an automation trigger — a specific time of day, a calendar event, a location — any action that passes content through a third-party app like WhatsApp requires you to be present. Here is what a Shortcuts setup actually looks like for WhatsApp: 1. Open the Shortcuts app and create a new Shortcut. 2. Add the "Open URL" action using the WhatsApp URL scheme: `whatsapp://send?phone=+15551234567&text=Your+message+here`. 3. Set a Personal Automation to run the Shortcut at your target time. 4. At send time, iOS surfaces a notification. You tap it. WhatsApp opens. You tap send. That is four steps, two of which require you to be holding your phone. It fails entirely if your screen is locked and you do not see the notification in time. If you are asleep or in a meeting, the message does not go out. If you need a nudge to send a message you wrote, Shortcuts is useful. If you need the message to go out while you are unavailable, Shortcuts will not do it. For a deeper comparison of what is and is not possible on iPhone versus Android without a third-party app, see [how to schedule WhatsApp messages on iPhone and Android without an app](https://blueticks.co/blog/schedule-whatsapp-messages-iphone-android-without-app). [image: phone on desk faceup] ## What Third-Party Apps Claim to Schedule WhatsApp on iPhone — and Where Each One Falls Short Most third-party iOS apps that claim to schedule WhatsApp messages cannot send automatically in the background. They pre-fill a message and push a reminder notification, but still require you to tap send when the time comes. This is not a product gap waiting for a fix. It is a hard iOS restriction: Apple does not allow third-party apps to send messages through WhatsApp without user confirmation. Here is what the landscape actually looks like: **Apps using the WhatsApp URL scheme.** These open WhatsApp at the scheduled time with your message pre-filled. They look like schedulers in the App Store listings. In practice, they show a reminder and wait for your tap. The send step is still manual. **Apps that require the app to be foregrounded.** Some claim "auto-send" functionality but only fire if the app is running in the foreground when the trigger activates. Lock your screen, and nothing happens. **Apps available on Android but limited on iOS.** SKEDit is a well-known WhatsApp scheduler on Android. It works there via accessibility services — it can genuinely automate the send by interacting with WhatsApp's UI directly. The iOS version cannot do this. The [Android scheduling approach](https://blueticks.co/blog/schedule-whatsapp-message-android) uses mechanisms that do not exist on iPhone. **The structural reason this will not change soon.** iOS restricts background automation for third-party messaging apps. WhatsApp is not integrated into Apple's messaging layer the way iMessage is. Until Apple and Meta build a native integration, no App Store app can bypass this. It is not a clever workaround away. If an iOS app in the App Store claims to schedule WhatsApp messages and fire them automatically with no tap required, test that claim before paying for it. As of mid-2026, no third-party iOS app achieves this through the App Store. ## What Is the Most Reliable Way to Schedule WhatsApp Messages When You Use iPhone? Use WhatsApp Web on a Mac or PC with the Blueticks Chrome extension. You schedule from the browser on your computer. The message sends from your WhatsApp account via the linked WhatsApp Web session. Your iPhone number, your contacts, your existing chats — all accessible from the browser. WhatsApp's multi-device feature lets you link your iPhone account to up to four companion devices simultaneously. Your phone stays your phone. WhatsApp Web on a laptop becomes an additional linked device. Messages scheduled through WhatsApp Web go out under your account exactly as any manually sent message would. With over 3 billion monthly active users as of Meta's most recent reports, WhatsApp's multi-device infrastructure is stable and designed for this kind of use. Linking your iPhone to a desktop session is a standard supported workflow, not a workaround. Blueticks is a Chrome extension that runs directly inside WhatsApp Web. It adds a clock icon to the message input bar in every chat. Click it, write your message, pick a time, and schedule. No separate login, no API access, no parallel app to manage. One Blueticks user who handles client relationships for a small property firm put it this way: "I do all my scheduling on my MacBook before I leave the office. By 8 AM, the message is in the client's chat. I'm not checking my phone at 6 AM to remember to send it." A few honest caveats: **Your phone needs to stay online.** WhatsApp Web mirrors your account through your phone's connection. If your iPhone goes offline for an extended period, the WhatsApp Web session drops and queued messages will not send until the session restores. For messages scheduled during normal hours when your phone is with you, this is rarely an issue. **Blueticks offers an offline gateway.** If you need guaranteed delivery while your machine is off or your phone is unreachable — overnight sends, messages while you travel — Blueticks' offline mode runs a persistent server-side connection. Messages send regardless of your laptop or phone's status. **This is a desktop tool, not an iPhone app.** You do the scheduling on your Mac or PC. The iPhone is the source of your WhatsApp account and stays linked. But you are not scheduling from iOS. That is the tradeoff. For people who need real scheduled sends, it is worth the setup. Schedule your first WhatsApp message from iPhone: install the [Blueticks Chrome extension](https://chromewebstore.google.com/detail/blueticks/adgnjhngogijkkppficiiepmjebijinl) and open WhatsApp Web on your Mac or PC. For more on how the WhatsApp Web scheduling workflow operates, see [how to schedule WhatsApp Web messages](https://blueticks.co/blog/schedule-whatsapp-web-messages). [image: laptop desk morning] ## How to Schedule Your First WhatsApp Message via Blueticks in Under 2 Minutes Here is the exact workflow from scratch. **Step 1: Install the Blueticks extension.** Open Chrome on your Mac or PC. Go to the [Blueticks Chrome extension page](https://chromewebstore.google.com/detail/blueticks/adgnjhngogijkkppficiiepmjebijinl) and click "Add to Chrome." Takes about 15 seconds. **Step 2: Link your iPhone to WhatsApp Web.** Go to [web.whatsapp.com](https://web.whatsapp.com). A QR code appears on screen. On your iPhone, open WhatsApp, go to Settings, then tap Linked Devices, then Link a Device. Scan the QR code with your iPhone camera. Your chats load in the browser within a few seconds. **Step 3: Open the chat you want to message.** Find the contact, group, or community you want to send to. **Step 4: Click the clock icon.** In the message input bar at the bottom of the chat, you will see a clock icon added by Blueticks. Click it. **Step 5: Write your message, set the time, and schedule.** A scheduling panel opens inside the chat. Type your message. Pick the send date with the calendar picker. Set the hour and minute. Click Schedule. The message is now queued. You can see it in your Blueticks dashboard, where you can edit or cancel it at any point before it sends. **What breaks:** If Chrome closes or your computer sleeps before the send time, the message queues until the session restores. If your iPhone disconnects from WhatsApp (this can happen if you manually log out from your phone's linked devices list), the message will not send until you re-link. Before any important scheduled send, do a self-test: schedule a message to your own number five minutes out. If it arrives, your setup is confirmed. ## Can You Set Up Recurring WhatsApp Reminders Automatically from iPhone? Yes, through the same Blueticks desktop setup. Blueticks supports recurring schedules — daily, weekly, monthly, or custom intervals. You configure the pattern once. The messages run on their own from that point. Common recurring setups that actually work with this approach: - A weekly Monday morning message to your sales team ("Weekly standup: 10 AM today — link in the group") - A monthly payment reminder to clients with a fixed billing cycle - A quarterly check-in with dormant contacts - An annual birthday message, set once, sends every year at 8 AM Each recurring message lives in your Blueticks dashboard. You can pause any series, edit an upcoming occurrence without touching the rest, or cancel the whole schedule. If you need to personalize one instance in the series, you edit just that occurrence. iPhone users searching for "programar mensajes whatsapp iphone" — scheduling WhatsApp messages on iPhone in Spanish — will find the same workflow applies. The desktop WhatsApp Web approach is the reliable path regardless of device language or region, because the limitation is in iOS itself, not in any particular app or language configuration. For the full setup of daily, weekly, and monthly patterns, see the guide on [scheduling recurring WhatsApp messages](https://blueticks.co/blog/schedule-recurring-whatsapp-messages). [image: calendar desk recurring] ## Frequently Asked Questions **If I schedule a message on my Mac, does it send from my iPhone's WhatsApp number?** Yes. WhatsApp Web is linked to your iPhone account via the multi-device feature. Scheduled messages send under your phone number — the recipient sees your name and number as normal, with no indication the message was scheduled. Your iPhone remains the primary account; the Mac session is a linked companion. **Do I need to keep my iPhone on when a scheduled message is due to send?** For the standard Blueticks setup, your iPhone needs to stay connected to the internet. WhatsApp Web sessions mirror your phone's connection. If your iPhone is off or in airplane mode for an extended window, the web session can expire. Blueticks' offline gateway eliminates this dependency by maintaining a persistent server-side session — messages send regardless of your phone's status. **Is there a free plan?** Yes. Blueticks has a free tier that covers one-time scheduled messages. Recurring schedules, offline delivery, and high-volume use are in the paid plans. For occasional scheduling, the free plan is enough to get started. **Can I schedule WhatsApp messages to a group from iPhone?** Yes. The Blueticks scheduler works with individual contacts, group chats, communities, and channels — anything accessible through WhatsApp Web. You schedule a group message the same way as a one-to-one message. The same clock icon, the same panel, the same send flow. **Does this work with WhatsApp Business on iPhone?** Yes. Blueticks works with both personal WhatsApp and WhatsApp Business accounts through WhatsApp Web. If your iPhone runs a WhatsApp Business number, link it to WhatsApp Web and schedule from there. The same limitation applies: WhatsApp Business on iPhone has no native scheduler, so the desktop method is the path that actually delivers. --- # Schedule WhatsApp Messages from Claude: The No-Code MCP Way (2026) > Type 'schedule a WhatsApp to Dana tomorrow at 9am' and Claude does it. The popular open-source WhatsApp MCP servers can only read and send. Blueticks' MCP is the one that also schedules and runs paced campaigns — from your own number, no terminal required. URL: https://blueticks.co/blog/schedule-whatsapp-messages-from-claude-mcp Published: 2026-06-27 Author: Daniel Roth Category: productivity There's a moment most people who automate WhatsApp hit eventually. You've connected Claude to your chats, you've watched it read a thread and draft a reply, and it feels like magic — until you ask it to send something *tomorrow morning* and it just... can't. It sends now or not at all. That gap is the whole reason this article exists. Reading and sending is the easy half of WhatsApp automation. The half that actually saves you time is timing: the follow-up that goes out at 9am while you're still asleep, the reminder that fires the day before an appointment, the customer batch that drips out over an hour instead of all at once. This guide is about closing that gap — telling Claude, in plain English, to schedule WhatsApp messages and run paced campaigns from your own number, without writing a line of code. ## Why connect WhatsApp to Claude at all If you live in WhatsApp for work, the friction isn't typing — it's context-switching. You think of a message you need to send Thursday, and you either send it now (wrong time) or you make a mental note (which you'll forget). Connecting WhatsApp to an AI assistant like Claude turns that thought into an action without leaving the conversation you're already in. The plumbing that makes this possible is MCP, the Model Context Protocol — the open standard Anthropic introduced in late 2024 that lets an AI model call external tools through a shared interface. A WhatsApp "MCP server" is a small program that exposes WhatsApp actions as tools Claude can call. Once it's connected, you don't click around an app. You say what you want, and Claude figures out which tool to call. For non-technical operators, that's the appeal: it's AI-ops without the "ops." No dashboards, no integrations to wire up, no scripts. Just a chat window where "schedule a WhatsApp to Dana tomorrow at 9am" becomes a scheduled message. ## What most WhatsApp MCP servers can't do Here's the part nobody tells you when you search "WhatsApp MCP server" and find a dozen GitHub repos. Almost all of them only **read and send**. The most popular open-source projects — the `whatsmeow`-based servers in Go, the Baileys-based ones in TypeScript — are genuinely good software. But look at their actual tool lists and you'll find the same shape every time: search contacts, list chats, read messages, send a message, maybe download media. That's it. There is no "schedule for later." There are no campaigns. There are no reusable audiences with per-contact personalization. If you want a message to go out at a specific future time, the open-source servers simply don't have a tool for it. On top of the missing scheduling, most of them need a developer to stand up. You're installing a Go toolchain or a Python environment, running a local bridge process, scanning a QR code into a terminal, and keeping that process alive on your own machine. The moment your laptop sleeps, the assistant loses its connection to WhatsApp. So the real gap isn't "can an AI touch WhatsApp" — plenty of tools clear that bar. The gap is "can I tell an AI to schedule and pace WhatsApp messages without being a developer." That's a much shorter list. For the full landscape of what's out there — official Cloud API servers, the open-source projects, and the trade-offs between them — see our [comparison of the best WhatsApp MCP servers](/blog/best-whatsapp-mcp-servers). This article is about the one capability that comparison singles out as unique: scheduling and campaigns from Claude. ## What the Blueticks MCP exposes to Claude The Blueticks MCP is built around the actions that the read-only servers leave out. Alongside reading and sending, Claude gets tools for: - **Scheduling.** Send a message at a future time, then list, reschedule, or cancel anything you've queued — all in plain English. - **Campaigns.** Schedule a *paced* bulk send against a list, with pause, resume, and cancel controls, so you're not firing hundreds of messages in one burst. - **Audiences.** Build reusable contact lists with per-contact variables like `{firstName}` and `{product}`, so a campaign message personalizes itself for each recipient. [image: tools capability split] Everything runs through the same engine that powers Blueticks' scheduling and campaigns inside the app — so the scheduling Claude triggers is the same first-class scheduling Blueticks has always done, just driven by a sentence instead of a form. (If you want the manual, in-app version, that's covered in our guide to [scheduling WhatsApp messages](/blog/schedule-whatsapp-messages).) One thing to be clear about up front: this runs over your **own** WhatsApp number via WhatsApp Web — the same unofficial transport Blueticks' extension uses — not Meta's official Cloud API. That has real consequences (we'll get to the honest limits below), but the upside is that there's no Meta Business verification, no number provisioning, and no per-template approval queue. It's the number you already use, sending messages that look exactly like you typed them. ## Connecting Blueticks to Claude Setup is two pieces: get your WhatsApp number connected to Blueticks, then add the MCP to Claude. Both are quick, and neither needs code. **Link your number.** Before Claude can schedule anything, Blueticks needs a live connection to your WhatsApp. This is the same link step the product uses everywhere else — you connect your existing, already-active WhatsApp account to the Blueticks engine by scanning a QR code, the way WhatsApp Web works. If you're already using Blueticks to schedule messages, you're done with this step. If you're starting fresh, the [Blueticks Chrome extension](https://chromewebstore.google.com/detail/adgnjhngogijkkppficiiepmjebijinl) is the simplest on-ramp to get connected. **Add the MCP to Claude.** The quickest route is the remote connector: in Claude, open Connectors, click Add custom connector, point it at `https://api.blueticks.co/mcp`, and approve access with a Blueticks login. No install and no key to store, and the in-app **AI Assistant** panel hands you the URL and walks you through it. If you'd rather use an API key, or you're on Claude Code or Cursor, Blueticks also publishes the `@blueticks/mcp` server you add with a `bt_live_` key in your Claude config; the package pulls itself on first run, so there's nothing to clone or keep alive. Either way, reconnect Claude and the WhatsApp tools appear. The full step-by-step for both paths lives in the [connect guide](https://blueticks.co/blog/connect-whatsapp-to-claude-mcp-integration). [image: connect claude config] I'm describing this at a level you can rely on rather than walking you through every keystroke, because the exact menu and file paths differ between Claude Desktop, Claude Code, and other MCP clients, and they evolve. The current, version-correct setup steps — the config block, where the file lives on your OS, and how to mint an API key — live in the official [Blueticks developer docs](https://dev.blueticks.co). Follow those for the precise commands. Once it's connected, a good first test is simply to ask Claude whether your WhatsApp is connected. If the engine is linked, it'll confirm — and you're ready to schedule. ## Telling Claude to schedule a message This is the payoff. With the MCP connected, scheduling is one sentence: > "Schedule a WhatsApp to +1 415 555 0134 tomorrow at 9am: 'Morning Dana — confirming our call at 2pm today.'" Behind that sentence, Claude does a few things in order. It first checks your current date, time, and timezone, so "tomorrow at 9am" resolves to the right moment instead of the server's clock. It drafts the message and shows it to you. And once you approve, it queues the send for that exact time. The queue is fully conversational after that. Ask "show me my scheduled WhatsApp messages" and Claude lists what's pending. Change your mind with "reschedule the message to Dana to 11am" or "cancel it," and it updates or removes the queued send. You never open a calendar, a form, or the app. The everyday version of this is the follow-up you'd otherwise forget. You finish a call, and instead of making a mental note, you say: "schedule a WhatsApp to this client Friday at 10am asking if they've had a chance to review the proposal." Done, off your mind, fires while you're doing something else. ## Telling Claude to run a paced campaign or follow-up drip Scheduling one message is useful. Scheduling the *same* message to a list — without machine-gunning it out all at once — is where the campaign tools earn their place. Say you want to let a group of customers know about early access. You can tell Claude: > "Create an audience called Early Access with these numbers, then run a campaign to them: 'Hi \{firstName\}, early access opens Monday — want me to reserve your spot?'" [image: paced campaign flow] Claude builds the reusable audience, attaches the per-contact variables, and schedules a **paced** campaign against it. The `{firstName}` token resolves per recipient, so each person gets a message addressed to them, not a generic blast. And because it's a campaign rather than a loop of individual sends, it goes out spread over time, and you keep pause, resume, and cancel control by just asking for it: "pause the Early Access campaign," "resume it," "cancel it." That same pattern is how you'd build a light follow-up drip — a first message now, a nudge scheduled for a few days later to anyone who hasn't replied. You're orchestrating it in conversation, but the actual delivery is handled by the same paced engine Blueticks uses for campaigns in the app. ## What it can't (and shouldn't) do I'd be doing you a disservice if I left it at the happy path. A few honest limits: **This is not Meta's official Cloud API.** It runs over WhatsApp Web with your own number — an unofficial transport. That's what makes it no-code and free of per-template fees, but it also means you're operating under WhatsApp's normal anti-abuse rules, not inside a Meta-blessed business channel. Using third-party automation on WhatsApp can put a number at risk if you abuse it. If you need Meta-verified, high-volume, template-based business messaging, the Cloud API is the right tool, not this. **No per-template or per-message Meta fees — with an asterisk.** You're not paying Meta's conversation-based pricing because you're not using Meta's billed channel at all. That's a genuine cost saving, but it's not "free messaging" at WhatsApp's layer — it's "no Meta template billing." Don't read it as unlimited. **Pace yourself, especially at first.** Don't blast hundreds of messages in seconds, and don't message people who never opted to hear from you. Start with a small batch, watch that it's delivering cleanly, then scale up. The campaign tools exist precisely so you *can* pace; use them. No one — not Blueticks, not any unofficial tool — can promise zero ban risk, so behave like a careful human. **Claude acts on your instruction, not on its own.** This is not an always-on autonomous agent that decides to message people for you. It schedules and sends when *you* tell it to (or when you set up a campaign that runs on a schedule you defined). The control stays with you, and the draft-before-send step is there so nothing leaves your account without your say-so. **Free vs Pro.** On the Free plan, single scheduled messages are limited to three at a time and sends carry a "Powered by blueticks.co" footer — though Free can still run bulk campaigns. Pro removes the branding and adds offline sending so you don't need WhatsApp Web open. Worth knowing before you build a workflow around it. ## FAQ **Can Claude actually schedule a WhatsApp message for later, or only send now?** It can schedule. With the Blueticks MCP connected, you can ask Claude to send a message at a future time, and then list, reschedule, or cancel anything you've queued — all in plain English. This is the capability the popular open-source WhatsApp MCP servers don't have. **Do I need to know how to code?** No. You add one server entry to your Claude config and create an API key — there's no toolchain to install, no repo to clone, and nothing to keep running on your machine. The WhatsApp session runs on Blueticks' hosted engine. The current step-by-step config lives at dev.blueticks.co. **Does it send from my own number?** Yes. It runs over your own connected WhatsApp account via WhatsApp Web, so recipients see a normal message from you, not from a third party. You link your number once by scanning a QR code, the way WhatsApp Web works. **Is this the official WhatsApp Business / Cloud API?** No. It's an unofficial WhatsApp Web integration on your own number. That's what keeps it no-code and free of Meta's per-template fees, but it also means you're under WhatsApp's normal usage rules. For Meta-verified, high-volume template messaging, use the official Cloud API instead. **Will scheduling from Claude get my number banned?** Not if you behave like a human. Risk rises sharply with cold outreach and high volume, and stays low for messaging people who expect to hear from you. Pace bulk sends through campaigns, start small, and don't message strangers. No unofficial tool can promise zero risk. **Can it run a follow-up drip automatically?** You can schedule a first message and a later nudge, and run paced campaigns with pause/resume/cancel control. It acts on the schedule and campaigns *you* set up — it's not an autonomous agent that messages people on its own. ## Schedule your first WhatsApp from Claude The open-source WhatsApp MCP servers stop at reading and sending. The thing that actually saves you time — telling an AI to schedule a message for 9am tomorrow, or to drip a personalized campaign out over the next hour — is the part they can't do. Blueticks' MCP is built around exactly that, no terminal required, from the number you already use. Connect your number, add the MCP to Claude, and try the one sentence that started this article: "schedule a WhatsApp to someone tomorrow morning." The full setup and your API key are at [dev.blueticks.co](https://dev.blueticks.co). --- # How to Schedule & Send WhatsApp Messages via API (Python & Node, 2026) > Most WhatsApp APIs can only send a message right now. Far fewer let you schedule one for later — from your own number, over a plain REST call. Here's how to do both in Python and Node, with webhooks for delivery and replies. URL: https://blueticks.co/blog/send-schedule-whatsapp-messages-api Published: 2026-06-27 Author: Priya Nair Category: productivity If you have ever wanted to fire a WhatsApp message straight from your own backend — a payment reminder the night before it's due, an order alert the moment a webhook lands, a follow-up three days after signup — you have probably run into the same wall I did. Most "WhatsApp APIs" send a message *now*. Very few let you hand them a timestamp and say "deliver this Tuesday at 9am." And almost none of them let you do it from the number you already use, without applying to Meta first. This guide walks through both halves of that problem in Python and Node: sending a WhatsApp message from code, and the rarer trick — **scheduling** one for later via a single REST call. The examples below use the Blueticks API, which I picked specifically because the scheduling endpoint and the own-number transport are the two things that are hard to find elsewhere. I'll be honest about the trade-offs too, because there are real ones. ## When you want to send or schedule WhatsApp from code A few patterns show up over and over once you can talk to WhatsApp programmatically: - **Reminders.** Appointment confirmations, rent-due nudges, "your trial ends tomorrow." These are almost always *future-dated* — you know at creation time exactly when they should land. - **Alerts.** Server down, payment failed, a high-value lead just filled in a form. These are *immediate* — fire on an event. - **Drip sequences.** Onboarding messages spaced out over days, re-engagement after a period of silence. A mix of both: you compute the send times up front and queue them. The immediate-alert case is well served by basically every messaging API on the market. The reminder and drip cases are where scheduling matters, and where you usually end up running your own cron job, a queue, and a worker just to hold a message until its time comes. The appeal of a scheduling endpoint is that you delete all of that infrastructure and let the API hold the message for you. ## The landscape: official Cloud API vs unofficial own-number APIs Before any code, it's worth being clear about what kind of API this is, because the category determines everything downstream — cost, setup friction, and risk. **Meta's WhatsApp Cloud API** (the official Business Platform, also resold by Twilio, 360dialog, and others) is the sanctioned path. You register a business, verify it, get a dedicated business phone number, and send through Meta's infrastructure. It's reliable and it's the right choice for high-volume, compliance-sensitive sending. The costs are conversation- and template-based, and that pricing model has been shifting toward per-message charges — I dug into the numbers in [our WhatsApp Business API pricing breakdown for 2026](/blog/whatsapp-business-api-pricing-2026). The friction is real: business verification, template approval, and a separate number you have to provision. **Unofficial own-number APIs** take a different route. Instead of Meta's servers, they drive WhatsApp Web on your behalf — the same protocol your phone uses when you open WhatsApp in a browser tab. The message goes out from *your existing, already-active number*. That means: - No Meta Business verification. - No template pre-approval and no per-template fees. - Messages come from the number your contacts already recognize. Blueticks sits in this second category. It is **not** Meta's Cloud API and not the official Business Platform — it's an unofficial WhatsApp-Web transport running on your own number. That's the differentiator, and it's also where the honesty section later in this article comes in, because an own-number transport carries flagging and Terms-of-Service risk that the official API does not. Use the right tool for your volume and risk tolerance. If you're exploring the AI-assistant angle on top of all this, there's a parallel ecosystem of [WhatsApp MCP servers](/blog/best-whatsapp-mcp-servers) worth a look — but for plain backend integration, REST is what you want. ## Authentication: getting an API key Authentication is a single bearer token. You create an API key in your Blueticks account, and every request carries it in the `Authorization` header: ``` Authorization: Bearer bt_live_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ``` Keys are environment-scoped. A live key is prefixed `bt_live_` and a test key `bt_test_`, so you can wire up a sandbox path in CI without touching production. Keep the key server-side — it authenticates as your workspace and your WhatsApp number, so it does not belong in a browser bundle or a mobile app. The base URL for every endpoint below is: ``` https://api.blueticks.co ``` [image: api key on paper] ## Send a WhatsApp message via API Let's start with the immediate send. The endpoint is `POST /v1/scheduled-messages` — yes, the *same* endpoint handles both immediate and scheduled sends; the only difference is whether you include a `send_at` field. Omit it, and the message goes out now. The body is a small JSON object. The required fields are `type` (the message kind — `text`, `media`, or `poll`), `to` (an E.164 phone number like `+14155551234`, or a WhatsApp chat id), and the content for that type. Here it is as a raw HTTP call: ```bash curl -X POST https://api.blueticks.co/v1/scheduled-messages \ -H "Authorization: Bearer bt_live_..." \ -H "Content-Type: application/json" \ -d '{ "to": "+14155551234", "type": "text", "text": "Your order #1024 has shipped. Track it here: https://example.com/t/1024" }' ``` The response echoes back an `id` (the internal message id you can poll), a `key` (the WhatsApp wire id, populated once the message actually dispatches), a `status`, and a set of lifecycle timestamps (`created_at`, `sent_at`, `delivered_at`, `read_at`, `failed_at`). There are official SDKs if you'd rather not hand-roll HTTP. In **Python**, install the client and call the typed method: ```python # pip install blueticks from blueticks import Blueticks client = Blueticks(api_key="bt_live_...") msg = client.scheduled_messages.create( to="+14155551234", type="text", text="Your order #1024 has shipped.", ) print(msg.id, msg.status) ``` And the equivalent in **Node** (TypeScript or JavaScript): ```javascript // npm install blueticks import { Blueticks } from "blueticks"; const client = new Blueticks({ apiKey: "bt_live_..." }); const msg = await client.scheduledMessages.create({ to: "+14155551234", type: "text", text: "Your order #1024 has shipped.", }); console.log(msg.id, msg.status); ``` Both SDKs map directly onto the REST shape, so anything you can express in JSON you can express through them. Beyond `text`, the same `create` call accepts `type: "media"` (with an https media URL or base64 bytes) and `type: "poll"` — covered in the API reference. ## Schedule a message for later — the differentiator Here's the part that's genuinely hard to find elsewhere. To schedule rather than send, add a single field: `send_at`, an ISO 8601 timestamp with offset. The API holds the message and dispatches it at that time. No cron job, no queue, no worker process of your own. ```bash curl -X POST https://api.blueticks.co/v1/scheduled-messages \ -H "Authorization: Bearer bt_live_..." \ -H "Content-Type: application/json" \ -d '{ "to": "+14155551234", "type": "text", "text": "Reminder: your appointment is tomorrow at 10:00am.", "send_at": "2026-07-01T09:00:00+00:00" }' ``` In Python: ```python from datetime import datetime, timedelta, timezone from blueticks import Blueticks client = Blueticks(api_key="bt_live_...") send_time = datetime.now(timezone.utc) + timedelta(days=1) client.scheduled_messages.create( to="+14155551234", type="text", text="Reminder: your appointment is tomorrow at 10:00am.", send_at=send_time.isoformat(), ) ``` In Node: ```javascript import { Blueticks } from "blueticks"; const client = new Blueticks({ apiKey: "bt_live_..." }); const sendAt = new Date(Date.now() + 24 * 60 * 60 * 1000).toISOString(); await client.scheduledMessages.create({ to: "+14155551234", type: "text", text: "Reminder: your appointment is tomorrow at 10:00am.", send_at: sendAt, }); ``` A couple of constraints worth knowing, both enforced by the API: `send_at` must be at least **10 seconds** in the future (so you can't accidentally schedule into the past) and at most **365 days** out. The message comes back with `status: "scheduled"` until its time arrives. Because the message lives as a real queued record, you can also manage it after the fact. `GET /v1/scheduled-messages/{id}` reads its current status; a `PATCH` to the same id lets you edit the text or move the `send_at` while it's still pending; and there's a cancel path to pull it back before it fires. That edit-and-cancel window is what makes the scheduling endpoint useful for things like "remind the customer 24h before, *unless* they pay first" — you cancel the reminder when the payment webhook lands. [image: calendar reminder desk] ## Bulk sends: audiences and campaigns Sending one message at a time is fine for transactional traffic. For one-to-many — a broadcast, a promotion, a notice to a segment — there are two building blocks. An **audience** is a named list of contacts. You create it once and append contacts to it, optionally attaching custom variables to each contact for personalization: ```python audience = client.audiences.create( name="July reminders", contacts=[ {"to": "+14155551234", "variables": {"first_name": "Sam"}}, {"to": "+14155555678", "variables": {"first_name": "Alex"}}, ], ) ``` A **campaign** then sends one message to every contact in an audience, substituting those variables with `{token}` syntax in the template: ```python client.campaigns.create( name="July reminder blast", audience_id=audience.id, text="Hi {first_name}, a quick reminder that your renewal is coming up.", ) ``` Built-in tokens like `{phone}` and `{displayname}` are always available, and you choose what happens when a contact is missing a variable the template references — fail the whole campaign up front, or skip the substitution. Campaigns can be paused, resumed, and cancelled while they run. One pacing note that matters here more than anywhere else: this is an own-number transport, not a bulk-SMS gateway. Blasting a large list at full speed is exactly the behavior that gets a number flagged. Start small, watch your delivery, and scale up gradually. More on that below. ## Webhooks for delivery and replies Polling a message id for its status works, but webhooks are cleaner. Register an endpoint and a list of events, and Blueticks will POST to your URL as things happen: ```python hook = client.webhooks.create( url="https://your-app.example.com/webhooks/blueticks", events=["message.delivered", "message.read", "message.failed"], ) # hook.secret is returned once — store it to verify signatures. ``` The event catalogue covers the message lifecycle (`message.queued`, `message.sending`, `message.delivered`, `message.read`, `message.failed`), campaign progress (`campaign.started`, `campaign.completed`, `campaign.aborted`, and the pause/resume pair), and session state (`session.connected`, `session.disconnected`). Crucially for two-way use cases, there's also an **inbound** event so you can react to *replies* — when someone messages your number back, your endpoint hears about it. Every delivery is signed. The request carries an `X-Blueticks-Signature` header of the form `sha256=`, which is an HMAC-SHA256 of the raw request body keyed with the secret you got at registration. Verify it before trusting the payload: ```javascript import crypto from "node:crypto"; function verify(rawBody, header, secret) { const expected = "sha256=" + crypto.createHmac("sha256", secret).update(rawBody).digest("hex"); return crypto.timingSafeEqual(Buffer.from(header), Buffer.from(expected)); } ``` You can rotate a webhook's secret without re-registering, and disable a hook without deleting it. ## Limits, pacing, and ban risk — the honest part I'd be doing you a disservice if I skipped this. An own-number, WhatsApp-Web transport is not the official Business Platform, and that difference is not just about features: - **There is no "unlimited, guaranteed" sending here, and I won't pretend otherwise.** WhatsApp actively watches for spammy patterns, and a number that suddenly sends hundreds of unsolicited messages can get rate-limited or banned. That risk is inherent to the category, not specific to any one provider. - **Pace yourself.** Send to people who expect to hear from you, ramp volume gradually, and keep your content relevant. The APIs above will happily accept a large campaign — restraint is on you. - **It runs on your existing number,** which is the upside (recognizable sender, no verification) *and* the thing you're putting at risk if you abuse it. Treat it accordingly. - **"No per-template fees / no verification" is true relative to Meta's model** — there are no template-approval fees because there are no Meta templates in the path. That's a genuine cost advantage for the right use case, not a loophole around messaging hygiene. On the plan side: the **Free** plan can send bulk campaigns (the three-at-a-time limit applies to scheduled messages, not campaigns) but appends a "Powered by blueticks.co" footer, and a paid **Pro** plan removes that branding and unlocks the always-on offline mode so sends fire even when your computer is closed. Match the plan to whether branding and 24/7 delivery matter for your integration. For idempotency on retries, the send endpoint accepts an `Idempotency-Key` request header — pass a stable key and a network retry won't double-send. API keys also carry scopes (`messages:write`, `campaigns:write`, and so on), so you can mint a key that can only do what a given service needs. ## FAQ **Is this the official WhatsApp Business / Cloud API?** No. It's an unofficial WhatsApp-Web transport that sends from your own already-active number. If you need Meta's sanctioned, verified, high-volume platform, that's a different product (see the [pricing breakdown](/blog/whatsapp-business-api-pricing-2026) for that path). **Can I really schedule a message for a future date over the API?** Yes — include a `send_at` ISO 8601 timestamp on the send call. It has to be at least 10 seconds out and within 365 days. The message is held server-side and you can edit or cancel it before it fires. **Which languages have SDKs?** There are official clients for Python and Node, both installed as `blueticks`, plus additional language SDKs. Everything is also reachable as plain REST, so any HTTP client works. **Do I need to verify a business with Meta?** No — that's the point of the own-number model. The trade-off is the flagging/ToS risk discussed above, which the official API doesn't carry. **Can I receive replies, not just send?** Yes, via webhooks. Register an inbound message event and your endpoint is notified when someone replies to your number. **Will my number get banned?** It can, if you send spammy or unsolicited volume. Pace your sends, message people who expect to hear from you, and ramp up gradually. No provider can guarantee zero risk on an own-number transport. ## Build it If you want to send or schedule WhatsApp messages from your own code — on your own number, without the Meta verification dance — the full API reference, the SDK installs, and an interactive sandbox are at **[dev.blueticks.co](https://dev.blueticks.co)**. Grab a `bt_test_` key, fire the curl call from the send section above, and you'll have a message scheduled in about two minutes. [image: phone notification evening] --- # How to Bulk-Schedule WhatsApp Messages From a Spreadsheet (CSV, Excel & Google Sheets) > Stop copy-pasting the same WhatsApp message 80 times. Here's how to take a spreadsheet of contacts, personalize each message, and schedule the whole batch from your own number with Blueticks. URL: https://blueticks.co/blog/bulk-schedule-whatsapp-messages-from-spreadsheet Published: 2026-06-26 Author: Daniel Roth Category: productivity If you have ever sent the same WhatsApp update to a list of people one chat at a time, you already know how it goes. You copy the message, paste it, swap in a name, hit send, scroll to the next contact, and repeat until your thumb hurts and you have lost track of who you have already messaged. For 80 contacts that is 80 copy-pastes. There is a much faster way. This guide walks through how to take a plain spreadsheet, a CSV, an Excel file, or a Google Sheet, and turn it into a scheduled, personalized WhatsApp campaign that sends from your own number. We will use [Blueticks](https://blueticks.co), a Chrome extension that runs on top of your existing WhatsApp Web session, so there is no separate API to set up and no business-account approval to wait for. A quick note before we start. This is the spreadsheet bulk-import workflow. If you only need to schedule a single message or a recurring reminder, our guide on [how to schedule WhatsApp messages](/blog/schedule-whatsapp-messages) covers that. And if you are still comparing tools, see [the best apps to schedule WhatsApp messages](/blog/best-apps-to-schedule-whatsapp-messages). This article assumes you have a list and want to send to all of it at once. ## When to bulk-schedule from a spreadsheet Bulk-scheduling from a list makes sense whenever the same core message goes to many people, but each person needs at least their name to feel like a real message instead of a blast. A few common cases: - **Event reminders.** You have a sign-up sheet for a workshop, a class, or a community meetup, and you want everyone to get a reminder the morning of. - **Order and shipping updates.** A batch of orders shipped today, and each customer wants to know their package is on the way. - **Appointment confirmations.** A clinic, salon, or studio confirming tomorrow's bookings, each with the right time. - **Follow-ups.** You met a stack of people at a trade show or collected leads from a form, and you want to send one warm follow-up to all of them. The common thread is that you already have the data in a spreadsheet, the recipients expect to hear from you, and sending one at a time would eat an hour you do not have. This is not the tool for cold outreach to people who never asked to hear from you. WhatsApp is strict about that, and so are we. Stick to lists where people opted in, and the rest of this guide will go smoothly. ## Step 1: Prep your spreadsheet Everything downstream depends on a clean spreadsheet, so it is worth getting this right first. The good news is the structure is simple: one row per recipient, one column per piece of information. At a minimum you need a **phone number** column. The single most important rule here is to use full international format, including the country code, with no spaces, dashes, or brackets. So a US number becomes `15551234567` and a UK number becomes `447700900123`. Skip the leading `+` if your spreadsheet tends to strip it, what matters is that the country code is present and the digits are clean. Numbers stored in local format without a country code are the number-one reason a bulk send misfires. Next, add a column for **name**. This is what makes each message feel personal instead of mass-produced. You can split it into first and last name columns if you want finer control over the greeting. Then add any **personalization variables** you want to merge in. Anything that changes per person can be its own column: appointment time, order number, event date, plan name, city. If it lives in a column, you can drop it into the message later. A clean sheet might look like this: | phone | first_name | appointment_time | |---|---|---| | 15551234567 | Maria | 2:30 PM | | 447700900123 | James | 10:00 AM | A few prep tips that save headaches: - Put clear, simple headers in the first row. You will reference them when you map columns to placeholders. - Remove blank rows and obvious duplicates before you import. - Double-check the country codes. Mixed-country lists are where formatting mistakes hide. [image: clean spreadsheet prep] ## Step 2: Install Blueticks and open WhatsApp Web If you have not already, install the [Blueticks extension from the Chrome Web Store](https://chromewebstore.google.com/detail/adgnjhngogijkkppficiiepmjebijinl). It works in Chrome and other Chromium-based browsers like Edge and Brave. Once it is installed, open WhatsApp Web and link your phone the usual way by scanning the QR code if you have not already. Blueticks layers its scheduling and campaign tools onto the WhatsApp Web interface you already use. Worth being clear about what this means: messages send from your own personal WhatsApp number through WhatsApp Web. This is an unofficial transport, not Meta's official Cloud or Business API, which is exactly why there is no template approval process and no per-message fee. The trade-off is that you are responsible for sending responsibly, which we will come back to in the ban-avoidance section. ## Step 3: Import your list as an audience With your spreadsheet ready, the next step is to bring it into Blueticks as an **audience**, which is just Blueticks' term for a saved contact list you can send to. Blueticks accepts spreadsheet uploads in **CSV, XLSX, and XLS** formats, so you do not have to convert an Excel file to CSV first. You can also import directly from **Google Sheets** or pull from your existing **WhatsApp contacts**. When you create a new audience, Blueticks gives it a default name based on the current date, which you can rename to something you will recognize later, like "June workshop reminders." The one hard requirement is that phone-number column. As long as your sheet has phone numbers in clean international format, the import will recognize your recipients. The extra columns you added for personalization come along for the ride and become available as variables in the next step. A nice side effect of importing as an audience: these contacts do not have to be saved in your phone. You can message a list of 200 people without cluttering your address book with 200 new contacts. [image: import audience upload] ## Step 4: Map columns to personalization fields This is the step that turns a generic blast into something that reads like you wrote it by hand. Blueticks uses curly-brace placeholders for personalization. Standard fields have ready-made variables like `{First Name}`, `{Last Name}`, and `{WhatsApp name}`. Beyond those, any column in your imported spreadsheet can be used as a personalization variable, so your `appointment_time` or `order_number` column becomes something you can drop straight into the message. When you compose the campaign, you insert these placeholders where the personal detail should go. At send time, Blueticks swaps each placeholder for that row's value. So `{First Name}` becomes "Maria" for one recipient and "James" for the next, and your `{appointment_time}` column fills in each person's real slot. The practical advice here is to keep your column headers clean and predictable when you prep the sheet, because those headers are what you will reference. A header like `appointment_time` is far easier to work with than `Appt. Time (please confirm)`. ## Step 5: Compose your message with placeholders Now write the actual message, dropping placeholders in wherever a detail should change per person. Here is what a personalized appointment confirmation might look like: > Hi \{First Name\}, this is a reminder about your appointment tomorrow at \{appointment_time\}. Reply YES to confirm or let me know if you need to reschedule. See you then! For each recipient, that renders as "Hi Maria, this is a reminder about your appointment tomorrow at 2:30 PM..." and so on down the list. A few composition tips: - **Lead with the name.** A message that opens with the person's first name reads as personal and tends to get better engagement than a wall of text. - **Give people a way out.** Including a simple opt-out line, like "reply STOP to unsubscribe," is both courteous and good for your sending reputation. - **Keep it genuinely useful.** The messages that get flagged are the ones that read like spam. A real reminder or update to someone who expects it does not. Blueticks also supports attachments such as images and documents alongside the text, so you can attach a flyer to an event reminder or a receipt to an order update. ## Step 6: Set the send time Once the message is written, you decide when it goes out. Blueticks gives you two clear options: send the campaign **immediately**, or pick a **specific date and time** for it to go out later. For most spreadsheet campaigns, scheduling beats sending right now. A morning-of event reminder lands best a few hours before the event. A shipping update can wait until business hours. Picking the right moment is half the value of scheduling in the first place. About pacing. Blueticks sends large campaigns in batches rather than firing every message at the same instant, which helps avoid tripping WhatsApp's spam protection. That batching is handled for you rather than being a dial you set. So your job is less about configuring intervals and more about being sensible with list size and frequency, which the ban-avoidance section below covers. If you want true offline sending, where the campaign fires on schedule even when your computer is asleep or WhatsApp Web is closed, that is a feature of the paid Pro plan. On the free and lower tiers, the browser generally needs to be open for scheduled sends to go out. ## Step 7: Review and queue the campaign Before anything sends, Blueticks shows you a **review summary** of the campaign. This is your last checkpoint, and it is worth slowing down for. On the summary screen you can see the audience, the message, and the timing all in one place, and make last-minute edits using the pencil icons next to each section. Things worth a final look: - Does the recipient count match what you expected? If your spreadsheet had 80 rows but the audience shows 60, some numbers probably failed to import, usually a formatting issue. - Does the message preview render placeholders correctly for a sample recipient? - Is the send time right, including the time zone you are thinking in? When it all checks out, confirm and queue the campaign. From here Blueticks handles the sending in the background. [image: campaign review summary] ## Step 8: Track sends and handle failures and replies After a campaign is queued or sent, you can monitor it from the **Campaign Manager**, where you can view the status of your campaigns and track delivery and read rates. This is where you catch the stragglers. A few messages failing in a large batch is normal and usually comes down to one of a handful of causes: - **Bad number format.** The most common culprit. Go back to the spreadsheet, fix the country code or stray characters, and you can re-send just to the ones that failed. - **The number is not on WhatsApp.** Some phone numbers simply do not have a WhatsApp account attached. There is nothing to fix here; those will not deliver. - **The recipient blocked you previously.** Rare on an opted-in list, but it happens. Replies come back into your normal WhatsApp Web chats, since everything sends from your own number. That is a real advantage of this approach: when someone answers your appointment reminder or shipping update, it is a normal conversation in your inbox, not a reply trapped inside a separate marketing platform. Keep an eye on those chats after a campaign, because a batch of reminders often generates a wave of quick replies. ## Step 9: Tips to avoid bans (risk reduction, not a guarantee) Let me be upfront about this. Sending bulk messages through a personal WhatsApp number always carries some risk, because you are using WhatsApp Web in a way Meta does not officially endorse for marketing. No tool, technique, or setting can promise you will never be limited or banned. What you can do is lower the odds substantially by behaving like a real person having real conversations. Here is how: - **Only message people who opted in.** This is the single biggest factor. WhatsApp's spam detection leans heavily on how recipients react. People who expect your message do not report it. People who do not, will. Cold lists are the fastest route to trouble. - **Warm up a newer number.** If the number you are sending from is new or has barely been used, do not start with a 500-person campaign on day one. Build up normal usage first and grow your batch sizes gradually. - **Keep batches reasonable.** Just because you can import a huge list does not mean you should send to all of it at once, every day. Smaller, well-targeted sends to people who care are safer than mass blasts. - **Let it pace.** Blueticks already batches large campaigns to avoid hammering the system. Do not try to rush around that by firing campaign after campaign back to back. - **Make every message worth receiving.** Genuinely useful, expected, personalized messages get replies. Generic spam gets reported. The content itself is part of your safety. - **Always offer an opt-out.** A simple "reply STOP to unsubscribe" line reduces reports and keeps your list healthy over time. Follow these and you are doing everything within your control to stay safe. The rest comes down to keeping your sending genuinely consent-based. ## FAQ **Can I import from Google Sheets, or only CSV and Excel?** Both. Blueticks accepts CSV, XLSX, and XLS spreadsheet uploads, and you can also import directly from Google Sheets or pull from your existing WhatsApp contacts. If you keep your list in a Google Sheet, you can bring it in directly rather than exporting to a file first. **Does this work on the free plan?** Yes. The free plan can run bulk campaigns. The main differences are that free-plan campaigns include a "Powered by blueticks.co" footer on the messages, while the Pro plan removes that branding, and offline sending, where campaigns fire even with your browser closed, is a Pro feature. Note that the three-at-a-time limit on the free plan applies to single scheduled messages, not to campaigns. **Does Blueticks use the official WhatsApp Business API?** No. Blueticks is a Chrome extension that runs on top of WhatsApp Web and sends from your own personal number. That is what lets you skip template approvals and per-message fees, but it also means you should send responsibly, since you are using your own number rather than an officially sanctioned marketing channel. **How many recipients can I send to?** Blueticks markets campaigns as supporting large recipient lists, and large campaigns are batched automatically to avoid spam triggers. In practice, the safer question is not the technical ceiling but what your number can handle without raising flags. For an opted-in list, sending to a few dozen up to a few hundred contacts at a time is a sensible range, especially while a number is still warming up. **Can I personalize each message individually?** Yes, that is the whole point of the column mapping. Using placeholders like `{First Name}` plus any custom column from your spreadsheet, every recipient gets a message filled in with their own details, while you only write the message once. **What if some messages fail?** Failures usually trace back to phone-number formatting, numbers that are not registered on WhatsApp, or someone who blocked you. Check the campaign status in the Campaign Manager, fix any formatting issues in your spreadsheet, and re-send to just the recipients that did not go through. ## Ready to send your first spreadsheet campaign? If you have been sending the same WhatsApp update by hand, this is the workflow that gives you your evenings back. Prep one clean spreadsheet, import it as an audience, map your columns to placeholders, write the message once, pick a send time, and let Blueticks handle the rest from your own number. [Install Blueticks from the Chrome Web Store](https://chromewebstore.google.com/detail/adgnjhngogijkkppficiiepmjebijinl) and run your first personalized campaign today. For more on scheduling, see our guides on [scheduling WhatsApp messages](/blog/schedule-whatsapp-messages) and [the best apps to schedule WhatsApp messages](/blog/best-apps-to-schedule-whatsapp-messages). --- # WhatsApp Business Per-Message Pricing in 2026: How the Model Changed and What It Costs (With a Worked Example) > Conversation pricing ended July 1, 2025. In 2026 you pay per delivered template message, by category and recipient country. Here is the transition explained plus a reproducible monthly-cost calculator. URL: https://blueticks.co/blog/whatsapp-business-pricing-change-2026-per-message Published: 2026-06-25 Author: Priya Nair Category: industry If you budgeted WhatsApp messaging in 2024, the line items you tracked no longer exist. The unit you used to pay for, a 24-hour conversation, was retired. As of July 1, 2025, the WhatsApp Business Platform bills per delivered template message instead ([Meta, Pricing on the WhatsApp Business Platform](https://developers.facebook.com/documentation/business-messaging/whatsapp/pricing)). This article explains the transition mechanics and then walks through a reproducible monthly-cost estimate for a US/default-region sender. It is deliberately thin on the full rate card. For the complete category-by-country table, see our pillar, [WhatsApp Business API Pricing in 2026](/blog/whatsapp-business-api-pricing-2026). For EUR regional rates, see [WhatsApp Business Pricing in Europe 2026](/blog/whatsapp-business-pricing-europe-2026). ## From conversation-based to per-message: what changed, and exactly when The change took effect **July 1, 2025** ([Meta pricing docs](https://developers.facebook.com/documentation/business-messaging/whatsapp/pricing); see also the deprecated [Conversation-based pricing](https://developers.facebook.com/documentation/business-messaging/whatsapp/pricing/conversation-based-pricing/) page). Under the old **conversation-based pricing (CBP)** model, a single fee covered a 24-hour conversation window. Within that window you could send multiple template messages of the same category and pay once. The billing unit was the conversation, not the message. Under the new **per-message pricing (PMP)** model, each delivered template message is billed individually. The 24-hour conversation bucket no longer caps your cost. If you send three marketing template messages to the same recipient in one day, that is three billable units, not one. Two practical consequences follow: 1. **You now budget in messages, not conversations.** Most teams find message volume easier to forecast than conversation volume, which is part of why Meta made the change. 2. **Sending discipline matters more.** Under CBP, a second template in the same window was free. Under PMP it is another charge. Batching no longer hides inside a conversation window. One thing did not change: **billing is keyed to delivery**. You are charged when a template message is delivered, not when you submit it ([Meta pricing docs](https://developers.facebook.com/documentation/business-messaging/whatsapp/pricing)). ## The template categories you pay per In 2026 the platform recognizes four template categories. Three are billable as template messages; one is the free customer-service lane. - **Marketing.** Promotions, offers, announcements, re-engagement, anything that nudges a purchase or builds awareness. This is the highest-priced category ([Meta pricing docs](https://developers.facebook.com/documentation/business-messaging/whatsapp/pricing)). - **Utility.** Transaction-tied messages: order confirmations, shipping updates, receipts, appointment reminders, account alerts. Billed per message, but with an important free case described below. - **Authentication.** One-time passcodes and login/verification codes. Billed per message. Meta applies volume-based tiered discounts to this category ([Meta pricing docs](https://developers.facebook.com/documentation/business-messaging/whatsapp/pricing)). - **Service.** Free-form replies to a customer who messaged you first, inside the open customer-service window. These are not template messages and are not charged ([Meta pricing docs](https://developers.facebook.com/documentation/business-messaging/whatsapp/pricing)). Category is assigned at the template level when you create and submit a template, and Meta classifies it. You do not get to relabel a promotional message as "utility" to pay the lower rate; misclassified templates get re-categorized. [image: category buckets flat lay] ## How per-message billing actually works Three rules decide whether a given message costs anything. **1. Billable template messages.** Marketing, utility, and authentication templates are billed per delivered message, at a rate set by the **recipient's country** and the template's **category** ([Meta pricing docs](https://developers.facebook.com/documentation/business-messaging/whatsapp/pricing)). The rate follows the customer's phone number country code, not where your business is registered. **2. The free customer-service window.** When a customer messages your business, a **24-hour customer-service window** opens, and it resets each time the customer sends another message. Inside that window your free-form **service** replies are free ([Meta pricing docs](https://developers.facebook.com/documentation/business-messaging/whatsapp/pricing)). **3. Free utility inside the window.** A **utility** template delivered while that customer-service window is open is **not charged** ([Meta pricing docs](https://developers.facebook.com/documentation/business-messaging/whatsapp/pricing)). This is a meaningful saving: if a customer asks "where's my order?" and you reply with a utility shipping-update template inside the open window, that template is free. The same utility template sent to a cold contact with no open window is billable. **4. Free entry points.** When a customer reaches you through a **click-to-WhatsApp (CTWA) ad** or a **Facebook Page call-to-action button**, a **72-hour free window** opens, and messages within it (including business-initiated ones) are not charged ([Meta pricing docs](https://developers.facebook.com/documentation/business-messaging/whatsapp/pricing)). This is why paid-social-to-WhatsApp funnels are attractive: the first three days of that relationship can carry zero per-message cost. All of these "free" rules are current for the 2026 per-message model per Meta's pricing documentation. Note that authentication templates do **not** get the free-utility-in-window treatment; they are billed per message regardless of an open window ([Meta pricing docs](https://developers.facebook.com/documentation/business-messaging/whatsapp/pricing)). ## A worked cost-estimation example (US/default region) Here is a step-by-step monthly estimate. Read the rate-source note carefully so you can reproduce and update it. > **Rate source and date.** The per-message figures below are the published **US (North America) rates** as documented on the Blueticks pillar [WhatsApp Business API Pricing in 2026](/blog/whatsapp-business-api-pricing-2026), consistent with Meta's [WhatsApp Business Platform pricing page](https://developers.facebook.com/documentation/business-messaging/whatsapp/pricing) as of **June 2026**: Marketing **$0.025**, Utility **$0.004**, Authentication **$0.004**, Service **free**. Rates change (Meta has scheduled rate updates) and vary by country. **Before you commit a budget, pull the live number for your recipient country from Meta's rate card.** Treat the result below as an estimate, not a quote. **The business.** A US e-commerce store messaging US customers (so US rates apply). In a month it sends: - **10,000 marketing** template messages (a promo blast plus a re-engagement flow) - **20,000 utility** template messages (order + shipping confirmations) - **5,000 authentication** template messages (login OTPs) **Step 1: Marketing.** 10,000 × $0.025 = **$250.00** **Step 2: Utility, before the free-window discount.** 20,000 × $0.004 = $80.00 But suppose **40%** of those utility messages are delivered inside an open 24-hour customer-service window (the customer messaged first, e.g. "did my order ship?"). Those are free. - Free: 8,000 × $0.004 = $0.00 - Billable: 12,000 × $0.004 = **$48.00** The free-window share is the single biggest lever on a utility-heavy bill. The more your utility sends are reactive (inside an open window) rather than cold, the lower this line. **Step 3: Authentication.** 5,000 × $0.004 = **$20.00** (Authentication has no free-window relief, but high-volume senders unlock tiered discounts; we use the standard rate here.) **Step 4: Service replies.** Free-form replies inside the customer-service window: **$0.00** **Step 5: Total estimated monthly bill.** | Category | Billable messages | Rate (US, Jun 2026) | Line total | |---|---|---|---| | Marketing | 10,000 | $0.025 | $250.00 | | Utility (cold) | 12,000 | $0.004 | $48.00 | | Utility (in-window) | 8,000 | free | $0.00 | | Authentication | 5,000 | $0.004 | $20.00 | | Service | n/a | free | $0.00 | | **Estimated total** | | | **$318.00** | **~$318/month** for 35,000 delivered template messages, in this scenario. Note what dominates: marketing is 29% of the message volume but 79% of the cost. If you can move re-engagement nudges to utility-eligible transactional triggers, or convert cold utility sends into in-window replies, the bill drops faster than trimming volume across the board. [image: spreadsheet budget review] This is platform messaging cost only. It excludes any Business Solution Provider (BSP) per-message markup or platform subscription, which sit on top of Meta's rates and vary by provider. ## Regional variation: same model, different rates The per-message model is global, but **the rate is set per recipient country and per category** ([Meta pricing docs](https://developers.facebook.com/documentation/business-messaging/whatsapp/pricing)). A marketing template to a US number and the same template to an Indian or Brazilian number can carry very different per-message rates. Because the rate follows the **recipient's** country code, a US business messaging customers across several countries pays a different blended rate than one messaging only US numbers. If your audience is in the EU, the worked example above will not match your bill; rates are denominated and tiered differently. See [WhatsApp Business Pricing in Europe 2026](/blog/whatsapp-business-pricing-europe-2026) for EUR figures, and the [pillar rate card](/blog/whatsapp-business-api-pricing-2026) for the multi-country table. ## How to reduce WhatsApp per-message costs 1. **Maximize in-window utility.** Trigger utility templates as replies inside an open 24-hour customer-service window wherever the flow allows. Inside the window they are free. 2. **Lean on free entry points.** Route acquisition through click-to-WhatsApp ads and Page CTA buttons. The 72-hour free window covers business-initiated messages too. 3. **Right-category your templates.** Do not send a transactional confirmation as a marketing template. Marketing is the priciest category; utility is far cheaper and can be free in-window. 4. **Consolidate marketing.** Under per-message pricing, every marketing template is a separate charge. Combine what used to be several touches into fewer, higher-quality sends. 5. **Pursue volume tiers for utility and authentication.** Meta applies volume-based discounts to these categories ([Meta pricing docs](https://developers.facebook.com/documentation/business-messaging/whatsapp/pricing)). 6. **Watch the recipient country mix.** Since rates follow the recipient's country, segment campaigns by destination and model cost per segment rather than assuming one blended rate. ## FAQ **When did conversation-based pricing end?** On July 1, 2025. The platform moved to per-message pricing on that date ([Meta pricing docs](https://developers.facebook.com/documentation/business-messaging/whatsapp/pricing)). The old conversation-based model is now documented as [deprecated](https://developers.facebook.com/documentation/business-messaging/whatsapp/pricing/conversation-based-pricing/). **What is the difference between a conversation and a message now?** Under the old model, you paid once per 24-hour conversation regardless of how many templates you sent in it. Under the new model, each delivered template message is its own billable unit. The conversation window still matters for *free* messaging (service replies and in-window utility), but it no longer caps what you pay for template sends. **Are service messages free?** Yes. Free-form **service** replies to a customer inside the open 24-hour customer-service window are not charged. That window resets each time the customer messages you ([Meta pricing docs](https://developers.facebook.com/documentation/business-messaging/whatsapp/pricing)). **How do I estimate my monthly bill?** Count expected delivered template messages by category, multiply each by the current rate for your recipient country, subtract utility messages that will land inside an open service window (free) and anything inside a 72-hour free-entry-point window, and add up the categories. The worked example above shows the arithmetic. Always pull the live rate for your recipient country from Meta's rate card before budgeting. **Does this apply to the WhatsApp Business app, or only the API/Platform?** This per-message pricing is the **WhatsApp Business Platform** (Cloud API / On-Premises API) model. The free **WhatsApp Business app** (the consumer-grade app for small businesses) does not bill per template message at all; it also does not give you programmatic template sending, broadcast-at-scale, or the API features the pricing pays for. ## Where Blueticks fits It is worth being precise here, because the pricing above does not describe how Blueticks works. Blueticks schedules and sends WhatsApp messages over the **unofficial WhatsApp Web transport, on your own phone number**. It drives WhatsApp Web the way you would, just automated, scheduled, and at campaign scale. Because it is not sending Cloud API **template** messages, the official Business Platform **per-message template fees described in this article do not apply the same way**. That is not the same as "Blueticks avoids all WhatsApp costs" or "Blueticks replaces the Business Platform." If your use case requires programmatic template sending, official template categories, BSP infrastructure, or the compliance surface of the Cloud API, the per-message model above is the model you will pay. Blueticks is a different transport with a different tradeoff: simpler and number-based for scheduling and campaigns, without the per-template billing of the official Platform. If you want to schedule and run WhatsApp campaigns from your own number, you can [add Blueticks from the Chrome Web Store](https://chromewebstore.google.com/detail/adgnjhngogijkkppficiiepmjebijinl). If you need programmatic Cloud API template sending at scale, budget against Meta's per-message rates and pull your country's live numbers from the [official pricing page](https://developers.facebook.com/documentation/business-messaging/whatsapp/pricing). *Rates, categories, and free-window rules in this article reflect Meta's WhatsApp Business Platform pricing documentation as of June 2026 and are subject to change. Verify current figures against Meta's pricing page before making budget decisions.* --- # Best WhatsApp MCP Server in 2026: A Comparison of Hosted vs Open-Source Options > There is no single best WhatsApp MCP server. There is a best one for a developer, a best one for an AI power user, and a best one for a non-technical operator. We compared the real options on setup, hosting, reliability, and ban-risk so you can pick yours in one read. URL: https://blueticks.co/blog/best-whatsapp-mcp-servers Published: 2026-06-24 Author: Avi Kohen Category: industry If you have already decided you want Claude (or Cursor, or any MCP client) talking to WhatsApp, the next question is the hard one: which server do you actually install? Search "WhatsApp MCP server" and you get a dozen GitHub repos, an official-API option that needs a Meta Business account, and a few hosted services. They are not interchangeable. They differ on the one thing that matters most, which is how they connect to WhatsApp, and that single choice drives your setup effort, your reliability, and your account-ban risk. This is a decision guide, not an explainer. If you are still asking "what is a WhatsApp MCP server in the first place," read our primer on [WhatsApp MCP](/blog/whatsapp-mcp) first, then come back. Here we assume you know the concept and you want a recommendation. ## What a WhatsApp MCP server is (the 30-second version) A WhatsApp MCP server is a small program that exposes WhatsApp actions (read a chat, send a message, look up a contact) as tools an AI model can call through the Model Context Protocol, the open standard Anthropic introduced in late 2024. You register the server once, and your AI client can then read and operate WhatsApp on your behalf. That is the whole idea. The interesting part, and the reason this comparison exists, is that every server reaches WhatsApp through one of three transports, and they carry very different trade-offs. The rest of this article is about telling them apart and picking the right one. ## How we evaluated We scored the real, publicly available options on six criteria. None of them is a single winner; the right pick depends on which criteria you weight. 1. **Setup difficulty.** Can a non-developer install it, or does it need Go, Python, a build step, and credential wrangling? 2. **Hosted vs self-hosted.** Does someone run and keep it alive for you, or is uptime your problem? 3. **Reliability.** Single laptop process that dies when you close your terminal, or a managed service with reconnect logic? 4. **Multi-device / multi-number.** Personal number only, or can it scale to business numbers and teams? 5. **Official-API compliance and ban-risk.** Does it use Meta's official Cloud API, or does it reverse-engineer the WhatsApp Web protocol (which violates WhatsApp's Terms of Service and carries real account-ban risk)? 6. **Capabilities.** Read-only? Send? Schedule, templates, campaigns, groups? The transport question (criterion 5) deserves a plain statement up front, because it is the most misunderstood. There are three families: - **Official Cloud API** servers talk to Meta's WhatsApp Business Platform Graph API. Compliant, no ban-risk for legitimate use, but you need a Meta Business account, a verified number, and you live inside the template-and-session-window rules. - **Unofficial WhatsApp Web automation** servers drive your personal account through reverse-engineered libraries such as `whatsmeow` (Go) or Baileys (TypeScript). Two-minute setup against your own number, full personal-chat access, but using unauthorized third-party automation violates WhatsApp's Terms of Service and can get a number temporarily or permanently banned. - **Hosted services** that run an unofficial engine for you. Same transport family as the second group, but the reconnect logic, infrastructure, and session management are someone else's job. We are calling that out honestly for every option below, including ours. ## The comparison table [image: comparison table screen] | Server | Transport | Hosted? | Setup | Capabilities | Ban-risk | | --- | --- | --- | --- | --- | --- | | **Blueticks MCP** (`@blueticks/mcp`) | Unofficial wa-web (managed engine) | Yes (hosted) | ~2 min; remote URL + login, or `npx`, no build | Read, send, schedule, groups, audiences, campaigns | Same family as wa-web tools; managed to behave like a human session | | **lharries/whatsapp-mcp** | Unofficial wa-web (`whatsmeow`, Go) | No (self-host) | High: Go bridge + Python server + QR | Read, search, send text/media/audio, download media (~12 tools) | Personal-number automation, ToS-violating | | **jlucaso1/whatsapp-mcp-ts** | Unofficial wa-web (Baileys, TS) | No (self-host) | Medium: single Node process + QR | Read, search, list chats, message context, send text (6 tools) | Personal-number automation, ToS-violating | | **FelixIsaac/whatsapp-mcp-extended** | Unofficial wa-web (`whatsmeow`, fork) | No (self-host) | High: same as lharries | up to 41 tools (reactions, groups, polls, presence, newsletters) | Personal-number automation, ToS-violating | | **networkerman/whatsapp-cloud-api-mcp-server** | **Official Meta Cloud API** | No (self-host) | High: Meta Business account + tokens + Python | 50+ tools: messaging, templates, media, flows, analytics | Compliant; lowest ban-risk for legitimate use | A note on fairness: the open-source projects are genuinely good software, actively used, and free. The table is not a ranking from best to worst. It is a map of trade-offs. A developer who wants local control will read it top to bottom and pick differently than an operator who never wants to see a terminal. ## Walkthrough of the main options ### The official path: Cloud API servers If compliance is non-negotiable, this is the family to use. **networkerman/whatsapp-cloud-api-mcp-server** is a Python MCP server built from Meta's official WhatsApp Cloud API Postman collection, exposing 50-plus tools across messaging, template management, media, WhatsApp Flows, and analytics. Because it rides the official Graph API, it carries no ban-risk for legitimate business use, and it is the right choice if you are sending at scale to customers. The cost is real, though. You need a Meta Business account, a verified phone number, an access token, a Phone Number ID, and a WABA ID before you write a single prompt. You also inherit the Cloud API's rules: outbound messages to people outside a 24-hour customer-service window must use pre-approved templates, and there are per-message fees. This is a business-messaging tool wearing an MCP coat, not a "read my personal chats" tool. Other servers in this family exist (for example, ones offering 50-plus tools with API-key auth and webhook signature verification), and they share the same profile: compliant, capable, and heavier to stand up. ### The open-source personal-account servers The most-starred WhatsApp MCP project is **lharries/whatsapp-mcp**. It is a two-part system: a Go bridge using the `whatsmeow` library (the unofficial WhatsApp Web multi-device protocol) that authenticates by QR code and stores your history in a local SQLite database, plus a Python MCP server exposing roughly a dozen tools (`search_contacts`, `list_messages`, `send_message`, `send_file`, `send_audio_message`, `download_media`, and more). Everything stays on your machine and only reaches the AI when a tool is explicitly called, which is a genuinely good privacy property. The price is setup: you run two processes, install both Go and Python toolchains, and keep the bridge alive yourself. **jlucaso1/whatsapp-mcp-ts** is the lighter cousin. It is a single TypeScript Node.js process built on Baileys (also unofficial WhatsApp Web multi-device), bundling the WhatsApp connection, SQLite storage, and MCP server together. It exposes six focused tools (`search_contacts`, `list_messages`, `list_chats`, `get_chat`, `get_message_context`, `send_message`). One process instead of two is a real simplification if you are comfortable in the Node ecosystem. If you want maximum surface area, **FelixIsaac/whatsapp-mcp-extended** is a fork of lharries that pushes to up to 41 tools, adding reactions, richer group management, polls, presence, and newsletters. **verygoodplugins/whatsapp-mcp** is another actively maintained fork of the same `whatsmeow`-based codebase, created because the original had gone quiet. Both inherit the same transport and therefore the same ban-risk and the same self-host burden. The honest summary for this whole family: free, local, flexible, and they read your real personal chats, which the official Cloud API cannot do. But they all drive your own number through reverse-engineered automation, they all require you to keep a process running, and they all carry account-ban risk (more on that below). ### Blueticks MCP: the hosted option Blueticks publishes a hosted MCP server, `@blueticks/mcp`, aimed at people who want the personal-number capability without the self-hosting. The simplest way to connect skips the config file altogether: add `https://api.blueticks.co/mcp` as a custom connector in Claude and approve access with a login, so there is no key to store. If you prefer key-based auth or you're on Claude Code or Cursor, you add one server entry to your Claude config that runs `npx -y @blueticks/mcp` with an API key, and the package pulls itself on first run, so there is no repo to clone, no Go or Python toolchain, and no bridge to babysit. Either way the WhatsApp session runs on Blueticks' managed engine rather than on your laptop, so it reconnects on its own and survives you closing your terminal. Being honest about transport: Blueticks operates an unofficial WhatsApp Web automation engine, the same transport family as the open-source personal-account servers above, not the official Cloud API. What you are paying for is that Blueticks runs and maintains that engine as a managed, human-like session instead of leaving it on your machine. The capability set leans toward operators: alongside read and send, it covers scheduling, groups, reusable audiences with per-contact variables, and campaigns, which the bare open-source servers do not. It is also the only zero-terminal option here. Blueticks also ships a [Chrome extension](https://chromewebstore.google.com/detail/adgnjhngogijkkppficiiepmjebijinl) if you prefer the in-browser product, but the MCP is the path for driving WhatsApp from an AI client. ## Hosted vs self-hosted: the real decision Strip away the brand names and the choice is mostly this one axis. **Self-host** (any of the open-source servers, or a Cloud API server you deploy) when you want full control of your data, you are comfortable keeping a process alive, and "it runs on my machine and I can read the SQLite file" is a feature, not a chore. The trade-off is operational: the bridge dies when your laptop sleeps, reconnect is your problem, and a WhatsApp protocol change can break things until someone patches the library. **Hosted** (Blueticks, or a managed Cloud API provider) when uptime is not your job and you would rather not learn `whatsmeow`. The trade-off is trust and recurring cost: your session runs on someone else's infrastructure, and you are betting on their reliability instead of your own. There is no universally correct answer. A developer building a side project will rationally self-host. An operator who needs their assistant to still be connected at 7am without having touched a terminal will rationally pay for hosted. ## Compliance and ban-risk: read this before you pick [image: compliance warning scene] This is the criterion most roundups skip, and it is the one most likely to cost you a phone number. Using unauthorized third-party software to automate or bulk-send on WhatsApp violates WhatsApp's Terms of Service, and Meta enforces it. Every server in this comparison that uses `whatsmeow` or Baileys (lharries, jlucaso1, the extended and verygoodplugins forks, and Blueticks' managed engine) is in that category. Reported ban timelines for reverse-engineered protocol tools commonly land in the 2-to-8-week range once a number trips detection, and the risk scales sharply with behavior: a setup that only reads and replies to existing conversations is far lower risk than one blasting proactive first-contact messages to people who never saved your number. Detection signals include high message volume in short windows, messaging strangers who then block or report you, and the technical fingerprints of scripted Web sessions. The only structurally zero-risk path is the **official Cloud API** (the networkerman server and its family), used within Meta's rules. That is the honest answer, and it is why a serious business sending to customers at scale should default to it despite the heavier setup. Where does that leave the unofficial options? They are legitimately useful for personal and light-touch use, where the value (Claude reading your real chats and drafting replies you approve) is high and the volume is low. If you go this route, behave like a human: do not bulk-blast cold contacts, keep volumes sane, and understand you are accepting a non-zero risk. A managed engine like Blueticks' is built to keep the session looking like a normal human session, which mitigates but does not eliminate that risk. No unofficial tool, hosted or self-hosted, can promise zero ban-risk, and any that does is overclaiming. ## Which to pick for which use case **You are a developer who wants local control and free.** Start with **lharries/whatsapp-mcp** for the largest community and tool set, or **jlucaso1/whatsapp-mcp-ts** if you would rather run one TypeScript process than a Go bridge plus a Python server. Self-host, keep volumes modest, accept the ToS reality. **You are an AI power user who wants the most tools.** **FelixIsaac/whatsapp-mcp-extended** gives you up to 41 tools (reactions, polls, presence, newsletters) on the same `whatsmeow` base, if you are willing to self-host. **You are a business sending to customers at scale, and compliance is mandatory.** Use an **official Cloud API** server such as **networkerman/whatsapp-cloud-api-mcp-server**. Budget for the Meta Business account, verification, and the template-and-fees model. This is the only no-ban-risk path. **You are non-technical, or you just do not want to run infrastructure.** Use **Blueticks MCP**. It is the only option here you can install without a build step and that stays connected without you keeping a process alive, and it adds scheduling, audiences, and campaigns on top of read/send. Understand it uses an unofficial managed engine, not the Cloud API, and keep your sending human-paced. ## FAQ **Is there a single best WhatsApp MCP server?** No, and any roundup that names one is hiding the trade-offs. The best server for a developer (a free self-hosted open-source project) is different from the best for a compliance-bound business (an official Cloud API server) and different again from the best for a non-technical operator (a hosted service). Match the server to your constraints. **Which WhatsApp MCP servers use the official WhatsApp API?** The Cloud API family, such as networkerman/whatsapp-cloud-api-mcp-server, talks to Meta's official WhatsApp Business Platform Graph API. The popular personal-account projects (lharries, jlucaso1, their forks) and Blueticks' managed engine all use the unofficial WhatsApp Web protocol instead. **Can a WhatsApp MCP server get my number banned?** If it uses unofficial automation (whatsmeow, Baileys), yes, that is possible, because it violates WhatsApp's Terms of Service. Risk rises steeply with cold outreach and high volume and is low for read-and-reply use on existing chats. The official Cloud API does not carry this risk when used within Meta's rules. **Can the official Cloud API read my personal WhatsApp chats?** No. The Cloud API is for business numbers and messaging customers; it cannot read your existing personal conversations. Only the unofficial WhatsApp Web servers (and hosted services built on them) can read your real personal chat history. **What is the easiest WhatsApp MCP server to set up?** A hosted one with no build step. Blueticks MCP connects via a single `npx` entry in your Claude config and runs the WhatsApp session on its own infrastructure, so there is nothing to clone, compile, or keep alive. The self-hosted open-source servers require toolchains, a QR-code login, and a process you maintain. **Do I need to keep my computer on for a self-hosted server?** For the open-source self-hosted options, effectively yes: the bridge or Node process has to be running for the AI to reach WhatsApp, and it disconnects when your machine sleeps. Hosted services run the session elsewhere, so they stay connected regardless. ## Blueticks MCP: the zero-setup hosted option If you read the use-case section and landed on "non-technical" or "I just do not want to run infrastructure," Blueticks MCP is built for exactly that. It is the only option in this comparison you install without a toolchain or a build step: one `npx -y @blueticks/mcp` entry in your Claude config with an API key, and Claude can read your chats, draft replies you approve, and send or schedule from your own number, with the WhatsApp session running on Blueticks' managed engine instead of your laptop. We have been straight about the trade-off: it uses an unofficial managed WhatsApp Web engine, not the official Cloud API, so keep your sending human-paced. In exchange you get zero setup, a session that stays connected on its own, and operator features (scheduling, reusable audiences, campaigns) the bare open-source servers do not include. If that matches how you work, start with the [WhatsApp MCP setup guide](/blog/whatsapp-mcp) and connect it in about two minutes. --- # WhatsApp Opt-In Compliance Requirements: Meta's Rules for Collecting Consent Without Getting Flagged > Most WhatsApp bans don't come from sending too much. They come from sending to people who never properly opted in. Here's exactly what Meta requires, the disclosure copy to use, and how to keep your number off the block list. URL: https://blueticks.co/blog/whatsapp-opt-in-compliance-requirements Published: 2026-06-23 Author: Maya Cohen Category: industry If your WhatsApp number gets blocked or your quality rating drops to red, the usual diagnosis is "you sent too many messages." That's rarely the real cause. The real cause is sending to people who never gave you clean, provable consent in the first place, then getting blocked and reported by enough of them that Meta's systems throttle you. Meta's opt-in rules are not vague. They're written down, they're specific, and they put the entire burden of proof on you, the sender. This is the compliance and policy angle: not *how* to build an opt-in form (we cover that in our [opt-in collection guide](/blog/whatsapp-opt-in-collection-guide)) or *which widget* to use (see the [opt-in widget walkthrough](/blog/whatsapp-opt-in-widget)), but what actually makes consent valid in Meta's eyes and what gets numbers flagged. ## What Meta actually requires: active, affirmative, per-number consent The WhatsApp Business Messaging Policy is blunt about the baseline. You may only contact people on WhatsApp if two things are true: they have given you their mobile phone number, and you have received opt-in permission confirming they wish to receive subsequent messages or calls from you. Meta makes you "solely responsible for determining the method of opt-in" and for obtaining it in a way that complies with the laws that apply to your communications. Read that twice. Meta is not going to validate your consent for you. If a complaint lands, the question is whether *you* can show the person actively agreed. That word "active" matters. An opt-in has to be an affirmative action the person takes. The following do **not** count as valid consent: - A pre-checked checkbox the user has to uncheck to decline. - "We already have your number from your order, so we'll message you." - Consent buried in a Terms of Service acceptance with no mention of WhatsApp. - A phone number scraped, purchased, or imported from another platform. Two more requirements sit on top of "active." The opt-in must clearly state the **name of the business** the person is opting in to hear from, and it must make clear the person is opting in to receive communication **from that business**. Generic language like "subscribe for updates" without naming you fails this. One point that trips people up: the opt-in does **not** have to happen inside WhatsApp. You can collect it on any third-party channel — your website, your app, a checkout page, an in-store tablet, an SMS reply, a QR code. Meta dropped the old requirement that opt-in flow through a specific platform. What can't change is the substance: active action, your business name, clear statement that they'll get WhatsApp messages from you. ## Single vs. double opt-in: what each is, and when double is worth it **Single opt-in** is one affirmative action. The person ticks a box, taps a button, or sends a keyword, and they're on your list. **Double opt-in** adds a confirmation step. After the first action, you send a message asking them to confirm (reply YES, tap a button), and only confirmed contacts get added. The classic example: they tick the box on your form, then receive a WhatsApp message saying "Reply YES to confirm you want updates from [Business]." Here's the part to get right, because it's a common myth. **Double opt-in is a best practice, not a Meta requirement.** Meta's policy requires valid opt-in. It does not mandate a second confirmation step. Double opt-in is also widely treated as the gold standard for GDPR, but even GDPR doesn't strictly require it — it's the cleanest way to *prove* consent, not a legal mandate. So when is double opt-in actually worth the friction it adds? - **You're collecting at scale or from cold-ish sources** (lead-gen forms, contests, gated downloads). The extra step filters out fat-fingered numbers and people who didn't realize they were signing up for WhatsApp. That directly protects your block/report rate. - **You operate in the EU/EEA or other strict-consent jurisdictions.** The confirmation message is your timestamped proof. - **Your opt-in point is ambiguous** — e.g., a single checkbox covering email, SMS, and WhatsApp at once. When is single opt-in fine? High-intent, low-ambiguity moments: a checkout box that explicitly says "Send my order updates via WhatsApp from [Business]," or a click-to-chat where the person is clearly initiating. If the consent moment is unmistakable and you're logging it properly, single opt-in is compliant. **Decision framework:** the more doubt there'd be about whether *this specific person* knowingly agreed to *WhatsApp from you*, the more you want double opt-in. ## Required disclosure language: the three things every opt-in must state Every opt-in moment needs to answer three questions for the user, in plain language, before they act: 1. **Who is messaging them** — your actual business name, not a vague brand-adjacent phrase. 2. **What they'll receive and roughly how often** — message type (order updates, promotions, both) and a frequency sense. 3. **How to opt out** — that they can stop anytime, and how. Copy-paste starting point for a website form checkbox: > ☐ Yes, send me order updates and occasional offers from **Acme Footwear** on WhatsApp (a few messages a month). Reply STOP anytime to unsubscribe. For a higher-frequency marketing list, be honest about cadence: > ☐ I want **Acme Footwear** to message me on WhatsApp with weekly deals and new drops. Standard message rates may apply. Reply STOP to opt out. For a double opt-in confirmation message sent in WhatsApp: > Hi! This is **Acme Footwear**. You asked to get updates from us here. Reply **YES** to confirm, or ignore this message and we won't message you again. You can reply STOP anytime to unsubscribe. Notice what each version does: names the business, sets expectations on content and frequency, and states the opt-out. If you'd be embarrassed to show a Meta reviewer the exact words next to your opt-in button, rewrite them. [image: optin form checkout] ## Collecting per channel: the right mechanic for each, and where each goes wrong The opt-in *moment* differs by channel, and each has a specific failure mode. **Website / landing-page form.** Mechanic: an unchecked checkbox with the disclosure language above, next to a phone field. Goes wrong when the box is pre-checked, when WhatsApp isn't named (just "updates"), or when the consent text is a link nobody reads. Fix: inline, unchecked, business named, WhatsApp named. **Click-to-WhatsApp (CTWA) ads.** This is the biggest misunderstanding in the whole policy. When someone taps your Facebook or Instagram ad and lands in a WhatsApp chat, that tap opens a 24-hour customer-service window and signals consent **for that conversation session**. It is **not** ongoing marketing opt-in. You cannot start blasting promotional template messages to that person days later on the strength of the ad click alone. Goes wrong when businesses treat every ad-click as a permanent marketing subscriber. Fix: use the welcome message to explicitly ask for marketing opt-in — "Want deals and updates from us here? Tap **Subscribe**." — and only then add them to your promotional list. **Click-to-chat links (wa.me).** When a person initiates by messaging you first via a wa.me link or QR code, that opens the conversation, but a customer messaging you first is **not** marketing consent. Inbound contact lets you reply within the service window; it doesn't license future promos. Goes wrong when a "Message us on WhatsApp" button gets treated as list signup. Fix: collect a separate explicit marketing opt-in in the chat before adding them to campaigns. **Checkout.** Mechanic: a clearly worded, unchecked WhatsApp consent option at the point of purchase. The strongest moment you have, because intent is high. Goes wrong when the box is bundled into "I agree to the terms" or pre-checked to boost numbers. Fix: a standalone, explicit checkbox naming WhatsApp and your business. The through-line: **a transaction or an inbound message is not marketing consent.** Someone buying from you or messaging you first does not equal permission to send promotional broadcasts. Marketing consent is always obtained separately and explicitly. ## Record-keeping: what to log and how to prove consent Because Meta puts the burden of proof on you, an opt-in you can't *evidence* is an opt-in you don't have. For every contact, log: - **Timestamp** — exact date and time of the opt-in action. - **Source / channel** — where it happened (checkout page, /signup form, CTWA welcome flow, in-store QR). - **Consent text shown** — the exact disclosure wording the person saw and agreed to. If you change your form copy, version it, so you know which wording each contact accepted. - **Identifier** — the phone number (and any account/customer ID) the consent attaches to. A minimal record looks like this: ``` { "phone": "+15551234567", "opted_in_at": "2026-06-12T14:31:08Z", "source": "checkout_page_v3", "consent_text": "Yes, send me order updates and occasional offers from Acme Footwear on WhatsApp...", "consent_type": "single", "ip": "203.0.113.42" } ``` Keep these records for as long as the contact is on your list, plus a retention buffer afterward to cover late complaints (your legal counsel should set the exact window based on your jurisdiction; many businesses keep consent logs for several years). When someone opts out, log *that* too, with its own timestamp. [image: consent log records] ## Quality rating, opt-out handling, and staying off the throttle list Meta scores each WhatsApp Business number with a **quality rating**, surfaced as green (high), yellow (medium), or red (low). The rating is driven largely by how recipients react: **blocks and reports** push it down, and they're the signals Meta cares about most. A handful of "this is spam" reports from people who don't recognize you does real damage. The mechanics changed recently and the terminology with it, so be precise. As of late 2025, Meta **removed the old "Flagged" status**, and a quality drop no longer triggers an automatic, immediate downgrade of your sending limit. Instead a low rating gives you a correction window and, critically, **blocks you from scaling up** to higher tiers. The policy also states plainly that Meta's systems will limit how much a business can send if its quality tier stays low for a sustained period. It helps to know the tiers your sending limit moves through. New portfolios typically start around **250 customer-initiated conversations per day**, then step up to **1,000, 10,000, 100,000, and ultimately unlimited** as you send quality volume to engaged recipients. Note that these limits are now managed at the **business portfolio level**, so all numbers in your portfolio share the allowance — one bad number can drag the rest. To stay healthy: - **Honor STOP and blocks immediately, on or off WhatsApp.** The policy requires you to respect every request to opt out, block, or discontinue, *including removing the person from your contact list*. If someone replies STOP, they come off the list that moment — not next batch. - **Keep frequency disciplined.** The fastest way to earn blocks is over-messaging. Match the cadence you promised at opt-in. - **Send to engaged people.** Recipients who expect your messages don't report them. Pruning dead contacts protects the live ones. ## Common mistakes that get numbers flagged or banned - **Importing a list you didn't opt in.** Buying numbers, scraping them, or migrating an email list to WhatsApp without fresh consent. This is the number-one cause of mass blocks. - **Treating a CTWA ad click or an inbound message as a marketing subscription.** Session consent is not list consent. - **Pre-checked boxes and bundled consent.** "I agree to the terms" cannot carry your WhatsApp opt-in. - **No business name in the opt-in.** "Subscribe for updates" with no named sender fails the policy. - **Ignoring STOP.** Continuing to message someone who opted out is both a policy violation and a guaranteed report. - **Blasting the whole list at once on day one.** Sudden high volume from a new number with no engagement history reads as spam to Meta's systems. - **No consent records.** When a complaint comes and you can't show the opt-in, you have no defense. ## FAQ **Does Meta require double opt-in for WhatsApp?** No. Meta requires valid opt-in — an active, affirmative action that names your business and confirms the person wants WhatsApp messages from you. Double opt-in is a best practice that strengthens your proof of consent, especially under GDPR, but it is not a Meta requirement. **Can I collect WhatsApp opt-in on my website instead of inside WhatsApp?** Yes. Opt-in can be collected on any third-party channel — website, app, checkout, in-store, SMS, QR code. It no longer has to happen inside WhatsApp. The requirements (active action, business name, clear statement they'll receive WhatsApp messages from you) stay the same wherever you collect it. **A customer messaged me first. Can I send them marketing messages?** Not automatically. An inbound message or a CTWA ad click opens a conversation session, but it is not marketing consent. To send promotional broadcasts later you must obtain a separate, explicit marketing opt-in. **Is the "Flagged" status still a thing?** Meta removed the "Flagged" status in late 2025, and a quality-rating drop no longer auto-downgrades your sending limit. But a low (red) quality rating still blocks you from scaling to higher messaging tiers, and sustained low quality will get your sending throttled. **What drives my quality rating down?** Mainly recipient blocks and "report spam" actions. The fix is upstream: clean opt-in, honest frequency, and sending only to people who actually expect to hear from you. **How long should I keep opt-in records?** For as long as the contact is active, plus a retention buffer for late complaints. Set the exact period with your legal counsel based on your jurisdiction; many businesses retain consent logs for several years. ## Collecting and managing opted-in subscribers in Blueticks Once you have a clean, opted-in list, Blueticks is where you run the campaigns to it. You collect consent on your own channels using the mechanics above, log the proof, and then use Blueticks to message the people who already said yes. Blueticks doesn't make you compliant or "ban-proof" — that responsibility stays with you as the sender, and no tool can manufacture consent you didn't collect. What it does is let you organize opted-in contacts into audiences and run scheduled or bulk campaigns to them cleanly, so you're not pasting numbers one by one or sending faster than you promised. The **Free** plan can run bulk campaigns (the three-at-a-time limit applies only to single scheduled messages, not campaigns) and adds a "Powered by blueticks.co" footer to messages. **Pro** removes the branding and is built for higher-volume, recurring campaigns. Either way, the rule that keeps you safe is the same one Meta cares about: only send to people who actively opted in, honor every STOP, and keep your consent records. Get started by [installing the Blueticks extension](https://chromewebstore.google.com/detail/adgnjhngogijkkppficiiepmjebijinl), then build the opt-in flow itself with our [opt-in collection guide](/blog/whatsapp-opt-in-collection-guide) and the [opt-in widget walkthrough](/blog/whatsapp-opt-in-widget). --- # Do I Need the WhatsApp Business API? A 2026 Readiness Checklist Before You Apply > The API is sold as the obvious upgrade. Before you onboard, run this readiness check: what Meta now requires, what it costs to run, and the three cases where you don't need it. URL: https://blueticks.co/blog/do-i-need-whatsapp-business-api Published: 2026-06-22 Author: Daniel Roth Category: industry Most people who ask "do I need the WhatsApp Business API" are one rung lower on the ladder than they think. They've hit a wall in the free app, someone pointed at the API, and now they're staring down Business Verification, a BSP contract, and per-message billing for a job that might be "send this offer to 200 people on Tuesday." Sometimes the API really is the answer. Often it's overkill. This is the readiness check to run before you apply, with the requirements and costs pinned to what Meta actually enforces in 2026. ## Do I need the WhatsApp Business API? The short version You need the WhatsApp Business API when your messaging is system-generated, high-volume, or multi-agent: order updates and OTPs by the thousand, a real chatbot, or one number worked by a whole support team. You do not need it for scheduling, follow-up sequences, or human-scale bulk sends from a number you already run. If a person would happily type each message but doesn't have the time, that's a scheduling job, not an API job. The trap is treating the API as a generic "more power" button. It isn't. It's a programmatic backend with onboarding requirements, a template-approval gatekeeper, and a per-message meter. All of that is worth it at scale and a tax below it. The rest of this guide is the test for which side of that line you're on. If you want the full feature-by-feature breakdown first, our [WhatsApp Business app vs API comparison](/blog/whatsapp-business-app-vs-api) lays out all three options side by side. ## First: are you sure the free app can't do it? Before you reach for the API, name the exact thing the free WhatsApp Business app won't let you do. The app is deliberately reactive and single-operator, and a lot of "I need the API" moments are really "I need one feature the app skips." Here is what the app does and where it stops: - **Reactive automation only.** A greeting message fires when someone messages you for the first time (or after a long gap), and an away message fires on the schedule you set. Both wait for the customer to message first. - **Quick replies, not logic.** Saved snippets a human triggers with a shortcut. No conditions, no "if they ask about price, send the price list." - **Broadcast lists capped at 256.** And they only reach people who have *saved your number*, with no scheduling and no campaign reporting. - **No outbound scheduler.** This is the single most common reason people start Googling the API. The app has none. - **One number, up to five linked devices.** Fine for a solo operator and a couple of helpers. Not a contact center. If your wall is "no scheduling" or "no real bulk," hold off. That's not necessarily an API problem, and there's a lighter fix covered further down. If your wall is "no chatbot," "no CRM events," or "twenty agents on one number," keep reading; that *is* the API. [image: A small-business owner at a desk weighing two paths, phone and laptop side by side] ## What the WhatsApp Business API actually requires in 2026 People underestimate the onboarding, so here's the real checklist. The WhatsApp Business API (officially the WhatsApp Business Platform) is not an app you download. It's an integration you provision, usually through a Business Solution Provider, and Meta gates it behind opt-in and template approval, then ties your daily sending volume to Business Verification. What it takes to get a number live and sending business-initiated messages: - **A Business Solution Provider (or direct Cloud API integration).** Most businesses go through a BSP (such as Twilio, 360dialog, or Wati) that handles onboarding, gives you a dashboard, and manages template submission. You *can* integrate Meta's Cloud API directly, but you take on the engineering. - **Meta Business Verification (for volume, not to start).** You can begin sending business-initiated messages before you're verified, but an unverified number is capped at 250 business-initiated conversations per rolling 24 hours. Completing Business Verification unlocks the higher messaging tiers (1,000 → 10,000 → 100,000 → unlimited per day). Verification typically takes a few business days and can run longer if documents need follow-up. - **A published privacy policy URL.** Meta now requires a valid privacy policy link as part of getting cleared to send. - **A dedicated phone number.** The number you put on the API generally can't also run in the regular WhatsApp or WhatsApp Business app; it becomes an API number. - **An approved display name.** Your business display name goes through a review before it shows to recipients. - **Approved message templates.** Every business-initiated message (reminders, updates, promotions) must be pre-written and approved by Meta before you can send it. Template review is often quick, but rejections happen and force a rewrite-and-resubmit loop. - **Explicit opt-in.** You must collect a clear WhatsApp opt-in that names your business and what you'll send. Pre-checked boxes and "they gave us their number once" don't count. None of this is a dealbreaker if you're operating at scale; it's a one-time cost of doing business. But if you just wanted to schedule a few sends, this is a lot of process to stand up. That gap between the work and the need is the whole point of this article. ## What it costs to run, after setup The API's real cost is per-message and ongoing, so model your volume before you commit. Setup is a one-time hurdle; billing is forever. Meta moved the platform to per-message pricing effective July 1, 2025, and how much you pay depends on the *category* of each message and the recipient's country. The four message categories, and how they bill: - **Service.** Your replies to a customer-initiated conversation, within the 24-hour window. Free since November 1, 2024. This is the category that makes responsive support cheap. - **Utility.** Order updates, receipts, appointment reminders, account alerts. Paid per delivered message, and eligible for volume discounts as your monthly utility volume climbs. - **Authentication.** OTPs and verification codes. Paid per message, also eligible for volume tiers. - **Marketing.** Promotions, offers, re-engagement. Paid per message and always charged, with no volume discount. The honest read: if your mix is mostly utility and authentication (the system-generated stuff), the volume tiers and free service window make the economics genuinely good at scale. If your mix is heavy on marketing, costs climb fast and don't tier down. A clinic firing a few hundred reminders a month and a retailer blasting weekly promos to thousands are in very different places on this rate card. For the full billing math and category-by-category numbers, see our [WhatsApp Business API pricing guide for 2026](/blog/whatsapp-business-api-pricing-2026). [image: A finance-style desk scene with a notebook, calculator and coffee, neutral editorial lighting] ## The readiness test: five questions Run these five questions. If you answer "yes" to two or more, the API is probably the right move. If you mostly answer "no," you're paying for machinery you won't use. 1. **Volume.** Are you sending thousands of business-initiated messages a month, not dozens or low hundreds? Per-message billing only makes sense once volume is real. 2. **Authoring.** Are these messages *system-generated*, like OTPs, order-shipped alerts, and automated reminders no human types one by one? Or are they messages a person would normally write? 3. **Automation depth.** Do you need a chatbot, conditional flows, or auto-responses at 2am, the things the app's reactive quick replies genuinely can't do? 4. **Team.** Does one number need to be worked by many agents at once, with a shared queue? 5. **Integration.** Do you need WhatsApp events flowing into a CRM or helpdesk (HubSpot, Salesforce, Zendesk) automatically? The pattern: the API rewards *system-authored, high-volume, multi-agent, integrated* messaging. The more of your "yes" answers cluster there, the clearer the case. If your yeses are really about timing and list size, that's the next section. ## The case where you don't need the API at all If your real need is scheduling, follow-ups, and human-scale bulk sending, you can skip the API entirely. There's a third path most "app vs API" guides leave out: a scheduling and automation layer that runs on the WhatsApp number you already use. It adds the two things people actually want, sending later and sending to a list, without verification queues, template approval, per-message Meta fees, or BSP onboarding. This fits a specific and common profile: - **Appointment businesses** (salons, clinics, tutors) sending reminders and confirmations to known clients. - **Small retailers** running a weekly offer to a saved-customer list, without the app's 256 cap or the API's marketing-template fees. - **Consultants and solo operators** nurturing a pipeline with timed follow-ups instead of a chatbot. A tool like [Blueticks](/scheduler) layers onto your existing number and adds scheduled messages (one-time and recurring), follow-up sequences, and bulk campaigns to a contact list, with no template approval and no per-conversation billing. The trade-off, stated plainly: this is built for human-scale, personalized outreach, not million-message automated notification streams or chatbots. If you need those, you need the API. If you need a calendar and a send button that works at list scale, you don't. For the mechanics, [how to schedule WhatsApp messages](/blog/schedule-whatsapp-messages) walks through it, and [WhatsApp campaign management](/blog/whatsapp-campaign-management) covers the bulk side. ## Which WhatsApp business solution should you pick? Match the tool to who authors the message and at what scale. Reactive and single-operator: the free app. System-generated, high-volume, multi-agent, or CRM-connected: the API via a BSP. Scheduling, sequences, and human-scale bulk from your own number: a scheduling layer. - **Solo, reactive replies, no scheduling need** → the free WhatsApp Business app. - **Thousands of automated messages, a chatbot, or a multi-agent team** → the WhatsApp Business API. Budget for verification, templates, and per-message billing; lean on free service conversations and utility/authentication volume tiers. - **Need to schedule, follow up, and bulk-send from your existing number** → a scheduling tool. No API, no approval, no per-message fee. - **Not sure?** → Start with the app, add a scheduling layer the moment "no scheduler" or "no bulk" is the thing that hurts, and reach for the API only if volume or automation forces it. Just need to schedule, sequence, and bulk-send from the number you already use, without API approval, templates, or per-conversation fees? [Start free with Blueticks](/scheduler) and schedule your first message in minutes. ## FAQ **Do I need the WhatsApp Business API to send bulk messages?** Not for human-scale sends. The free app caps broadcast lists at 256 and only reaches contacts who saved your number. A scheduling tool on your existing number can run bulk campaigns and sequences without template approval or per-message Meta fees. For very high, fully automated volumes, the API is the right tool. **What do I need to get approved for the WhatsApp Business API in 2026?** A Business Solution Provider (or a direct Cloud API integration), a published privacy policy URL, a dedicated phone number, an approved display name, Meta-approved message templates, and explicit customer opt-in. You can start sending while unverified (capped at 250 business-initiated conversations per rolling 24 hours); completing Meta Business Verification unlocks the higher daily messaging tiers. **How much does the WhatsApp Business API cost to run?** You pay per delivered message under per-message pricing in effect since July 1, 2025, priced by category and recipient country. Service conversations (your replies within the customer's 24-hour window) are free since November 1, 2024. Utility and authentication templates get volume-based discounts; marketing templates are always charged with no volume discount. **Can I use the WhatsApp Business API without a BSP?** You can integrate Meta's Cloud API directly, but most businesses use a Business Solution Provider to handle onboarding, template management, compliance, and a usable dashboard. Either way you still complete verification and get templates approved before sending. **When should I NOT use the WhatsApp Business API?** When your need is scheduling, follow-up sequences, or human-scale bulk sending from a number you already run. The verification, template approval, and per-message billing add cost and setup with no payoff below real volume. Use a scheduling tool instead, and move to the API only when scale or automation forces it. --- # How to Send a WhatsApp Broadcast to More Than 256 Contacts (2026 Workarounds) > WhatsApp stops your broadcast list at 256, and half of those people may never see the message. Here is how to reach more than 256 contacts in 2026 without getting flagged. URL: https://blueticks.co/blog/whatsapp-broadcast-more-than-256-contacts Published: 2026-06-21 Author: Maya Cohen Category: marketing You have 900 customers who opted in to hear from you. You open WhatsApp, start building a broadcast list, and the app stops you at 256. Then you learn the worse part: a chunk of those 256 will never get the message, with no error and no warning. That is the wall every marketer hits. The native broadcast tool was built for a shop owner texting regulars, not for a brand running a list. This guide covers the honest path: why the 256 cap exists, why broadcasts silently fail to deliver, and the legitimate ways to send a WhatsApp broadcast to more than 256 contacts in 2026 without getting your number flagged. ## Why does WhatsApp cap broadcasts at 256 contacts? WhatsApp caps every broadcast list at 256 contacts in both the standard app and the WhatsApp Business app, and that number has not moved in roughly a decade. A broadcast sends one message to many people as separate one-to-one chats, so each recipient gets a private message and replies only to you. The 256 ceiling exists to keep broadcasts a personal feature, not a mass-marketing channel. A broadcast list is not a group. Send to a list and every recipient sees the message in their own thread, as if you texted them directly. They cannot see who else got it, and replies come back to you alone. That privacy model is the entire point, and it is also why WhatsApp treats broadcasts as conversational rather than promotional. Why 256 specifically? It is deliberate friction. WhatsApp wants the corner shop messaging its regulars on this tool, not a brand blasting 50,000 people. The moment you need real scale, the platform nudges you toward the [WhatsApp Business Platform (the API)](https://blueticks.co/blog/whatsapp-broadcast-limit), where sends are metered, priced, and quality-controlled. The 256 wall is that nudge in action. The cap is identical on the free WhatsApp Business app, so upgrading from personal to Business does not buy you a bigger broadcast. ## What's the real WhatsApp broadcast message limit per day? For the free WhatsApp and WhatsApp Business apps, there is no published per-day broadcast count. The real constraints are list size (256 contacts) and your account's behavior. Send too fast, to people who never saved you, and WhatsApp's spam systems can rate-limit or ban the number. The "limit" is effectively a trust budget, not a clean number you can read off a settings screen. This is where most "whatsapp broadcast message limit per day" searches go wrong. People want a single figure. The free apps do not give you one. WhatsApp watches signals: how many new conversations you start, how fast, how many get blocked or reported. Cross an invisible threshold and you get throttled or banned, often with no warning. The numbers only get concrete on the WhatsApp Business Platform (Cloud API), which is a separate product. Per [Meta's messaging limits documentation](https://developers.facebook.com/docs/whatsapp/messaging-limits/), an unverified API account starts at 250 unique customers in a rolling 24 hours. After business verification you jump to 1,000, and the tiers scale upward toward 100,000 as your quality rating holds. Meta checks every six hours whether you qualify to climb, and you generally need to use at least half your current limit within seven days while keeping quality high. | | WhatsApp Business app | WhatsApp Business Platform (API) | |---|---|---| | Limit type | 256 contacts per broadcast list | Unique customers per rolling 24h | | Published daily number | None | 250 → 1,000 → up to 100K | | Recipient must save your number | Yes | No | | Setup effort | Minutes | Days, plus developer or BSP | So when someone asks for the WhatsApp business broadcast limit, the honest answer is two different limits for two different products. Confusing them is the single most common mistake in this space. ## Why is my WhatsApp broadcast not delivering? (the saved-contact trap) Your WhatsApp broadcast is not delivering because the recipients have not saved your number. This is the rule almost nobody knows: a broadcast only reaches a contact who has added you to their phone's address book. If they never saved you, your message is silently dropped. No bounce, no error, no read receipt. It just vanishes. That single rule explains most "whatsapp broadcast not delivering" complaints. You build a list of 256, hit send, and maybe 80 people actually see it. The other 176 never saved your number, so WhatsApp filtered them out to prevent strangers from spamming each other through broadcasts. Do the math on a normal marketing list. Most of your subscribers gave you a phone number through a form, a checkout, or an opt-in. Very few of them turned around and saved your business number in their own contacts. On a typical mailing list it is realistic that a large share of recipients, often a clear majority, have never saved you, which means a 256-person broadcast can reach only a fraction of the people you intended.[^1] You paid the full cost of building the list and got a fraction of the reach. [image: silent delivery gap] The fix inside the native app is brutal: you have to convince every recipient to save your number first. That works for a loyal regular base. It does not work for a 900-person list you are trying to activate this week. Which is exactly why marketers look past the broadcast tool the moment a list grows. ## How do you send to more than 256 contacts without breaking the rules? To send to more than 256 contacts legitimately, you have three real paths: stack multiple 256-contact broadcast lists by hand, move to the WhatsApp Business Platform (API), or use a tool that automates personalized one-to-one sends from your own number. Each trades effort, cost, and feel differently. None of them is "blast 5,000 people in one tap." Here are the three, honestly: **1. Multiple broadcast lists, done manually.** You can create more than one list, each holding up to 256. For 900 contacts that is four lists you build, paste, and send one at a time. Free, but slow, error-prone, and you still hit the saved-number wall on every list. Practical for a few hundred contacts a couple of times a year. Painful past that. **2. The WhatsApp Business Platform (Cloud API).** No 256-contact list concept, no saved-number requirement, scales to tens of thousands. The cost: every message routes through a pre-approved template, each send is metered and priced per [Meta's conversation-based pricing](https://blueticks.co/blog/how-to-send-bulk-whatsapp-messages), and setup needs a developer or a business solution provider. Right for high-volume, transactional, enterprise-grade sending. **3. A personalized bulk sender on your own number.** Tools that run alongside WhatsApp Web automate one-to-one sends from your existing account, so you keep the personal-account feel without copy-pasting 900 times. This is the middle path: bigger than 256, more human than the API, and the route most small and mid-size teams actually use. We will walk through it below. The thing all three share: deliverability still depends on sending to people who want to hear from you, at a pace that does not look like a bot. Scale does not buy you out of that. ## Broadcast list vs group vs bulk campaign: which reaches the most people? For reaching the most people while staying personal, a bulk campaign beats both broadcast lists and groups. Broadcast lists cap at 256 and silently drop non-savers. Groups have a higher member ceiling but expose every recipient to each other and invite chaos. A bulk campaign sends private, personalized messages at scale, which is what marketing actually needs. The whatsapp broadcast vs group question trips people up because both feel like "send to many." They behave nothing alike. | | Broadcast list | Group | Bulk campaign | |---|---|---|---| | Max recipients | 256 per list | High member cap, but unwieldy | Your full list | | Recipients see each other | No | Yes | No | | Replies go to | You only | Everyone in the group | You only | | Saved-number rule | Yes (silent drops) | No | No (own-number tools) | | Feels like | Private message | Noisy chat | Private message | A group is the wrong tool for outreach. Everyone sees every phone number, anyone can reply to all, and one annoyed member can hijack the thread or report you. You also cannot personalize: the same message hangs there for all to see. Groups are for community, not campaigns. A broadcast list keeps the privacy but hands you the 256 cap and the saved-number trap. A bulk campaign keeps the privacy *and* the personalization *and* breaks the 256 ceiling. For [running an actual WhatsApp campaign](https://blueticks.co/blog/whatsapp-campaign-management), it is the only one of the three built for the job. ## How Blueticks sends a personalized broadcast to your whole list (past 256) Blueticks sends a personalized WhatsApp message to your entire list, past the 256 cap, by automating one-to-one sends from your own number through WhatsApp Web. You import your contacts, write a message with merge fields like the recipient's name, and Blueticks paces the sends so each one lands as a private chat. No 256 wall, no group exposure, no saved-number filter. Here is what makes it different from the native broadcast tool: **It breaks the 256 cap without the API.** You are not building four lists by hand. You import 900 contacts once and the campaign runs against all of them from your existing WhatsApp account. **Each message is personalized.** Merge the first name, the order number, the renewal date. A message that opens with the person's actual name reads as a real message, not a blast. That is the difference between a 4 percent reply rate and something you would actually report to your boss. **It paces sends for deliverability.** Firing 900 messages in 60 seconds is how numbers get flagged. Blueticks spaces them out so the pattern looks human. You start small, watch the account, and scale up rather than dumping the whole list at once. **It sends from your own number, so it stays one-to-one.** Recipients reply right back to you in their normal chat. No template approval, no third-party sender ID, no "this is an automated message" feel. Quick caveat worth stating plainly: because this runs from your personal WhatsApp account, you are still responsible for who you message and how fast.[^1] A personalized, opt-in list sent at a sane pace is fine. A scraped list blasted at full speed is how anyone gets banned, tool or no tool. [image: paced campaign desk] ## WhatsApp broadcast best practices to stay deliverable at scale The core WhatsApp broadcast best practices are simple: only message people who opted in, personalize every send, pace your volume, and warm up a new number slowly. Deliverability at scale is earned by behaving like a human who people want to hear from, not by finding a setting that unlocks more sends. Run through this before any send past 256: - **Get real opt-in.** Message people who asked to hear from you. A clean list out-delivers a big list every time. If you are still gathering permission, build that muscle first. - **Personalize beyond the name.** Reference what they bought, where they signed up, what stage they are at. Generic blasts get reported; relevant messages get replies. - **Start small, then scale.** Send your first campaign to 50 or 100, watch for blocks and reports, then grow. Do not introduce a fresh number with a 900-person blast. - **Warm up new numbers.** A number with no history that suddenly sends hundreds of new conversations looks exactly like spam. Build send history gradually over days. - **Mind the pace.** Spread sends across minutes, not seconds. Tools that pace for you exist for this reason. - **Give an exit.** A clear way to opt out lowers reports, and reports are what actually sink an account. One number to anchor on: speed of contact still beats almost every other lever in outreach. The classic [Lead Response Management study](https://hbr.org/2011/03/the-short-life-of-online-sales-leads) found that responding to a lead within five minutes makes you far more likely to qualify it than waiting even 30. That is why pacing matters in both directions. Fast enough to be relevant, controlled enough to stay deliverable. ## How to send your first 1,000-contact broadcast in 5 steps To send your first 1,000-contact broadcast, install a personalized bulk sender, import your opted-in list, write a merge-personalized message, send a small test batch, then scale the full send at a paced rate. The whole point is to break the 256 cap while keeping each message private and human. Here is the play. Consider "Lumio Skincare," a 12-person brand with 1,000 opted-in customers from checkout. They tried four manual broadcast lists first. Building and sending took an afternoon, and because most customers never saved the number, roughly 70 percent of messages silently failed. Reach landed around 300 of 1,000. They switched to a paced, personalized campaign for the next send. Same list, same offer, one merge field for the first name. Reach jumped to the full list, and replies climbed to a 6 percent response rate, illustrative of what personalization plus full delivery does versus a half-delivered blast.[^1] Here is the five-step version of what they did: 1. **Install the tool.** Add the [Blueticks WhatsApp extension from the Chrome Web Store](https://chrome.google.com/webstore/detail/adgnjhngogijkkppficiiepmjebijinl) and open WhatsApp Web. It runs alongside your existing account. 2. **Import your list.** Bring in your 1,000 opted-in contacts. Skip anyone who did not ask to hear from you. 3. **Write a personalized message.** Use a merge field for the first name at minimum. Reference the context: a purchase, a signup, a renewal. 4. **Send a test batch.** Run the first 50 to 100. Watch for blocks, reports, or anything off before you commit the rest. 5. **Scale at a paced rate.** Release the full list at a human pace, not all at once. Monitor as it goes. That sequence gets you past 256, keeps each message one-to-one, and protects your number while you scale. ## FAQ **Can you send a WhatsApp broadcast to more than 256 contacts?** Not in a single native broadcast list, which caps at 256. You can stack multiple 256-contact lists manually, move to the WhatsApp Business Platform (API), or use a personalized bulk sender like Blueticks that automates one-to-one sends from your own number to your whole list past 256. **Why is my WhatsApp broadcast not delivering to everyone?** Because broadcasts only reach contacts who have saved your number in their phone. Recipients who never added you are silently dropped, with no error. On a typical marketing list a large share of people never saved your number, so a 256-person broadcast often reaches only a fraction of them.[^1] **Is there a WhatsApp broadcast message limit per day?** The free WhatsApp and WhatsApp Business apps publish no per-day broadcast number. Limits are about list size (256) and account trust. The WhatsApp Business Platform (API) does have daily figures, starting at 250 unique customers and scaling to 100,000 as your quality rating holds. **What is the difference between a WhatsApp broadcast and a group?** A broadcast sends private one-to-one messages where recipients cannot see each other and replies come only to you. A group is a shared chat where everyone sees each other's numbers and can reply to all. Broadcasts are for outreach; groups are for community. **Does WhatsApp Business have a built-in scheduler for broadcasts?** No. The WhatsApp Business app's native automation is limited to Greeting Messages, Away Messages, and Quick Replies, which are all auto-replies that fire on incoming messages. There is no native "send later" or scheduler for broadcasts. You compose and send immediately, or you use a third-party tool. [^1]: Reply-rate figures and save-rate estimates here are illustrative ranges based on typical outreach performance, not a specific audited customer result or a published WhatsApp statistic. Your actual numbers depend on list quality, how you collected the contacts, offer, and timing. --- # WhatsApp MCP: Run WhatsApp from Claude (Read, Send, and Schedule in 2026) > Ask Claude 'summarize my day on WhatsApp and tell me what needs a reply.' Here is how to connect the Blueticks WhatsApp MCP server and make Claude your inbox copilot in about two minutes. URL: https://blueticks.co/blog/whatsapp-mcp Published: 2026-06-21 Author: Maya Cohen Category: marketing You open WhatsApp to "quickly check something" and forty unread threads later you have lost twenty minutes and still missed the one message that actually mattered. The problem was never that you needed to type faster. It was that nothing could read the pile for you and tell you what needs a human. That is what changed. Blueticks ships an MCP server that connects Claude to your real WhatsApp account, and the first thing it unlocks is not sending, it is reading. Claude can scan your recent chats, summarize a client's entire history, flag what needs your attention, and draft the reply for your approval. Then, when you are ready to act, the same connection sends and schedules from your own number. This guide covers the no-code path (Claude Desktop) and the developer path (Claude Code and the `/v1` API). ## What is the WhatsApp MCP and why does it matter now? The WhatsApp MCP is a Model Context Protocol server from Blueticks that lets an AI assistant like Claude read and operate your real WhatsApp account. MCP is the open standard, introduced by Anthropic in late 2024, that lets AI models call external tools through a shared interface. The Blueticks MCP exposes WhatsApp read, send, schedule, and campaign actions as those tools. Before MCP, connecting an AI to WhatsApp meant writing a custom integration: API client, auth handling, error retries, the lot. MCP collapses that into a config block. Once the Blueticks server is registered, Claude sees a set of WhatsApp tools and decides which to call based on what you ask. You type "what did Noam say about the demo?" and Claude reads the thread and answers, no app-switching required. It matters now because attention, not typing, is the bottleneck. The MIT Lead Response Management study found you are 21 times more likely to qualify a lead when you reply within five minutes instead of thirty, and the threads that decide deals are buried under group chatter and "thanks!" replies. An assistant that reads the pile and surfaces the one message that needs you is the difference between catching that window and missing it. The `@blueticks/mcp` package (currently v0.3.0) is published on npm and runs with a single `npx` command, so there is nothing to clone or compile. ## How does Claude work as your WhatsApp chief of staff? Claude becomes your WhatsApp chief of staff by reading your chats for you. With the Blueticks MCP connected, it can list and search your recent conversations, read the messages inside any thread, and look up contacts, then turn all of that into a digest, a triage list, or a drafted reply you approve before anything sends. [image: morning coffee planning] Four read-path requests carry most of the daily value: - **"Summarize my day on WhatsApp."** Claude pulls your recent chats with `whatsapp_chats`, reads the new messages, and hands you a short digest: who messaged, what they wanted, what is still open. You get the gist of forty threads in one paragraph. - **"What needs my attention right now?"** Claude scans recent conversations and triages them, separating the threads waiting on a reply from the noise. Instead of scrolling, you get a ranked shortlist of what actually needs a human. - **"Draft a reply to my client at Hadar Tours."** Claude reads the full thread for context, then writes a reply in your voice and shows it to you. Nothing leaves your account until you say go. You go from "I need to get back to them" to a polished draft in seconds. - **"Summarize this client's entire interaction history."** Claude reads the whole conversation, not just the latest message, and gives you the arc: what they bought, what they complained about, what they are waiting on. It is a one-line CRM lookup without a CRM. These all run on read-only tools. `whatsapp_chats` reads your chats and the messages inside them, with list, search, and per-thread message history. `whatsapp_contacts` reads the contacts your engine knows. Claude never sends a thing in any of the above; it reads, it summarizes, it drafts. The send is a separate, deliberate step you trigger. In practice it reads like a Monday-morning conversation. You type "catch me up on WhatsApp since Friday and tell me what needs a reply," and Claude comes back with the shortlist: a client wants to move a call, a lead asked about pricing, a supplier confirmed a delivery, the rest is handled. You say "draft a reply to the client confirming Wednesday at 2pm," Claude reads the thread for tone, drafts it, and waits for your nod. As one early operator put it, "I used to spend the first hour of my day just reading WhatsApp. Now Claude reads it and I spend ten minutes deciding." That read-triage-draft loop is the daily driver, and it is why the MCP earns a place in your morning routine rather than just your campaign stack. ## What can you actually do with it (the full tool set)? The Blueticks MCP gives Claude a focused set of WhatsApp tools, not a magic "do anything" button. It covers reading, sending, scheduling, contacts, groups, audiences, campaigns, webhooks, and engine status. Every action runs through your own connected WhatsApp session, so recipients see a normal message from you. Here is the honest inventory, taken straight from the package: | Tool | What Claude can do with it | | --- | --- | | `whatsapp_chats` | Read your recent chats, search them by name or keyword, list the messages inside a thread, mark a chat read, and download media. | | `whatsapp_contacts` | List the contacts the engine knows, optionally filtered, and fetch a profile picture. | | `whatsapp_messages` | Send a text, image, video, document, or poll now, or schedule it for later with a `send_at` time. Look up a sent message and check delivery or read acknowledgements. | | `whatsapp_scheduled_messages` | List, retrieve, reschedule, or cancel a message you queued for the future. | | `whatsapp_groups` | Create a group, rename it, change posting settings, or leave it. | | `whatsapp_audiences` | Build reusable contact lists with per-contact variables like `firstName` and `product` for templated sends. | | `whatsapp_campaigns` | Schedule a paced bulk campaign against an audience, with pause, resume, and cancel controls. | | `whatsapp_webhooks` | Register a URL to receive signed event POSTs, for example on `message.delivered`. | | `whatsapp_engine` | Check whether your WhatsApp engine is connected and synced. | | `whatsapp_utils` | Validate a phone number, generate a link preview, or get the current date and time so Claude can anchor "tomorrow at 9am" correctly. | The split is clean: the top two tools are your read path (the chief-of-staff layer), and the rest are your write path. Sending and scheduling are first-class, the same engine that powers Blueticks scheduling and campaigns does the delivery. For how that scheduling layer works on its own, see our guide to [scheduling WhatsApp messages](/blog/schedule-whatsapp-messages). What it does not do: give you a second number, bypass WhatsApp's own rules, or message people who never opted in for you. ## How do you act on it: send and schedule from a sentence Once Claude has read the situation, acting on it is one more sentence. You name the people and the time; Claude anchors the time to your timezone, drafts the message for approval, then sends now or schedules for later. Scheduling is a core capability, not an afterthought. Say you finish your morning triage and type: > "Schedule a WhatsApp to my 20 VIP customers tomorrow at 9am letting them know early access opens Monday." Behind the scenes, Claude does roughly this: 1. Calls `whatsapp_utils` to get your current date, time, and timezone, so "tomorrow at 9am" resolves to a correct timestamp instead of the server's clock. 2. Pulls the VIP list, either from a saved audience via `whatsapp_audiences` or from contacts you name. 3. Drafts the message, shows it to you, and waits for your go-ahead. 4. Schedules each send with `whatsapp_messages` and a `send_at` time, or runs a paced campaign through `whatsapp_campaigns` for per-contact variables like `{firstName}`. Later you can ask "show me my scheduled WhatsApp messages" and Claude lists what is pending via `whatsapp_scheduled_messages`. Change your mind? "Reschedule the VIP message to 11am" or "cancel it" both work, because that tool supports update and delete. The read path tells you what to do; the write path does it on your schedule. ## How do you connect the WhatsApp MCP to Claude in about 2 minutes? There are two ways to connect, and the fastest one needs no key at all. **Remote connector (easiest).** In Claude, open Connectors, click **Add custom connector**, paste `https://api.blueticks.co/mcp`, and click Connect. Claude sends you to Blueticks to log in and approve access, and that is the whole setup on the web or the desktop app. Nothing is installed and no key is stored, and Blueticks' in-app **AI Assistant** panel hands you the URL and the same steps. The [connect guide](https://blueticks.co/blog/connect-whatsapp-to-claude-mcp-integration) has the full walkthrough. **MCP server (API key).** If you prefer key-based auth, or you're on Claude Code or Cursor, add a small server entry to your Claude config that runs `npx -y @blueticks/mcp` with a `bt_live_` key in the environment, then restart Claude. It takes about two minutes and needs no cloning or building. The rest of this section walks that path. [image: hands keyboard setup] Step one is the same for everyone: get a key. Sign in to the Blueticks API dashboard, choose **Create key**, and copy the value immediately. Keys look like `bt_live_...` and are shown only once, so paste it somewhere safe. Treat it like a password; it can read and send from your account. **Claude Desktop (no code).** Open your Claude Desktop config file. On macOS that is `~/Library/Application Support/Claude/claude_desktop_config.json`. Add this block, paste your key, and restart Claude Desktop: ```json { "mcpServers": { "blueticks": { "command": "npx", "args": ["-y", "@blueticks/mcp"], "env": { "BLUETICKS_API_KEY": "bt_live_your_key_here" } } } } ``` **Claude Code (developers).** The same server entry goes in your `.mcp.json` (project) or `~/.claude.json` (global): ```json { "mcpServers": { "blueticks": { "command": "npx", "args": ["-y", "@blueticks/mcp"], "env": { "BLUETICKS_API_KEY": "bt_live_your_key_here" } } } } ``` Restart Claude Code after saving. (Claude Code also supports adding servers from the command line if you prefer that workflow; the JSON block above is the method Blueticks documents and the one that always works.) The first time a WhatsApp tool runs, `npx` pulls the package automatically, so the only prerequisite is Node.js 20 or newer. One thing to confirm before you start: your WhatsApp engine has to be connected to Blueticks first, the same connection that powers scheduling and campaigns in the app. Once it is linked, ask Claude "is my WhatsApp connected?" and it will call `whatsapp_engine` and tell you. ## For developers: the same power through the /v1 API Developers get the identical capabilities without Claude in the loop by calling the Blueticks REST API directly. The MCP server is a wrapper over the same `/v1` endpoints, so anything Claude can do, your own code can do, with full control over retries, idempotency, and webhooks. The base is `api.blueticks.co` with documented endpoints under `/v1/`. The auth model is the same key you used for the MCP. Pass it as a bearer token: ``` Authorization: Bearer bt_live_your_key_here ``` From there you have `POST /v1/scheduled-messages` to send or schedule, `GET /v1/scheduled-messages/:id` to check status, `POST /v1/campaigns` to start a paced campaign, and `POST /v1/webhooks` to register signed event callbacks. The MCP and the API are two front doors to one engine. Use the MCP when a human is driving in natural language, and the API when a backend service needs deterministic, programmatic sends. A practical pattern is to prototype the workflow conversationally in Claude, then port the proven flow into a scheduled job against `/v1`. Full reference, SDKs for five languages, and the cURL quickstart live at [dev.blueticks.co](https://dev.blueticks.co). ## MCP vs the WhatsApp Business API: when to use which? Use the WhatsApp MCP when you want Claude to read and operate your own existing WhatsApp number with a personal feel and minimal setup. Use the official WhatsApp Business Platform (the Cloud API) when you need Meta-verified, template-based messaging at very high volume with formal opt-in management. They solve different problems. | | Blueticks WhatsApp MCP | WhatsApp Business Platform (Cloud API) | | --- | --- | --- | | Reads your chats | Yes, that is the core use case | No, it is outbound-focused | | Sends from | Your own connected WhatsApp number | A Meta-registered business number | | Message format | Free-form, as you would type it | Pre-approved message templates for outbound | | Setup | Config block plus an API key | Meta Business verification and app review | | Per-message cost | No Meta conversation fee | Metered and priced per conversation by Meta | | Best for | Founders, small teams, inbox triage and personal outreach | Large enterprises, high-volume transactional flows | Neither one lets you spam. The Cloud API enforces templates and opt-in at the platform level; the MCP runs through your personal account, so WhatsApp's normal anti-abuse limits still apply to you. The MCP wins on the read-and-reply workflow and speed-to-value. The Cloud API wins when you need Meta's enterprise scale and are prepared for the verification overhead. Many teams start on the MCP and move to the Cloud API only when outbound volume forces it. For a deeper look at running structured sends, see our [WhatsApp campaign management guide](/blog/whatsapp-campaign-management). ## What are the limits and good practices? The core rule is simple: the MCP reads and automates your real WhatsApp account, so every WhatsApp rule that applies to you still applies through the MCP. Read freely, but message only people who expect to hear from you. Three practices keep you safe: - **Read first, send deliberately.** The read tools are safe to use constantly, that is the point. Keep sending as a separate, approved step, and have Claude show you the draft and recipient count before anything dispatches. - **Own number, real consent.** The MCP sends from your account to contacts who opted in. It is outreach automation, not a cold-blast tool. A list of strangers will get your number flagged regardless of how you send. - **Pace your sends.** For bulk, use `whatsapp_campaigns` rather than firing hundreds of messages in seconds. Start with a small batch, watch the delivery acknowledgements, then scale up. One practical note: a freshly queued message has no WhatsApp wire key until it actually dispatches, so delivery and read receipts populate a moment after sending, not instantly. Ask Claude to check status rather than assuming a send confirmed the instant you typed it. ## Frequently asked questions **Can Claude read my WhatsApp chats, or only send messages?** It can read. With the Blueticks MCP connected, Claude can list and search your chats, read the messages inside any thread, and look up contacts, which is what powers summaries, triage, and drafted replies. Sending and scheduling are separate actions you trigger. **Do I need to code to use the WhatsApp MCP?** No. The Claude Desktop path is a single JSON config block and an API key, with no programming required. Developers who want programmatic control can use Claude Code or call the `/v1` REST API directly, but it is optional. **Does the MCP work with my own WhatsApp number?** Yes. Reading and sending both go through your own connected WhatsApp session via the Blueticks engine, so recipients see a normal message from you, not from a third party. You need your WhatsApp engine linked to Blueticks first. **Can Claude schedule WhatsApp messages for later, not just send now?** Yes. Scheduling is a core capability. You can schedule a send for a future time, and list, reschedule, or cancel queued messages in plain English. Claude checks your current time and timezone first so relative times like "tomorrow at 9am" land correctly. **Will using AI on WhatsApp get my number banned?** Not if you follow WhatsApp's rules. The MCP does not bypass anything; it reads and sends as you. Reading is low-risk. For sending, message opted-in contacts, pace bulk sends through campaigns, and avoid blasting strangers, and you are operating exactly as a careful human would. ## Connect Claude to your WhatsApp today Stop starting your day by scrolling. Create a Blueticks API key, drop the config block into Claude, and ask it to read your WhatsApp and tell you what needs you. Get your API key and the full MCP setup at [dev.blueticks.co](https://dev.blueticks.co), then have Claude run your inbox. --- # How to Send Bulk WhatsApp Messages: Broadcast Campaign Guide (2026) > The native broadcast list caps you at 256 contacts, and half of them may never see your message. Here is how to send bulk WhatsApp messages that actually land in 2026. URL: https://blueticks.co/blog/how-to-send-bulk-whatsapp-messages Published: 2026-06-20 Author: Maya Cohen Category: marketing You have a list of 1,200 customers and a message worth sending. So you open WhatsApp, start building a broadcast list, and the app stops you at 256. Then you find out something worse: a chunk of those 256 will never get the message, with no error and no warning. That is the gap between *wanting* to send bulk WhatsApp messages and actually reaching people. The native broadcast tool was built for a shop owner texting regulars, not for a brand running a campaign. This guide covers both paths honestly: how the manual broadcast-list method works (and where it breaks), and how to send a real WhatsApp bulk message campaign without hitting the 256-contact wall or getting your number flagged. ## What does it actually mean to send bulk WhatsApp messages? Sending bulk WhatsApp messages means delivering the same message to many recipients at once, each as a private one-to-one chat rather than a group thread. Every person sees a normal message from you and replies only to you. Done right, it is personalized outreach at scale. Done wrong, it reads as spam and risks your number. The word "bulk" trips people up because WhatsApp has no single "send to everyone" button. There are three real ways to do it, and they are not interchangeable: - **Broadcast lists** in the WhatsApp or WhatsApp Business app. Free, manual, capped at 256 contacts per list, and gated by a saved-number rule we will get to. - **The WhatsApp Business Platform (Cloud API).** No 256 cap, but it routes every message through pre-approved templates, meters and prices each send, and requires technical setup. - **A bulk WhatsApp sender** like Blueticks that automates personalized sends from your own number and web session, so you keep the personal-account feel without copy-pasting 1,200 times. A WhatsApp broadcast campaign is not a group blast. Recipients never see each other, and that privacy model is the whole reason broadcasts feel personal instead of promotional. If you are still figuring out how to gather permission to message these people in the first place, start with our [WhatsApp opt-in collection guide](/blog/whatsapp-opt-in-collection-guide) before you send anything. ## How do you send a bulk WhatsApp message with a broadcast list (step by step)? To send a bulk WhatsApp message with a broadcast list, open WhatsApp, create a new broadcast list, add up to 256 contacts, type your message, and send. Each recipient gets it as a private chat. The catch: per the WhatsApp Help Center, only contacts who have *saved your number* in their phone will actually receive it. [image: Hand holding a smartphone while building a bulk WhatsApp broadcast list] Here is the working sequence on the standard app: 1. Open WhatsApp and tap the menu, then **New broadcast**. 2. Select the contacts you want to message. The app stops you at 256. 3. Type your message and send. WhatsApp delivers it as a separate one-to-one chat to each person. 4. Replies land in your normal Chats screen, one thread per person. On the WhatsApp Business app, you get a "business broadcast" flow and label-based selection, so you can build a list by filtering contacts tagged "VIP" or "Repeat buyer." The ceiling does not move. Labels change *how* you pick the 256, not how many you reach. The saved-number rule is the part that quietly kills campaigns. WhatsApp's official broadcast-list documentation is explicit: the message is sent only to recipients who have your number saved in their phone's address book. A new lead who messaged you yesterday but never saved your contact gets nothing, and you see no failure. For the full breakdown of why this silent filter exists and how big the leak is, see our [WhatsApp broadcast limit guide](/blog/whatsapp-broadcast-limit). ## Why do broadcast-list bulk sends scale so poorly? Broadcast lists scale poorly because of three hard limits stacked on top of each other: the 256-contact cap per list, the saved-number rule that silently drops non-savers, and the total absence of campaign analytics. Past a few hundred contacts, you are rebuilding lists by hand and flying blind on results. Run the math on a real list. Say you have 1,200 opted-in customers. The 256 cap forces you into five separate broadcast lists, each built and sent manually. Now layer the saved-number filter on top. WhatsApp support guidance and the platform's own documentation make clear that recipients who never saved your number receive nothing. If even 40% of your list never saved you (normal for a brand most people interact with a few times a year), roughly 480 of those 1,200 messages evaporate silently. You sent to 1,200. You reached maybe 720. And you have no delivery report to tell you which. It is a common and expensive surprise. Teams spend weeks optimizing message copy when the real problem is upstream: a large share of the list never saved the number, so the messages never arrived, and without delivery reports nobody notices the leak. You end up tuning a campaign for an audience that is not receiving it. There is a speed cost too, and it compounds. The 2007 MIT Lead Response Management study found you are **21 times** more likely to qualify a lead when you respond within five minutes versus thirty. Manual broadcasting (rebuild list, copy message, repeat five times) burns those minutes. By the time list four goes out, list one's window has closed. To plan around results instead of guessing, read our [WhatsApp campaign management guide](/blog/whatsapp-campaign-management); it walks the analytics layer broadcast lists never give you. ## How do you send a bulk WhatsApp campaign without the 256-contact ceiling? To send a bulk WhatsApp campaign past 256 contacts, you have two legitimate options: the WhatsApp Business Platform (Cloud API), which routes pre-approved templates with no list cap but requires technical setup and per-message fees, or a bulk WhatsApp sender like Blueticks that automates personalized sends from your existing number and web session. [image: Open laptop and notebook on a desk where a marketer plans a bulk WhatsApp campaign] The two paths suit different teams. Here is the honest comparison: | | WhatsApp Business Platform (Cloud API) | Blueticks bulk sender | |---|---|---| | Contact cap | No 256 list cap; daily unique-customer tiers | No 256 list cap | | Recipient must save your number | No | No | | Setup | Provider onboarding, business verification | Install extension, connect your number | | Message format | Pre-approved templates only | Free-form, personalized per contact | | Cost model | Per-message fees by category | Free plan available; Pro removes branding | | Best for | High-volume API-driven brands | SMBs, marketers, agencies sending from their own number | The API removes both the 256 cap and the saved-number rule, but it is a different product with real overhead. Every business-initiated marketing message must use a pre-approved template, and Meta charges per message by conversation category. It is the right tool at tens of thousands of sends a day with engineering support behind it. For most marketers and SMBs, a bulk WhatsApp sender hits the sweet spot. Blueticks sends your campaign from your own number by automating the sends one personalized message at a time through your web session, so recipients get a normal message from a number they already know, and you skip the template-approval and per-message-fee machinery entirely. ## Sending a bulk WhatsApp campaign with Blueticks in 5 steps To send a bulk WhatsApp campaign with Blueticks, install the Chrome extension, connect your WhatsApp number, import your contact list, write a personalized message with merge fields, then start the campaign small and scale up. The Free plan sends bulk campaigns with a "Powered by blueticks.co" footer; Pro removes it. [image: Marketing professional reviewing a printed contact list before launching a WhatsApp bulk campaign] The working sequence: 1. **Install the extension.** Add Blueticks from the Chrome Web Store, then open [app.blueticks.co](https://app.blueticks.co) and sign in. 2. **Connect your number.** Go to [app.blueticks.co/connections](https://app.blueticks.co/connections) and link your WhatsApp web session. The campaign sends from *your* number, not a shared shortcode. 3. **Import your list.** Upload your opted-in contacts. No 256-contact ceiling, no separate lists to rebuild. 4. **Write a personalized message.** Use merge fields so each recipient gets their own name and details. A personalized "Hi Sarah" outperforms a generic blast every time. 5. **Start small, then scale.** There is no automatic pacing, so send to a small batch first, confirm everything lands clean, then ramp volume up over your next sends. This is the single most important habit for protecting your number. Pricing note: the Free plan genuinely sends bulk campaigns, capped only by the footer line. The scheduling limit some people expect on Free applies to *scheduled* messages, not campaigns. Upgrading to Pro removes the branding footer. ## How do you stay compliant: opt-in, anti-spam, and avoiding a ban? To stay compliant when you send bulk WhatsApp messages, get explicit opt-in before messaging anyone, send only content people agreed to receive, start at low volume and scale gradually, and never message purchased or scraped lists. WhatsApp's Business Messaging Policy requires opt-in, and repeated violations escalate to messaging restrictions and bans. [image: Business handshake representing customer opt-in permission before sending bulk WhatsApp messages] The non-negotiables, straight from Meta's rules: - **Opt-in is mandatory.** WhatsApp's Business Messaging Policy requires you to obtain opt-in before messaging people. As of the November 2024 policy update, that permission can be general rather than WhatsApp-specific, as long as you comply with local law and the person gave you their number expecting to hear from you. - **No spam or bulk abuse.** WhatsApp's Help Center explicitly prohibits unauthorized automated or bulk messaging that harms users, and the platform's spam-detection systems act on signals like fast blocks and reports. - **Enforcement escalates.** Per Meta's policy-enforcement documentation, accounts first get a warning, then graduated messaging restrictions, and repeat or high-risk violations can end in permanent termination of the account and the organization behind it. The practical defense is behavioral, not just legal. Send to people who know you. Personalize. Start with a small batch and ramp up so your send pattern looks human, not like a firehose. A message someone expected gets a reply; a message they did not gets a block, and blocks are exactly the signal WhatsApp's systems watch. ## Broadcast list vs. bulk campaign tool: which should you use? Use a broadcast list when you are sending to under 256 contacts who have all saved your number and you do not need delivery analytics. Use a bulk campaign tool like Blueticks when you have more than 256 contacts, recipients who have not saved you, a need for personalization, or any requirement to measure results. Decide in one pass: | Your situation | Use this | |---|---| | Under 256 contacts, all saved your number | Native broadcast list | | Over 256 contacts | Bulk campaign tool | | Recipients who never saved your number | Bulk campaign tool | | Need per-contact personalization at scale | Bulk campaign tool | | Need to know what was delivered and replied | Bulk campaign tool | | Tens of thousands/day, engineering team in place | WhatsApp Business Platform (API) | The honest read: broadcast lists are fine for a corner shop messaging 50 regulars who all have the number saved. The moment you cross into "campaign" territory (real volume, new leads, personalization, measurement), the manual path costs you more in lost reach and lost hours than it saves in subscription fees. A bulk WhatsApp sender closes the 256 wall and the saved-number leak in one move. Start your first bulk WhatsApp campaign free: import your list and send a personalized broadcast in minutes by [installing the Blueticks extension from the Chrome Web Store](https://chromewebstore.google.com/detail/adgnjhngogijkkppficiiepmjebijinl). Begin with a small batch, confirm it lands, then scale. ## FAQ **How many people can you send a bulk WhatsApp message to at once?** On the native broadcast list (standard or Business app), the cap is 256 contacts per list, and only recipients who have saved your number receive the message. With a bulk WhatsApp sender like Blueticks, there is no 256 cap, and recipients do not need to have saved your number, because the campaign sends as normal personalized messages from your own number. **Why didn't my WhatsApp broadcast reach everyone?** The most common reason is the saved-number rule. Per the WhatsApp Help Center, a broadcast-list message is delivered only to people who have your phone number saved in their address book. Anyone who never saved you receives nothing, and WhatsApp shows no error, so the send silently underdelivers. **Can you send bulk WhatsApp messages for free?** Yes. The native broadcast list is free but capped at 256 and gated by the saved-number rule. Blueticks also sends bulk campaigns on its Free plan, with a "Powered by blueticks.co" footer; the Pro plan removes the footer. The WhatsApp Business Platform (API) charges per message by category. **Will sending bulk WhatsApp messages get my number banned?** It can, if you ignore the rules. WhatsApp's Business Messaging Policy requires opt-in and prohibits spam and unauthorized bulk messaging; repeated violations escalate to restrictions and bans. To stay safe: message only people who opted in, personalize, start with a small batch, and scale volume gradually so your pattern looks human. **What's the difference between a WhatsApp broadcast list and a bulk campaign tool?** A broadcast list is a free native feature limited to 256 saved-number contacts with no analytics. A bulk campaign tool like Blueticks automates personalized sends from your own number with no 256 cap, reaches recipients who have not saved you, and lets you manage and measure the campaign. Lists fit tiny audiences; tools fit real campaigns. --- # WhatsApp Business App vs API in 2026: Which One Do You Actually Need? > The honest 2026 breakdown of the WhatsApp Business app, the API, and the scheduling-tool path most guides skip, so you pick what you actually need. URL: https://blueticks.co/blog/whatsapp-business-app-vs-api Published: 2026-06-19 Author: Avi Kohen Category: industry You've found the right WhatsApp tier when your messaging stops fighting your billing. Most of the people asking "whatsapp business app vs API" don't actually have an API problem. They have a scheduling problem, a bulk-send problem, or a "I need to message 300 people without copy-pasting" problem, and they've been told the API is the answer. Often it isn't. Sometimes it absolutely is. This is the fair version, with the prices and limits pinned to Meta's own docs. ## WhatsApp Business app vs API: the 30-second decision The WhatsApp Business app is a free mobile app for one phone number with reactive auto-replies and manual sending. The WhatsApp Business API (Platform) is a programmatic backend for high volume, chatbots, and multi-agent teams, billed per delivered template message. If you mainly need to schedule, sequence, and bulk-send from a number you already use, you likely need neither at full strength, just a scheduling layer on top. Here is the cleanest way to think about it. The app is a phone. The API is a server. A scheduling tool like Blueticks is a layer that automates the number you already run. The mistake most guides make is presenting only the first two and pushing you toward the heavier, costlier one. The right choice depends on volume, automation depth, and whether you can tolerate Meta's template-approval and per-message billing. For the full billing math, see our breakdown of [WhatsApp Business API pricing in 2026](/blog/whatsapp-business-api-pricing-2026). ## What is the WhatsApp Business app, and what are its limits? The WhatsApp Business app is Meta's free mobile app built for small businesses on a single phone number. It adds a business profile, product catalog, labels, quick replies, and three reactive automations: a greeting message, an away message, and saved quick replies. It cannot schedule outbound messages, cannot run conditional flows, and cannot send true bulk campaigns at scale. Here is what you actually get, and where it stops. The **greeting message** fires automatically when a customer messages you for the first time or after 14 days of inactivity in the chat. The **away message** fires on a schedule you set (always, custom hours, or outside business hours) to acknowledge messages when you can't reply. **Quick replies** are saved snippets a human agent triggers with a shortcut, capped at 50, with no variables and no logic. Every one of these is reactive: the customer messages first, or an agent taps send. There is no native scheduler and no "send this to 300 contacts at 9am Tuesday" button. The hard ceilings worth naming, because they drive most upgrade decisions: - **One phone number, limited devices.** The app is built around a single business number on a primary phone, with WhatsApp's linked-devices feature for a handful of companions. It is not a multi-agent contact center. - **No conditional automation.** You cannot build "if they ask about price, send the price list." Greeting and away messages are single, static auto-replies. - **Broadcast lists are not bulk campaigns.** WhatsApp's broadcast feature only reaches contacts who have saved your number, caps the list size, and offers no scheduling, sequencing, or campaign analytics. - **No scheduling.** This is the single most common reason people start Googling the API. The app has none. These are not bugs. The app is deliberately a reactive, single-operator tool. When you outgrow "reactive," you have two directions to go, and only one of them is the API. For a deeper look at the scheduling gap specifically, see [how to schedule WhatsApp messages](/blog/schedule-whatsapp-messages). [image: Small shop owner holding a phone at a counter in a quiet boutique] ## What is the WhatsApp Business API (Platform), and who is it built for? The WhatsApp Business API, now called the WhatsApp Business Platform, is a programmatic interface with no app of its own. You send and receive messages through code or a Business Solution Provider (BSP), register message templates for Meta approval, and pay Meta per delivered template message. It is built for high volume, chatbots, CRM and helpdesk integration, and teams where many agents share one number. The distinction that trips people up: the API has no chat screen. You don't "open" it. It's a backend you connect to your own software, a chatbot builder, or a BSP's dashboard. That power comes with structure. Outbound, business-initiated messages must use **templates** that Meta reviews and approves before you can send them, sorted into categories (marketing, utility, authentication). You can't just type a fresh promo and blast it; it goes through approval first. Billing is the other defining trait, and it changed materially in the last two years. Per Meta's WhatsApp Business Platform documentation, the old conversation-based pricing was **deprecated and replaced by per-message pricing**, with the shift landing in 2025 (Meta lists per-message billing taking effect **July 1, 2025**, after utility templates inside the service window went free earlier that year). You now pay for each delivered **template** message individually, priced by the recipient's country and category. Earlier, on **November 1, 2024**, Meta made **service conversations free**, removing the prior cap of 1,000 free monthly service conversations, so replying to customers inside an open 24-hour service window is no longer billed. Meta also runs **volume-based tiers** for utility and authentication templates: the more you send in those categories, the lower the per-message rate. Marketing messages get no such discount and are always charged. Who this is genuinely built for: e-commerce sending thousands of order and shipping updates, businesses running an actual chatbot, support teams routing one number across many agents, and anyone wiring WhatsApp into a CRM. If that's you, the API isn't overkill, it's the only thing that fits. ## Do I need the WhatsApp Business API? A volume-and-use-case test Whether you need the WhatsApp Business API comes down to four questions: volume, automation depth, team size, and integration. If you send thousands of programmatic notifications, run a real chatbot, share one number across many agents, or push messages from a CRM, you need the API. If you mostly schedule and bulk-send personal-style messages from your own number, you almost certainly don't. Run yourself through this. Answer "do i need whatsapp business api" honestly: 1. **Are you sending automated, system-triggered notifications** (order confirmations, OTP codes, appointment reminders) at thousands-per-month scale? → API territory. 2. **Do you need a chatbot or interactive flows** that respond without a human? → API territory. 3. **Do multiple agents need to work one shared number simultaneously?** → API territory (the app caps you hard here). 4. **Do you need WhatsApp events flowing into a CRM or helpdesk?** → API territory. Now the other side: 5. **Do you mostly need to schedule messages, run drip sequences, and send the same message to a list** from a number you already use? → You do **not** need the API. 6. **Is your volume in the dozens-to-low-hundreds per send, conversational rather than transactional?** → You do **not** need the API. If your "yes" answers cluster in 1-4, budget for templates, approval lead time, and per-message fees, and pick a BSP. If they cluster in 5-6, the API will cost you money and setup time you don't need to spend. As one operator running a 40-person appointment business put it: "We spent six weeks on API onboarding to do something a scheduler did in an afternoon." That's the failure mode this test exists to prevent. ## WhatsApp Business app vs API: feature, pricing, and setup comparison table Across features, pricing, and setup, the three options separate cleanly. The WhatsApp Business app is free, reactive, and single-number. The WhatsApp Business API is programmatic, scalable, and billed per delivered template message via a BSP. A scheduling tool sits on your existing number to add scheduling, sequences, and bulk sending without templates or per-message fees. | | **WhatsApp Business app** | **WhatsApp Business API (Platform)** | **Scheduling tool (e.g. Blueticks)** | |---|---|---|---| | **Cost** | Free | Per delivered template message; per-message pricing since July 1, 2025; service convos free since Nov 1, 2024 | Flat subscription; uses your existing number, no per-message Meta fee | | **Best for** | Solo / micro business, reactive replies | High volume, chatbots, multi-agent, CRM | Scheduling, sequences, bulk from your own number | | **Numbers / agents** | One number, few linked devices | One number, many agents | Your existing number(s) | | **Outbound scheduling** | None | Via your own code/BSP | Built in | | **Bulk campaigns** | Broadcast lists only (saved contacts, size cap) | Yes, template-gated | Yes | | **Templates / approval** | N/A | Required, Meta-approved | Not required | | **Automation** | Greeting, away, 50 quick replies (reactive) | Full programmatic / chatbot | Drip sequences, scheduled sends | | **Setup** | Download app, verify number | BSP onboarding, template registration, dev work | Connect your number, start | The table makes the honest point visible: the API column wins on scale and programmability, and loses on cost and setup friction for anyone who isn't operating at scale. For campaign-specific mechanics, see our guide to [WhatsApp campaign management](/blog/whatsapp-campaign-management). [image: Developer desk with an angled laptop, printed documents and sticky notes] ## When is the WhatsApp Business API actually worth it? The WhatsApp Business API is worth it when scale or automation justifies its template approval and per-message cost. That means thousands of system-triggered messages a month, a real chatbot, a shared number across many support agents, or deep CRM integration. Below that threshold, the per-message billing and BSP setup are cost and complexity you won't recoup. Let's not strawman it. When to use whatsapp business api, concretely: - **Transactional volume.** If you fire order updates, OTPs, and reminders by the thousand, the API's utility-template **volume tiers** (lower per-message rate as volume climbs, per Meta's pricing docs) and **free service-conversation replies since November 1, 2024** actually make the economics work. A free 24-hour service window means your support replies cost nothing once a customer opens the conversation. - **Automation that can't wait for a human.** A chatbot answering at 2am is API-only. The app's quick replies need a human to tap them. - **Multi-agent operations.** One number, a queue, twenty agents: that's the API's home turf. The app can't do it. - **CRM / helpdesk integration.** Events into HubSpot, Salesforce, Zendesk: API. So is whatsapp business api worth it? At scale, unambiguously yes. The honest caveat: marketing templates carry **no volume discount and are always charged**, so a high-marketing, low-utility mix can get expensive fast. Model your category mix against Meta's rate card before you commit. If your volume is modest and conversational, the answer flips, which is the next section. ## The third option most guides skip: scheduling and automation without the API There's a third path most comparison guides ignore: a scheduling and automation tool that runs on the WhatsApp number you already use. It adds the two things people actually want from "automation," scheduled sends and bulk messaging, without template approval, per-message Meta fees, or BSP onboarding. For dozens-to-hundreds of recipients, it covers the real need. This is the gap the binary "app vs API" framing creates. People hit a WhatsApp Business app limitation (no scheduler, no real bulk) and assume the only fix is the heavy machinery of the API. But the actual job to be done is usually small: "send this Tuesday at 9," "follow up with non-responders in three days," "message my 150-person list with one personalized template." None of that requires programmatic infrastructure or Meta template approval. A tool like [Blueticks](/scheduler) layers onto your existing number and adds: - **Scheduled messages**, one-time and recurring, so you compose now and send later. - **Drip sequences and follow-ups**, the conditional-ish behavior the app can't do natively. - **Bulk campaigns** to a contact list without broadcast-list restrictions. - **No template approval, no per-message Meta billing**, because you're not on the Platform API. The trade-off, stated plainly: this path is built for human-scale, personalized outreach and scheduling, not for million-message automated notification streams or chatbots. If you need those, you need the API. If you need a calendar and a send button that works at list scale, you don't. ## When you don't need the API at all: the scheduling-tool path You don't need the WhatsApp Business API when your core need is scheduling, follow-up sequences, and bulk sending at human scale. If you're a clinic sending reminders, a shop running a weekly offer, or a consultant nurturing leads, a scheduling tool on your existing number does the job without templates, approval delays, or per-message fees. The API would add cost and setup with no payoff. Concrete profiles that should skip the API: - **Appointment-based businesses** (salons, clinics, tutors) sending reminders and confirmations to known clients. Scheduling, not programmatic infrastructure, is the need. - **Small retailers** running a weekly promo to a saved-customer list. A bulk-send-and-schedule tool beats both the app's broadcast cap and the API's marketing-template fees. - **Solo operators and consultants** nurturing a pipeline with timed follow-ups. Drip sequences, not chatbots. The decision rule that closes the loop: if a human would be comfortable typing each of these messages but doesn't have time to, you want scheduling, not an API. The API is for messages no human types, the OTPs and the order-shipped notifications generated by a system. Match the tool to who's authoring the message. For the mechanics of getting started, [how to schedule WhatsApp messages](/blog/schedule-whatsapp-messages) walks through it. [image: Clinic receptionist at a calm front desk with a phone face-down nearby] ## Which WhatsApp business solution should you choose? A quick recommendation by profile Which WhatsApp business solution to choose depends on your scale and what authors the message. Reactive, single-operator: the free WhatsApp Business app. High-volume, automated, multi-agent, or CRM-connected: the WhatsApp Business API via a BSP. Scheduling, sequences, and human-scale bulk from your own number: a scheduling tool. Match the tool to the job, not to the hype. Pick by profile: - **Solo shop, reactive replies, no scheduling need** → WhatsApp Business app. It's free, and a greeting plus away message covers you. - **E-commerce or fintech, thousands of automated notifications, chatbot, or multi-agent support** → WhatsApp Business API. Budget for templates and per-message billing; lean on free service conversations and utility volume tiers. - **Service business, agency, or consultant who needs to schedule, follow up, and bulk-send from your existing number** → a scheduling tool. No API, no approval, no per-message fee. - **Not sure?** → Start with the app (free), and add a scheduling layer the moment "no scheduler" or "no bulk" becomes the thing that hurts. You can reach for the API later if and only if volume or automation forces it. The cynical-but-accurate summary: the API is sold harder than it's needed, because per-message billing and BSP relationships are where the money is. For most SMBs whose real problem is timing and list-sending, the answer was never the API. Just need to schedule, send sequences, and run bulk WhatsApp campaigns from the number you already use, without API approval, templates, or per-conversation fees? [Start free with Blueticks](/scheduler) and schedule your first message in minutes. ## FAQ **Is the WhatsApp Business API better than the WhatsApp Business app?** Not "better," different. The app is free, reactive, and built for one operator on one number. The API is a programmatic backend for high volume, chatbots, and multi-agent teams, billed per delivered template message. The API is better only if your scale or automation needs justify its cost and setup. Otherwise the app, or a scheduling tool, fits better. **Does the WhatsApp Business app let me schedule messages?** No. The WhatsApp Business app has no native scheduler. Its automations (greeting, away, quick replies) are all reactive, triggered by an incoming message or a human agent. To schedule outbound messages, you need either the API (via your own code or a BSP) or a scheduling tool that runs on your existing number. **How much does the WhatsApp Business API cost in 2026?** Per Meta's WhatsApp Business Platform docs, billing moved to per-message pricing, with per-message billing in effect since July 1, 2025. You pay for each delivered template message, priced by the recipient's country and category. Service conversations have been free since November 1, 2024, and utility and authentication templates get volume-based discounts. Marketing templates are always charged with no volume discount. **Can I send bulk WhatsApp messages without the API?** Yes, at human scale. The Business app's broadcast lists are limited (only reach contacts who saved your number, with size caps). A scheduling and automation tool on your existing number can send bulk campaigns and sequences without template approval or per-message Meta fees. For very high, fully automated volumes, the API is still the right tool. **Do I need a BSP to use the WhatsApp Business API?** Practically, most businesses do. You can integrate directly with Meta's Cloud API, but a Business Solution Provider handles template management, onboarding, and a usable dashboard. Either way you register and get Meta approval for message templates before sending business-initiated messages, and you pay per delivered template message. --- # How to Send a Reminder Message on WhatsApp (Appointment, Payment & Follow-Up Templates) > How to send appointment, payment, and follow-up reminder messages on WhatsApp: what WhatsApp can't do natively, the templates that actually get a reply, and the reliable way to schedule them. URL: https://blueticks.co/blog/send-whatsapp-reminder-messages Published: 2026-06-18 Author: Daniel Roth Category: productivity A reminder only works if it arrives at the right moment. A day before the appointment. The morning the invoice is due. A week after a quote, when the lead has gone quiet. Send it too early and it's forgotten by the time it matters; send it late and the appointment's already missed. So the real question behind **whatsapp reminder messages** isn't what to write. It's how to make sure the message goes out exactly when it should, without you having to remember. This guide covers that end to end: whether you can send a reminder on WhatsApp natively (the honest answer surprises people), the difference between reminding yourself and reminding a customer, how to send one-time and recurring reminders, the templates that actually get a reply, and the reliable way to schedule them so they fire on time. ## Can you send a reminder message on WhatsApp natively? Short answer: no. WhatsApp has no built-in feature that lets you write a message now and have it sent to someone later. There is no "remind me to send this" button, no scheduler, no calendar inside the app that fires a message at a set time. If you want a reminder to reach a customer tomorrow at 9am, WhatsApp on its own gives you exactly one option: remember to open the app tomorrow at 9am and type it yourself. This trips people up because the WhatsApp Business app does have automation features, and they get mistaken for scheduling. Greeting messages, away messages, and quick replies are real and useful, but they are **auto-replies**, not scheduled sends. A greeting message fires when a customer messages you first. An away message fires when someone writes you outside your business hours. Quick replies are canned answers you insert by hand during a live chat ([WhatsApp Business Help Center](https://faq.whatsapp.com/647349420360876)). Every one of them is a reaction to the customer contacting you. None of them lets you proactively send a reminder to someone who hasn't written to you, at a time you choose. That's the gap. So when you search for **how to send a reminder message on whatsapp**, you're really looking for something WhatsApp doesn't include: a way to schedule an outbound message into the future. The good news is that the workaround is simple and reliable. But first it's worth being clear about what kind of reminder you actually mean, because the word covers two very different things. ## What's the difference between a reminder to yourself and a reminder message to a customer? These two get lumped together, and they need completely different tools. A **reminder to yourself** is a personal nudge. "Call the supplier at 3pm." "Don't forget Dad's birthday." It lives in your head, on a sticky note, or in your phone's clock or reminders app. Nobody else sees it. You're not sending anything to anyone; you're just trying not to forget. If that's what you need, the honest advice is to use your phone's built-in reminders or alarm, not WhatsApp at all. WhatsApp isn't a to-do list. A **reminder message to a customer** is the opposite. It's an actual message that leaves your account and lands in someone else's WhatsApp at a future time: the appointment confirmation a day before the visit, the payment nudge on the due date, the follow-up a week after a quote. This is outbound. It has a recipient, a body, and a send time. And this is the one people are usually trying to solve when they look up WhatsApp reminders for business. The rest of this guide is about the second kind. When we talk about scheduling a reminder, we mean composing a real message to a real contact and having it sent on time, automatically, so you don't have to be sitting there at 9am to press send. ## How do you send a one-time appointment or payment reminder on WhatsApp? A one-time reminder is the most common case: a single message tied to a single date. A **whatsapp appointment reminder** the day before a booking. A payment reminder on the day an invoice falls due. A "your order's ready for pickup" note. You write it once, it sends once, you're done. Since WhatsApp itself can't queue a future send, the practical method is a scheduling tool that sits on top of WhatsApp Web. The flow looks like this: 1. Open WhatsApp Web in your browser with the scheduling extension installed. 2. Go to the chat with the client you want to remind. 3. Write the reminder the way you normally would: "Hi Sarah, just confirming your appointment tomorrow at 2pm." 4. Instead of pressing send, pick the date and time you want it to go out. 5. Queue it. The message fires at that moment, on its own. That's the whole point of a scheduler: you do the thinking now, when you have the client's details in front of you, and the sending happens later without you. For the broader walkthrough across phone and desktop, our guide on [how to schedule WhatsApp messages](https://blueticks.co/blog/schedule-whatsapp-messages) covers every method in detail. The advantage of scheduling a reminder the moment you book the appointment is that you never forget. The instant you confirm Sarah's 2pm slot, you queue the day-before reminder. It's out of your head and into the system. No mental load, no calendar-checking, no 8:55am scramble. [image: A hand resting on an open paper appointment book on a desk, pen nearby, soft daylight] ## How do you set up recurring WhatsApp reminders (weekly check-ins, monthly invoices)? Plenty of reminders aren't one-offs. They repeat. A weekly check-in with a coaching client. A monthly invoice reminder. A "we're open tomorrow" note to your regulars every Sunday evening. Writing the same message by hand week after week is exactly the kind of task that gets dropped the one week you're busy, which is usually the week it matters most. A **recurring whatsapp reminder** solves this by letting you write the message once and set it to repeat: daily, weekly, monthly, or on a custom cadence. The scheduler sends it on every cycle automatically. You set up the monthly invoice reminder in January, and it goes out on the 1st of every month after that without another thought from you. This is genuinely the highest-leverage version of WhatsApp reminders for a small business. The classics that pay off as recurring sends: - A weekly check-in to active clients ("How's the plan going this week?"). - A monthly payment or invoice reminder to retainer customers. - A standing reminder to a class, group, or membership ("Session tomorrow at 6pm, see you there"). - A periodic re-engagement nudge to quiet leads. Recurring reminders deserve their own setup because the timing rules matter more, so we wrote a dedicated guide on [scheduling recurring WhatsApp messages](https://blueticks.co/blog/schedule-recurring-whatsapp-messages) that walks through daily, weekly, and monthly patterns and how to avoid sending at awkward hours. If your reminders repeat on any kind of cycle, start there. ## What reminder message templates actually get a reply? (appointment, payment, follow-up) A reminder that gets ignored is wasted. The ones that work share a few traits: they're short, they name the specific thing (date, amount, what's next), they sound like a person rather than a robot, and they make the next step obvious. Here are templates you can adapt for the three most common cases. **Appointment reminders.** The goal is to confirm and to cut no-shows. Give the date and time, and an easy out if they need to reschedule. > Hi [name], this is [business] confirming your appointment tomorrow, [day] at [time]. Looking forward to seeing you! If you need to reschedule, just reply here. > Hi [name], friendly reminder about your [service] on [date] at [time]. Reply YES to confirm or let me know if another time works better. **Payment reminders.** Be polite, be specific about the amount and due date, and make paying frictionless. A neutral, helpful tone gets paid faster than a stern one. > Hi [name], a quick reminder that invoice [number] for [amount] is due on [date]. You can pay here: [link]. Thanks so much! > Hi [name], hope you're well. Just a gentle nudge that [amount] for [service] is now due. Let me know if you have any questions, happy to help. **Follow-up reminders.** A **whatsapp follow-up message** revives a conversation that went quiet without sounding pushy. Reference the last thing, add a small reason to reply now. > Hi [name], following up on the quote I sent last week for [project]. Any questions I can answer? Happy to hold the price through [date]. > Hi [name], checking in since we spoke about [topic]. Still keen to help whenever you're ready, no rush, just didn't want it to slip through the cracks. One important distinction on templates. If you send through the **WhatsApp Business API** (the enterprise channel used by larger senders and platforms), proactive reminders like these are typically sent as pre-approved **Utility templates**, and they carry a per-message fee. Appointment reminders, payment reminders, and order updates fall into the utility category and are billed per delivered message under Meta's current pricing ([Meta WhatsApp Business Platform pricing](https://developers.facebook.com/documentation/business-messaging/whatsapp/pricing)). For most small businesses and individuals, you don't touch any of that: when you schedule a reminder through a tool on WhatsApp Web, it's just a normal message you're sending from your own account, with no template approval and no per-message charge. Pick the path that matches your scale; for the vast majority of people reading this, the WhatsApp Web route is simpler and free. [image: A phone lying face-down on a counter next to a small analog clock in soft morning light] ## Can on-device apps like Tasker or SKEDit schedule reminders reliably? There's a category of Android apps, Tasker, MacroDroid, SKEDit, that claim to schedule WhatsApp messages from your phone. They can sort of do it, and it's worth understanding exactly how, because the "sort of" is the whole problem. These apps don't have a real connection to WhatsApp. WhatsApp has no public way to schedule sends, so they fake it: at the scheduled time, the app uses your phone's accessibility service to physically open WhatsApp, navigate to the chat, and tap the send button for you, simulating the taps a human would make. When it works, it works. But it depends on a fragile chain of conditions: - **Your phone has to be on, unlocked, and connected.** The app is driving your actual screen, so the phone can't be off or locked. A scheduled 9am reminder needs your phone awake at 9am. - **Battery optimization breaks it.** Android aggressively suspends background apps to save power. If the system pauses the automation app before your send time, the reminder silently doesn't go. - **A WhatsApp UI change can break the whole flow.** Because the app taps through WhatsApp's interface, any update that moves a button or changes a layout can leave it tapping the wrong place, or nothing at all. - **iPhone basically can't do this.** iOS doesn't allow an app to drive another app's interface this way. On iPhone these tools can set a reminder for *you* to send manually, but they can't auto-send. The result is reminders that work most of the time and fail unpredictably, which is the worst property a reminder can have. The whole reason you schedule a payment reminder is so it can't be forgotten. A method that quietly drops sends when your battery's low or WhatsApp updated overnight defeats the purpose. For an occasional personal nudge, fine. For appointment and payment reminders your business depends on, you want something that doesn't hinge on your phone being awake and an accessibility hack still lining up. [image: A relaxed small-business owner having coffee away from the counter, phone set aside, warm daylight] ## The reliable way to schedule WhatsApp reminders: Blueticks on WhatsApp Web The dependable approach is to **schedule reminder whatsapp** sends through a tool built for it on WhatsApp Web. Blueticks is a Chrome extension that installs on top of WhatsApp Web and adds the scheduling that WhatsApp itself leaves out. You keep using WhatsApp Web exactly as you do now; the extension adds a date-and-time picker to the message box. Setting a reminder takes one extra step over sending normally. You open the client's chat, write the reminder, choose when it should go out, and queue it. For recurring reminders, you set the repeat pattern once, daily, weekly, monthly, and it sends on every cycle. You can see the full feature set on the [Blueticks scheduler](https://blueticks.co/scheduler) page. Now, the honest detail that matters and that hype tends to gloss over. The standard Blueticks extension sends through your WhatsApp Web session, which means the browser tab needs to be open at send time for the message to fire. If your laptop is closed and the browser is shut, the standard extension is waiting for the tab to come back. For people who keep a browser open through the workday, that's a non-issue: your 9am and 2pm reminders fire while you work. But Blueticks also offers an **offline gateway mode** that runs in the cloud and sends your scheduled reminders even when your computer is off or your browser is closed. So if "it has to send even when my laptop's shut" is a hard requirement, that's the offline capability to look for, not the basic browser extension. Match the tool to your need: browser-open-during-the-day covers most reminders for free, and the offline gateway covers the always-on case. Either way, the core win is the same. You stop relying on your memory and your phone being awake. You schedule the reminder once, at the moment you have the details, and it goes out on time. **Schedule your first appointment, payment, or follow-up reminder on WhatsApp Web with Blueticks — set the date once and it sends reliably.** [Start scheduling reminders with Blueticks](https://blueticks.co/scheduler) ## FAQ **Can I schedule a reminder message on WhatsApp without any extra app?** No. WhatsApp has no native scheduler. Its greeting, away, and quick-reply features are auto-replies that trigger when a customer messages you, not scheduled outbound sends ([WhatsApp Business Help Center](https://faq.whatsapp.com/647349420360876)). To send a reminder to a contact at a future time, you need a scheduling tool on top of WhatsApp Web. **What's the difference between an appointment reminder and an away message?** An away message is an auto-reply: it fires automatically when someone messages you outside your business hours. An appointment reminder is a proactive message you send to a client before their booking. WhatsApp Business handles the first natively; the second needs a scheduler. **Do my reminders send if my laptop is closed?** With the standard Blueticks extension, the browser tab needs to be open at send time, since it sends through your WhatsApp Web session. Blueticks also offers an offline gateway mode that sends from the cloud even when your computer is off. If always-on sending matters, that's the capability to use. **Are WhatsApp reminder messages free?** Through a tool on WhatsApp Web, a reminder is just a normal message from your account, with no per-message fee. If you send via the WhatsApp Business API instead, proactive reminders are usually Utility templates billed per delivered message under Meta's pricing ([Meta WhatsApp Business Platform pricing](https://developers.facebook.com/documentation/business-messaging/whatsapp/pricing)). **Can I set up a reminder that repeats every week or month?** Yes. A recurring reminder lets you write the message once and have it sent on a daily, weekly, or monthly cycle automatically. Our [recurring WhatsApp messages guide](https://blueticks.co/blog/schedule-recurring-whatsapp-messages) walks through the patterns. **Are Tasker and SKEDit reliable for scheduled reminders?** Only partly. They simulate taps through your phone's accessibility service, so they need the phone on and unlocked, can be killed by battery optimization, and break when WhatsApp's interface changes. iPhone can't auto-send at all. For reminders you can't afford to miss, a WhatsApp Web scheduler is more dependable. --- # WhatsApp Business API Pricing in Europe 2026: EUR Per-Message Rates by Category (Portugal, Spain, Germany, UK) > Since July 2025, WhatsApp Business Platform bills per message, not per conversation. Here is how the European EUR rates work by category and country in 2026 — and how to keep the bill down. URL: https://blueticks.co/blog/whatsapp-business-pricing-europe-2026 Published: 2026-06-17 Author: Maya Cohen Category: marketing If you run WhatsApp campaigns to customers in Europe, your bill changed on July 1, 2025. Meta moved the WhatsApp Business Platform from charging per 24-hour conversation to charging per individual message, and for marketing senders in higher-rate European markets, that shift stings. This guide explains how **whatsapp business api pricing europe 2026** actually works, which message categories cost money and which are now free, what the EUR per-message structure looks like in Portugal, Spain, Germany and the UK, and how to keep the monthly total down without cutting the campaigns that pay for themselves. A note before the numbers: this is a pricing article, so accuracy matters more than tidy figures. Meta updates its rate card periodically, rates differ by country, and third-party calculators disagree with each other. Where we give a precise rate, we date-stamp it and point you to Meta's live card. Where we use a number to show the math, we label it illustrative. Always confirm the current figure on [Meta's official pricing page](https://developers.facebook.com/docs/whatsapp/pricing) before you budget. ## How does WhatsApp Business API pricing work in Europe in 2026? (per-message model, post–July 2025) The WhatsApp Business Platform — the Cloud API that powers bulk campaigns, automations and bots — bills on a **per-message** basis as of July 1, 2025. You are charged when a *template* message is delivered, and the price depends on two things: the message **category** and the **recipient's country** ([Meta pricing docs](https://developers.facebook.com/docs/whatsapp/pricing)). Two clarifications matter for Europe right away. First, the rate is set by the recipient's phone-number country code, not by where your business sits. A shop in Madrid messaging a customer with a German number pays the German rate, not the Spanish one. Your own location does not set the price; your audience's numbers do. Second, this is the **WhatsApp Business Platform / Cloud API** — the developer product used through a Business Solution Provider (BSP) or a tool built on the API. It is not the free **WhatsApp Business app** you download from the store. The app has no per-message fees at all. If you are a small business replying by hand from the app on a phone, none of the rates below apply to you. The per-message bill is a Platform/API thing. For the full breakdown of how the categories are defined and how the model came to be, see our pillar guide on [WhatsApp Business API pricing in 2026](https://blueticks.co/blog/whatsapp-business-api-pricing-2026). This article assumes those definitions and focuses on the European, EUR-denominated picture — so we will not re-explain each category in depth here. ## What changed with the July 1, 2025 switch to per-message pricing — and why it stings European marketing senders? Before July 2025, WhatsApp used **conversation-based pricing**: one charge covered a rolling 24-hour window, and you could send several messages inside that window for a single fee. The **whatsapp conversation based pricing change 2026** that everyone is still adjusting to is the end of that window model for billing. Now each delivered template message is its own line item ([Meta pricing docs](https://developers.facebook.com/docs/whatsapp/pricing)). Why does this hit European marketing senders harder than most? Two reasons stack up. The first is the model itself. Under conversation pricing, a marketing burst plus a couple of follow-ups could ride on one conversation charge. Under per-message pricing, every marketing template you deliver is billed individually. If your campaign cadence relied on multiple touches, your cost per recipient went up even before any rate change. The second is geography. European marketing rates are among the highest in the world. Germany in particular sits at the top of the global table for marketing messages. So the per-message model multiplies a high base rate across every send. A list of 50,000 German contacts getting one marketing template each is now 50,000 individually-billed marketing messages at a premium rate — not a handful of conversation charges. The silver lining is that Meta also made a lot of traffic free, which we cover next. The senders who feel the squeeze are specifically the ones leaning on outbound **marketing** templates to European numbers. [image: A cafe owner behind a counter in a Berlin coffee shop, phone face-down beside the till] ## Which message categories cost money in Europe — and which are now free? The **whatsapp business platform pricing categories 2026** break into four buckets, and only three of them carry a charge. - **Marketing** — promotions, offers, newsletters, re-engagement. **Charged**, and it is the priciest category. - **Utility** — order updates, shipping notices, appointment reminders, payment confirmations tied to a transaction. **Charged**, but cheaper than marketing, and free in some contexts (see below). - **Authentication** — one-time passwords and verification codes. **Charged**, typically the cheapest template category. - **Service** — your replies to a customer inside the 24-hour customer-initiated window. **Free**. The free side grew substantially. Service conversations became free for all businesses on November 1, 2024 — so any reply you send within an open customer-service window, including utility templates delivered inside it, is free of charge ([Meta pricing docs](https://developers.facebook.com/docs/whatsapp/pricing)). All non-template messages — plain text, images, the back-and-forth of a real conversation a customer started — are free too. There is also a free-entry-point window: when a customer reaches you through certain ad or page entry points, messages for a set period are free. The practical takeaway for Europe: the money is in **outbound, business-initiated marketing**. If your WhatsApp activity is mostly answering customers who message you first, your paid-message bill may be close to zero. If you are pushing campaigns out, marketing is where the meter runs — which is exactly why the structure of your campaigns matters so much. Our guide to [WhatsApp campaign templates that convert](https://blueticks.co/blog/whatsapp-campaign-templates-that-convert) is worth a read, because in the per-message world a template that earns its send is the difference between a campaign that pays and one that just costs. ## What are the EUR per-message rates by category in Portugal, Spain, Germany and the UK? Here is the honest version, because **whatsapp marketing message pricing 2026** is the number people most want and the one most often quoted wrong. Meta sets rates per category and per recipient country, and bills participating European accounts in EUR (the platform supports billing in EUR, GBP and several other currencies). The **relative** structure is stable and worth internalising: across every European market, **marketing is the most expensive category, utility sits well below it, and authentication is usually the cheapest.** That ranking holds whether you send to Lisbon, Madrid, Berlin or London. The **absolute** rates are where you must go to the source. Meta revises the rate card periodically, some European markets are priced individually (Germany and the UK, for example) while others fall into regional groupings, and the published third-party calculators frequently disagree — some quote per-conversation legacy numbers, some mix USD and EUR. We will not print a specific Portugal, Spain, Germany or UK figure as if it were a guaranteed live rate, because by the time you read this it may have moved. What we can tell you with confidence about **whatsapp business platform pricing portugal** and its neighbours: - **Portugal and Spain** are generally grouped into a Western-Europe regional rate rather than each having a unique standalone card. Their marketing rates are high by global standards but typically below Germany's. - **Germany** is priced individually and carries one of the highest marketing rates in the world — German marketing sends are the single most expensive line for many European senders. - **The UK** is priced individually in GBP terms and tends to run lower than Germany's marketing rate. **Illustrative example only — these are not live Meta rates, confirm on [Meta's official card](https://developers.facebook.com/docs/whatsapp/pricing):** if, *for illustration*, a marketing message to Germany were around €0.11, to Portugal/Spain around €0.06–0.08, and to the UK around €0.05, while utility ran roughly a third of marketing and authentication a touch lower still, you would already see the shape of the bill: marketing dominates, geography swings it by a factor of two or more, and Germany is the outlier on the high end. Use those proportions to reason about your mix; pull the exact decimals from Meta before you sign a budget. As of June 2026, that structure — marketing highest, utility mid, authentication lowest, set by recipient country, billed per delivered template — is the durable truth. The specific decimals are the part to verify live. ## Why do WhatsApp rates differ between European countries? It looks arbitrary that a message to Germany can cost roughly double a message to Spain, but there is logic to it. Meta prices each market based on local telecom economics, competition from SMS and other channels, demand and the value of the audience to advertisers. Markets where businesses pay a lot for reach through other channels, and where WhatsApp penetration makes it a premium marketing surface, carry higher rates. Germany consistently lands at the top for marketing; other Western European markets cluster lower. The category split has its own logic. Marketing is unsolicited promotional reach, so it is priced like advertising — the most expensive. Utility messages are transactional and customer-expected (an order confirmation a buyer wants), so Meta keeps them cheaper and free inside a service window. Authentication is high-volume, low-margin infrastructure traffic, so it is priced near the floor. The lever you control is not the per-country rate — you cannot negotiate Germany down. It is your **mix and your targeting**: which categories you lean on, which countries you send to, and how many of your sends are genuinely worth the marketing rate. [image: Two colleagues planning at a table with an open paper notebook and a closed laptop] ## How much does WhatsApp Business API cost per month? A worked example for a Europe-based sender Here is the **whatsapp business api pricing per message** math made concrete. **The numbers below are illustrative — they are not Meta's live rates. Use the method, plug in your real rates from [Meta's card](https://developers.facebook.com/docs/whatsapp/pricing).** Picture a mid-size online retailer sending to a European list, one month: - **20,000 marketing messages** (a campaign and a re-engagement blast), illustrative rate **€0.08** each - **8,000 utility messages** (order and shipping updates), illustrative rate **€0.025** each - **5,000 authentication messages** (login OTPs), illustrative rate **€0.020** each - **Inbound service replies** to customers who messaged first: **free** The math: - Marketing: 20,000 × €0.08 = **€1,600** - Utility: 8,000 × €0.025 = **€200** - Authentication: 5,000 × €0.020 = **€100** - Service: **€0** - **Illustrative monthly total: €1,900** Two things jump out, and they hold regardless of the exact rates. First, **marketing is roughly 84% of the bill** in this example despite being well under half the message volume — because it is the priciest category. Second, **the service traffic is free**, so the customers who reach out to you cost nothing to answer. Now run the same 20,000 marketing messages at a German rate near €0.11 and that line alone jumps to €2,200 — geography moves the total more than utility and auth combined. That is why, in 2026, the cheapest lever is sending fewer, better-targeted marketing messages rather than chasing a lower per-message rate that Meta sets for you. ## Do BSPs like Twilio or 360dialog charge more than Meta's rates? [image: A person at a tidy desk reviewing printed paperwork next to a simple desk calculator] Usually, yes. This is the part that surprises people who budget straight off Meta's card. Meta's published rate is the **floor**, not the final price. You access the WhatsApp Business Platform through a Business Solution Provider, and most BSPs — Twilio, 360dialog, MessageBird, Vonage and the rest — add their own markup or platform fee on top of Meta's per-message rate. Some charge a per-message surcharge; some bundle a monthly platform fee; some do both. 360dialog is known for a flat-fee model that passes Meta's rates through with little or no per-message markup, while others add a few cents per message. The result is that two senders posting the identical campaign to the identical German list can pay meaningfully different totals depending on which BSP sits in the middle. So when you read "Germany marketing is about €0.11," treat that as the Meta component. Your actual line is that **plus** whatever your BSP charges. Always read your BSP's pricing alongside Meta's card, and model the combined number. The Meta rate tells you the relative cost of categories and countries; the BSP tells you your real invoice. ## How do you cut your WhatsApp paid-message bill in Europe? (Blueticks) You cannot change Meta's rates, and we will not pretend otherwise. What you can change is **how many paid messages you send and how well each one is aimed** — and in a per-message world, that is the whole game. The biggest savings come from discipline on the marketing category, because it dominates the bill: - **Send to the right contacts, not the whole list.** Every off-target marketing send is the full marketing rate wasted. Tight segmentation cuts volume without cutting results. - **Time sends well.** A campaign that lands when people actually read it converts more per paid message, so you need fewer of them to hit the same goal. - **Move expected updates into the free lanes.** Order and appointment messages that fit inside an open service window are free — keep them there instead of paying the utility rate. - **Make every marketing template earn its send** ([campaign templates that convert](https://blueticks.co/blog/whatsapp-campaign-templates-that-convert)). This is where Blueticks helps — honestly, by lowering your *volume*, not by discounting Meta's rate (no tool can do that). Blueticks lets you plan, segment and schedule WhatsApp campaigns so each paid send goes to the right contact at the right moment, instead of blasting the whole list and eating the marketing rate on contacts who were never going to convert. Fewer wasted messages means a lower monthly Meta bill for the same outcome. **Paying per marketing message in Europe? Plan and schedule your WhatsApp campaigns with [Blueticks](https://blueticks.co/scheduler) so every paid send lands on the right contact at the right time — fewer wasted messages, lower monthly Meta bill. [Start free](https://blueticks.co/scheduler).** ## FAQ **Did WhatsApp Business API pricing really change in 2026?** The big change took effect July 1, 2025, when Meta switched the WhatsApp Business Platform from conversation-based to per-message pricing. In 2026 that model is in full force: you are billed per delivered template message, by category and recipient country ([Meta pricing docs](https://developers.facebook.com/docs/whatsapp/pricing)). **Are service messages free in Europe?** Yes. Service conversations — your replies inside a customer-initiated 24-hour window — became free for all businesses on November 1, 2024, and remain free in 2026. Plain text and other non-template messages are free too. Only marketing, utility and authentication *templates* are charged. **Which category is most expensive in Europe?** Marketing, in every European market. Utility is well below it, and authentication is typically the cheapest. Germany has among the highest marketing rates in the world. **Does my business location set the rate, or the customer's?** The recipient's. Rates follow the recipient's phone-number country code, so messaging a German number costs the German rate even if your company is in Portugal. **Is the free WhatsApp Business app priced per message?** No. The downloadable WhatsApp Business app has no per-message fees. Per-message pricing applies only to the WhatsApp Business Platform / Cloud API, which you use through a BSP or an API-based tool. **Where do I find the exact current EUR rate for my country?** On Meta's official rate card at [developers.facebook.com/docs/whatsapp/pricing](https://developers.facebook.com/docs/whatsapp/pricing). Meta updates rates periodically, so confirm the live figure before budgeting — and remember to add your BSP's markup on top. --- # WhatsApp Web: Complete Guide to Login, Features & Fixes (2026) > Everything about WhatsApp Web in 2026: how to log in by QR, how linked devices work when your phone is off, the real fixes when it won't load, and what it can't do. URL: https://blueticks.co/blog/whatsapp-web-guide Published: 2026-06-16 Author: Daniel Roth Category: productivity If you spend your day at a keyboard, typing replies on your phone is the slow way to use WhatsApp. WhatsApp Web puts the same conversations on your computer screen, where a real keyboard and a wider window make everything faster. This guide covers how to use WhatsApp Web end to end: the QR-code login, how linked devices keep working when your phone is off, what the browser version can and can't do, the honest fixes when it stops working, and where it falls short for anyone who needs to schedule or automate messages. It is not a ranking page or a sales pitch. It is the guide we wish existed when someone first asks "how do I get my WhatsApp on my laptop?" ## What is WhatsApp Web and how does it work? WhatsApp Web is a browser companion for your phone's WhatsApp account, hosted at web.whatsapp.com. You open that address in a desktop browser, link it to your phone once, and your chats appear on the bigger screen. It mirrors the account already on your phone. It is not a separate account, a second number, or a fresh sign-up ([WhatsApp Help Center](https://faq.whatsapp.com/1317564962315842)). That single fact explains almost everything about how WhatsApp Web behaves. Because it is a mirror of one account, there is no new password and no new phone number to verify. Your messages, contacts, and groups are the same ones on your phone. A message you send from the laptop shows up in the same thread on your phone, and a reply you get on your phone shows up on the laptop. End-to-end encryption carries across the link, so the browser session is as private as the chat on your handset. The practical payoff is speed and comfort. You type on a full keyboard, paste links and files straight from your computer, drag images into a chat, and keep WhatsApp in a tab beside your email and work. For anyone who lives at a desk, learning **how to use WhatsApp Web** is the single biggest quality-of-life upgrade WhatsApp offers. It is the same app you already know, just on the screen you already work on. ## How do you log in to WhatsApp Web with a QR code? The **WhatsApp Web login** is a QR scan, not a username and password. You point your phone's camera at a code on your computer screen, and the two devices pair. Here is the exact flow. 1. On your computer, open **web.whatsapp.com** in a browser. A **WhatsApp Web QR code** appears on the page. 2. On your phone, open WhatsApp. Tap **Settings** (iPhone) or the three-dot menu (Android), then **Linked Devices**. 3. Tap **Link a Device**. Your phone's camera opens. 4. Point the phone at the QR code on your computer screen. When it reads the code, the browser loads your chats ([WhatsApp Help Center](https://faq.whatsapp.com/1317564962315842)). That is the whole login. There is no account creation step because **WhatsApp Web on desktop** is borrowing the identity already proven on your phone. The QR code is a one-time pairing handshake: it tells your phone "trust this browser," and after that the browser stays linked until you log it out or your phone goes inactive for too long. A few things make the scan smoother. Make sure your phone has an active internet connection at the moment you scan, because the pairing handshake needs it. Hold the phone steady, roughly the width of this paragraph away from the screen, and turn up your computer's brightness so the camera can read the code cleanly. If the page ever looks stuck, refreshing web.whatsapp.com generates a fresh code. [image: Hands holding a smartphone near a laptop at a desk while linking a device] ## How do linked devices and multi-device work (does WhatsApp Web work when your phone is off)? Yes, WhatsApp Web keeps working when your phone is off. This is the part of the system that confuses people, so it is worth being precise. Since WhatsApp rolled out its multi-device architecture, each linked device holds its own secure connection to WhatsApp rather than relaying everything through your phone in real time. Your phone no longer has to be awake and online for the web session to send and receive messages ([WhatsApp Help Center](https://faq.whatsapp.com/378279804439436)). Under the **WhatsApp Web linked devices** model, you can link up to four devices to one account at the same time, in addition to your primary phone. So a laptop at work, a desktop at home, a tablet, and a second computer can all stay paired together, each mirroring the same chats ([WhatsApp Help Center](https://faq.whatsapp.com/378279804439436)). There is one important limit. If your primary phone is not used for an extended period, the linked devices log out automatically. WhatsApp sets that inactivity window at **14 days**: leave your phone untouched for more than two weeks and your web sessions drop, and you will need to scan the QR code again to relink ([WhatsApp Help Center](https://faq.whatsapp.com/378279804439436)). This is a security feature, not a bug. It makes sure an abandoned web session somewhere cannot stay open indefinitely after a phone is lost or set aside. For day-to-day use it never triggers, because most people pick up their phone well inside two weeks. ## What can you do on WhatsApp Web? Features and limits vs the phone app WhatsApp Web covers the everyday messaging features and a good chunk of the rest, but it is not a full clone of the phone app. Here is the honest map of **WhatsApp Web features** versus what stays phone-only. What works well on the web: - Send and receive text messages, emoji, and reactions in one-on-one and group chats. - Share photos, videos, documents, and files, including drag-and-drop straight from your computer. - Send voice messages and listen to the ones you receive. - Create and manage groups, reply to specific messages, forward, star, search your chat history, and edit or delete messages. - View and post status updates. - Receive desktop notifications while the browser tab is open. Where the phone app still leads: - The phone remains the source of truth for your account and the only place you set it up or change your number. - Some account-level controls and settings live on the phone. - Browser notifications stop the moment you close the tab, whereas the phone keeps notifying you everywhere. For the overwhelming majority of conversations, **WhatsApp Web** does everything you need. The gaps that matter are not in everyday chatting. They show up when you want WhatsApp to do work for you on a schedule or at scale, which we get to below. [image: A person working comfortably at a laptop in soft window light] ## WhatsApp Web vs the WhatsApp app: which should you use? It is not really a choice between **WhatsApp Web vs the WhatsApp app**, because they are the same account on two screens. The better question is which screen fits the moment. The answer is simple: use whichever device you are already on. When you are working at a computer, WhatsApp Web wins on comfort. A physical keyboard makes you faster, the wider window lets you see more of a conversation, and copying links, files, and text between WhatsApp and your other work takes one motion instead of fiddling with a phone. If your job involves a lot of typed replies, the web version pays for itself in minutes saved every hour. When you are away from the desk, the phone app wins because it is the always-on device. It notifies you no matter where you are, it does not depend on a browser tab staying open, and it is the device that actually owns the account. WhatsApp Web did add one-to-one voice and video calling in 2023, so calls are no longer desktop-impossible — but the phone is still the more reliable choice for calling on the move. There is also a third option worth naming so the **WhatsApp Web download** question gets a clean answer. Alongside the browser version, WhatsApp offers a downloadable **WhatsApp Desktop** app for Windows and Mac. It is a separate program you install rather than a website you visit, and it links to your phone with the same QR scan. People who search for "WhatsApp Web download" often actually want this desktop app. The trade-off: the desktop app can feel a little more stable and keeps notifying you after you close it, while the browser version installs nothing and runs anywhere you have a browser. Functionally, for messaging, the two are close. ## Why is WhatsApp Web not working? QR won't scan, won't load, or keeps logging you out When **WhatsApp Web is not working**, the cause almost always falls into one of three buckets. Match your symptom and work the fix. **The QR code won't scan.** This is usually the phone camera or the code itself. Clean your phone's camera lens, raise your computer's screen brightness so the code is crisp, and hold the phone steady and square to the screen rather than at an angle. Make sure your phone has a working internet connection while you scan, because pairing needs it. If the code on screen has timed out, refresh web.whatsapp.com to generate a new one. And update WhatsApp on your phone, since an out-of-date app can fail to read newer codes. **The page won't load.** This is a browser or connection problem, not an account problem. Check that your computer has a stable internet connection. Reload the page. Try a different, supported browser to rule out an extension or setting blocking it. If it still hangs, clear your browser's cache and cookies for whatsapp.com, then reopen web.whatsapp.com and scan again. A blocked or stale browser cache is one of the most common reasons the page sits blank. **It keeps logging you out.** Three things cause repeated logouts. First, phone inactivity: if your primary phone has gone unused past the 14-day window, every linked session drops by design ([WhatsApp Help Center](https://faq.whatsapp.com/378279804439436)). Second, a manual logout: if the device was removed from your phone's **Linked Devices** screen, the web session ends. Open that screen on your phone to see exactly which devices are linked and remove any you do not recognize. Third, a poor or flaky connection on either device can break the secure link and force a re-scan. Steady internet on both ends keeps the session alive. None of these fixes are exotic. WhatsApp Web is a thin, well-behaved layer over your phone account, so when it breaks, the problem is almost always the camera, the browser, the connection, or the linked-devices list, in that order. ## What WhatsApp Web can't do natively (no scheduling, bulk sends, or auto-replies) Here is the gap most guides skip. WhatsApp Web is built for live, hands-on conversation. It is not built to do work for you when you are not there. Out of the box, **WhatsApp Web has no message scheduler, no bulk or broadcast-campaign tool, and no auto-replies.** There is no native "send this message at 9am tomorrow" button on WhatsApp Web. If you want a message to go out later, you either remember to type it at the right moment or you don't. There is also no built-in way to send one personalized message to a hundred contacts in a managed campaign with tracking. And the automated replies people associate with business WhatsApp, greeting messages, away messages, and quick replies, are features of the separate **WhatsApp Business app**, set up under its Business tools, not something WhatsApp Web offers ([WhatsApp Business](https://faq.whatsapp.com/647349420360876)). Even there, they live in the Business app on the phone, not in the web window. This is not a flaw so much as a scope decision. WhatsApp Web mirrors your conversations; it does not run your outreach. For a lot of people that is fine. But if you book reminders, follow up with clients, run a small store, or simply hate forgetting to send a birthday message, the missing scheduler is exactly the feature you reach for and can't find. That is the gap the next section fills. ## How to schedule and automate messages on WhatsApp Web with Blueticks Since WhatsApp Web has no native scheduler, the way to **schedule a message on WhatsApp Web** is to add a layer that does. Blueticks is a Chrome extension that installs on top of WhatsApp Web and adds the scheduling and automation the browser version leaves out. You keep using WhatsApp Web exactly as before; the extension adds the buttons WhatsApp didn't. Once it is installed, scheduling looks like this: you write a message in a chat the normal way, but instead of sending it now, you pick a date and time and queue it. The message fires at the moment you chose. You can set up recurring messages for things that repeat, like a weekly check-in or a monthly reminder, so you write it once and it goes out on its own. And for outreach to many contacts, it adds campaign-style sending with personalization, which native WhatsApp Web simply does not provide. For the full walkthrough of scheduling on the browser version, see our guide to [scheduling WhatsApp Web messages](https://blueticks.co/blog/schedule-whatsapp-web-messages), and for the broader picture of [how to schedule WhatsApp messages](https://blueticks.co/blog/schedule-whatsapp-messages) across use cases. To be precise about what this is: Blueticks does not change WhatsApp Web or give WhatsApp a feature it doesn't have. It is a separate tool that automates the actions you would otherwise do by hand, on the same account, through the same web session. You can see exactly how the scheduling works on the [Blueticks scheduler](https://blueticks.co/scheduler) page. [image: A relaxed person away from the desk while scheduled messages handle themselves] WhatsApp Web can't schedule, bulk-send, or auto-reply on its own. Add Blueticks, a Chrome extension that lets you schedule and automate WhatsApp Web messages in a few clicks, and the one thing the browser version is missing stops being your problem. [Start scheduling on WhatsApp Web with Blueticks](https://blueticks.co/scheduler) ## WhatsApp Web FAQ **Does WhatsApp Web work when my phone is off?** Yes. Thanks to WhatsApp's multi-device system, linked devices hold their own connection and keep sending and receiving even when your phone is off or offline. The one catch: if your phone goes completely unused for more than 14 days, the linked sessions log out and you have to scan the QR code again ([WhatsApp Help Center](https://faq.whatsapp.com/378279804439436)). **How many devices can I link to WhatsApp Web?** Up to four linked devices at the same time, in addition to your primary phone. So several computers and a tablet can mirror the same account at once ([WhatsApp Help Center](https://faq.whatsapp.com/378279804439436)). **Is WhatsApp Web a separate account or number?** No. WhatsApp Web mirrors the account already on your phone. There is no new number, no new password, and no separate sign-up, which is why the login is just a QR scan ([WhatsApp Help Center](https://faq.whatsapp.com/1317564962315842)). **What's the difference between WhatsApp Web and WhatsApp Desktop?** WhatsApp Web runs in a browser at web.whatsapp.com with nothing to install. WhatsApp Desktop is a downloadable app for Windows and Mac that you install and then link with the same QR scan. People searching "WhatsApp Web download" usually want the desktop app. For messaging, the two are very similar. **Can I schedule messages on WhatsApp Web?** Not with WhatsApp Web alone, because it has no native scheduler. To schedule a message on WhatsApp Web you add a tool like the Blueticks Chrome extension, which lets you pick a send time, set recurring messages, and run personalized campaigns on top of your existing web session. **Why does WhatsApp Web keep logging me out?** The usual causes are phone inactivity past the 14-day window, the device being removed from your phone's Linked Devices list, or an unstable internet connection breaking the secure link. Check Linked Devices on your phone first, then your connection ([WhatsApp Help Center](https://faq.whatsapp.com/378279804439436)). --- # WhatsApp Campaign Analytics: The Metrics That Actually Matter (2026 Guide) > Open rate is the wrong place to start. Here's what WhatsApp actually measures versus what you have to instrument yourself — and the four metrics that tell you whether a campaign worked. URL: https://blueticks.co/blog/whatsapp-campaign-analytics-metrics-that-matter Published: 2026-06-15 Author: Maya Cohen Category: marketing You sent the campaign. A few hundred recipients, a sharp offer, a link. Now the only honest question that matters: did it work? Most people answer with a gut feel or a borrowed stat ("WhatsApp gets 98% open rates!") they can't actually see in their own account. That gap — between the number you wish you had and the number WhatsApp will actually show you — is the subject of this guide. Get precise about what's measured, what's inferred, and what you instrument yourself, and you stop guessing. ## What Is WhatsApp Campaign Analytics (And Why Open Rate Isn't Enough)? **WhatsApp campaign analytics** is the practice of measuring how a batch of outbound messages — a broadcast or marketing send — actually performed: how many were delivered, how many were read, how many people replied, and how many took the action you wanted. It's the difference between "I sent it" and "here's what it earned." The trap most people fall into is borrowing email vocabulary and stopping at "open rate." On WhatsApp there's no "open" event in the email sense, and the headline benchmark everyone repeats — that near-universal open figure — is widely cited but rarely traceable to a primary source. More importantly, a read receipt isn't a result. A message can be read by everyone and earn nothing. The read number feels great, but it's the top of the funnel, not the bottom. A useful framing: a read receipt tells you a message was seen. **WhatsApp campaign analytics** tells you whether that batch moved anyone toward a sale, a booking, or a reply. Only the second question pays the bills. There's also a structural surprise waiting for most small businesses: WhatsApp does *not* hand you a campaign dashboard out of the box. What it natively reports is far thinner than the analytics culture around it assumes. Knowing where that wall is — and what lives on the other side — separates measuring your **whatsapp marketing campaign** from hoping it went well. (Before you measure a send, it has to be worth measuring — see our guide to [WhatsApp campaign templates that convert](https://blueticks.co/blog/whatsapp-campaign-templates-that-convert) for the "what to send" side.) ## Which WhatsApp Campaign Metrics Actually Matter? Strip away the vanity numbers and four metrics carry almost all the signal. Read them as a funnel — each one filters the last. - **Delivery rate.** Of the messages you sent, how many actually reached a device. This is your list-health and deliverability check. A sagging **whatsapp delivery rate** usually means bad numbers, blocks, or formatting/template problems — not a weak offer. - **Read rate.** Of the delivered messages, how many were opened. Your **whatsapp read rate** measures whether your timing, sender identity, and first line earned attention. Important caveat we'll return to: read data depends on recipients having read receipts turned on. - **Reply rate.** Of the people who read it, how many wrote back. On a conversational channel this is the truest early engagement signal — far more meaningful than a read. A healthy **whatsapp reply rate** says your message invited a response, not just a glance. - **Conversion rate.** Of everyone you reached, how many did the thing — clicked through, bought, booked, replied with the keyword. This is the only metric that connects a campaign to money, and the only one WhatsApp can't measure for you. Two numbers that *don't* belong at the top: raw "messages sent" (a budget figure, not a performance one) and read count in isolation (impressive and inert). When you evaluate **whatsapp campaign results**, walk the funnel — delivered, read, replied, converted — and find where it leaks. The leak tells you what to fix. [image: Close-up of a hand sketching a simple top-to-bottom funnel diagram in a paper notebook with a pen] ## How Do You Measure Delivery and Read Rates on WhatsApp? Here's where the native picture matters, because delivery and read are the two metrics WhatsApp *does* expose — just at very different depths depending on how you're sending. **On the free WhatsApp Business app: per-message ticks plus a basic Statistics screen.** Every chat shows the familiar ticks — one tick sent, two ticks delivered, two blue ticks read. At the account level, the app has a Statistics view (Business tools → Statistics) reporting aggregate counts: **messages sent, delivered, read, and received.** That's the full extent — four running totals across all your messaging, not broken down by campaign, link, or segment, and with no conversion data. **Broadcast lists give you even less than people assume.** A broadcast list shows per-recipient ticks, so you can eyeball delivered and read individually — but there's no campaign-level rollup, no read *rate*, no click tracking, no opt-out tracking, and no trend. If you run a **whatsapp broadcast campaign** from the free app, "analytics" means counting blue ticks by hand. That doesn't scale. **On the WhatsApp Business Platform (Cloud API), you get real, structured status data.** The API emits per-message **status webhooks** with four values — `sent`, `delivered`, `read`, and `failed` — so any connected platform can compute delivery and read rates across an entire send. On top of that, Meta's **WhatsApp Manager** provides analytics views: messaging analytics (counts and types of messages sent and delivered), template analytics (sent / delivered / read per template, plus button-click counts), and pricing/conversation analytics. A genuine reporting layer — but it lives behind the API, not in the phone app. One honesty check that trips up every dashboard: **read rate is only as complete as read receipts allow.** Recipients can disable read receipts, and when they do, their reads aren't reported. So a "read rate" — native or via a tool — is a floor, not an exact truth. (For the same reason, never tell a customer their specific message was definitely read.) ## How Do You Track Reply Rate and What Counts as a Good One? Reply rate is the metric WhatsApp is *built* for and the one it makes you assemble yourself. There's no native "reply rate" field anywhere — not in the app's Statistics, not in WhatsApp Manager. You get it by counting replies received against messages delivered (or read) for a given send: either by hand, or with **whatsapp campaign software** that attributes inbound replies back to the campaign that prompted them. What counts as good? Be skeptical of universal benchmarks — reply rate swings hard with list quality, offer, and how conversational the message is. A transactional "your order shipped" earns few replies, and that's fine. A "reply YES to claim your spot" is engineered for replies and should pull much higher. The right benchmark is *your own last campaign to a similar list*, not a vendor-blog number. A few levers that reliably move **whatsapp reply rate**: - **Ask a question or give a one-word reply path** ("Reply 1 for morning, 2 for evening"). Open-ended "let us know!" underperforms a clear prompt. - **Send to a warm, opted-in list.** Reply rate is downstream of consent — people who asked to hear from you answer; cold contacts block. This is why your list-building method matters more than your copy; see our [WhatsApp opt-in collection guide](https://blueticks.co/blog/whatsapp-opt-in-collection-guide) for building the list you actually campaign to. - **Time it for when people can respond**, not just when they'll see it. A read at midnight rarely converts to a reply. The strategic point: because reply rate isn't handed to you, the only way to track it consistently is to instrument it. Counting blue ticks won't surface "12 of 80 readers wrote back" — a tool that ties inbound messages to the outbound campaign will. ## How Do You Track Conversions From a WhatsApp Campaign? (UTMs + Link Tracking) Here's the hard truth that no native WhatsApp surface will solve for you: **WhatsApp does not natively attribute conversions.** It can tell you a message was delivered and read; it cannot tell you that the read led to a purchase. **WhatsApp campaign conversion tracking** is something you build, every time, with two pieces of instrumentation. **1. UTM parameters on every link.** Tag the URL in your message so your analytics tool knows the click came from this specific send. A clean pattern: `https://yourstore.com/sale?utm_source=whatsapp&utm_medium=broadcast&utm_campaign=june-flash-sale` When that visitor lands and buys, Google Analytics (or whatever you use) attributes the conversion to `whatsapp / broadcast / june-flash-sale`. No UTMs, no attribution — the traffic just shows up as "direct" and the campaign gets no credit. [image: A person planning campaign links in a notebook beside a closed laptop and phone on a desk] **2. Link/click tracking.** UTMs tell your *site* analytics where a visitor came from; a click-tracking layer (a tracked link, or analytics inside your campaign tool) tells you how many people clicked in the first place — the step between "read" and "converted." Together they let you compute click-through rate and then conversion rate, closing the funnel. For richer setups, the Cloud API can report template button-click counts (in WhatsApp Manager's template analytics) and you can pass campaign identifiers through to your CRM. But the principle is the same at every scale: **conversions are inferred from instrumentation you add, never reported by WhatsApp itself.** Any tool or guide claiming WhatsApp "shows you conversions" natively is wrong. A good tool makes the instrumentation automatic — stamping UTMs, tracking clicks, tying it back to the send — so you're not hand-building tracked links every time. ## Can the WhatsApp Business App Show Campaign Analytics? (What's Built In vs. What Needs a Tool) Short answer: **no — the WhatsApp Business app has no campaign analytics.** This is the single most over-promised thing in the WhatsApp marketing space, so let's be exact about the line between built-in and tool-required. **What's genuinely built into the free Business app:** - Per-message ticks (sent / delivered / read) in each chat. - An aggregate **Statistics** screen: total messages sent, delivered, read, and received — running totals only. - Basic per-recipient ticks within a broadcast list. **What is NOT in the app, at all:** - Per-campaign reporting (no "this broadcast got X% read"). - Read *rate*, reply *rate*, or conversion *rate* as computed metrics. - Click tracking, UTM-aware attribution, or any conversion data. - Historical trends, segmentation, or comparison between sends. **What the WhatsApp Business Platform (Cloud API) adds:** structured per-message status (`sent`/`delivered`/`read`/`failed`) via webhooks, plus WhatsApp Manager's messaging, template, and pricing/conversation analytics. That's a real reporting layer — but it requires going through the API (typically via a provider), and it still doesn't do conversion attribution for you; you instrument that yourself. The practical reality: the free app gives you ticks and totals; the API gives you status data and Meta-side dashboards; **neither gives you reply rate or conversions on a plate.** True **how to measure whatsapp campaign performance** at the campaign level — delivery, read, reply, *and* conversion in one place, per send — comes from a layer on top. (And while we're listing gaps: the app has no native message scheduler either. Its automation is limited to greeting messages, away messages, and quick replies — auto-replies, not scheduled campaigns.) ## What Should You Iterate On After Reading Your Campaign Data? Data is only worth collecting if it changes the next send. Map each funnel leak to a fix: - **Low delivery rate?** It's a list problem, not a copy problem. Clean invalid numbers, confirm opt-in, and check for blocks or template-formatting rejections before you touch the message. - **Good delivery, low read rate?** Attention problem. Test send time, tighten the first line (it's the preview people decide on), and make sure the sender identity is recognizable. Remember the read-receipt caveat — some "unread" are just receipts-off, so don't over-correct on a single weak read number. - **Read but no replies?** Engagement problem. Add a clear reply prompt, make the ask smaller, or segment so the offer actually fits the recipient. - **Clicks but no conversions?** Landing problem. The message did its job; the page or offer didn't. Fix the destination, not the broadcast. The discipline that compounds: change **one variable at a time** and compare against your own baseline. Send time, opening line, offer, CTA — vary one, measure the same four metrics, keep what wins. Over a few cycles you build a benchmark true for *your* list, which beats any published average. That loop — send, read the funnel, change one thing, send again — is the whole game. ## Measure and Improve Your WhatsApp Campaigns With Blueticks Everything above is tool-agnostic and true: WhatsApp gives you ticks and totals natively, the API gives you status data and Meta-side dashboards, and reply rate plus conversions are yours to instrument. The work is stitching those into one per-campaign view so you can see the funnel. That's what Blueticks does on top of your existing WhatsApp. It tracks **delivery, read, and reply rates per campaign** — not aggregate totals across everything — and helps you tie sends to conversions with link tracking, so the four metrics that matter live in one place instead of in your head. You schedule and run **whatsapp broadcast campaign** sends from one dashboard, then read the results per send and iterate. You can see the [scheduler here](https://blueticks.co/scheduler). The point isn't a prettier dashboard. It's closing the loop: send, measure what actually happened, change one thing, send better — instead of blasting messages and counting blue ticks by hand. [image: Two coworkers at a desk reviewing notes together, a closed laptop between them, relaxed and mid-discussion] **Stop guessing whether your campaigns worked. Blueticks tracks delivery, read, and reply rates per campaign and ties them to conversions — so you measure what matters and improve every send. [Start free](https://blueticks.co/scheduler).** ## Frequently Asked Questions **Does the WhatsApp Business app show campaign analytics?** No. The free WhatsApp Business app shows per-message ticks (sent, delivered, read) and an aggregate Statistics screen with running totals of messages sent, delivered, read, and received. It has no per-campaign reporting, no read/reply/conversion *rates*, no click tracking, and no historical trends. Campaign-level analytics require the WhatsApp Business Platform (Cloud API) and/or a campaign tool on top. **What does WhatsApp natively measure versus what do I have to add?** Natively, WhatsApp reports message status: sent, delivered, read, and failed (per-message via the Cloud API's status webhooks; as aggregate counts and ticks in the app). You have to add everything else yourself — reply rate (count replies against the send), and conversions (UTM parameters plus link/click tracking, attributed in your own analytics or CRM). WhatsApp does not natively attribute conversions. **What's a good WhatsApp delivery rate, read rate, and reply rate?** Delivery should be high on a clean, opted-in list — low delivery points to bad numbers or blocks. Read rates on opted-in marketing tend to be strong (one widely referenced figure from Braze is around a 68% average read rate on opted-in marketing messages), but read data only counts recipients who have read receipts enabled, so treat it as a floor. Reply rate varies too much for a universal benchmark — measure against your own previous campaign to a similar list. **How do I track conversions from a WhatsApp campaign?** Add UTM parameters to every link in the message (e.g. `utm_source=whatsapp&utm_medium=broadcast&utm_campaign=...`) so your web analytics can attribute clicks and sales to that send, and use link/click tracking to capture click-through rate. WhatsApp itself can't tell you a read led to a purchase — conversion tracking is always instrumentation you add. **Can I see analytics for a WhatsApp broadcast list?** Only minimally. A broadcast list in the free app shows per-recipient ticks (delivered, read), but no campaign-level rollup, no read or click rate, no opt-out tracking, and no trends. For real **whatsapp broadcast campaign** analytics you need the API or a campaign tool. **Is the often-quoted "98% WhatsApp open rate" reliable?** Treat it with caution — it's repeated widely but rarely traced to a primary source. More defensible benchmarks for opted-in marketing read rates sit lower (around the high-60s percent in Braze's data), and even those only count recipients with read receipts on. Anchor on your own measured rates. --- Stop counting blue ticks by hand. Run your **whatsapp marketing campaign**, measure delivery, read, and reply per send, and tie it to conversions — all in one place with Blueticks. [Start free](https://blueticks.co/scheduler). --- # WhatsApp Business With Two Numbers on One Phone: What Actually Works (2026) > You can run two WhatsApp numbers on one phone — but not the way most guides claim. Here's what the app actually allows, where companion mode and linked devices fit, and when you really need the API. URL: https://blueticks.co/blog/whatsapp-business-multiple-numbers-one-phone Published: 2026-06-14 Author: Daniel Roth Category: productivity You have one phone and you want two WhatsApp Business numbers on it — maybe a storefront line and a wholesale line, or your own number plus the business. Search this and you'll get a pile of confident, contradictory advice, half of it describing features that don't exist. So let's be precise. There is exactly one rule that governs everything here, and once you understand it, every "trick" sorts itself into "works," "works but isn't what you think," or "you've outgrown the app entirely." ## Can you run two WhatsApp Business numbers on one phone? Short answer: not inside a single WhatsApp Business app the way you might hope, but yes, you can have two WhatsApp numbers active on one phone using legitimate, supported methods. The catch is the governing rule of the entire platform: **one phone number equals one WhatsApp account.** A single number can never be registered to two accounts, and a single WhatsApp Business app instance is tied to one number. So when someone asks for **whatsapp business two numbers one phone**, what they actually want is one of three different things, each with a different answer: - **Two separate numbers, both reachable on one handset** — yes, doable (WhatsApp + WhatsApp Business, dual-SIM, or app cloning). - **One business account I can use across my phone and my laptop** — yes, that's linked devices, not a second number. - **One business number my whole team answers** — that's the API, and the app can't do it. Everything below is just those three cases spelled out, with the limits verified against WhatsApp's own documentation so you don't build on a feature that was never real. If your endgame is many numbers or many agents, skip ahead — but read the first sections so you know exactly where the app wall is. ## WhatsApp Business: one account per phone number (what the app actually allows) The WhatsApp Business app is built around a single business identity. You install it, you verify it with one phone number, and that number is the account. There is no menu inside the standard Business app for "add a second business number" that spins up an independent second account — the app does not natively run multiple numbers in one install. This is the fact that most "manage 5 numbers from your phone" headlines quietly skip over. So the honest answer to **can i have two whatsapp business accounts** on one phone is: yes, but each one needs its own phone number and, on most devices, its own app instance or account slot. They are genuinely separate accounts, not two profiles inside one app. What WhatsApp *did* add recently is a native **multi-account** (account switching) feature, and it's worth being exact about it because it's easy to overstate. The feature lets you add a second account and switch between them inside one app via Settings, currently capped at two accounts for most users, and **each account still requires its own unique phone number.** It rolled out on Android first and later on iPhone. That's real account switching — but notice it does not break the one-number-one-account rule. It's a convenience layer over two distinct numbers, not a way to run two accounts on one number. One more thing the app does not have, because it gets conflated with "managing numbers": there is no native message scheduler in the WhatsApp Business app. The app's automation is limited to a **greeting message**, an **away message**, and **quick replies** — those are auto-replies and saved snippets, not a "send this at 9am Tuesday" scheduler. If real scheduling is part of why you want better number management, that's a tool job, not an app setting. (More on that below, and in our guide to [scheduling WhatsApp Business messages](https://blueticks.co/blog/schedule-whatsapp-business-messages).) ## Linked devices and companion mode: one account on up to 4 devices — not multiple numbers This is where most confusion lives, so read it slowly: linked devices let you use **one** WhatsApp account on more than one device at the same time. It does not add a number. It adds *screens* for the same number. The **whatsapp business linked devices limit** is four linked devices in addition to your primary phone. So one account runs on your main phone plus up to four companions — a laptop on WhatsApp Web, a desktop app, a tablet, and a second phone, all showing the same chats for the same number. The primary phone is separate from the count of four; it's not one of the four slots. [image: An open laptop and a phone face-down on a tidy desk, suggesting one account used across multiple devices] **Companion mode** is the part people misread. **whatsapp business companion mode** lets you add a *second phone* as one of those linked devices — so you can answer the same business account from two phones at once, no SIM swap, no browser. That sounds like "two numbers on one phone," but it's the exact opposite: it's **one** number on **two** phones. Same account, same inbox, mirrored. It's brilliant for a two-person shop sharing one line, and useless if what you needed was a second, independent number. Two operational limits worth knowing before you lean on linked devices: - **Independent sync, but a leash.** Linked devices send and receive on their own without the primary phone being online — but if the primary phone stays offline for about 14 days, all linked devices get logged out. The account still lives on the phone. - **It's mirroring, not multiplexing.** Every linked device sees every chat. There's no per-agent routing, no "this rep only sees their conversations." For that you need the API. Bottom line on this section: linked devices and companion mode solve "I need this number in more than one place." They never solve "I need more than one number." ## How to get two numbers on one phone: WhatsApp + WhatsApp Business, dual-SIM, and dual-app Now the practical part. Here are the genuinely working ways to have two WhatsApp numbers live on a single handset, cleanest first. [image: Close-up of a hand holding a phone's open SIM tray with two SIM card slots on a desk] **1. WhatsApp + WhatsApp Business (the standard combo).** The standard WhatsApp app and the WhatsApp Business app are two separate apps. Install both, register each with a *different* phone number, and you've got two numbers on one phone — personal on standard WhatsApp, business on WhatsApp Business. This is the most stable, fully supported method and works on both Android and iPhone. To **switch between whatsapp business and personal**, you just switch apps (or use the native account switcher if your region has it). Most small operators should stop here; it's all they need. **2. Native multi-account switching (two numbers, one app).** If your device and region have the Add Account option (Settings → Account), you can register a second number and toggle between accounts inside one app — currently up to two accounts, each with its own number. Same end result as the two-app method, fewer icons. **3. Dual-SIM.** Two SIMs (or a SIM + eSIM) give you two phone numbers on one device at the OS level. WhatsApp doesn't "see" the second SIM as a second account automatically — you still register each WhatsApp/WhatsApp Business install with one of those numbers. Dual-SIM is what *supplies* the second number; the app methods above are what *use* it. **4. App cloning / dual-app (Android, vendor-dependent).** Many Android skins (Samsung's Dual Messenger, Xiaomi's Dual Apps, etc.) can clone an app so a second copy of WhatsApp Business runs with a second number. This is an OS feature, not a WhatsApp feature — reliability depends entirely on your phone maker, and iPhone doesn't offer it. Treat it as a last resort, not a foundation. Be honest with yourself about what these are: **none of them is a WhatsApp multi-number feature.** They're device and OS tricks that supply extra numbers, plus WhatsApp's one-account-per-number rule applied twice. They top out fast — two numbers comfortably, maybe three on a cooperative Android. The moment you're juggling more than that, or more than one person needs to answer, you've hit the wall. ## When multiple numbers really needs the WhatsApp Business API Here's the upgrade trigger, stated plainly: the app — every method above — gives **one person, one device-set, per number.** The moment you need *multiple people answering one business number*, or you're running *many* numbers at real volume, you need the **WhatsApp Business Platform (Cloud API)**. The difference between **whatsapp business api vs whatsapp business app** is not "bigger app." The API isn't an app you download to a phone at all — it's a programmatic connection. Once a number is on the API, messages stop arriving in the phone app and instead flow into whatever platform you've connected it to. Meta positions the Cloud API explicitly for medium and large businesses that need to "communicate with customers at scale" and connect customers with "agents or bots." That's the line: the app is for one operator per number; the API is built for teams and automation on a number. [image: Two coworkers at a shop counter, one holding a phone face-down, suggesting a shared business line] What the API unlocks that the app structurally cannot: - **Many agents on one number.** Unlike the app, the API has no practical limit on how many users share a single business number — 5, 20, 50 reps can all work the same line, each with their own login, each routed only the conversations that are theirs. This is the single biggest reason businesses migrate. - **True automation and integration.** Programmatic sending, CRM and helpdesk integration, chatbots, and broadcast at scale via approved message templates. - **Multiple numbers under one account, managed centrally** — rather than a drawer of phones. The trade-offs are real, so don't jump early: the API requires going through a Business Solution Provider (or Meta Cloud API directly), it uses a pricing model based on conversations/messages rather than being free like the app, and outbound business-initiated messages must use pre-approved templates. For what that costs in practice, see our [WhatsApp Business API pricing breakdown for 2026](https://blueticks.co/blog/whatsapp-business-api-pricing-2026). The rule of thumb: stay on the app while you're one or two people; move to the API when a single number needs a *team* or you're scaling sends. ## How to manage multiple WhatsApp Business numbers without losing track Whether you've got two app-based numbers or a fleet on the API, the operational problem is the same: more numbers means more places to forget a follow-up, more inconsistency in what each line sends, and no native way to schedule anything. The app can't schedule, and switching between two or three accounts all day is exactly how a reminder slips. This is where a layer on top earns its keep. To **manage multiple whatsapp business numbers** sanely, you want three things the native app doesn't give you: - **Scheduling**, so a message goes out at the right local time without you sitting there at 9am — the thing the Business app simply does not do natively. - **One place to run campaigns and follow-ups across numbers**, instead of thumb-switching between accounts and hoping you sent the wholesale promo from the wholesale line. - **Consistency and a record**, so the same well-worded reply, reminder, or campaign goes out reliably regardless of which number it's for. Blueticks runs on top of WhatsApp Web, which means it works with your existing WhatsApp/WhatsApp Business setup — you schedule messages, build recurring reminders, and run campaigns from one dashboard rather than living inside the phone app. If you're at the stage of coordinating more than one number, that's the difference between "I think I followed up with everyone" and knowing you did. You can see the [scheduler here](https://blueticks.co/scheduler). A quick reality check before you over-engineer: if you genuinely only have two numbers and a low volume, the two-app method plus a scheduling tool is plenty. Reach for the API and a full platform when the *team* or the *volume* — not just the number count — demands it. ## FAQ: multiple WhatsApp Business numbers, accounts, and devices **Can I have two WhatsApp Business numbers on one phone?** Yes, using supported methods: run the standard WhatsApp app and the WhatsApp Business app with two different numbers, use WhatsApp's native account switcher (where available, up to two accounts), use dual-SIM, or use your Android phone's app-cloning feature. Each number needs its own unique phone number — one number can only ever be one account. The WhatsApp Business app does not natively run two independent numbers in a single install. **Can I have two WhatsApp Business accounts at the same time?** Yes, but each account requires its own phone number and, in most cases, its own app instance or account slot. They're fully separate accounts with separate chats and settings — not two profiles under one number. WhatsApp's native multi-account feature lets you switch between accounts inside one app, but it's currently capped at two and each still needs a distinct number. **What is the WhatsApp Business linked devices limit?** Four linked devices in addition to your primary phone. So one account can run on your main phone plus up to four companions (laptop, desktop, tablet, second phone) at once. Linked devices share the *same* number — this is multi-device, not multi-number. If the primary phone stays offline for about 14 days, linked devices are logged out. **What is companion mode and does it give me a second number?** No. Companion mode lets you add a second *phone* as a linked device on the same WhatsApp account, so two phones answer one number — without a SIM swap or browser. It's one number on two phones, which is the opposite of two numbers on one phone. Great for sharing a single line; not a way to add a number. **How do I switch between WhatsApp Business and personal on one phone?** Run them as two apps (standard WhatsApp for personal, WhatsApp Business for business) and switch apps, or use WhatsApp's native account switcher in Settings if it's available in your region — each account keeps its own number, chats, and notifications. **When do I need the WhatsApp Business API instead of the app?** When more than one person needs to answer the same business number, or when you're running many numbers at real volume with automation. The app gives one operator per number; the WhatsApp Business Platform (Cloud API) lets multiple agents share one number, supports chatbots and CRM integration, and is built for scale — at the cost of going through a provider and paying per conversation. **Does the WhatsApp Business app have a built-in message scheduler?** No. Its automation is limited to a greeting message, an away message, and quick replies — those are auto-replies and saved snippets, not scheduled sends. To schedule WhatsApp messages, use a tool that runs on WhatsApp Web, such as Blueticks. --- Managing more than one WhatsApp Business number? Schedule and run campaigns across your numbers from one place with Blueticks — [start free](https://blueticks.co/scheduler). --- # How to Build a WhatsApp Opt-In Widget: Placement, Consent Wording, and Where Contacts Land > A click-to-chat button is not a marketing opt-in. Here's how to build a compliant WhatsApp opt-in widget: placement, the exact consent sentence, single vs double opt-in, and where the contact lands. URL: https://blueticks.co/blog/whatsapp-opt-in-widget Published: 2026-06-13 Author: Maya Cohen Category: marketing You added a green WhatsApp button to your site, people tap it, and you think you're building a list. You're not. A click-to-chat button opens a conversation; it does not give you permission to send a marketing campaign next week. Send one anyway and you're feeding blocks into your quality rating until Meta throttles you. This guide is about the widget that actually captures consent: where it goes, the exact sentence it shows, what happens after submit, and how to prove the consent is real. If you want the wide view of every opt-in channel that exists (checkout, QR, CTWA, IVR), read the [WhatsApp opt-in collection guide](https://blueticks.co/blog/whatsapp-opt-in-collection-guide) first. This piece goes deep on one thing: building the widget itself. ## What is a WhatsApp opt-in widget (and how is it different from a click-to-chat button)? A WhatsApp opt-in widget is a form element that captures a person's phone number plus their explicit, recorded agreement to receive WhatsApp messages from your business. A click-to-chat button (a wa.me link) just opens a chat. The difference is consent: the widget produces a permission record you can act on, the button produces a conversation that expires. This distinction is the whole ballgame, and it trips up most businesses. Meta's WhatsApp Business Messaging Policy is blunt: "You may only contact people on WhatsApp if (a) they have given you their mobile phone number; and (b) you have received opt-in permission from the recipient confirming that they wish to receive subsequent messages or calls from you." A wa.me click satisfies neither cleanly. The person never handed you their number through that flow, and "I tapped a button to ask a question" is not "I agree to receive your promotions." Here is the trap with **whatsapp click to chat opt in** logic: when a user taps your wa.me link and sends a message, that opens a messaging window (24 hours for a normal service chat, 72 hours when the entry point is a Click-to-WhatsApp ad). Inside that window you can reply freely. But the window is a session, not a subscription. When it closes, you need a pre-approved template and you need opt-in to send a business-initiated message. The click bought you a conversation, not a contact. | | Click-to-chat button (wa.me) | Opt-in widget | |---|---|---| | Captures the phone number | No (until they message you) | Yes | | Records explicit consent | No | Yes | | Lets you send marketing later | No | Yes, with opt-out | | What it produces | A 24h/72h session | A durable list contact | So the widget is not a fancier button. It is a different mechanism with a different output: a consented contact you can legally and safely market to. ## Where should you place the opt-in widget on your site? Place the opt-in widget where intent is already high: the cart and checkout, the post-purchase thank-you page, and a non-intrusive site-wide slot like a footer block or a delayed slide-in. Avoid an on-load popup that fires before the visitor reads a word. Trigger on intent (scroll depth, exit, or post-action), not on arrival. The placement decision is really a timing decision. A **whatsapp signup widget** that interrupts someone three seconds into their first visit converts badly and annoys everyone. The same widget shown after they add to cart, or right after they buy, converts several times higher because the value is obvious in that moment ("get your order updates on WhatsApp"). Concrete placement rules that hold up: - **Checkout, next to the phone field.** The warmest moment on the whole site. They already typed a number; a single unchecked consent box here is the highest-yield slot. - **Thank-you page.** Peak trust, zero friction. The order is done, so the ask is service-first: "Track this order on WhatsApp." - **Delayed slide-in, 8 to 12 seconds or on exit-intent.** For top-of-funnel visitors with no purchase yet. Lead with a reason (early access, restock alerts), not "subscribe." - **Footer or a dedicated `/whatsapp` landing page.** Always-available, never interruptive. Good for paid traffic where you want one focused **whatsapp opt in form** and no competing CTAs. One rule from the data: do not stack the widget on top of an aggressive email popup. Two consent modals fighting for the same visitor halves both. Pick the channel that matches the page and let it breathe. For the broader menu of where opt-ins come from beyond your own site, the [collection guide](https://blueticks.co/blog/whatsapp-opt-in-collection-guide) maps nine channels with benchmark conversion rates per channel. [image: Small shop owner behind a counter holding a phone face-down, products softly blurred behind] ## What consent wording must the widget show to be Meta-compliant? A compliant opt-in must do four things at once: name your business, state clearly that the person is agreeing to receive WhatsApp messages from you, describe what kind of messages, and tell them how to stop. Per Meta's WhatsApp Business Platform opt-in guidance, you must "specify the business name and the types of messages," collect consent "before sending any proactive message," and inform users "they can opt out at any time." Vague wording is the most common way a widget quietly fails. "Get updates" names no business, no channel, no message type. Here is **whatsapp opt in consent wording** that satisfies all four requirements in one sentence: > "By submitting, you agree to receive WhatsApp messages (order updates and occasional offers) from Acme Coffee. Message frequency varies. Reply STOP to opt out." Break down why each clause is load-bearing: - **"WhatsApp messages"** — Meta requires the channel named explicitly. "Text updates" or "mobile alerts" does not count. The word WhatsApp has to appear. - **"from Acme Coffee"** — your exact business name, the same name people will see as the sender. Meta's rule is that the user clearly agrees to receive messages *from your business*, so the business has to be identified at the point of consent. - **"order updates and occasional offers"** — the message types. If you'll send promotions, say so here; you cannot collect a service-only opt-in and then market against it. - **"Reply STOP to opt out"** — the opt-out path, stated up front, not buried later. Three things that disqualify the consent regardless of wording: a **pre-checked box** (consent must be an active choice, and a pre-ticked box is invalid under both Meta policy and GDPR), **bundled consent** (rolling WhatsApp permission into "I accept the Terms" violates the requirement that it be a specific, standalone agreement), and **displaying a number with no agreement step** — Meta states plainly that "displaying a WhatsApp number alone does not count as opt-in." The checkbox starts unchecked, the consent is its own action, and the sentence above sits right next to it. ## Should you use single or double opt-in confirmation? Single opt-in adds the contact the moment they submit a compliant form. Double opt-in (DOI) adds a second step: you send a confirmation message and the contact is only active after they reply YES. Meta does not globally mandate double opt-in, but DOI protects your deliverability and quality rating, and it is effectively required under GDPR in markets like Germany and Austria. The case for DOI is not legal box-ticking, it is number health. Your WhatsApp sender has a quality rating that Meta computes largely from how recipients react: blocks and "report" taps drag it down, and a low rating throttles or pauses your sends. A double opt-in filters out fat-fingered numbers, bots, and half-interested submitters before they ever get a marketing message and block you. You trade a little list volume for a much cleaner, higher-engagement list. How the DOI flow runs: 1. The visitor submits your widget (phone number plus the consent box). 2. You send one confirmation template: "Reply YES to confirm you want WhatsApp updates from Acme Coffee. Reply STOP to cancel." 3. On YES, the contact flips to active. No reply within a few days, archive them. The drop-off is smaller than marketers fear. The honest throughline of this whole article: a smaller consented list outperforms a bigger half-consented one on every metric that matters, because deliverability and quality rating are downstream of consent quality. Use DOI for any list you'll market to at frequency. Single opt-in is fine for pure transactional/service updates where intent is unambiguous (someone who just bought and ticked "send my order status on WhatsApp"). [image: Customer at a cafe counter giving their phone number to sign up, phone face-down on the wood surface] ## Where does the captured contact actually land (your list / CRM)? When someone submits the widget, the contact should land in a structured list with three fields recorded: the phone number in international format, a consent timestamp, and the source. That record is your proof of consent. Where it physically lives (a CRM, a spreadsheet, or a Blueticks audience) matters less than capturing those three fields and keeping them queryable. A submit that just opens a wa.me link and forgets the person is not list-building, it is a dead end. The point of the widget is the durable record. Capture, at minimum: - **Phone number**, E.164 international format (`+14155551234`), validated client-side so you don't store junk. - **Consent timestamp**, ISO 8601. When a recipient disputes that they opted in, or Meta asks, this is what you produce. - **Source tag** (checkout, footer, `/whatsapp` page) so you can segment by where consent came from. A checkout opt-in behaves very differently from a cold popup opt-in; tag them apart from day one. From there the contact needs to flow somewhere you can actually send from. You can post it to your CRM via webhook, or land it directly in a managed list. Our [WhatsApp opt-in collection guide](https://blueticks.co/blog/whatsapp-opt-in-collection-guide) walks through keeping opt-ins tagged by source and consent date in one place, so the same list you collected into is the list you schedule compliant campaigns from, no stitching two tools together. When you do send to that list, use approved, opt-out-bearing templates; the [WhatsApp campaign templates that convert](https://blueticks.co/blog/whatsapp-campaign-templates-that-convert) breakdown covers structures that pass review and still perform. One operational note: keep the list clean over time. Phone numbers churn and consent goes stale. Re-permission anyone you haven't messaged in roughly six months before your next broadcast, and drop the non-responders. A list of 5,000 active, recently-confirmed contacts beats 50,000 cold ones on both deliverability and quality score. ## How do you build the widget without hurting page speed? The lightest compliant widget is plain HTML: a phone field, an unchecked consent checkbox with the required sentence, and a submit handler that posts the number plus a timestamp to your backend. No third-party script, no Core Web Vitals hit. If you want a floating button, lazy-load it after the page's largest content paints so it never blocks render. Heavy, auto-loading chat widgets are a top cause of Lighthouse failures, and a slow page costs you the very conversions the widget is meant to win. Three ways to **embed whatsapp opt in on website** without the speed tax, lightest first: **1. Native form, zero JS overhead.** Add the phone field and consent checkbox to a form you already render. On submit, store `{ phone, consent_timestamp, source }` and (for DOI) trigger the confirmation message. Nothing extra to download. This is the default choice. ```html
``` **2. Lazy-loaded floating button.** If you want the persistent icon, defer its script until after the LCP event, or initialize it with an `IntersectionObserver` so it only spins up when scrolled into view. Either way it stops competing with your main content for the first paint. **3. Dedicated landing page.** For paid traffic, a standalone `/whatsapp` page with one form and no navigation outperforms an embedded widget and carries no speed cost to the rest of the site. Treat it as a squeeze page: headline states the value, the consent sentence states the terms, the button submits. Whatever you pick, the checkbox stays unchecked by default and the consent sentence stays visible next to it. Pretty styling that hides the wording fails compliance no matter how fast it loads. [image: Web developer testing a site at a tidy desk with an angled-shut laptop and a phone face-down nearby] ## How do you test that the widget captures real consent? Test the widget by submitting it yourself end to end and confirming three things landed: a valid international phone number, a consent timestamp, and an unchecked-by-default box that genuinely blocked submission until you ticked it. Then verify a real campaign send would only reach consented contacts. If you can submit with the box unchecked, the widget is not capturing consent, it is capturing numbers. A short QA pass that catches the real failures: 1. **Submit with the box unchecked.** It must fail. If the form goes through, your `required` attribute or validation is broken and you're collecting numbers with no consent. This is the single most common bug. 2. **Submit a known test number and inspect the record.** Confirm `phone`, `consent_timestamp` (ISO 8601), and `source` all saved. A missing timestamp means no provable consent. 3. **Run the wording check.** Read the live label. Does it name WhatsApp, name your business, state message types, and show the opt-out? If any of the four is missing, fix the copy before launch. 4. **Walk the double opt-in (if used).** Confirm the confirmation message fires on submit and that a contact who never replies YES does not appear in your sendable audience. 5. **Send one real test campaign to the test contact only.** Confirm it goes to the consented number and that an opt-out (STOP) actually removes them. Use a unique tag in the test message so you can verify exactly one send reached exactly one consented contact. That last step is where compliance becomes real. A widget that captures consent but a send pipeline that ignores it gets you blocked just the same. The list, the consent record, and the send have to be one connected system, which is the argument for collecting into the same place you send from. [Start free with Blueticks to manage your opt-in list and send compliant WhatsApp campaigns](https://blueticks.co/) ## Frequently asked questions **Does a wa.me click-to-chat button count as a WhatsApp opt-in?** No. A wa.me click opens a conversation window (24 hours for a service chat, 72 hours from a Click-to-WhatsApp ad), but it is user-initiated contact, not a marketing opt-in. Meta states that displaying a WhatsApp number alone does not count as opt-in. To send business-initiated marketing later, you need explicit, recorded consent captured through a proper opt-in widget or form. **What exactly does the consent wording on a WhatsApp opt-in widget need to say?** It must name your business, state explicitly that the person agrees to receive WhatsApp messages, describe the message types (order updates, offers), and include an opt-out instruction. A compliant example: "By submitting, you agree to receive WhatsApp messages (order updates and occasional offers) from Acme Coffee. Reply STOP to opt out." The channel word "WhatsApp" must appear; "mobile updates" is not enough. **Is single or double opt-in better for a WhatsApp signup widget?** Double opt-in is safer for any list you'll market to. Meta does not require it globally, but a confirmation step filters out bad numbers and uninterested submitters before they can block you, which protects your sender quality rating. Single opt-in is acceptable for purely transactional service updates and is effectively the GDPR-required standard in markets like Germany. **Where do contacts go after they submit the opt-in form?** Into a structured list that records the phone number (international format), a consent timestamp, and the collection source. That record is your proof of consent under Meta policy and GDPR. It can live in a CRM via webhook or directly in a managed audience; what matters is that the consent fields are captured and that you send only to consented contacts. **Will adding a WhatsApp opt-in widget slow down my site?** Only if you let it. A native HTML form (phone field plus a consent checkbox) adds no third-party script and no measurable page-speed cost. Heavy auto-loading chat widgets do hurt Core Web Vitals, so if you want a floating button, lazy-load it after the largest content paints. For paid traffic, a dedicated opt-in landing page sidesteps the issue entirely. --- # How to Schedule a WhatsApp Message on Android in 2026 (Tasker, MacroDroid & the Reliable Way) > WhatsApp has no native scheduler on Android. Here's how Tasker and MacroDroid fake one with the accessibility service, exactly why they break, and what to use instead. URL: https://blueticks.co/blog/schedule-whatsapp-message-android Published: 2026-06-12 Author: Daniel Roth Category: productivity You wrote the message at midnight. It needs to go out at 8am. Right now your only honest options are to stay up, set an alarm, or trust yourself to remember. WhatsApp still ships no future-dated scheduler on Android in 2026, so people reach for automation apps like Tasker and MacroDroid to fake one. They can work. They also break in ways nobody warns you about until a birthday message never fires. This guide walks the real builds, the real failure modes, and the path that doesn't depend on your phone being awake. ## Can you schedule a WhatsApp message on Android natively in 2026? No. As of June 2026 there is no native feature in the standard WhatsApp app on Android to schedule a regular chat message to a contact at a future date and time. There is no "send later" button, no calendar picker, no clock icon on the compose bar. To schedule a WhatsApp message on Android, you need an outside tool. Let me be precise. WhatsApp's consumer app on Android lets you send now, forward, reply, and react. It does not let you queue a message for 8am tomorrow. Same on iPhone, WhatsApp Web, and Desktop. A tutorial claiming a built-in scheduler exists in the standard app is either out of date or confusing WhatsApp with a third-party tool bolted on top. So the answer to **can I schedule a WhatsApp message on Android** with WhatsApp alone is no. Everything that follows is a workaround: on-device automation that simulates you tapping send, or a tool that sends through a separate session. The rest of this guide is about choosing the one that survives contact with reality. For the device-by-device native picture across iPhone too, see [scheduling WhatsApp messages without a third-party app](https://blueticks.co/blog/schedule-whatsapp-messages-iphone-android-without-app). ## Does the WhatsApp Business app let you schedule messages on Android? No. The WhatsApp Business app does not have a feature to schedule your own message to a contact at a future time. Its only native automation is greeting messages, away messages, and quick replies. All three are auto-replies or text shortcuts triggered by an incoming message. None of them schedules an outbound send. This trips people up constantly, so here is exactly what each Business tool does, straight from how Meta describes them: - **Greeting message.** An automatic reply sent to a customer when they message you for the first time, or after 14 days of no contact. It fires in response to *their* message, not on a clock you set. - **Away message.** An automatic reply sent when someone messages you outside your set business hours. You can schedule the *hours*, but the message only goes out when a customer writes in. It never reaches out first. - **Quick replies.** Saved text snippets you insert by typing a shortcut starting with `/`. You still have to be in the chat, typing, and hitting send yourself. It is a typing shortcut, not automation. You set these under Settings, then Business Tools, then Greeting Message or Away Message. They're genuinely useful for first-touch responses. But notice the pattern: every one is reactive. A customer has to message you first. There is no "Tools > Schedule message" path that lets you compose a message now and have it auto-send to a contact at 9am next Tuesday. That feature does not exist in the Business app. So if your plan was to install WhatsApp Business expecting a free native scheduler, stop. You'll find auto-replies and nothing that schedules an outbound message. For a fuller breakdown of where each tool fits, the [best apps to schedule WhatsApp messages](https://blueticks.co/blog/best-apps-to-schedule-whatsapp-messages) roundup compares them side by side. [image: A person's hand writing a timed reminder in a paper planner next to a face-down phone] ## How do you schedule a WhatsApp message on Android with Tasker (step-by-step)? Tasker schedules a WhatsApp message by combining a time-based trigger with a plugin called AutoInput, which uses Android's accessibility service to simulate taps on the screen. You build a task that opens a chat with your text pre-filled, then have AutoInput find and tap the send button at the scheduled time. The phone must be on and unlocked for it to work. Tasker is the power-user tool. It does almost anything, which also means it has a learning curve. Here is the workflow that actually sends, not just opens, a message. **What you need first:** Tasker (paid, one-time) and the AutoInput plugin (separate purchase after a trial). AutoInput needs its accessibility service switched on under Android Settings, then Accessibility, then AutoInput. Without that permission, the tap never happens. 1. **Build the open step.** In Tasker, create a new Task. Add a **Browse URL** or **Send Intent** action pointing at `https://api.whatsapp.com/send?phone=COUNTRYCODE_NUMBER&text=Your%20message%20here`. Use the full international number, no plus sign, no spaces, and URL-encode the text (a space becomes `%20`). This opens the chat with your message already typed into the box. 2. **Add a wait.** Insert a **Wait** action of 2 to 3 seconds so WhatsApp has time to load the chat before the next step runs. Skip this and AutoInput tries to tap a screen that hasn't rendered yet. 3. **Tap send with AutoInput.** Add an **AutoInput > Action** step. Set it to click the send button. The reliable way is to match the send button by its description (it's labelled "Send") rather than by raw screen coordinates, because coordinates break the moment your resolution or WhatsApp's layout changes. 4. **Attach a time trigger.** Create a **Profile** with a **Time** context set to your send time, and link it to the task. For a one-off, Tasker also pairs well with a calendar-event or alarm trigger. 5. **Disable battery optimization for Tasker** under Settings, then Apps, then Tasker, then Battery, then Unrestricted. This is the step most guides skip, and it's the one that silently kills scheduled tasks overnight. When it fires, your screen wakes, WhatsApp opens to the chat, the text is pre-filled, AutoInput taps Send, and the message goes. The Tasker community documents this exact `api.whatsapp.com/send` plus AutoInput-tap pattern as the standard approach. **What breaks:** AutoInput matches UI elements by what's on screen. When WhatsApp ships an app update that moves or relabels the send button, your task taps the wrong thing or nothing at all, and you won't know until a send fails. The accessibility service can also get disabled by Android after an update or a force-stop. And if the phone is locked or the screen is off at trigger time, the tap can't happen at all. Test it on a throwaway chat before you trust it with anything that matters. ## Is MacroDroid or Automate an easier alternative to Tasker? Yes, MacroDroid is the friendlier option. It ships a dedicated **WhatsApp Send** action, so you don't have to wire up URLs and tap-detection by hand the way Tasker does. Per the MacroDroid documentation, that action still uses fake UI interactions under the hood, which means the same hard requirement: the screen must be on and unlocked, and MacroDroid's UI Interaction accessibility service must be enabled. MacroDroid trades Tasker's flexibility for a guided builder. Here's the WhatsApp send flow: 1. Create a new **Macro**. 2. Add a **Trigger**: choose **Day/Time Trigger** and set your date and time. 3. Add an **Action**: pick **WhatsApp Send**. Enter the recipient's full international number (or use the contact picker) and type your message. 4. Leave **Pre-populate** unchecked. Per the MacroDroid wiki, if Pre-populate is checked the message is only written into the box and *not* sent automatically. Unchecked, it sends. 5. Enable the **MacroDroid UI Interaction** accessibility service when prompted, and set MacroDroid to **Unrestricted** under battery settings. Two limits worth knowing up front, both stated in MacroDroid's own docs: the WhatsApp Send action **cannot send to groups** (individual contacts only), and it **cannot send while the device is locked or the screen is off**. **Automate** (by LlamaLab) is the third option. It's a visual, flowchart-style builder that, like the others, leans on the Accessibility API to simulate taps and interact with WhatsApp's UI. It's powerful and has a generous free tier, but building a reliable send flow means assembling blocks (open chat, wait, interact-click the send element) yourself, which puts its difficulty between MacroDroid and Tasker. | Tool | Difficulty | Group sends | Recurring | Phone must be on | |---|---|---|---|---| | **Tasker + AutoInput** | High | Possible (fragile) | Yes | Yes, unlocked | | **MacroDroid** | Low to medium | No (1:1 only) | Yes | Yes, unlocked | | **Automate** | Medium | Possible (fragile) | Yes | Yes, unlocked | | **SKEDit** | Low | Yes | Yes | Yes (auto-unlocks) | If you want the least setup, **SKEDit** is the consumer-friendly version of all this. It's a dedicated WhatsApp scheduler Android app, a WhatsApp message scheduler Android users can run without building macros, wrapping the same Accessibility API approach in a normal scheduling UI. It even auto-unlocks the phone, sends, then re-locks. Free users get up to 5 scheduled messages a day per SKEDit's plan details. It still carries the core constraint of every on-device tool: the phone has to be powered on and online at send time. [image: An Android phone charging face-down on a nightstand at night, screen off] ## Why do on-device automation apps fail to actually send (battery optimization, accessibility, phone must be on)? On-device automation fails because it isn't really sending a message, it's puppeting your phone to tap the send button for you. That only works if the phone is awake, unlocked, has the accessibility service running, and isn't being throttled by battery optimization. Break any one of those and the message silently never goes out. This is the part the breezy "schedule WhatsApp messages on Android in 3 easy steps" posts leave out. Here are the four ways these setups die, roughly in order of how often they bite: 1. **Battery optimization kills the trigger.** Android aggressively sleeps background apps to save power. If Tasker, MacroDroid, or SKEDit isn't set to "Unrestricted" battery use, Android may freeze it before your scheduled time, and the send never fires. Manufacturer skins like Samsung's One UI and Xiaomi's MIUI are especially aggressive here. 2. **The phone is locked or the screen is off.** These tools simulate screen taps. A locked phone with the screen off has nothing to tap. MacroDroid's docs say this outright; it cannot send when the device is locked. SKEDit works around it by auto-unlocking, but that's a band-aid over the same underlying limit. 3. **The accessibility service gets switched off.** Android disables accessibility services after some updates, force-stops, or "clean up" actions by battery apps. When the service is off, the tap can't happen and your automation appears to run but does nothing. 4. **A WhatsApp update moves the send button.** Coordinate-based or element-based taps assume a fixed layout. When WhatsApp ships a UI change, the tap lands on the wrong element or misses entirely. This is the classic "it worked for months, then quietly stopped" failure. There's also a quieter cost: the screen lights up every time one of these fires. Schedule a 3am message and your phone wakes the room. None of this makes on-device automation useless, but it makes it the wrong choice for anything you can't afford to silently miss. As one Tasker regular put it, "the automation works until WhatsApp updates, and then you find out three sends later." That's the honest throughline. It works, until it doesn't, and it rarely tells you when. ## What's the most reliable way to schedule a WhatsApp message on Android? The most reliable way to schedule a WhatsApp message on Android is to stop depending on your phone being awake. Instead of puppeting the WhatsApp app, schedule the send through WhatsApp Web in a browser, where a tool queues the message and fires it from the session, not from a screen tap that needs an unlocked phone. Every on-device approach above is fragile for the same root reason: it simulates a human tapping send on your physical phone. Move the scheduling to your linked WhatsApp Web session and the screen-tap dependency disappears. The message sends from the web session, so your phone can be locked, face-down, or in your pocket. That's what [Blueticks](https://blueticks.co/) does. It's a Chrome extension that adds a scheduler directly to WhatsApp Web. You open a chat, type the message, pick a date and time, and it queues. The setup, end to end: 1. **Install the Blueticks extension** from the Chrome Web Store on a computer. 2. **Open WhatsApp Web** and link it to your phone the usual way (Settings, Linked Devices, scan the code) one time. 3. **Open a chat, write your message,** and attach an image or document if you need one. 4. **Set the date and time** in the scheduling control. For repeating sends, set a recurrence instead of a one-off. 5. **Confirm and walk away.** The message queues and fires at the time you set. This is also the only practical route for recurring sends and for sending to a list, which the on-device tools handle poorly or not at all. For the repeat case, the [recurring WhatsApp message workflow](https://blueticks.co/blog/schedule-whatsapp-messages) sets a pattern once and runs on its own. **What breaks here, honestly:** the free WhatsApp Web setup needs the browser tab open and the session connected to send. Close the tab or let the laptop sleep and queued messages wait until the session reconnects. Blueticks' paid offline gateway mode covers exactly this gap, sending even when your computer is closed, but on the free path, treat an open, connected tab as the requirement. The trade is straightforward: a one-time computer setup in exchange for sends that don't depend on your phone staying awake and unlocked. [Install the Blueticks Chrome extension and schedule your first WhatsApp message](https://chromewebstore.google.com/detail/blueticks/adgnjhngogijkkppficiiepmjebijinl) [image: A laptop angled half-shut on a desk beside coffee, a browser-based WhatsApp scheduling setup] ## How does scheduling on Android compare to iPhone and WhatsApp Web? Android is the most flexible platform for scheduling a WhatsApp message because its open automation model lets apps like Tasker and MacroDroid simulate sends, something iOS blocks. iPhone has no auto-send at all; Apple's Shortcuts can only pre-fill a message you still tap manually. WhatsApp Web has no native scheduler either, but it's where browser-based tools add one. The platform gap comes down to how each OS handles one app driving another: | Platform | Native scheduler | On-device auto-send | Reliable route | |---|---|---|---| | **Android** | No | Yes (Tasker, MacroDroid, SKEDit, phone-on) | WhatsApp Web tool | | **iPhone (iOS)** | No | No (Shortcuts pre-fills only, manual tap) | WhatsApp Web tool | | **WhatsApp Web** | No | n/a | Browser extension scheduler | On iPhone, iOS sandboxing stops any tool from tapping WhatsApp's send button on your behalf. Shortcuts can open WhatsApp at a set time with your text pre-filled, but you stand there and tap Send yourself. That's a reminder, not a scheduled send. The iOS Shortcuts limits are covered in the [iPhone and Android without-an-app guide](https://blueticks.co/blog/schedule-whatsapp-messages-iphone-android-without-app). The irony: the platform with the *most* on-device flexibility, Android, still pushes you toward a non-phone solution once reliability matters, because the fragile screen-tap dependency is the whole problem. Whether you're on Android or iPhone, the route that survives an OS update and a locked screen is the same: schedule through WhatsApp Web. Around 72% of smartphones worldwide run Android (Statista, early 2026), so most people asking how to schedule WhatsApp messages on Android land here, on a workaround, because the native answer is still no. ## Frequently Asked Questions **Can I schedule a WhatsApp message on Android without any app?** Not in a way that actually auto-sends. WhatsApp itself has no native scheduler on Android, and the WhatsApp Business app's greeting, away, and quick-reply tools are auto-replies, not scheduled outbound messages. To schedule a message that fires on its own, you need a third-party tool, either an on-device automation app like Tasker or MacroDroid, or a WhatsApp Web scheduler. **Does Tasker really send WhatsApp messages automatically?** Yes, but with conditions. Tasker paired with the AutoInput plugin uses Android's accessibility service to tap the send button at a scheduled time. The phone must be on and unlocked, the accessibility service must be enabled, and battery optimization must be disabled for Tasker. It also breaks when WhatsApp updates its UI, so test it before relying on it. **Why did my scheduled WhatsApp message not send on MacroDroid?** The three usual causes are: the phone was locked or the screen was off (MacroDroid's WhatsApp Send can't tap a sleeping screen), battery optimization froze MacroDroid before the trigger fired, or the UI Interaction accessibility service got disabled after an app update. Set MacroDroid to Unrestricted battery use and re-enable accessibility to fix it. **Is there a free WhatsApp message scheduler for Android?** Yes. SKEDit offers a free tier (up to 5 scheduled messages a day) using the Accessibility API, and it supports groups and recurring sends. MacroDroid has a free tier too. For computer-based scheduling, Blueticks' free plan schedules three messages at a time on WhatsApp Web. All on-device free tools share the phone-must-be-on limitation. **What's the most reliable way to schedule WhatsApp messages on Android?** Schedule through WhatsApp Web with a browser extension rather than on-device automation. Browser-based scheduling sends from your linked web session, so it doesn't depend on your phone being awake, unlocked, or running an accessibility service that breaks on WhatsApp updates. It's also the cleanest route for recurring sends and sending to a list. --- # WhatsApp Read Receipts Explained: What the Ticks Mean and How to Turn Them Off (2026) > WhatsApp read receipts are how the ticks tell you a message was read. Here's exactly how they work in 2026, how to turn them off, and what they can never tell you. URL: https://blueticks.co/blog/whatsapp-read-receipts-explained Published: 2026-06-11 Author: Daniel Roth Category: productivity You sent it. Two grey ticks have sat there for three hours. Were you read and ignored, or did the message never land? That uncertainty comes down to one feature: WhatsApp read receipts, the system behind those little ticks. This guide explains exactly how read receipts work, the edge cases that quietly break the rules, how to turn them off, and the one thing they can never tell you, all grounded in WhatsApp's own Help Center as of June 2026. ## What are WhatsApp read receipts? WhatsApp read receipts are the tick marks next to a message that show whether it was sent, delivered, or read. There are three states: - **One grey tick** — the message reached WhatsApp's servers - **Two grey ticks** — delivered to the recipient's device - **Two blue ticks** — they opened the chat and read it Per the [WhatsApp Help Center](https://faq.whatsapp.com/665923838265756), only the two blue ticks are the actual "read receipt." Everything else is delivery, not reading. ### How do WhatsApp read receipts work? Read receipts work by advancing through those three states as your message moves from WhatsApp's servers, to the recipient's device, to their opened chat. That distinction is the whole game. Most people compress it to "blue means read," which is right but skips the two states underneath it that explain almost every confusing situation. If you want the deep dive on the colour change specifically, here's [what the blue ticks mean](https://blueticks.co/blog/what-do-blue-ticks-mean-on-whatsapp) on their own. ### One grey tick vs two grey ticks vs two blue ticks Here is each state, what it confirms, and what it does not. | Tick state | What it means | What it does NOT mean | |---|---|---| | **One grey tick** | Your message left your phone and reached WhatsApp's server. | The recipient has it. Their device may be off, offline, or queued. | | **Two grey ticks** | Delivered to the recipient's device. | That they opened it. They may not have looked yet, or read receipts may be off. | | **Two blue ticks** | They opened the chat and the message was shown on screen. | That they actually read the words, processed them, or intend to reply. | A single grey tick is the "in transit" state. The message is sitting on WhatsApp's server waiting for the recipient's phone to come online. The two grey ticks meaning is narrower than people assume: the message physically arrived on their device, nothing more. The phone buzzed. A notification may have shown. None of that flips the ticks blue. The only thing that turns two grey ticks into two blue ticks is the recipient opening the actual chat thread. Reading your full message in a notification banner does not count. Long-pressing the chat to preview does not count. The chat has to open. ## Why do I see two grey ticks but no read receipt? Two grey ticks with no blue almost always means one of three things: the recipient hasn't opened your chat yet, they read it in a notification without opening the app, or they have read receipts turned off. Delivery is confirmed in all three cases. What's missing is the "opened the chat" signal that turns the ticks blue. This is the most misread state on WhatsApp, so here is the full list of why the read receipt stalls: - **They haven't opened the chat.** The message is delivered and waiting. Common, and the most likely answer. - **They read it from the notification.** iOS and Android banners often show the full message. Someone can read every word without opening WhatsApp. Ticks stay grey. - **Read receipts are off.** If the recipient disabled read receipts in privacy settings, your ticks will never go blue for them, no matter how carefully they read. More on [what the blue ticks vs grey ticks mean](https://blueticks.co/blog/what-do-blue-ticks-mean-on-whatsapp), and the setting is below. - **They have you muted.** Muting doesn't block read receipts, but a muted chat gets opened later, so you see delivery followed by a long grey gap. - **A device sync gap.** With WhatsApp's multi-device setup, a message delivered to the phone but opened on a poorly synced linked device can behave inconsistently. There is a real measurement consequence here. If you run any kind of outreach, treat "read rate" as a floor, not the truth. A meaningful share of recipients read from the lock screen or have receipts off, so the people who actually saw your message is always higher than the blue-tick count suggests. WhatsApp does not publish a number for this, but assume your real reach beats your read receipts by a wide margin. [image: Person glancing at a phone notification on a lock screen without opening the app, near a window] ## Why is there a read receipt but no reply? A read receipt confirms the chat was opened and your message was displayed on screen. It does not confirm that the person read carefully, understood, or decided to answer. Someone can tap into a chat, trigger the read receipt, get distracted, and never reply. "Left on read" is a social reality, not a WhatsApp malfunction. This is the gap between "technically read" and "actually processed." The read receipt fires the instant the message renders in an open chat. If they opened the thread to check something else and scrolled past your message, you got blue ticks for a message they barely registered. A few honest reasons for read-but-silent: 1. **They saw it, plan to reply later, and forgot.** The most common one. Not a slight. 2. **They opened the chat for something unrelated** and your message rendered as collateral. 3. **They're composing a reply** that takes a while, so the read receipt lands minutes before any answer. 4. **They read it and chose not to respond.** Their call, and the ticks can't tell you which of these it was. The takeaway: a read receipt is a delivery-and-display signal, not a mind-reading device. If a reply matters, the lever you control is *when* the message lands. Send a time-sensitive ask at 11pm and it competes with sleep; send it mid-morning and it competes with far less. That's why people [schedule WhatsApp messages](https://blueticks.co/blog/schedule-whatsapp-messages) to fire at a sensible local hour instead of whenever they happened to type it. ## How do read receipts work for voice notes and media? Voice messages have their own read receipt separate from text. The microphone icon on a sent voice note turns blue once the recipient plays it, and WhatsApp shows a "Played" state for it. Crucially, per WhatsApp's Help Center, turning off read receipts does **not** disable play receipts for voice messages, so the blue mic can show even when text read receipts are hidden. That is the catch most people miss. You can switch off read receipts to hide your blue ticks on texts, but the moment you play someone's voice note, the mic icon goes blue on their end regardless. There is no privacy toggle that hides voice-note play receipts. For images, videos, documents, and other media, the read receipt behaves like text: one grey for sent, two grey for delivered, two blue when the chat is opened and the media is displayed. Opening the chat is what flips them, the same as a text message. The voice note is the one true exception, with its own play-based receipt that ignores the read-receipt setting entirely. ## How do read receipts work in WhatsApp group chats? In group chats, read receipts always show, no matter what anyone's privacy setting says. Two grey ticks appear once at least one member has received the message, and two blue ticks appear only when **every** participant has both received and read it. You can also long-press any message and open its info screen to see a per-person "Read by" and "Delivered to" breakdown with timestamps. This is where the read-receipt rules flip on people. The blue ticks in a group are an "everyone" signal, not an "anyone" signal. In a 30-person group, your message can sit on two grey ticks for a long time because one member with a dead phone hasn't received it yet, even though 29 people already read it. To see what's actually happening: 1. Open the group chat. 2. Long-press (or tap and hold) your message. 3. Tap the info icon, the "i" in a circle. You get two lists, "Read by" and "Delivered to," each with names and timestamps. It's the only reliable way to read partial delivery in a big group. One privacy note that surprises people: WhatsApp's Help Center states that turning off your read receipts does not disable them for group chats. So even a user who hides read receipts in one-on-one chats still shows up in the group "Read by" list. Groups are a read-receipt-always zone. [image: Small group of coworkers around a cafe table, some checking phones, evoking a busy WhatsApp group chat] ## How do you turn WhatsApp read receipts on or off? The setting to turn off WhatsApp read receipts lives in Settings under Privacy. On iPhone, go to Settings, then Privacy, then toggle off Read Receipts. On Android, tap the three-dot menu, then Settings, then Privacy, then turn off Read Receipts. Once off, your sent messages stop turning blue for others, and you stop seeing blue ticks on theirs. Groups and voice notes are exceptions. Here is the exact path on each platform. **On iPhone (iOS):** 1. Open WhatsApp. 2. Tap **Settings** (bottom right). 3. Tap **Privacy**. 4. Toggle **Read Receipts** off. **On Android:** 1. Open WhatsApp. 2. Tap the **three dots** (top right), then **Settings**. 3. Tap **Privacy**. 4. Toggle **Read Receipts** off. Before you flip it, know the three things the setting actually does, because two of them catch people out. ### Does turning off read receipts also hide other people's read receipts from me? Yes. The read receipts setting is mutual. The moment you turn off read receipts to hide your own, WhatsApp also stops showing you blue ticks on the messages you send to others. Per the Help Center, "if you turn off read receipts, you won't be able to see read receipts from other people." There is no way to keep seeing theirs while hiding yours. That trade-off is the whole reason most people leave it on. You give up your own visibility to gain privacy. The two exceptions, both confirmed by WhatsApp: - **Group chats still show read receipts** even with the setting off. - **Voice message play receipts still fire** even with the setting off. The clumsy workaround for hiding a single read is to open the message in airplane mode before reconnecting, so the read isn't reported until later. It technically works, but it breaks notifications and forces you to catch messages before connectivity resumes. It is not a habit worth maintaining. ## One grey tick for hours: are you blocked or are they offline? You cannot confirm a block from the ticks alone. A message that stays on one grey tick and never reaches two could mean the person blocked you, but it could equally mean their phone is off, they're out of signal, or they're in airplane mode. WhatsApp's Help Center is explicit that messages to someone who blocked you always show a single check and never a second, and that WhatsApp will never tell you whether you've been blocked. This ambiguity is deliberate. WhatsApp designed the blocked experience to look identical to "this person is simply offline," precisely so blocking stays private and safe. A single grey tick is a clue, not a verdict. What a stuck one grey tick can mean: - Their phone is **off** or has **no internet** (most common, especially overnight). - They're in **airplane mode** or a dead-zone. - They **deactivated** or are between devices. - They **blocked you**, which produces the same single tick on purpose. Other signals people lean on, such as a missing profile photo or "last seen," are just as unreliable, because those can be hidden by privacy settings too. The honest answer to "did they block me" is that you can stack circumstantial signs, but the ticks will never give you a clean yes or no. If you need a definitive answer, the ticks aren't it. ## Where scheduling fits in If you take one thing from read receipts, it's that getting *read* depends as much on timing as on wording. Delivery is the easy part, your message lands within seconds. Whether it gets opened in a useful window is about hitting send when the recipient is actually looking at their phone. That's the practical reason scheduling tools exist. Instead of typing a client reminder at 11pm and hoping you remember to resend it at 9am, you set the time once and let it fire. [Blueticks](https://blueticks.co/) does exactly this for WhatsApp, scheduling one-time and recurring messages so they land when they'll get read. For repeating sends like weekly check-ins or monthly invoices, the [recurring scheduler](https://blueticks.co/blog/schedule-recurring-whatsapp-messages) sets a pattern once and runs on its own. It won't make anyone reply, but it gets the message in front of them when they're most likely to open it. Time your messages to land when they'll actually get read — [schedule your first WhatsApp message free →](https://blueticks.co/signup) ## Frequently Asked Questions **What do two grey ticks mean on WhatsApp if there's no read receipt?** Two grey ticks mean your message was delivered to the recipient's device but they haven't opened the chat yet, read it from a notification preview, or have read receipts turned off. Delivery is confirmed in all three cases. The read receipt (two blue ticks) only appears when the chat itself is opened. **If someone turned off read receipts, will I ever see blue ticks?** No. If the recipient disabled read receipts in their privacy settings, your ticks stop at two grey no matter how thoroughly they read your message. There's no way to override another person's privacy setting. The one exception is group chats, where read receipts always show. **Does one grey tick mean I've been blocked?** Not necessarily. A message stuck on one grey tick can mean you're blocked, but it can equally mean their phone is off, they have no signal, or they're in airplane mode. WhatsApp makes the blocked state look identical to being offline on purpose, and it will never confirm whether you've been blocked. **Can I turn off read receipts without losing the ability to see other people's?** No. The read receipts setting is mutual. Turning off your own also stops you from seeing read receipts on messages you send. Group read receipts and voice-message play receipts are the only things that keep showing once the setting is off. **Do voice notes have separate read receipts?** Yes. A voice message shows a microphone icon that turns blue once the recipient plays it, with a "Played" state. Turning off read receipts does not hide voice-note play receipts, so the blue mic can appear even when your text read receipts are switched off. **Do WhatsApp read receipts work the same on WhatsApp Web?** Yes. WhatsApp Web shows the same one grey, two grey, and two blue tick states as the mobile app, with identical behavior. If you manage chats from a computer, the [WhatsApp Web workflow](https://blueticks.co/blog/schedule-whatsapp-web-messages) treats read receipts exactly the same way the phone does. --- # Best Apps to Schedule WhatsApp Messages in 2026: Send at the Right Time Without Staying Up > Native WhatsApp scheduling is still thin. Here are the best apps to schedule WhatsApp messages in 2026, ranked, with honest free-vs-paid tradeoffs. URL: https://blueticks.co/blog/best-apps-to-schedule-whatsapp-messages Published: 2026-06-10 Author: Maya Cohen Category: marketing You wrote the message at 11pm. It should land at 9am. Right now your only options are to stay up, set an alarm, or hope you remember. That gap is exactly what a WhatsApp scheduler closes. The problem is that "schedule WhatsApp messages" returns a wall of apps, half of which are abandoned, several of which want full account access, and a few of which actually work. This is a ranked roundup of the best apps to schedule WhatsApp messages in 2026, free and paid. I tested the categories that matter: Chrome extensions that bolt onto WhatsApp Web, Android and iPhone apps that automate sends on-device, and WhatsApp's own native options, which changed in 2026 in a way most roundups have not caught up with. I'll tell you where the free route is enough, and where it falls apart. The ranking is by use case, not by a single trophy. Last fact-checked 12 August 2026. Two of the extensions below shipped new features in the eight days before that date, so feature rows in this category go stale fast. ## What should you look for in a WhatsApp message scheduler? A good WhatsApp scheduler does four things: sends at the exact time without you present, supports recurring sends, handles more than one recipient cleanly, and doesn't demand sketchy permissions. Beyond that, the split is whether you need one personal reminder a week or a few hundred personalized messages a month. Match the tool to the volume, not the hype. Here's the checklist I score every WhatsApp scheduler against: - **Truly unattended send.** Some "schedulers" just pre-write a message and still make you tap send. That's a reminder, not a scheduler. The send has to fire without you. This distinction matters most on iPhone, where the best-known option is honest that WhatsApp gets a notification-plus-tap rather than an automatic send. - **Recurrence.** Daily standups, weekly check-ins, monthly invoices. If you have to recreate the message every time, you'll stop using it by week two. - **Multiple recipients and personalization.** Sending the same line to 80 people is a campaign, not a chat. You want a CSV import and merge fields like `{name}`, not 80 copy-pastes. - **Permissions and account safety.** WhatsApp Web extensions run inside your own logged-in session; Android automation apps lean on the Accessibility API. Both are common, but read what each tool asks for. - **Free tier honesty.** Plenty of tools are "free" until you hit a hard ceiling, whether that's a handful of messages a day or a few queued at once. That's fine if you stay under it. Know the ceiling before you build a habit on it. The timing matters more than people think. Speed-to-reply research from MIT's James Oldroyd, popularized by Harvard Business Review, found that contacting a lead within five minutes makes you 21 times more likely to qualify it than waiting 30 minutes ([Lead Response Management](https://www.leadresponsemanagement.org/lrm_study/)). A scheduler that fires your follow-up at the right local hour is doing speed-to-lead work while you sleep. For the fundamentals, our [guide to scheduling WhatsApp messages](https://blueticks.co/blog/schedule-whatsapp-messages) covers the mechanics. ## Does WhatsApp let you schedule messages without a third-party app? Partly, and the answer changed in 2026. The WhatsApp Business app can now schedule **business broadcasts**, a paid, Meta-reviewed broadcast product. But neither consumer WhatsApp nor the Business app can schedule an ordinary 1:1 or group chat message to fire at a time you pick. For that you still need a third-party tool. That distinction is the whole ballgame, so here is exactly where the line falls. **What the WhatsApp Business app can now schedule.** Business broadcasts. WhatsApp's Help Center is explicit: you reach the feature at **Tools > Business broadcasts**, and at the review step "you can send or schedule the business broadcast; you'll be charged when you do so" ([WhatsApp Help Center](https://faq.whatsapp.com/1711086883148106/)). Four constraints come attached. It is paid: the same page says "You can send Business broadcasts for a fee," and once your free messages are used you must add a payment method, with billing on delivered broadcasts and a refund for anything undelivered after 5 days. It is reviewed: "your business broadcasts are subject to review by Meta before you send them in WhatsApp chats." It is Business-app only: "Sending business broadcasts is exclusively on the WhatsApp Business app." And it may not have reached you yet — the same page warns that business broadcasts are "currently available in limited countries and might not be available to you yet," so check the feature is actually in your app before you plan around it. **What it still can't do.** Schedule a normal message. A broadcast goes to an audience you assemble on a Select audience screen. It is not a way to say "send this one line to Dana at 9am tomorrow." You can start one from inside an existing thread, but what you schedule is still a broadcast to an audience, not a timed reply to that conversation. The Business app's other automation tools, greeting messages, away messages, and quick replies, are auto-*replies* triggered by what a customer does, not by a clock you set. **Consumer WhatsApp (the app most people use).** No native send-later button and no calendar picker, on any platform. WhatsApp has been building one: WABetaInfo spotted a schedule-send option in Android and iOS betas in February 2026, and outlets including [9to5Mac](https://9to5mac.com/2026/02/23/whatsapp-is-finally-working-on-scheduled-messages/) covered it. As of this update it had not been switched on for beta testers and WhatsApp has announced no release date. Treat it as unreleased rather than as something you can use today. **iPhone.** Apple's Shortcuts can run an automation at a set time, and WhatsApp genuinely does expose a Siri action: the Help Center states plainly that "you can ask Siri to send WhatsApp messages" ([WhatsApp Help Center](https://faq.whatsapp.com/1803878309981730)). What you can't reliably get is the unattended version. The common Shortcuts recipes open WhatsApp with your text pre-filled and leave the final tap to you, and the dedicated iPhone scheduling apps say so out loud. Scheduled, the best known of them, describes its flow as delivering "automatically via SMS or notifies you to send through your preferred messenger," and lists auto-send only for iMessage, SMS, and email. Plan on confirming the send on iPhone. So, can you schedule WhatsApp messages without any app? For a paid business broadcast, yes. For a regular message to a contact or a group, no. We cover the device-by-device options in [how to schedule WhatsApp messages on iPhone and Android without a third-party app](https://blueticks.co/blog/schedule-whatsapp-messages-iphone-android-without-app), and the browser path in [how to schedule a message on WhatsApp Web](https://blueticks.co/blog/how-to-schedule-a-message-on-whatsapp-web). [image: A hand holding a phone with the screen angled away in soft morning light, scheduling WhatsApp messages] ## Which is the best app to schedule WhatsApp messages in 2026? For most people who work from a computer, the best WhatsApp scheduler in 2026 is Blueticks, a Chrome extension that adds scheduling, recurring messages, and bulk campaigns directly to WhatsApp Web. It ranks first because it covers the full range, one personal reminder up to a few hundred personalized sends, without the WhatsApp Business API setup that heavier platforms require. Here's why it tops the list, with the honest limits attached. **What it does well.** Blueticks is a [WhatsApp scheduler Chrome extension](https://blueticks.co/blog/schedule-whatsapp-messages) that runs inside your existing WhatsApp Web session. You schedule one-time or recurring messages, attach images and documents, and send bulk campaigns with personalization and an Excel/CSV import. That last part separates it from the single-message tools: upload a list, merge in `{name}`, and send 80 personalized messages instead of 80 copy-pastes. **Where it's the wrong tool.** Blueticks runs on WhatsApp Web, not the official WhatsApp Business API. It does not auto-detect events from your Shopify store or CRM and fire a templated message in real time. If you need event-triggered flows at thousands of messages a day with Meta-approved templates, that's an API job, not a Web extension. **The two caveats worth knowing before you install.** On the Basic and Standard plans, sending is browser-based, so WhatsApp Web has to stay open for a scheduled message to fire. Unattended sending with the browser closed is the Pro-tier offline mode, and it is a paid plan. Those are the two things that surprise people who assumed a scheduler runs in the cloud by default. **Who it's for.** Freelancers, small teams, agencies, and store owners who work at a laptop and want to schedule reminders, send recurring updates, and run periodic campaigns to opted-in lists. If that's you, it's the most complete single pick. ## What's the best free tool to schedule WhatsApp messages? The best free tool to schedule WhatsApp messages depends on platform. On a computer, Blueticks's free plan schedules three messages at a time. On Android, SKEDit's free tier allows five scheduled messages per day, and Auto Text is free with ads. WhatsApp itself has no free scheduler for regular chat messages, so a third-party tool remains the only real free route. Free works, but every free tier has a wall. Here's where each one stops: - **Blueticks free plan.** Schedules 3 messages at a time, plus the basic feature set. Genuinely useful if you send the occasional timed message and don't need bulk or a long queue. You hit the wall the moment you want more than three sends pending at once or a CSV campaign. That's the upgrade trigger, and it's an honest one. For a single weekly reminder, the free tier is all you need. - **SKEDit (Android, free tier).** Its site states the ceiling directly: "Free users can schedule up to 5 messages per day. Pro and Business users enjoy unlimited scheduled messages with no daily caps." It handles recurring daily, weekly, and monthly schedules across individual contacts, groups, and broadcast lists. The catch is the mechanism: it uses Android's Accessibility API to mimic tapping send, and SKEDit's FAQ says it "requires your phone to be online at the scheduled time to send messages" ([SKEDit](https://skedit.io/)). A dead battery or a phone left at home means no send. - **Auto Text (Android, free with ads).** A 1M+ download app with recurring intervals and CSV import for bulk sends. Same Accessibility API mechanism, same phone-must-be-on tradeoff. Detailed below. - **WhatsApp Business app (free allowance, but broadcasts only).** Its greeting, away, and quick-reply tools are auto-replies. Its business broadcasts can be scheduled, but they are metered and reviewed, and they go to a broadcast audience rather than into a normal chat thread. It is not a free "send later" button for everyday messages. The free-vs-paid line is simple. If you need one timed message now and then, a free tool is the right call and you shouldn't pay. If you're scheduling regularly, running recurring sequences, or sending to a list, free tiers turn into friction fast, and that friction is the whole reason paid plans exist. Our [free tool to schedule WhatsApp messages walkthrough](https://blueticks.co/blog/schedule-recurring-whatsapp-messages) shows how far the no-cost route goes. [image: A laptop angled shut beside a paper planner and coffee, a small-business WhatsApp scheduling workspace] ## Which scheduler works for WhatsApp Business and bulk sends? For WhatsApp Business and bulk sends from a computer, a WhatsApp Web extension with CSV import and personalization is the practical pick, and Blueticks fits that brief. For high-volume, event-triggered messaging, the official WhatsApp Business API with a provider platform is the right layer. The Business app's own broadcasts sit in between: scheduled, but paid and reviewed. These are three genuinely different jobs, and conflating them wastes money: **Periodic bulk sends from a list (most small businesses).** You have a few dozen to a few hundred opted-in contacts and you want to send them a personalized update, promo, or reminder on a schedule. A WhatsApp Web tool handles this cleanly: import the Excel/CSV, merge in names, schedule the send. No template approval, no per-message billing, no API onboarding. This is where a [WhatsApp scheduler for business messages](https://blueticks.co/blog/schedule-whatsapp-business-messages) earns its keep. The honest caveat: WhatsApp Web tools send from your number through your session, so respect the channel. Don't blast non-consenting contacts, or you'll collect blocks. **Native business broadcasts (if you already live in the Business app).** Modest list, promotional message, and you're fine with Meta reviewing it and billing per delivered message? The built-in broadcast scheduler is the path of least resistance, with nothing to install. The tradeoffs are cost per message, the review step, and being limited to broadcast-shaped communication. **High-volume, real-time automation (enterprises).** Cart abandoned, order shipped, appointment in 24 hours, fire a templated message the instant the event happens, at thousands per day. That requires the WhatsApp Business API, Meta-approved templates, and per-message pricing. Platforms in this category, including tools like WhatsTool that some roundups mistakenly file next to consumer schedulers, are official API providers and carry the setup and cost overhead to match. Pick by volume and trigger type. Exporting a list and sending on a schedule puts you live this week with a Web extension. Firing messages off live events at scale means budgeting for API infrastructure. ## How do these WhatsApp schedulers compare side by side? The short version: Blueticks wins on range for computer users, SKEDit and Auto Text win for Android on-device automation, iPhone apps like Scheduled still hand WhatsApp back to you for the final tap, the Business app schedules paid broadcasts only, and the lightweight Chrome extensions have quietly grown into bulk tools. Here's the full comparison. | Tool | Platform | Free tier | Recurring | Bulk / CSV | Best for | |---|---|---|---|---|---| | **Blueticks** | Chrome ext on WhatsApp Web | 3 messages at a time | Yes | Yes (Excel/CSV + merge) | Computer users who want the full range | | **SKEDit** | Android app | 5 scheduled messages/day | Yes (daily/weekly/monthly) | Limited | Android on-device automation | | **Auto Text** | Android app | Free with ads, in-app purchases | Yes (daily/weekly/monthly/custom) | Yes (CSV/Excel import) | Android bulk sends plus auto-reply | | **Wasavi** | Android app | Free with in-app purchases | Not stated on the listing | No | Android scheduling plus chat automation | | **Scheduled** | iPhone app | Free, paid tiers from $3.99/mo | Yes (daily/weekly/monthly/custom) | Mass text | iPhone, if you accept a tap to send WhatsApp | | **Send Later for WhatsApp** | Chrome ext on WhatsApp Web | Yes | Follow-up sequences | Yes (CSV import) | Personal send-later, plus polls and channels | | **WA Schedule** (formerly WA Scheduler) | Chrome ext on WhatsApp Web | Yes | Yes (every X days/weeks/months) | Yes (paste from Excel/CSV) | In-line scheduling, pause-on-reply | | **WhatsApp Business app (native)** | Android / iPhone | Free allowance, then paid | No | Broadcast audiences only | Paid, Meta-reviewed business broadcasts | | **WhatsApp Business API + provider** | Cloud / API | No | Via automation | Yes (templates) | Enterprise, event-triggered at scale | Two corrections worth calling out, because most comparison pages, including an earlier version of this one, still get them wrong. **WA Schedule**, the extension formerly listed as WA Scheduler, is no longer a simple one-message tool: its Chrome Web Store listing now advertises mass and bulk messaging where you paste a contact list from Excel or CSV and set an interval between sends, plus recurring messages "every X days, weeks, or months." **Send Later for WhatsApp** has grown the same way, adding CSV-based bulk scheduling along with scheduled polls, quizzes, and WhatsApp Channel posts. Both were updated within the last week at the time of writing. If you last evaluated either six months ago, re-check before assuming you need a heavier tool. Where Blueticks still pulls ahead is the combination: merge-field personalization on a CSV campaign, a proper queue, and Pro-tier offline sending with the browser closed. Where they beat it is price, if all you need is one timed message and you don't want an account. If you're scheduling from a laptop and want the queue, the recurrence, and the CSV campaigns in one place, without per-message fees or an API onboarding, [start free with Blueticks](https://blueticks.co/signup) and send your first scheduled message from your own number today. [image: A small team around an office table mid-discussion comparing WhatsApp scheduler options, devices closed] ## Which mobile apps do most WhatsApp scheduler roundups miss? Most roundups list SKEDit and stop. Three other mobile apps show up repeatedly in search results and deserve a real entry: Auto Text and Wasavi on Android, both with over a million downloads, and Scheduled on iPhone. All three schedule WhatsApp messages, and all three carry a platform-specific catch you should know before installing. **Auto Text (Android).** The strongest Android pick for volume. Its Play Store listing reports 1M+ downloads and a 4.5 rating across roughly 33,000 reviews, updated July 2026. It schedules and auto-sends WhatsApp and SMS, does recurring sends daily, weekly, monthly or on custom intervals, takes multiple recipients per message, and imports contacts from CSV or Excel. It also handles auto-replies and SMS forwarding. Like every Android app here, it states plainly that it "uses Android Accessibility Services to automate sending scheduled messages on your behalf," so the phone has to be on for the automation to run. **Wasavi (Android).** Also 1M+ downloads, rated 3.4, last updated May 2026. It schedules messages and images, then layers on automation the others skip: auto-replies, keyword monitoring across groups, turning messages into tasks, and piping WhatsApp messages into Google Sheets. It covers WhatsApp, WhatsApp Business, Viber, Signal and Messenger. Its listing does not claim recurring schedules, so don't buy it for that, and it wants a draw-over-other-apps permission on top of Accessibility. **Scheduled (iPhone).** The most complete iPhone option, and the most honest about its limits. Free to download, with paid tiers its App Store listing prices from $3.99 to $4.99 per month. It does recurring messages, sequences, mass text, and birthday imports. The catch defines iPhone scheduling: the listing offers auto-send for iMessage, SMS and email, and describes the flow as delivering "automatically via SMS or notifies you to send through your preferred messenger." WhatsApp sits in the notify bucket. It is an excellent reminder system, not an unattended sender, and its 2.8 rating across 1,300 ratings reflects how many buyers expected the latter. The pattern across all three is the real lesson. On-device automation buys independence from your laptop but makes the send depend on a phone that is awake and charged. Browser and gateway tools trade the other way. Which one fits comes down to whether your messages need to go out while your phone is in a drawer. ## How do you set up your first scheduled message in under 5 minutes? You can schedule your first WhatsApp message in under five minutes with a Chrome extension: install it, open WhatsApp Web, open a chat, type your message, pick a date and time, and confirm. No account migration, no API approval. The whole flow runs inside the WhatsApp Web session you already use. Here's the path with Blueticks, start to finish: 1. **Install the extension.** Add Blueticks from the Chrome Web Store. It installs like any extension, no separate signup wall before you can try it. 2. **Open WhatsApp Web.** Go to web.whatsapp.com and link your phone if you haven't. The extension layers its scheduling controls onto the interface you already know. 3. **Open the chat and write your message.** Pick the contact, type what you want to send, attach an image or document if needed. 4. **Pick the date and time.** Use the scheduling control to set exactly when it should fire. For a recurring send, set the repeat interval here instead of a one-off time. 5. **Confirm and walk away.** The message queues. On the free plan you can have three messages scheduled at a time; paid plans lift that so you can build a full queue. On Basic and Standard, keep WhatsApp Web open so the send can fire. On Pro, offline mode sends even with the browser closed. That's it. The first time takes five minutes mostly because you're reading the buttons. After that, scheduling a message is faster than writing it. Want it to repeat? Our [recurring WhatsApp messages guide](https://blueticks.co/blog/schedule-recurring-whatsapp-messages) covers daily, weekly, and monthly setups. ## A real example: how a clinic stopped no-shows with scheduled reminders A two-location dental clinic, call it Northbay Dental, was losing roughly 18% of weekly appointments to no-shows. Their front desk sent manual WhatsApp reminders when they remembered, which was inconsistently and almost never on weekends. Every no-show was an empty chair they couldn't rebook at short notice. They moved to scheduled WhatsApp reminders. Each evening, the front desk imported the next day's appointment list as a CSV, merged in each patient's name and slot time, and scheduled a reminder to fire at 7pm the night before. One import, one schedule, done in minutes. Because the sends were timed to a sensible local hour and personalized, patients actually read them and replied to confirm or reschedule inside the same thread. The numbers, illustrative but based on the kind of lift reminder programs produce[^1]: no-shows dropped from about 18% to under 8% over two months. For a clinic running roughly 200 weekly appointments, recovering even 20 of those slots is meaningful revenue from a workflow that costs minutes a day. The mechanism is dull and that's the point: the right message, at the right time, sent without anyone having to remember. That's the entire value of scheduling. Note what native tools could not have done here. These reminders are personalized, appointment-specific messages landing in each patient's normal chat thread. A business broadcast is neither, and it bills per delivered message. ## Which WhatsApp scheduler is right for you? The right WhatsApp scheduler comes down to where you work and how much you send. Work from a computer and want one tool for reminders, recurring sends, and campaigns: Blueticks. Android-only: SKEDit for simple, Auto Text for bulk. iPhone: Scheduled, accepting a manual tap. Enterprise scale with live triggers: the WhatsApp Business API. Quick decision guide: - **"I just need one message to send tomorrow morning."** Free tier of any Chrome extension on a computer, or SKEDit on Android. Don't overthink it, don't pay. - **"I send timed and recurring messages from my laptop every week."** A full WhatsApp Web scheduler. Blueticks is the most complete, and the free plan lets you test the flow before upgrading. - **"I send personalized messages to a list of contacts on a schedule."** You want CSV import and merge fields. Blueticks, Auto Text on Android, or one of the now bulk-capable Chrome extensions. - **"I need it to send while my laptop is closed and my phone is in a drawer."** That rules out on-device Android apps and browser-only plans. You want a gateway-backed offline mode, which on Blueticks is the Pro tier. - **"I want to send a promotional blast and I already use the WhatsApp Business app."** Try native business broadcasts first, budgeting for the per-message fee and the Meta review. For event-triggered messaging at scale, that becomes an API job instead. The honest summary: for most individuals and small businesses working at a computer, a WhatsApp Web scheduler covers it, and you can start free. For Android-only on-device sending, SKEDit or Auto Text is the answer. For true enterprise automation, the API is non-negotiable. Pick by your real volume, not the biggest feature list. ## FAQ: Scheduling WhatsApp messages **Can you schedule WhatsApp messages for free?** Yes, with a third-party tool. On a computer, the Blueticks free plan schedules three messages at a time. On Android, SKEDit's free tier covers five scheduled messages per day and Auto Text is free with ads. WhatsApp has no free scheduler for ordinary chat messages, so a tool is the only real free route. Free is enough for occasional reminders; regular or bulk scheduling is where paid plans start. **Does WhatsApp have a built-in schedule send feature?** Partly, as of 2026. The WhatsApp Business app can schedule business broadcasts at Tools > Business broadcasts, but they are charged per delivered message once your free allowance is used, and Meta reviews every broadcast before it sends. There is still no native way to schedule a regular 1:1 or group chat message, on consumer WhatsApp or in the Business app. Greeting, away, and quick-reply messages are auto-replies triggered by a customer's action, not timed sends. For an ordinary scheduled message you need a third-party tool. **What's the best app to schedule WhatsApp messages in 2026?** For computer users, Blueticks ranks first because it covers one-time scheduling, recurring messages, and bulk campaigns with CSV import in a single Chrome extension on WhatsApp Web. For Android, SKEDit is the simplest free pick and Auto Text is the strongest for bulk. For iPhone, Scheduled is the most capable, though WhatsApp sends still need your tap. For enterprise event-triggered messaging, the WhatsApp Business API is the right layer. **Is a WhatsApp scheduler Chrome extension safe to use?** WhatsApp Web extensions run inside your own logged-in WhatsApp Web session rather than storing your credentials, and they send from your own number. As with any extension, check the permissions it requests and stick to reputable tools. Android schedulers ask for the Accessibility API instead, which is a broad permission worth understanding before you grant it. Avoid blasting non-consenting contacts, since blocks and reports hurt your number regardless of the tool. **Can I schedule recurring WhatsApp messages?** Yes, but not natively. WhatsApp's business broadcast scheduling has no repeat option, and consumer WhatsApp has no scheduler at all. To send daily, weekly, or monthly messages automatically, you need a third-party scheduler that supports recurrence, such as Blueticks on WhatsApp Web, SKEDit or Auto Text on Android, or Scheduled on iPhone. Our [recurring messages guide](https://blueticks.co/blog/schedule-recurring-whatsapp-messages) walks through the setup. [^1]: No-show and recovery figures in the clinic example are illustrative, modeled on the typical lift appointment-reminder programs produce; they are not from a single named clinic. --- # Abandoned Cart WhatsApp Recovery: How to Win Back Lost Sales in 2026 > 70.22% of carts get abandoned. Here is the abandoned cart WhatsApp recovery playbook: sequence timing, template categories, opt-in rules, and the math. URL: https://blueticks.co/blog/abandoned-cart-whatsapp-recovery Published: 2026-06-09 Author: Maya Cohen Category: marketing Seven out of ten people who add to cart never pay. The Baymard Institute puts the documented average online shopping cart abandonment rate at 70.22%, calculated across 50 separate studies ([Baymard Institute, 2026](https://baymard.com/lists/cart-abandonment-rate)). For a store doing $50,000 a month in completed orders, that 70% is not a rounding error. It is the majority of your demand walking out the door after they already told you what they want. Email is the default recovery channel, and it underperforms. Post-Apple Mail Privacy Protection, email open rates sit around 20-25%. WhatsApp recovery messages get read at a far higher rate, which is why stores are moving cart recovery to the channel customers actually open. This guide covers the full abandoned cart WhatsApp playbook: how the 24-hour window works, which template category to use, the recovery sequence timing, the copy, the opt-in rules that keep your number from getting blocked, and how to measure recovery rate and ROAS. ## Why does WhatsApp beat email for abandoned cart recovery? WhatsApp beats email for cart recovery because messages land where the customer already lives. Email open rates run 20-25% after Apple Mail Privacy Protection; WhatsApp read rates run materially higher because the message arrives as a phone notification, not a promotions-tab entry. Higher reads mean more recovered carts from the same abandoner list, which is the only number that matters. Email recovery is not dead. It is just leaky at the top of the funnel. If a recovery email is never opened, the discount inside it never gets seen and the cart never gets recovered. WhatsApp inverts that. The message shows up as a notification on the lock screen, with a read receipt confirming it was seen. Read rates for opt-in WhatsApp broadcasts are commonly measured in the 60-80% range depending on segmentation, versus the 20-25% email benchmark. That gap compounds. If WhatsApp gets read three times more often than email, and your recovery copy and timing are equal, you recover roughly three times the carts from the same list. The other advantage is reply speed. A cart abandoner with a question ("does this ship to my city?", "is the discount stackable?") can answer it inside the same thread in seconds. Email forces a new round trip. As one ecommerce operator running recovery flows put it: "The carts we recover on WhatsApp are the ones where the customer had one small objection. They reply, we answer, they buy. On email that conversation never starts." For the full scaling picture, see our [WhatsApp ecommerce at scale Shopify case study](https://blueticks.co/blog/whatsapp-ecommerce-at-scale-shopify-case-study). [image: Hand reaching for smartphone on cafe table as a notification lights the lock screen] ## What is the 24-hour WhatsApp Business messaging window, and how does it affect cart recovery? The 24-hour window is WhatsApp's rule that a business can send free-form messages to a customer only within 24 hours of that customer's last inbound message. Outside that window, you may only send an approved message template ([Meta for Developers](https://developers.facebook.com/documentation/business-messaging/whatsapp/messages/send-messages)). Cart recovery almost always falls outside the window, so it requires a template. Here is why this matters for recovery. When a customer adds to cart and leaves, they have not messaged you. There is no open 24-hour window. Your recovery message is business-initiated outreach to someone who is not in an active conversation. Per Meta's rules, that message must use a pre-approved template. You cannot just type "Hey, you left something in your cart" and fire it off through the API. That free-form text is only allowed if the customer messaged you in the last 24 hours. The window does help you once the customer replies. The moment an abandoner answers your recovery template, a 24-hour window opens and you can send free-form messages: answer their shipping question, drop a one-time code, send a product photo, all without templates. The compliance trap is this: businesses that try to run recovery as free-form blasts outside the window get messages rejected or, worse, accumulate a poor account quality rating. Build the recovery flow as templates first, free-form conversation second. Our [WhatsApp campaign management guide](https://blueticks.co/blog/whatsapp-campaign-management) covers how to structure those sends. [image: Worker at a packing station preparing ecommerce orders in a small fulfillment warehouse] ## Which WhatsApp template category should you use for abandoned cart messages? Abandoned cart reminders fall under the marketing template category. Meta classifies templates into marketing, utility, authentication, and service. Marketing covers any message with a commercial or promotional objective, including offers and re-engagement; utility covers transactional follow-ups to a user action like order confirmations ([Meta for Developers](https://developers.facebook.com/documentation/business-messaging/whatsapp/templates/template-categorization)). A "come back and buy" nudge is commercial, so it is marketing. This categorization is not optional and you do not get the final say. When you submit a template, you propose a category, and WhatsApp validates the category against the actual content. Review can take up to 24 hours. If you label a cart-recovery message as utility to dodge marketing pricing, Meta re-categorizes it. The line is intent: a pure transactional notice ("Your order #1234 shipped") is utility; anything nudging a purchase that has not happened yet ("Still thinking it over? Here's 10% off") is marketing. This has a direct cost consequence. As of July 1, 2025, Meta moved to per-message pricing, billing per delivered template message by category and recipient country ([Meta for Developers pricing](https://developers.facebook.com/documentation/business-messaging/whatsapp/pricing)). Marketing templates are charged per message; utility templates can be free when delivered inside an open 24-hour window but are charged outside it. So cart recovery (marketing) carries a per-message cost you must price into your recovery-rate math. For the full breakdown, see our [WhatsApp Business API pricing 2026 guide](https://blueticks.co/blog/whatsapp-business-api-pricing-2026). **What breaks:** mis-categorizing a marketing nudge as utility to save money does not save money. Meta re-categorizes it, and a pattern of mislabeled templates drags down your account quality rating, which throttles how many messages you can send. ## How do you set up an abandoned cart WhatsApp recovery sequence (timing and message count)? A WhatsApp cart recovery sequence is a short series of 2-3 templated messages sent over roughly 24-48 hours after abandonment, escalating from a gentle reminder to a time-bound incentive. Keep it short. WhatsApp is a high-intimacy channel, and over-messaging an abandoner who did not opt in tightly is the fastest way to earn a block and damage your sender rating. Here is a recovery sequence that respects the channel and the rules: 1. **Message 1 — 1 hour after abandonment (reminder, no discount).** A marketing-category template: "You left items in your cart. They're still here. Want to finish up?" with a link back to the cart. No incentive yet. Many abandoners just got distracted, and you do not need to give margin away to recover them. 2. **Message 2 — 24 hours later (soft incentive or social proof).** If message 1 got no reply, send a second marketing template. Add a reason to act now: free shipping, a low-percentage code, or a "selling fast / low stock" note if it is true. Do not invent scarcity. 3. **Message 3 — 48 hours after abandonment (final, time-bound offer).** The last touch. A clear expiring incentive: "Your 10% code expires tonight." Then stop. A fourth and fifth message past this point produces blocks faster than sales. Cap the sequence at three. Once an abandoner replies to any message, the 24-hour window opens and you switch to free-form conversation to close them, which is where the highest recovery rates come from. Time each send to the abandoner's local hours where you can; a 3 a.m. cart reminder gets muted. For pacing across a whole abandoner list, our [WhatsApp campaign management guide](https://blueticks.co/blog/whatsapp-campaign-management) covers send scheduling. [image: Small ecommerce business owner reviewing orders at a tidy home-office desk with phone nearby] ## What should each abandoned cart WhatsApp message say? (copy examples) A strong cart recovery message is short, names the specific item, leads with the customer's intent rather than your offer, and includes one clear action. WhatsApp copy that reads like an email blast underperforms. The channel feels personal, so the message should too. Keep each under 40 words and use one link. Message 1 (reminder, marketing template): ``` Hi {{1}}, your {{2}} is still in your cart. Want to finish checking out? Here's your cart: {{3}} ``` Message 2 (incentive, marketing template): ``` Hi {{1}}, still thinking about your {{2}}? Here's free shipping on us if you complete your order today: {{3}} ``` Message 3 (final, time-bound): ``` Last call, {{1}}. Your 10% code SAVE10 expires at midnight. Grab your {{2}} before it's gone: {{3}} ``` The `{{1}}`, `{{2}}`, `{{3}}` are template variables: name, product, cart link. Meta requires variables in approved templates, so you cannot free-type personalization outside an open window. Three rules that lift recovery rate: - **Name the product, not "your items."** Specificity ("your Aergrind hand grinder") reconnects the customer to the exact thing they wanted. - **Lead with their intent.** "Still thinking about your X" outperforms "We have an offer for you." The customer cares about their decision, not your promotion. - **One action only.** One link, one verb. Do not bundle a newsletter signup or a "see more products" into a recovery message. Avoid putting a discount in message 1. If a customer would have bought at full price, an early discount just burns margin. Save the incentive for the second and third touches. For collecting the consent that lets you send these at all, see our [WhatsApp opt-in collection guide](https://blueticks.co/blog/whatsapp-opt-in-collection-guide). ## Do you need opt-in to send abandoned cart WhatsApp messages? Yes. You must collect explicit opt-in before sending any business-initiated WhatsApp message, including cart recovery. Meta requires businesses to obtain opt-in permission, clearly state the business name, and clearly state that the person is agreeing to receive messages, before the first proactive message ([Meta for Developers](https://developers.facebook.com/documentation/business-messaging/whatsapp/getting-opt-in)). Adding to cart is not opt-in. A checkbox consenting to WhatsApp messages is. This is the compliance line that sinks most cart-recovery programs. A customer entering a phone number at checkout has given you a number, not consent to message them on WhatsApp. You need a distinct, affirmative opt-in: a checkbox at checkout ("Send me order and cart updates on WhatsApp"), a click-to-WhatsApp entry point, or a consent captured in your signup flow. The opt-in must name your business and state what they are signing up for. **What breaks:** send marketing-category cart recovery to people who never opted in, and a meaningful share will block or report you. WhatsApp tracks a quality rating on your number, and a run of blocks and reports degrades it. A low quality rating throttles your daily messaging limits and, in the worst case, gets the number flagged. The recovery program that ignores opt-in does not just risk one rejected template; it risks the sender number the entire program runs on. Build opt-in collection before you build the recovery sequence. Our [WhatsApp opt-in collection guide](https://blueticks.co/blog/whatsapp-opt-in-collection-guide) walks through compliant capture points. [image: Boutique retail owner at the counter packaging an order beside a tablet for abandoned cart whatsapp follow-up] ## How do you measure WhatsApp cart recovery rate and ROAS? WhatsApp cart recovery rate is the percentage of abandoned carts that convert to a completed purchase after receiving your recovery sequence. Calculate it as recovered carts divided by total abandoned carts that entered the sequence. Then layer in the per-message template cost to get true ROAS, since marketing templates are billed per delivery. The core formula: **Recovery rate = (carts recovered via WhatsApp / abandoned carts sent the sequence) × 100** Measure it against a holdout. Hold back a random 10% of abandoners who get no WhatsApp sequence. Some of them will return and buy on their own. The honest recovery rate is the lift over that holdout, not the raw conversion of messaged carts. If 12% of messaged carts convert and 4% of the holdout converts on its own, your true WhatsApp-driven recovery rate is the 8-point lift. For ROAS, the cost side is concrete because marketing templates carry a per-message fee under Meta's per-message pricing. If a 3-message sequence costs you the marketing-template rate × up to three sends per abandoner, you can compute exact cost per recovered order: **Cost per recovered order = total template spend / orders recovered** **ROAS = recovered revenue / total template spend** Because abandoners are high-intent (they already chose the product), recovery ROAS typically beats cold acquisition campaigns. Track recovery rate, cost per recovered order, and the holdout lift together. One of those numbers alone will mislead you. ## API vs. scheduled messages: what's the right way to send WhatsApp cart recovery for your store size? The right method depends on volume and automation needs. High-volume, fully automated, real-time cart recovery requires the WhatsApp Business API: approved templates, opt-in management, per-message pricing, and a system that fires the sequence the moment a cart is abandoned. Smaller stores with periodic abandoner lists can run lighter recovery using scheduled and campaign sends through WhatsApp Web tools. The API route is the right answer when you need event-triggered recovery at scale: a cart is abandoned, and within an hour a templated message fires automatically, with the full sequence and opt-in tracking handled by software. That is the model in our [WhatsApp ecommerce at scale Shopify case study](https://blueticks.co/blog/whatsapp-ecommerce-at-scale-shopify-case-study). It carries the template approval process, the per-message marketing-template cost, and the operational overhead of API management. The lighter route fits stores that are not on the full API yet. If you export your abandoned-cart list periodically (say, daily) and want to send a recovery campaign to opted-in customers, a WhatsApp Web tool handles that. Blueticks is a Chrome extension for WhatsApp Web that does message scheduling, recurring messages, and bulk campaigns with CSV import and personalization. To be clear about what it is and is not: Blueticks is the scheduling and campaign layer that runs on top of WhatsApp Web. It does not provide a native ecommerce-platform integration that auto-detects cart abandonment in real time, and it is not a replacement for the WhatsApp Business API for high-volume automated flows. For a store that pulls an abandoner list and sends a scheduled, personalized recovery campaign to consenting customers, it is a fast, low-overhead way to start recovering carts before committing to full API infrastructure. Start where your volume is. If you are recovering a few dozen carts a day from a list, scheduled campaigns get you moving this week. When real-time, event-triggered recovery at thousands of carts becomes the bottleneck, move to the API. [Start recovering lost carts with Blueticks](https://blueticks.co/) ## FAQ **Do abandoned cart WhatsApp messages need to be approved templates?** Yes, when sent outside the 24-hour window, which cart recovery almost always is. A business-initiated message to a customer who has not messaged you in the last 24 hours must use a pre-approved template, and cart-recovery nudges fall under the marketing template category ([Meta for Developers](https://developers.facebook.com/documentation/business-messaging/whatsapp/messages/send-messages)). **How many WhatsApp cart recovery messages should I send?** Two to three over 24-48 hours. A reminder at 1 hour, a soft incentive at 24 hours, and a final time-bound offer at 48 hours. Stop after three. Over-messaging produces blocks and a degraded account quality rating faster than it produces sales. **Can I send a discount in the first cart recovery message?** You can, but it usually wastes margin. Many abandoners were simply distracted and will return on a no-discount reminder. Hold the incentive for the second and third touches so you only discount the customers who actually need the nudge. **Do I need opt-in to send abandoned cart WhatsApp messages?** Yes. Meta requires explicit opt-in before any business-initiated message, and adding to cart does not count. You need a distinct consent, such as a checkout checkbox naming your business and stating they will receive WhatsApp messages ([Meta for Developers](https://developers.facebook.com/documentation/business-messaging/whatsapp/getting-opt-in)). **What is a good WhatsApp cart recovery rate?** Measure lift over a holdout, not raw conversion. Hold back a random 10% of abandoners with no sequence, and report the difference between messaged-cart conversion and holdout conversion as your true recovery rate. That lift, plus cost per recovered order, is the honest scorecard. --- # How to Schedule WhatsApp Messages on WhatsApp Web (Free, Right Inside Your Browser) > Schedule WhatsApp messages free, right inside WhatsApp Web. QR linking, the exact workflow, recurring and offline sends — no native scheduler exists yet. URL: https://blueticks.co/blog/schedule-whatsapp-web-messages Published: 2026-06-08 Author: Daniel Roth Category: productivity You have a message you need to send later. A birthday note for 7 a.m. A payment reminder for Monday. A "we're open" ping to a customer the moment your shop unlocks. You are already at your computer, already in WhatsApp Web, and you do not want to set a phone alarm to remind yourself to tap send like it's 2009. Here is the good news, and the honest version of it. WhatsApp is reportedly building a native "Schedule Send" option, but it is still in development — not yet available to users, and not in a public beta you can opt into. There is no native scheduler in WhatsApp Web today. So if you want to schedule a WhatsApp Web message right now, on any account — and especially if you want recurring sends, a queue of multiple messages, or delivery while your computer is asleep — you need a scheduler that lives in the browser. This guide shows you exactly how to do that, for free, without leaving your browser tab. ## Can you schedule messages on WhatsApp Web? Yes — with a browser extension. A native scheduler is reportedly in development at WhatsApp, but it is not yet available to users and there is no native "send later" in WhatsApp Web today. To schedule on WhatsApp Web on any account, install a browser extension like Blueticks. It adds a clock icon to the chat box for one-time and recurring sends. WhatsApp Web is the version of WhatsApp that runs at web.whatsapp.com inside Chrome, Edge, Firefox, or another Chromium browser. It mirrors the chats on your phone, which means it is the perfect place to type carefully, paste links, and line up messages to go out later. Out of the box, WhatsApp Web shows you a plain send button and nothing else. A native scheduler is reportedly in the works, but it is not available to users yet, so the reliable, available-today path is a scheduler that plugs straight into the page you are already looking at. That is what a tool like [Blueticks](https://blueticks.co) does. It is a browser extension that drops a small clock icon right next to where you type, so scheduling a message feels like part of WhatsApp itself. For the broader picture across devices, see [how to schedule WhatsApp messages](https://blueticks.co/blog/schedule-whatsapp-messages). ## How do you schedule a WhatsApp Web message for free, step by step? Open web.whatsapp.com, install the Blueticks extension, then open any chat. Click the clock icon next to the message box, type your message, pick a date and time, and confirm. The message is queued and sends automatically at that moment. The free tier schedules three messages at a time at no cost. Here is the full walkthrough. [image: Person at a laptop installing a browser extension to schedule whatsapp web messages] 1. **Open WhatsApp Web.** Go to web.whatsapp.com in Chrome, Edge, Firefox, or another Chromium browser and make sure you are logged in (we cover QR linking in the next section). 2. **Install the extension.** Add Blueticks from your browser's extension store. It supports Chrome, Edge, Firefox, and Chromium-based browsers. 3. **Reload the WhatsApp Web tab.** This lets the extension inject its controls into the page. 4. **Open the chat** you want to message, whether it is a person or a group. 5. **Click the clock icon** that now appears next to the message box. 6. **Type your message** in the scheduling panel exactly as you want it to arrive. 7. **Pick the date and time** you want it sent. 8. **Choose one-time or recurring.** Send it once, or repeat it on a daily, weekly, or custom schedule. 9. **Confirm.** Your message joins the queue and sends automatically when the time comes. That's it. No copy-pasting into a separate app, no phone alarms, no native feature you may or may not have access to yet. If recurring is your real need, read [schedule recurring WhatsApp messages](https://blueticks.co/blog/schedule-recurring-whatsapp-messages). ## How do you link your phone to WhatsApp Web with the QR code? Open web.whatsapp.com on your computer to show a QR code. On your phone, open WhatsApp, go to Settings, tap Linked Devices, then Link a Device, and point your camera at the QR code on screen. Your chats sync to the browser within seconds, and the session stays linked. [image: Hands holding a phone toward a laptop screen to link a whatsapp web session by QR] Step by step: 1. **On your computer,** go to web.whatsapp.com. A QR code appears. 2. **On your phone,** open WhatsApp. 3. **Open Linked Devices.** On Android, tap the three-dot menu, then Linked Devices. On iPhone, tap Settings, then Linked Devices. 4. **Tap Link a Device.** Unlock with your face, fingerprint, or PIN if asked. 5. **Scan the QR code** on your computer screen with your phone's camera. 6. **Wait a few seconds** while your chats load into the browser. > **What breaks this:** WhatsApp keeps linked devices active as long as your phone checks in at least once every 14 days. If your phone stays offline past that window, WhatsApp logs out your linked sessions and you will need to scan the QR code again. Keep your phone connected to the internet now and then and you will not hit this. WhatsApp lets you link up to four devices plus your phone, so adding the browser does not push out your other sessions. ## Why is WhatsApp Web better than your phone for scheduling messages? WhatsApp Web gives you a full keyboard, a big screen, and the calm of working at a desk instead of thumbing a phone. You can write longer messages without typos, paste links cleanly, line up several sends in a row, and review everything before it goes out. For anything beyond a quick one-liner, the browser is simply the better cockpit. The phone is built for replying in the moment. The browser is built for planning ahead. When you are setting up reminders, customer follow-ups, or a morning greeting, planning ahead is exactly what you are doing, and a scheduler that lives in WhatsApp Web meets you there. There is also the matter of what the reported native feature would not do. From what has been described, the in-development "Schedule Send" is built around sending one message once. It is not expected to handle recurring sends, a queue of several scheduled messages, or delivery while your computer is closed — and in any case it is not available to use yet. A browser scheduler covers all of that today, which is why it remains the practical choice. If you also work from mobile, compare approaches in [schedule WhatsApp messages on iPhone and Android without the app](https://blueticks.co/blog/schedule-whatsapp-messages-iphone-android-without-app). ## What happens to a scheduled message when you close the WhatsApp Web tab? On the free tier, the scheduler runs inside your browser, so the WhatsApp Web tab needs to be open and your computer awake at send time. If you close the tab or your computer sleeps, the message waits and sends the next time the tab is open and active. To send with the browser fully closed, you need the Pro offline gateway. [image: A closed laptop on an empty desk illustrating a missed whatsapp web scheduled message] > **What breaks this:** A free in-browser scheduler is not magic. It needs the WhatsApp Web tab open and the computer awake to fire a message at the scheduled second. Close the laptop lid, quit the browser, or let the machine sleep, and a free scheduled message will hold until you are back. If your send time is 6 a.m. and your laptop is shut, plan for it: leave the tab open and the machine awake, or move up to the offline gateway below. This is the single most common surprise people hit with any in-browser scheduler, so it is worth saying plainly. Free and in-browser means in-browser. ## How do you schedule WhatsApp Web messages without leaving the browser open (Pro offline gateway)? Blueticks Pro includes an offline gateway that sends your scheduled messages even when your browser and computer are closed. Instead of relying on your local tab, your queue runs on Blueticks infrastructure, so a 6 a.m. message goes out at 6 a.m. whether or not your laptop is awake. It is the upgrade for true set-and-forget scheduling. [image: Data center server racks representing the cloud gateway that sends whatsapp web messages offline] With the free tier, you are the engine: the tab has to be open. With the Pro offline gateway, Blueticks is the engine. You schedule from WhatsApp Web as usual, then shut the lid and walk away. The message still sends. This is what makes overnight reminders, early-morning customer pings, and weekend follow-ups actually dependable. You are no longer betting on your own computer being awake at the right minute. ## Free vs. paid: which WhatsApp Web scheduler do you need? If you schedule the occasional message and do not mind keeping a tab open, the free tier is plenty: it handles three scheduled messages at a time at no cost. If you need recurring messages, several queued at once, or sends that fire while your computer is closed, the Pro offline gateway is the upgrade that removes those limits. Think of it as two questions. First, do you need more than three messages queued, or recurring sends? Second, do you need messages to go out while your computer is off? If the answer to either is yes, Pro is built for you. If not, free does the job. Either way, you are scheduling straight from WhatsApp Web today — something no native option lets you do yet. You can compare both on the [Blueticks pricing page](https://blueticks.co) and start on the free tier to see how it fits your routine. ## Is WhatsApp building a native scheduler? Reportedly yes, but it is in development and not available to users yet. WhatsApp is said to be working on a native "Schedule Send" option, but it is not in a public beta you can opt into, and it would only send a single message once. Recurring messages, a multi-message queue, and guaranteed offline delivery would still be outside its scope. A browser extension covers all of that today. Here is the accurate picture, based on what has actually been reported. WABetaInfo and outlets like MacRumors noted in 2026 that WhatsApp is developing a feature to schedule messages, aimed first at personal accounts on mobile. As described, it would let you pick a date and time for a single message that is then queued and sent automatically. The important caveat: features like this are under development and may change or be dropped before release — and crucially, this one is not yet available to users, even in a stable beta. A few things follow from that. There is no native scheduler you can use in WhatsApp Web today. Even if the personal-account feature ships, it is described as deliberately minimal — one message, one time — with no sign of recurring schedules, no queue of several pending messages you compose in one sitting, and no confirmed desktop support. Some 2026 guides claim it is already "live" or "rolling out in beta," but that goes beyond what the reporting supports, so treat those claims with caution. What does not change is the practical answer for today. If you want to schedule from WhatsApp Web right now, on any account, and you want recurring sends, multiple queued messages, or delivery while your computer is closed, a browser extension is the way to do it. A native feature, if and when it arrives, would be a welcome start — not a replacement for a real scheduling workflow. > "People assume the native option, whenever it finally arrives, will do everything. But what's been described sends one message, once, on personal accounts. The folks who actually run their week on WhatsApp need recurring reminders and a queue they can set up in one sitting from the browser. That gap is exactly where an extension earns its keep." — Blueticks support lead (illustrative) ## FAQ **Is there a native scheduler built into WhatsApp Web?** No. A native "Schedule Send" feature is reportedly in development (per WABetaInfo and others in 2026), but it is aimed at personal accounts on mobile, is not yet available to users, and is not in a public beta. There is no native scheduler in WhatsApp Web today. For scheduling on WhatsApp Web now, with recurring and offline options, use a browser extension like Blueticks. **Do I need to install anything to schedule on WhatsApp Web?** Yes. To schedule reliably today you add a browser extension to Chrome, Edge, Firefox, or another Chromium browser. It installs in a few clicks and adds a clock icon to the WhatsApp Web message box. There is a free tier, so you can try scheduling without paying. **Will my scheduled message send if I close my laptop?** On the free tier, no. The scheduler runs in your browser, so the WhatsApp Web tab must be open and your computer awake at send time. To send with everything closed, use the Blueticks Pro offline gateway, which runs your queue on Blueticks infrastructure. **Can I schedule recurring WhatsApp Web messages?** Yes, with a browser extension. Blueticks supports one-time and recurring schedules, so you can repeat a message daily, weekly, or on a custom pattern. The native WhatsApp beta does not offer recurring sends, which is one of the main reasons people use an extension. **How many devices can I link to WhatsApp Web?** WhatsApp lets you link up to four devices plus your phone. Linked sessions stay active as long as your phone checks in online at least once every 14 days. If it stays offline longer than that, you will need to rescan the QR code to relink. Ready to schedule your first message? Open [Blueticks](https://blueticks.co), add the extension, and send your next WhatsApp Web message on your schedule, not your memory. --- # How to Schedule Recurring WhatsApp Messages in 2026 (Daily, Weekly & Monthly Auto-Reminders) > WhatsApp has no native recurring scheduler. Here's how to set up daily, weekly, and monthly WhatsApp messages that send themselves on autopilot. URL: https://blueticks.co/blog/schedule-recurring-whatsapp-messages Published: 2026-06-07 Author: Daniel Roth Category: productivity You send the same message every week. Rent reminder to a roommate. Monday standup ping to the team. "Did you take your meds?" to your dad. Every single time you have to remember to do it, open the chat, and type it out. Most weeks you forget until it's late. A recurring WhatsApp message fixes that. You write it once, set the cadence, and it sends itself daily, weekly, or monthly without you touching your phone. This guide covers every way to schedule recurring WhatsApp messages in 2026, what WhatsApp can and cannot do on its own, and how to make sure the message actually goes out when you are asleep or offline. ## Can You Schedule Recurring WhatsApp Messages Natively? No. WhatsApp has no built-in scheduler, recurring or otherwise. There is no clock icon, no "send later," and no "repeat weekly" option anywhere in the app. The only timed automation WhatsApp ships is on the Business app, and it only sends auto-replies triggered by an incoming message, not outbound messages you choose to send on a schedule. To be precise about what the Business app actually does: it offers Greeting Messages and Away Messages. A greeting goes out when a customer messages you for the first time. An away message replies when someone contacts you outside your hours. WhatsApp's own [away message scheduling](https://faq.whatsapp.com/2565868990219715/) gives you three options: Always send, a specific custom schedule, and outside of business hours. Notice the pattern. Every one of those is a reply to something a contact sent you. None of them lets you send "Pay rent" to a roommate at 9 AM every Monday on your own initiative. That is the gap. Native WhatsApp is reactive. A recurring reminder is proactive. To get proactive recurring sends you need a tool that sits on top of WhatsApp, and the most direct one runs inside [WhatsApp Web](https://blueticks.co/blog/schedule-whatsapp-messages). ## What Counts as a Recurring WhatsApp Message (Daily, Weekly, Monthly)? A recurring WhatsApp message is one you set up once and that re-sends automatically on a fixed cadence, daily, weekly, or monthly, until you stop it. It differs from a one-time scheduled message, which fires a single time and then disappears. Recurring is for anything that repeats: standups, invoices, check-ins, medication pings. [image: Weekly planner notebook used to map out daily and weekly recurring WhatsApp reminders] Here is the practical breakdown of the three cadences and what each is good for: | Cadence | Sends | Best for | |---------|-------|----------| | Daily | Every day at a set time | Habit nudges, daily standup, medication reminders, end-of-day logs | | Weekly | Same day(s) each week | Team check-ins, weekend plans, weekly report requests, rent-due heads-up | | Monthly | Same date each month | Invoices, subscription reminders, rent, monthly report nudges | The difference matters because the wrong cadence creates noise. A daily "did you finish the report?" to a contractor who delivers weekly will get muted fast. Match the cadence to how often the thing actually repeats. Tools like Blueticks expose "One-time or recurring" and a "Repeat every" control so you pick the interval at setup time. If your need is a single future send instead of a repeating one, that is a [scheduled WhatsApp message](https://blueticks.co/blog/schedule-whatsapp-messages), not a recurring one. ## How Do You Set Up a Recurring WhatsApp Message That Sends Itself? You install a WhatsApp Web scheduler extension, open the chat you want to message, click the clock icon in the message box, write the message, choose "recurring," and set the interval. The extension then sends that message automatically on your chosen cadence. The whole setup takes under a minute per reminder. The tool most people use for this is [Blueticks](https://blueticks.co/), a Chrome extension trusted by over 200,000 users that adds a scheduling clock icon directly inside WhatsApp Web. It is built for exactly this: one-time and recurring sends to individuals, groups, channels, and communities. Once a recurring message is set, you do not re-enter it each week. It fires on its own. A quick note on why a browser extension and not a phone app: scheduling lives where the typing happens. WhatsApp Web is a full keyboard interface, so writing a clean recurring message, attaching a file, or scheduling several at once is faster there than thumb-typing on a phone. If you are coming from mobile, see the [iPhone and Android approaches](https://blueticks.co/blog/schedule-whatsapp-messages-iphone-android-without-app) for why the phone-only routes stay manual. [image: Person at a laptop scheduling a recurring WhatsApp message during a quiet work session] > "The reminders I forget to send are the ones that matter most. Setting them recurring once and never touching them again is the entire point. The reminder that needs me to remember it has already failed." — synthetic operator note, reflecting a common power-user workflow ## How to Schedule Recurring Messages on WhatsApp Web (Step-by-Step) To schedule a recurring message on WhatsApp Web, install the Blueticks extension, open WhatsApp Web, select a chat, click the clock icon in the message box, type your message, switch the schedule type to recurring, set the interval and time, then save. The message sends on that cadence automatically from then on. Here is the exact workflow: 1. **Install the extension.** Add [Blueticks from the Chrome Web Store](https://blueticks.co/) to Chrome, Edge, or another Chromium browser. It also runs on Firefox. 2. **Open WhatsApp Web.** Go to web.whatsapp.com and scan the QR code with your phone if you are not already logged in. 3. **Open the target chat.** Click the contact, group, or channel you want the recurring message to go to. 4. **Click the clock icon.** It appears in the message input box next to where you type. This opens the scheduler. 5. **Write your message.** Type the text. Attach an image or document if the reminder needs one. 6. **Choose recurring.** Switch the schedule type from one-time to recurring, then set the "Repeat every" interval to daily, weekly, or monthly and pick the time. 7. **Save.** The message is now queued. It will send on your cadence without further action. **What breaks:** if you only have the basic browser-sending setup, WhatsApp Web must stay open and the computer must be awake at send time. Close the tab, sleep the laptop, or lose Wi-Fi, and the scheduled send is skipped. That is the single most common reason a recurring message fails to go out. The fix is the offline gateway, covered further down. ## Which Recurring Reminders Are Worth Automating? (Payments, Birthdays, Standups, Follow-ups) The reminders worth automating are the ones that repeat on a predictable schedule and cost you something when you forget: rent and invoice reminders, recurring team standups, follow-up nudges to leads, and personal check-ins. If a message has a fixed cadence and a real consequence for being late, it belongs on a recurring schedule. [image: Hands sorting monthly bills, the kind of recurring payment reminder worth automating on WhatsApp] Concrete uses that map cleanly to the three cadences: - **Daily:** A standup prompt to your team at 9 AM. A "log your hours" nudge to contractors at 5 PM. A medication or hydration ping to a family member. Blueticks itself points to "recurring daily checkups for team members" as a core use. - **Weekly:** A rent-due heads-up to a roommate every Friday. A weekly report request to a direct report every Monday. A "still interested?" follow-up to a warm lead. - **Monthly:** An invoice or payment reminder on the 1st. A subscription-renewal heads-up. A monthly metrics request to each team lead. One honest caveat: recurring messages are for one-to-one or small-group reminders where the same text genuinely repeats. The moment you need different content per recipient, or you are sending to hundreds of people, you have crossed into broadcast territory, which is a different feature with different rules. More on that next. For repeated business-facing sends to a single client, the [WhatsApp Business scheduling guide](https://blueticks.co/blog/schedule-whatsapp-business-messages) covers the tradeoffs. ## How Do You Edit, Pause, or Stop a Recurring WhatsApp Message? You manage recurring messages from the scheduler's queue or scheduled-messages list, where every pending and recurring send is visible. From there you can edit the text or time, pause the cadence, or delete the recurring rule entirely. Changes apply to all future sends; messages already delivered are not affected. The important mental model: a recurring message is a rule, not a single queued item. When you edit it, you are editing every future send. When you delete it, you stop the whole series, not just the next one. So if your roommate moves out, you delete the rule once and the Friday rent pings stop for good. Practical steps: 1. Open WhatsApp Web with the extension active. 2. Open the scheduled messages list from the extension's clock or dashboard. 3. Find the recurring message by recipient and time. 4. Edit the text or interval to change future sends, or delete it to end the series. **What breaks:** if you edit a recurring message while the laptop is asleep and the offline gateway is not enabled, the change still saves, but the next send can still be skipped because there is nothing awake to fire it. Editing the rule and keeping the send mechanism alive are two separate things. Verify both. ## Recurring Personal Messages vs. Recurring Broadcasts: Which Do You Need? Choose recurring personal messages when the same text goes to one person or a small fixed group on a cadence, like a standup ping or a rent reminder. Choose a recurring broadcast or campaign when you are sending to many recipients at once, especially with personalization. The line is roughly the difference between a reminder and a marketing send. [image: Small team around a table, the audience for recurring daily standup WhatsApp reminders] A simple way to decide: | You need | Use | |----------|-----| | Same message, one person or small group, repeating | Recurring personal scheduled message | | Same message, many recipients, repeating or one-off | Broadcast / campaign | | Different message per recipient at scale | Campaign with personalization | The reason this matters is deliverability and risk. Blasting identical text to hundreds of contacts from a personal account is the fastest way to get rate-limited or flagged. A handful of recurring personal reminders to people who expect them is low-risk. A 500-recipient recurring blast is a campaign, and campaigns have their own pacing, opt-out, and template considerations. If your recurring need is really a list send, treat it as a campaign from the start, not a stretched personal reminder. ## How to Make Sure a Recurring Message Actually Sends When You're Offline To guarantee a recurring message sends when your computer is off, you need an offline gateway: a server-side send mode that fires your scheduled messages even with WhatsApp Web closed and the laptop asleep. Without it, scheduling runs in your browser, so the message only sends if the tab is open and the machine is awake at send time. This is the failure mode that catches everyone. The default browser-only setup is convenient but fragile. WhatsApp Web is the engine, so when the engine is off, nothing sends. A recurring 9 AM standup is useless if your laptop is closed at 9 AM, which it usually is. Blueticks addresses this with an offline capability on its Pro plan, described on the site as messages that send "even when your browser is closed." That moves the send off your machine and onto a hosted gateway, so the recurring schedule keeps firing whether your laptop is open, asleep, or shut down entirely. **What breaks, and how to be sure it does not:** - **Browser-only plans skip sends when the tab is closed or the laptop sleeps.** If you are on a basic browser-sending tier, leave WhatsApp Web open and disable sleep, or upgrade to the offline gateway. - **Phone disconnected from WhatsApp Web.** WhatsApp Web links to your phone. If the linked session expires, sends stop until you re-scan. Check the session periodically. - **Test the first recurrence.** Set the first send a few minutes out, close the tab if you are relying on offline mode, and confirm it actually arrives before you trust it for anything important. The honest takeaway: recurring scheduling is only as reliable as the thing doing the sending. Browser mode is fine for messages you can afford to miss. For anything with a real consequence, payroll pings, invoice reminders, medication checks, put it on the offline gateway and verify it once. Ready to set up your first recurring reminder? [Install Blueticks from the Chrome Web Store](https://blueticks.co/) and add a recurring message in under a minute. ## FAQ **Can WhatsApp schedule recurring messages without an extension?** No. Neither the standard WhatsApp app nor WhatsApp Business has a native scheduler for outbound messages. The Business app only sends auto-replies triggered by incoming messages. To send a recurring message on your own schedule you need a third-party tool like the Blueticks WhatsApp Web extension. **Will a recurring message send if my computer is off?** Only if you use an offline gateway. In the default browser-only setup, scheduling runs inside WhatsApp Web, so the message is skipped if the tab is closed or the laptop is asleep. Blueticks offers an offline capability on its Pro plan that sends even when your browser is closed. **Can I send recurring messages to a WhatsApp group?** Yes. A WhatsApp Web scheduler like Blueticks supports recurring sends to individuals, groups, channels, and communities. Open the group chat, click the clock icon, write the message, and set it to recurring. **How do I stop a recurring WhatsApp message?** Open the scheduled messages list in the extension, find the recurring rule by recipient and time, and delete it. Deleting the rule stops the entire series, not just the next send. Messages already delivered are unaffected. **Is it safe to automate WhatsApp reminders?** For one-to-one and small-group recurring reminders to people who expect them, the risk is low. The risk rises when you send identical messages to large lists from a personal account, which can trigger rate limits. For high-volume recurring sends, use a campaign or broadcast feature built for it rather than a personal scheduled message. --- # How to Build a WhatsApp Drip Sequence That Converts (2026 Guide) > A broadcast is one shot. A drip sequence is a system that follows up automatically. Here's how to build a WhatsApp drip sequence that converts in 2026 — triggers, timing, and the platform rules you can't ignore. URL: https://blueticks.co/blog/whatsapp-drip-sequence Published: 2026-06-06 Author: Maya Cohen Category: marketing You captured a lead. They replied once, asked a price, then went quiet. You meant to follow up. You didn't. Three days later the deal was cold, and you have forty more leads in exactly the same state. That is the problem a WhatsApp drip sequence solves. Instead of you remembering to chase every contact at the right moment, a pre-built series of timed messages does it for you. This guide walks the whole build for 2026: what a drip sequence actually is, the types that convert, how to set one up step by step, how many messages to send and how far apart, and the platform rules that decide whether your messages arrive at all. We'll be honest about what's possible on the free Business app versus the API versus a tool like Blueticks, because that distinction changes everything. ## What is a WhatsApp drip sequence (and how is it different from a broadcast)? A WhatsApp drip sequence is a pre-built series of messages sent to one person automatically, spaced over time or triggered by an action like a signup or a purchase. A broadcast is a single message sent to many people at once. The drip follows the individual; the broadcast hits the crowd. That difference is why a whatsapp automated follow up converts where a one-off blast stalls. Think of it as the difference between a megaphone and a conversation. A broadcast is the megaphone: same message, same second, everyone on the list. A drip sequence, also called a whatsapp follow up sequence or whatsapp nurture sequence, is closer to a smart assistant who messages each new lead on day 0, checks back on day 2, and sends a final nudge on day 5, without you touching anything. The mechanics behind that are simple. Each message in a drip has a trigger (a signup, an abandoned cart, a date) and a delay (an hour, a day, a week). The trigger fires, the clock starts, the next message sends. Your job is to design the sequence once. After that it runs on its own for every contact who enters it. Here's the practical split: | | Broadcast | Drip sequence | |---|---|---| | Audience | Many people, one send | One person, many sends over time | | Trigger | You hit send | An action or a time delay | | Goal | Announce, promote | Nurture, follow up, convert | | Effort per contact | Manual every time | Build once, runs forever | | Typical use | Flash sale, new launch | Onboarding, lead nurturing, cart recovery | Broadcasts still have their place. For the full broadcast workflow, including segmentation and compliant sends, see our guide on [WhatsApp campaign management](https://blueticks.co/blog/whatsapp-campaign-management). This article is about the other half: the automated follow-up that runs while you sleep. ## What types of WhatsApp drip sequences actually work? The WhatsApp drip sequences that consistently convert are tied to a clear trigger and a clear next step: lead nurturing after a form fill, abandoned-cart recovery, post-purchase onboarding, win-back for dormant contacts, and event or appointment reminders. Each one catches the contact at a moment of intent and walks them to the next action, instead of hoping a single message lands at the right second. [image: Hands arranging labeled sticky notes representing different WhatsApp follow-up sequence types on a glass wall] Five sequences earn their keep: 1. **Lead nurturing.** Someone fills a form or replies to an ad. A 3-touch whatsapp lead nurturing sequence introduces you, answers the obvious objection, then asks for the call or the order. Most B2B leads need more than one touch before they buy, and a sequence is how you deliver those touches without a human chasing each one. 2. **Abandoned-cart recovery.** The contact added to cart and left. A reminder within the hour, an incentive a day later, a final scarcity nudge after three days. WhatsApp is a strong recovery channel because the message lands in a thread the customer already reads. 3. **Post-purchase onboarding.** New customer, new sequence. Welcome, setup tip, then a check-in. This is where you reduce refunds and earn the second purchase. 4. **Win-back.** Dormant 90-plus days. One honest re-engagement message beats fourteen more flash-sale alerts they've already learned to ignore. 5. **Reminders.** Appointment, webinar, renewal. A confirmation, a 24-hour reminder, a 1-hour heads-up. This sequence alone can cut no-shows hard. The common thread: every one of these is a reply-or-action moment, not a cold blast. That's why drip beats broadcast on conversion. The sequence is built around what the contact just did. One honest caveat before you build any of these. True automated drips need a real scheduler. The free WhatsApp Business app has greeting messages and quick replies, but no native sequencer that fires message 2 a day after message 1. For genuine sequencing you need the WhatsApp Cloud API, or a tool that schedules sends for you. More on that split below. ## How do you set up a WhatsApp automated follow-up sequence step by step? Set up a WhatsApp automated follow-up sequence in five steps: confirm opt-in, pick a single trigger, map 3 to 4 timed messages, write each one to drive a specific action, then schedule the delays so the sequence runs without manual sends. Lock the opt-in first. Without documented consent, the rest of the sequence is a compliance problem, not a marketing one. [image: Marketer working through the steps to set up a WhatsApp automated follow-up sequence at a tidy desk] Here's the working build: 1. **Confirm opt-in.** Every contact in the sequence needs an explicit, recorded opt-in: your business name, WhatsApp named as the channel, the message types, and an opt-out path. A pre-checked box doesn't count. If your front-of-funnel consent is shaky, fix it first with our [WhatsApp opt-in collection guide](https://blueticks.co/blog/whatsapp-opt-in-collection-guide). 2. **Pick one trigger.** Signup, purchase, cart abandonment, or a calendar date. One trigger per sequence keeps the logic clean. "When someone fills the demo form" is a trigger. "When it feels right" is not. 3. **Map the touches.** Write down each message and its delay before you draft a word. A lead-nurture spine might be: Touch 1 immediately, Touch 2 at 48 hours, Touch 3 at day 5. Mapping first stops you from improvising a seven-message marathon nobody wants. 4. **Write each message to one action.** Every touch has a single job: book the call, claim the code, reply with a question. One message, one ask. For copy you can lift, our [WhatsApp campaign templates that convert](https://blueticks.co/blog/whatsapp-campaign-templates-that-convert) library covers cart recovery, win-back, and reminder copy with timing. 5. **Schedule the delays.** Set the trigger, set each delay, and let it run. This is the step the free app can't do on its own. [Blueticks](https://blueticks.co/scheduler) handles recurring and timed sends from your WhatsApp account, so the 1-hour, 48-hour, and day-5 touches fire on schedule without anyone clicking send at midnight. A note on the 24-hour window, because it governs how you build. When a contact messages you, you can send free-form replies for 24 hours after their last message, per the [WhatsApp Business Platform docs](https://www.twilio.com/docs/whatsapp/key-concepts). Outside that window, on the API you can only send an approved template. So a sequence that follows a customer's inbound reply can run free-form inside 24 hours; a sequence that reaches out cold, days later, needs an approved marketing or utility template. Design your delays with that line in mind. ## How many messages should a WhatsApp nurture sequence have — and how far apart? A WhatsApp nurture sequence should run 3 to 5 messages spaced over 5 to 14 days for most use cases. Front-load value, widen the gaps as you go, and stop the moment the contact converts. Fewer, well-timed touches beat a long drip, because WhatsApp caps how much marketing any one person receives, and over-sending triggers blocks that hurt your deliverability. [image: An analog clock beside a face-down smartphone on a cafe table representing WhatsApp message timing and spacing] There's no universal number, but the failure modes are predictable. Two messages is usually too few to overcome inertia. Eight is too many and starts earning blocks. The sweet spot for a whatsapp nurture sequence sits between three and five, with the cadence matched to the use case: | Sequence type | Messages | Spacing | |---|---|---| | Abandoned cart | 3 | 1 hour, 24 hours, 72 hours | | Lead nurturing | 3 to 4 | Day 0, day 2, day 5, day 9 | | Post-purchase onboarding | 3 to 5 | Day 0, day 1, day 7, day 14, day 30 | | Win-back | 2 to 3 | Day 0, day 3, day 7 | | Event reminder | 3 | At booking, 24 hours before, 1 hour before | Two platform rules cap your enthusiasm, and you have to respect both. First, the 24-hour customer-service window: outside it, marketing or utility outreach needs an approved template, so a long drip of cold free-form messages simply won't send on the API. Second, Meta limits how many marketing template messages a single user receives per day across all businesses combined, returning error 131049 when a user is saturated ([Meta's per-user marketing template limits](https://developers.facebook.com/documentation/business-messaging/whatsapp/templates/marketing-templates/per-user-limits/)). Widely reported as roughly two marketing messages per user per day, the exact ceiling is dynamic and personalized by Meta, not a fixed public number, so don't plan around a specific figure. Plan around the principle: send fewer, more relevant touches. > "We cut our nurture from seven messages to four and conversions went up. The extra three messages weren't nurturing anyone. They were training people to mute us." (Synthetic operator quote, representative of the over-sending pattern these limits exist to curb.) The rule of thumb: each message should earn the next one. If touch 2 adds nothing touch 1 didn't, cut it. ## How do you build a WhatsApp onboarding sequence for new customers? Build a WhatsApp onboarding sequence by triggering it on the purchase or signup, then sending 3 to 5 messages over the first 30 days: a same-day welcome, a day-1 setup nudge, a day-7 check-in, and a day-30 next-step or upsell. The goal is activation, not selling. A customer who reaches their first win early refunds less and buys again. A worked example. Take a fictional skincare subscription brand, call them Lumen Skincare. They sold well but churned hard: customers bought one box, never set up the routine, and cancelled by month two. They built a five-touch onboarding drip on the purchase trigger: 1. **Day 0, welcome.** Order confirmed, what arrives when, one line on how to start. No selling. 2. **Day 1, setup.** "Your kit ships tomorrow. Here's the 2-minute routine that makes it work." Pure value. 3. **Day 7, check-in.** "How's week one? Reply if anything's unclear." This message opens a 24-hour window every time someone replies, which lets support answer free-form. 4. **Day 14, social proof.** A short result story from a similar customer. 5. **Day 30, next step.** The upsell or the resubscribe nudge, timed to when the first box runs low. The numbers Lumen reported afterward, illustrative but within plausible ranges for this kind of activation work: the day-7 check-in pulled a 38% reply rate, month-two retention rose noticeably, and the day-30 upsell landed because it arrived exactly when the product ran out, not on an arbitrary calendar date. (Synthetic example; treat the figures as directional, not a guarantee.) The mechanic that makes onboarding sequences special: the check-in messages are reply-bait by design. Every reply opens the 24-hour service window, so your support team can answer free-form without burning a template. That turns a one-way drip into a two-way relationship. To keep all five touches firing on schedule across every new customer, [Blueticks's scheduler](https://blueticks.co/scheduler) runs the timed sends from your WhatsApp account, so day 7 and day 30 don't depend on anyone remembering. ## What metrics tell you if your WhatsApp drip sequence is working? The metrics that matter for a WhatsApp drip sequence are delivery rate, reply rate, per-step drop-off, conversion rate, and block or unsubscribe rate. Skip open rate as a comparison metric: WhatsApp opens run near-universal, so they can't separate a good sequence from a bad one. Watch where contacts fall out of the sequence and what share take the final action. [image: Analyst reviewing a printed WhatsApp drip sequence performance report with charts at a desk] Because almost every WhatsApp message gets opened, the open rate is a vanity number here. The signal lives downstream. Track these per step, not just per sequence: | Metric | What it tells you | |---|---| | Delivery rate | List quality and template/cap issues. A drop means blocks or saturation | | Reply rate per step | Which message actually engages, and which is dead weight | | Step drop-off | Where contacts go quiet, so you can cut or rewrite that touch | | Conversion rate | The money metric: who took the final action | | Block / unsubscribe rate | Your early warning. Climbing block rate means you're over-sending | The per-step view is what separates a tuned sequence from a guessed one. If touch 3 has the same reply rate whether you send it or not, it's noise. If 40% of contacts drop after touch 2, that message is the leak. Fix the leak before you add more messages. One number to anchor on: your block and unsubscribe rate. Keep it low. A rising block rate doesn't just lose contacts, it drags your quality rating, which throttles delivery for everyone else in the sequence. If a sequence converts at 6% but blocks at 4%, it's quietly poisoning your account. The best whatsapp sequence tool ties each send to its outcome so you can see this without a spreadsheet. For the full analytics breakdown including revenue per recipient, see our [WhatsApp campaign management](https://blueticks.co/blog/whatsapp-campaign-management) guide. ## App vs API vs tool: what can actually run a drip? Be clear-eyed about where you build. The free WhatsApp Business app gives you a greeting message and quick replies, but no true sequencer: it can't fire message 2 forty-eight hours after message 1 on its own. The WhatsApp Cloud API can run full automated sequences, but it's a raw HTTP interface with no built-in campaign builder, so you're either coding it or paying a provider. A WhatsApp sequence tool sits in the middle: for smaller lists, it schedules timed and recurring sends from your existing WhatsApp account without an API integration. | Option | Native drip automation? | Best for | |---|---|---| | WhatsApp Business app | No native sequencer | Manual replies, tiny operations | | WhatsApp Cloud API | Yes, but build-it-yourself | High volume, dev resources, CRM integration | | Scheduling tool (e.g. Blueticks) | Yes, scheduled timed sends | Smaller lists, no-code, runs from WhatsApp Web | Match the tool to your scale. A team nurturing a few hundred leads a month doesn't need a full API stack and the developer time that comes with it. A high-volume operation sending tens of thousands of templates a day does. Overbuilding costs money and time you won't get back; underbuilding means you're back to forgetting follow-ups. If you're running smaller, opted-in lists and want sequences without standing up an API integration, [Blueticks runs directly in your browser](https://chromewebstore.google.com/detail/blueticks/adgnjhngogijkkppficiiepmjebijinl) on WhatsApp Web. Map your triggers and delays once, and the sequence runs on schedule. [Install the Chrome extension](https://chromewebstore.google.com/detail/blueticks/adgnjhngogijkkppficiiepmjebijinl) and build your first follow-up sequence in under ten minutes. ## FAQ **What is a WhatsApp drip sequence?** A WhatsApp drip sequence is a pre-built series of messages sent to one contact automatically, spaced by time or triggered by an action like a signup or purchase. Unlike a broadcast, which sends one message to many people at once, a drip follows the individual: message 1 on day 0, message 2 two days later, and so on. It's how you deliver consistent follow-up at scale without chasing each lead by hand. Common types include lead nurturing, abandoned-cart recovery, onboarding, and win-back. **Can I send automated WhatsApp sequences from the free Business app?** Not really. The free WhatsApp Business app offers greeting messages, away messages, and quick replies, but it has no native scheduler that fires a follow-up message a day or a week later on its own. For genuine automated sequencing you need the WhatsApp Cloud API, which can run full drips but requires development work, or a scheduling tool like Blueticks that handles timed and recurring sends from your existing WhatsApp account for smaller lists without an API integration. **How many messages should a WhatsApp follow-up sequence have?** For most use cases, 3 to 5 messages spaced over 5 to 14 days. Abandoned-cart sequences run tighter (1 hour, 24 hours, 72 hours); onboarding sequences stretch across 30 days. Front-load the value and widen the gaps as you go. Don't over-send: Meta limits how many marketing template messages a single user receives per day across all businesses combined, so a long drip can fail to deliver and rising block rates hurt your quality rating. **Do I have to use approved templates for a WhatsApp drip sequence?** It depends on timing. When a contact messages you, you can send free-form replies for 24 hours after their last message. Inside that window, sequence messages don't need a template. Outside it, on the WhatsApp Business API, you can only send approved marketing, utility, or authentication templates. So a sequence that follows a customer's reply can run free-form within 24 hours, while cold outreach days later needs an approved template. Build your delays with that 24-hour line in mind. **Why aren't my WhatsApp sequence messages being delivered?** Three common causes in 2026. First, the recipient is a US (+1) number: Meta paused marketing template messages to US numbers starting April 1, 2025, and the pause is still in effect, so marketing simply doesn't arrive. Second, the user hit Meta's per-user marketing message cap (error 131049) after receiving too many marketing templates that day across all businesses. Third, your list includes non-opted-in contacts dragging down your quality rating. Segment out US contacts for marketing, respect the cap, and clean your list. *Benchmark and policy note: the 24-hour customer-service window, the per-user marketing template cap (error 131049), the US marketing pause (effective April 1, 2025), and per-message billing trace to Meta's WhatsApp Business Platform documentation and the WhatsApp Business Messaging Policy. Reply, conversion, and retention figures in the worked examples are illustrative ranges, not guarantees; your results vary by list quality, offer, and market.* --- # WhatsApp Broadcast Limit: How to Send to More Than 256 Contacts in 2026 > 256 contacts per broadcast list, and half of them may never see your message. Here is how the WhatsApp broadcast limit really works in 2026, and how to get past it. URL: https://blueticks.co/blog/whatsapp-broadcast-limit Published: 2026-06-05 Author: Avi Kohen Category: industry You built a broadcast list, added your customers, and hit send. WhatsApp let you add 256 people, then stopped. And of the 256 who made the list, a chunk never got the message at all, with no error and no warning. That is the WhatsApp broadcast limit doing two different jobs at once. There is a hard cap on list size, and there is a silent delivery filter that most people never notice until a campaign underperforms. This guide covers both: where the 256 number comes from, why broadcasts fail to land, and the legitimate ways to send to more than 256 contacts in 2026 without getting your account flagged. ## What is the WhatsApp broadcast limit (and why does it exist)? The WhatsApp broadcast limit is 256 contacts per broadcast list in the WhatsApp Business app and the standard app. A broadcast sends one message to many people as separate one-to-one chats, so each recipient sees a private message and replies only to you. The 256 cap exists to keep broadcasts a personal-messaging feature, not a mass-marketing channel. A broadcast list is not a group. When you send to a list, every recipient gets the message in their own chat thread, as if you messaged them directly. They cannot see who else received it, and their replies come back to you alone. That privacy model is the whole point, and it is also why WhatsApp treats broadcasts as conversational rather than promotional. The cap is consistent across both apps. Per [WhatsApp's Help Center guide on broadcast lists](https://faq.whatsapp.com/861663048350950/), a single list holds a maximum of 256 contacts. The WhatsApp Business app adds label-based selection on top, so you can build a list by filtering contacts tagged "VIP" or "New customers," but the ceiling does not move. Label filtering changes how you pick the 256, not how many you get. Why 256 specifically? It is a deliberate friction point. WhatsApp built broadcasts for the corner shop messaging its regulars, not for a brand blasting a list of 50,000. The moment you need real scale, the platform wants you on the Business Platform (the API), where sending is metered, priced, and quality-controlled. The 256 wall is the nudge. ## How does the 256-contact cap work on WhatsApp Business app vs the API? The WhatsApp business broadcast limit of 256 applies only to the WhatsApp Business app, the free app you install on a phone. The WhatsApp Business Platform (Cloud API) has no 256-contact list concept at all. Instead it limits how many unique people you can message in a rolling 24 hours, starting at 250 and scaling to unlimited as your account earns trust. These are two completely different products with two completely different limit models. Confusing them is the single most common mistake in this space. | | WhatsApp Business app | WhatsApp Business Platform (Cloud API) | |---|---|---| | Limit type | 256 contacts per broadcast list | Unique customers per rolling 24h | | Starting limit | 256 per list, unlimited lists | 250 unique customers/day | | Recipient must save your number | Yes | No | | Opt-in required | Best practice | Mandatory | | Scales to | Manual, list by list | 1K, 10K, 100K, unlimited | | Per-message billing | Free | Yes, since July 1, 2025 | | Setup | Install and go | Business verification + a provider | On the app, the 256 cap is per list, and you can create more than one list. So "how many contacts in whatsapp broadcast" has a two-part answer: 256 per list, unlimited lists, but you send to each list separately and manually. Nothing pools them into one send. On the API, there is no list object that caps at 256. According to [Meta's messaging limits documentation](https://developers.facebook.com/documentation/business-messaging/whatsapp/messaging-limits), a new phone number starts at 250 unique recipients per 24-hour window, then climbs through defined tiers: 1,000, then 10,000, then 100,000, then unlimited. The constraint is how many distinct people you reach in a day, not how many fit in a list. [image: Small business owner comparing the WhatsApp Business app and API on two devices at a desk] One detail that trips up teams scaling on the API: as of October 2025, messaging limits are calculated at the business portfolio level and shared across every phone number in that portfolio. Adding a second number does not double your daily capacity. Both numbers draw from the same tier. Plan your number architecture around the shared pool, not around per-number math. ## Why is your WhatsApp broadcast not delivering to everyone? The most common reason a WhatsApp broadcast is not delivering is that recipients have not saved your phone number. On the Business app, broadcast messages only reach contacts who have your number saved in their address book. If they have not saved you, the message is silently dropped. No error appears on your end. This is the rule that surprises everyone. You can add someone to a broadcast list and send to them, and WhatsApp will show the send as going out, but the recipient receives nothing because your number is not in their contacts. The list does not validate this. It will happily include 256 people and quietly deliver to only the subset who saved you. For a typical business list, that subset is often a minority. If you imported customers from a CRM and most of them never saved your business number, your effective reach can be a fraction of 256, even though the app reports a clean send. This is why "whatsapp broadcast not delivering" is almost always a contacts problem on the app, not a bug. There are a few other delivery killers worth knowing: - **Number not saved (app).** The big one. No save, no delivery. There is no workaround inside the Business app. - **Not opted in (API).** On the API, you can reach people who have not saved you, but only if they opted in. Messaging non-consenting numbers tanks your quality rating fast. - **Per-user marketing cap (API).** Meta limits each user to roughly two marketing template messages per day across all businesses combined. Exceed it and the send fails with error 131049, "not delivered to maintain a healthy ecosystem." The cause is the recipient's daily ceiling, not your account. - **US marketing pause (API).** Marketing template messages to US numbers (+1 country code) have been paused since April 1, 2025. Utility and authentication templates still deliver; marketing simply does not arrive, with no clear error. - **Quality rating throttling (API).** A "Low" quality rating from blocks and reports can cap or freeze your sends regardless of your tier. If you are running broadcasts off the app and seeing weak numbers, audit the saved-number issue first. It explains more failed broadcasts than every other cause combined. For the consent side of the equation, our [WhatsApp opt-in collection guide](/blog/whatsapp-opt-in-collection-guide) covers the channels and wording Meta now requires before any API send is allowed. ## How do you send a WhatsApp broadcast to more than 256 contacts? To send a WhatsApp broadcast to more than 256 contacts, you have two legitimate paths. On the free Business app, create multiple broadcast lists of 256 and send to each one separately. For genuine scale and reliable delivery, move to the WhatsApp Business Platform (the API), which removes the 256 list cap and delivers to people who have not saved your number, provided they opted in. The multiple-list workaround is real, but understand what it actually buys you. You are not bypassing the limit. You are repeating a manual send across however many lists you build. Three lists of 256 is three separate send actions, three sets of recipients who still need to have saved your number, and zero analytics tying it together. | Approach | Reach | Delivery reliability | Effort | |---|---|---|---| | Single broadcast list | Up to 256 | Only saved contacts | Low | | Multiple lists (app) | 256 x N lists | Only saved contacts | Linear, manual | | WhatsApp Business Platform (API) | 250 to unlimited per 24h | Opted-in, no save needed | Setup, then automated | The multiple-list path suits a small operation reaching a few hundred regulars who already have its number. The moment you need to reach thousands, or reach people who have not manually saved you, the app stops being the right tool. That is the threshold where the API earns its setup cost. There is a middle ground worth naming. If you are running off WhatsApp Web rather than the API, a scheduling layer can queue and stagger your sends across lists so you are not babysitting the app, and it can keep your campaigns organized instead of scattered across manual broadcasts. [Blueticks campaigns](/blog/whatsapp-campaign-management) handle scheduled and recurring sends from your existing WhatsApp account, which fits teams that have outgrown manual broadcasts but are not ready to stand up a full API integration. [image: Marketer planning how to send a WhatsApp broadcast to more than 256 contacts] ## What is the WhatsApp broadcast message limit per day? On the WhatsApp Business app, there is no published per-day broadcast message limit, but sending to many lists in quick succession can trigger temporary throttling or a ban if it looks like spam. On the WhatsApp Business Platform, the daily limit is explicit: a tiered number of unique customers per rolling 24 hours, from 250 up to unlimited. The app has no official daily counter, which leads people to assume there is no limit. There is, it is just behavioral. WhatsApp's automated systems watch for spike patterns, high block rates, and messages to people who never saved you. Hit those signals and you risk a temporary block or, repeated, a permanent ban. The absence of a published number is not permission to blast. The API is where the daily limit is concrete and worth memorizing. Per [Meta's messaging limits documentation](https://developers.facebook.com/documentation/business-messaging/whatsapp/messaging-limits), the tiers are: - **250** unique customers per 24 hours (new, unverified numbers) - **1,000** unique customers - **10,000** unique customers - **100,000** unique customers - **Unlimited** Movement up the tiers is automatic and trust-based. Meta evaluates your eligibility on a recurring cycle (every six hours in the current system) and promotes you when your sending volume and quality rating clear the bar. In 2026, a business that completes verification can jump straight to the 100,000 tier rather than crawling up from 250, which materially shortens the ramp for legitimate senders. Two things gate that climb. Your quality rating has to stay healthy, and the daily limit is shared across your whole portfolio of numbers, not granted per number. A throughput ceiling also applies on top of the daily limit (80 messages per second by default on the Cloud API), which matters only at high volume but is real. For how per-message pricing layers onto all of this, our [WhatsApp Business API pricing guide for 2026](/blog/whatsapp-business-api-pricing-2026) breaks down what each delivered template actually costs. ## WhatsApp broadcast vs group: which one should you actually use? For one-way business messaging, use a broadcast list, not a group. A broadcast sends private one-to-one messages where recipients cannot see each other and replies come back only to you. A group is a shared thread where up to 1,024 members see every message and reply, and everyone can see who else is in it. Groups are for community, broadcasts are for announcements. The two get confused because both let you message many people at once. The difference is privacy and direction. | | Broadcast list | Group | |---|---|---| | Max members | 256 | Up to 1,024 | | Message style | Private one-to-one | Shared thread | | Recipients see each other | No | Yes | | Replies go to | You only | Everyone | | Recipient must save your number | Yes | No | | Best for | Announcements, offers, updates | Communities, team chat | For a promotional send, a group is usually the wrong choice. Members see each other's numbers, anyone can reply to all, and one annoyed customer can spam the whole list or, worse, harvest your other customers' phone numbers. A group also has no real way to keep messaging one-directional. It is a conversation space, not a broadcast channel. The broadcast list keeps every recipient siloed, which is what you want for an offer or an update. The tradeoff is the 256 cap and the saved-number requirement. The group dodges the saved-number rule (people in a group receive messages without having saved you) and reaches up to 1,024, but you pay for that with zero privacy and an uncontrollable thread. [image: Shop owner sending personal WhatsApp updates to regular customers from behind a counter] For most "whatsapp broadcast vs group" decisions in a business context, the honest answer is neither at scale. Both are personal-messaging tools stretched past their design. Real audience messaging at volume belongs on the API, where consent, delivery, and analytics are first-class. Use broadcasts and groups for what they are good at: small, genuine, relationship-driven sends. ## What best practices keep your broadcast account in good standing? The core WhatsApp broadcast best practices are simple: only message people who saved your number or explicitly opted in, keep your block and report rate low, send relevant and infrequent messages, and never import scraped or purchased numbers. WhatsApp's enforcement keys on recipient behavior, blocks and reports, not on raw volume. Stay below the irritation threshold and you stay in good standing. The platform does not punish you for sending a lot. It punishes you for sending to people who do not want it. Every block and every "report spam" is a signal, and enough of them throttle or freeze your account regardless of which product you use. A practical checklist: 1. **Save-then-send on the app.** Build lists from people who already have your number saved. If they do not, your message will not arrive anyway, so chasing reach you cannot deliver is wasted effort. 2. **Opt-in is mandatory on the API.** Document a consent timestamp and source for every contact. This is not optional; it is the deliverability floor. 3. **Respect the two-marketing-message daily cap.** Each user can receive roughly two marketing templates per day across all brands. Over-send and you eat error 131049 and burn goodwill. 4. **Segment US numbers out of marketing.** Since April 1, 2025, marketing templates to +1 numbers do not deliver. Route them to utility or authentication content, or leave them out of marketing sends. 5. **Throttle and stagger.** Sudden spikes look like spam to WhatsApp's systems. Steady, relevant sending builds trust and moves you up the API tiers. 6. **Never use scraped or purchased lists.** This is the fastest route to a quality-rating downgrade and a ban. No exceptions. > "We stopped trying to beat the 256 limit on the app and just fixed who we were messaging. Half our list had never saved our number. Once we cleaned that up and moved the real audience to a proper opted-in setup, delivery went from a guess to a number we could trust." (Synthetic operator quote, representative of the saved-number and consent issues this guide documents.) The pattern across every limit in this article is the same. WhatsApp is not trying to stop you from reaching customers. It is trying to stop you from reaching people who did not ask to hear from you. Build your list around genuine consent and the limits stop being a wall and start being a guardrail. If you are ready to run real campaigns from a clean, opted-in list instead of fighting the broadcast cap, [start free with Blueticks](https://blueticks.co/signup) and schedule your first managed send in under ten minutes. For the message copy itself, our library of [WhatsApp campaign templates that convert](/blog/whatsapp-campaign-templates-that-convert) covers offer, reminder, and win-back wording that stays compliant. ## FAQ **How many contacts can I add to a WhatsApp broadcast list?** Up to 256 contacts per broadcast list, in both the WhatsApp Business app and the standard app. You can create more than one list, but each list sends separately, and there is no way to pool multiple lists into a single send. To reach more than 256 people in one managed send, you need the WhatsApp Business Platform (the API), which has no 256-contact list cap. **Why is my WhatsApp broadcast not delivering to everyone?** On the Business app, broadcast messages only reach contacts who have saved your phone number in their address book. If a recipient has not saved you, the message is silently dropped with no error shown to you. This is the most common cause of low broadcast delivery. On the API, the usual causes are missing opt-in, the per-user two-marketing-message daily cap (error 131049), the US marketing pause, or a low quality rating. **What is the WhatsApp broadcast message limit per day?** The Business app has no published daily limit, but sending heavily can trigger spam throttling or a ban based on recipient blocks and reports. The WhatsApp Business Platform has explicit daily limits: 250 unique customers per 24 hours to start, scaling through 1,000, 10,000, 100,000, and unlimited as your quality rating and volume earn each tier. Since October 2025, that limit is shared across all numbers in your business portfolio. **Should I use a WhatsApp broadcast or a group for my business?** Use a broadcast for one-way announcements and offers. Recipients get private one-to-one messages, cannot see each other, and their replies come only to you. Use a group only for genuine community or team interaction, where everyone seeing and replying to each other is the point. Groups hold up to 1,024 members but expose every member's number and let anyone reply to all, which makes them a poor fit for promotions. **Is it against WhatsApp's rules to send to more than 256 contacts?** No. Sending to more than 256 contacts is allowed through legitimate means: multiple broadcast lists on the app, or the WhatsApp Business Platform for scale. What violates the rules is messaging people who never opted in or never saved your number, using scraped or purchased lists, or using unofficial third-party apps that claim to bypass the limit. Those carry real ban risk. Stay on official products with consenting recipients and you stay compliant. *Sources: WhatsApp Help Center (broadcast lists), Meta's WhatsApp Business Platform messaging-limits documentation, and Meta's pricing documentation. Limit and tier figures (256 per list, 250 to unlimited API tiers, portfolio-level pooling since October 2025), the per-user two-marketing-message daily cap with error 131049, the US (+1) marketing pause from April 1, 2025, and per-message billing live July 1, 2025 reference Meta's published documentation current as of June 2026. Platform behavior changes; verify against Meta's docs before building around a specific figure.* --- # WhatsApp Campaign Management: How to Plan, Run, and Measure a Campaign in 2026 > A blast is not a campaign. Here's the end-to-end WhatsApp campaign management workflow for 2026: planning, segmentation, compliant sends, drips, and the analytics that actually move revenue. URL: https://blueticks.co/blog/whatsapp-campaign-management Published: 2026-06-04 Author: Maya Cohen Category: marketing [image: Marketing team planning a WhatsApp campaign management workflow at an office table] You sent a broadcast to 8,000 contacts last month. You have no idea how many were delivered, how many were read, how many replied, or how much revenue it drove. The send went out, a few orders trickled in, and the report was a screenshot of a number nobody could explain. That is sending. It is not campaign management. The gap between the two is the difference between a 3% broadcast conversion rate and a 20% automated-flow conversion rate. This guide walks the full whatsapp campaign management workflow for 2026: how to plan, segment, run a compliant broadcast, layer in drips, and measure results against numbers you can defend in a board meeting. ## What Is WhatsApp Campaign Management (vs a One-Off Broadcast)? WhatsApp campaign management is the end-to-end process of planning, segmenting, scheduling, sending, and measuring WhatsApp messages against a goal. A one-off broadcast is a single untracked send. Campaign management adds a defined objective, a segmented audience, a sequence, and analytics, so every send is measured and the next one improves. A broadcast is one event. A campaign is a system. The system has five moving parts: an objective (revenue, bookings, reactivation), a segment (who, and why them), a message or sequence, a send schedule, and a measurement loop. Skip any one and you are back to spraying. The payoff for treating it as a system is large. Chatarmin's 2026 WhatsApp KPI benchmarks put automated flow conversion at 10–25%, versus 3–7% for plain broadcasts, on the same channel and often the same list. The channel did not change. The management did. > "We stopped thinking of WhatsApp as a send button and started treating it like a campaign calendar. Conversion on the same audience roughly tripled inside one quarter." (Synthetic operator quote, representative of the broadcast-to-flow shift Chatarmin documents.) If you are still collecting contacts manually, fix the front of the funnel first. Our [WhatsApp opt-in collection guide](/blog/whatsapp-opt-in-collection-guide) covers the nine channels and the consent wording Meta now requires before any of this works. ## How Do You Plan a WhatsApp Campaign Step by Step? Plan a WhatsApp campaign in five steps: set one measurable objective, pick the audience segment that matches it, choose the message type (broadcast or drip), draft and get the template approved, then define the success metric before you send. Lock the metric first. A campaign without a pre-declared KPI is impossible to call a win or a loss. [image: Marketer mapping WhatsApp campaign management steps and segments on a whiteboard] Here is the working sequence: 1. **Objective.** One per campaign. "Recover 25% of abandoned carts this week," not "boost engagement." Vague goals produce unmeasurable sends. 2. **Segment.** Match the audience to the objective. A win-back goal targets 90-day-dormant contacts, not last-week buyers. 3. **Message type.** A single time-bound offer is a broadcast. A multi-touch nurture is a drip. Pick before you write. 4. **Template + approval.** Marketing templates need Meta approval. Build approval lag (often 1–3 hours, sometimes a day) into the calendar. 5. **Success metric.** Declare it now: reply rate, click rate, conversion, revenue per recipient. Chatarmin benchmarks revenue per recipient at €2.00–6.00 for e-commerce, a useful baseline to beat. One planning constraint that breaks campaigns: Meta caps each user at roughly two marketing template messages per day across all businesses combined. If your plan assumes daily sends to the same people, a chunk of those sends will silently fail with error 131049. Plan frequency around that ceiling, not your wishlist. For the copy itself, do not reinvent it here. Our [WhatsApp campaign templates that convert](/blog/whatsapp-campaign-templates-that-convert) library covers flash sale, cart recovery, win-back, and event-reminder message copy with timing. ## How Do You Build and Segment a Compliant Recipient List? Build a compliant list by collecting explicit, named opt-ins, then segment by behavior: purchase recency, category, engagement, and acquisition source. A compliant opt-in must state your business name, name WhatsApp as the channel, describe the message types, and give an opt-out path. Segment from day one, because list quality, not list size, drives deliverability. Segmentation is where most "underperforming" campaigns are actually misfires. The list was never the problem. The targeting was. Useful segment axes: - **Recency:** active (0–30 days), warm (31–90), dormant (90+). Each gets a different message and frequency. - **Category / purchase history:** match launches and upsells to what people already bought. - **Engagement tier:** repliers and clickers get priority during high-demand windows. - **Acquisition source:** a checkout opt-in behaves nothing like a "win a prize" lead. Track block rate per source. A checkout segment should run under 0.5% block rate; a broad lead-gen segment can run 2–5%. The compliance floor is non-negotiable. Uploading purchased or scraped numbers and firing templates at them is the fastest route to a quality-rating downgrade and a paused account. Every recipient needs a documented consent timestamp and source. Once your list is segmented, [Blueticks's campaign scheduler](/scheduler) lets you tag contacts by source and apply different send frequencies per cohort, so your dormant lead-gen list never gets the same cadence as your active buyers. ## How Do You Run a Bulk/Broadcast Campaign Without Getting Blocked? To run a WhatsApp broadcast campaign without getting blocked, send only to opted-in contacts, use a Meta-approved marketing template with a one-click opt-out, segment tightly instead of blasting your whole list, throttle send volume, and watch your quality rating in real time. Blocks and reports, not volume, are what trigger restrictions. The mechanics of how to run a WhatsApp campaign at scale come down to five controls: | Control | What it does | |---|---| | Verified opt-in only | Keeps undelivered/blocked rate low, protects quality score | | Approved template + opt-out button | Required for marketing sends; reduces reports | | Tight segmentation | Higher relevance, lower block rate per send | | Volume throttling | Avoids spike patterns that look like spam | | Live quality monitoring | Catch a "Low" rating before it becomes a pause | Two 2026 realities shape every broadcast. First, marketing templates to US (+1) numbers have been paused since April 1, 2025; utility and authentication still deliver, but marketing simply does not arrive, with no obvious error. Segment US contacts out of marketing broadcasts. Second, the per-message pricing model live since July 1, 2025 ([Meta's pricing docs](https://developers.facebook.com/documentation/business-messaging/whatsapp/pricing)) bills every delivered marketing template separately, so a sloppy 8,000-person blast is now 8,000 line items, most of them wasted. Precision is the cost lever and the deliverability lever at once. A 600-person segment at a 20% reply rate beats a 6,000-person blast at 2%, on revenue and on platform standing. For the full send-timing and copy mechanics, see [WhatsApp campaign templates that convert](/blog/whatsapp-campaign-templates-that-convert). ## How Do You Set Up a WhatsApp Drip Campaign on Autopilot? A WhatsApp drip campaign is a pre-built sequence of messages triggered by a behavior or time delay: cart abandonment, post-purchase, onboarding, or re-engagement. Set one up by defining the trigger, mapping 2–4 timed touches, writing each message, and scheduling the delays so the sequence runs without manual sends. Drips are where the conversion gap opens up. Chatarmin's benchmarks put automated flows at 10–25% conversion against 3–7% for one-shot broadcasts, and flag optimized cart-recovery flows exceeding 100x return on WhatsApp spend. The reason is timing: a sequence catches people at the moment of intent and follows up, instead of betting everything on one send landing at the right second. [image: Smartphone and analog clock on a cafe table representing a timed WhatsApp drip campaign sequence] A standard abandoned-cart drip: 1. **Touch 1.** 45–60 minutes after abandonment. Reminder, no discount yet. 2. **Touch 2.** 24 hours later. Add a small incentive. 3. **Touch 3.** 72 hours later. Final notice, scarcity plus social proof. Map the trigger, write the touches, set the delays, and the sequence runs itself. [Blueticks's campaign scheduler](/scheduler) handles recurring and timed sends, so the 1-hour, 24-hour, and 72-hour touches fire on schedule without anyone clicking send at midnight. Keep drip touches inside frequency limits, the per-user two-marketing-message daily cap applies to drips too. ## Which WhatsApp Campaign Analytics Actually Matter? The WhatsApp campaign analytics that matter are delivery rate, read rate, reply rate, click-through rate, conversion rate, revenue per recipient, and unsubscribe/block rate. Open rate is near-universal on WhatsApp, so it tells you little. Reply, click, and conversion are where real performance and real money show up. Open rate is a vanity number here. A 2026 Twilio Messaging Engagement Benchmark Report analyzing 4.8 billion WhatsApp messages across roughly 62,000 business accounts found an average open rate of 98.2%, with promotional API messages still hitting 96.7%, versus 21.4% for email ([reported figures](https://www.amraandelma.com/whatsapp-marketing-statistics/)). When almost everything gets opened, the open rate cannot separate a good campaign from a bad one. The downstream metrics do. [image: Analyst reviewing WhatsApp campaign analytics charts on a laptop at a desk] The metrics worth a dashboard, with Chatarmin 2026 benchmark ranges: | Metric | Why it matters | 2026 benchmark | |---|---|---| | Delivery rate | Catches list-quality and cap issues | 95–99% | | Reply rate | Real engagement signal | 45–55% | | Click-through rate | Intent on interactive sends | 45–60% (button messages) | | Conversion rate | The money metric | 3–7% broadcast / 10–25% flow | | Revenue per recipient | Normalizes across list sizes | €2.00–6.00 e-commerce | | Unsubscribe / block rate | Quality-score early warning | under 0.5% per campaign | How to measure WhatsApp campaign results in practice: tag every campaign, attribute orders with a unique link or code per send, and compare against the prior campaign, not an industry average. Your own last campaign is the only fair benchmark. To pick a tool that surfaces these without a spreadsheet, [Blueticks's scheduler and reporting](/scheduler) ties sends to outcomes in one place. ## What to Look For in WhatsApp Campaign Software? Good WhatsApp campaign software covers five jobs: list segmentation with consent tracking, template management and approval, scheduled and triggered sends, opt-out handling, and per-campaign analytics. The differentiator is whether it ties sends to revenue. If you still need a spreadsheet to know what a campaign earned, the tool is incomplete. A buying checklist for whatsapp campaign software: - **Segmentation + source tagging.** Filter by recency, category, and acquisition source at send time. - **Template + opt-out compliance.** Approved templates and one-click unsubscribe handled for you. - **Scheduling and drips.** Timed and recurring sends, not just manual blasts. - **Analytics tied to revenue.** Delivery, reply, click, conversion, and revenue per recipient per campaign. - **Fit to your scale.** For smaller lists, a WhatsApp Web tool avoids a full API integration; high-volume marketing pushes you toward an API via a certified provider. Match the tool to where you are. A team running 500-contact weekly segments has very different needs from one pushing 50,000-recipient daily campaigns. Overbuying a heavyweight API stack for a small list adds cost and complexity you will not use. [Blueticks](/scheduler) runs campaign scheduling and opt-out handling directly from your WhatsApp account, which suits teams that want management without standing up an API integration. ## WhatsApp Campaign Best Practices: Pre-Send Checklist WhatsApp campaign best practices come down to a pre-send checklist: confirm explicit opt-ins, segment the list, use an approved template with opt-out, respect the two-message daily cap, send in the morning window, and declare your success metric before launch. Run the checklist every time and most failures disappear before they happen. The case for the discipline: a fictional fashion brand, Meridian Apparel, ran a standard blast to its full 9,000-contact list and got a 3.2% click rate and 0.8% conversion. They then rebuilt it as managed campaigns, dormant-only segment, honest re-engagement copy, a 3-touch drip, morning send. The reactivation campaign hit an 11% click rate and 2.9% conversion on a slice of the same list (synthetic example, numbers within Chatarmin's documented broadcast-vs-flow ranges). Same brand, same product, different management. [image: Marketer ticking off a WhatsApp campaign best practices checklist before sending] Your pre-send checklist: - [ ] Every recipient has a documented, explicit opt-in - [ ] List segmented to match the campaign objective - [ ] Marketing template approved, with a one-click opt-out - [ ] US (+1) numbers excluded from marketing sends - [ ] Frequency respects the ~2 marketing-message daily cap - [ ] Send timed to the 8–10 AM local window for promos - [ ] Success metric declared before launch - [ ] Tracking link or code in place for attribution Run a fresh, compliant campaign from a real opted-in list today. [Start free with Blueticks](https://blueticks.co) and schedule your first managed campaign in under ten minutes. ## FAQ **What is the difference between a WhatsApp broadcast and a WhatsApp campaign?** A broadcast is a single send to a list. A campaign is a managed process: a defined objective, a segmented audience, a message or drip sequence, a schedule, and measured analytics. A broadcast can be one part of a campaign, but a campaign adds the targeting and measurement that let you improve the next send. The conversion gap is real, Chatarmin's 2026 benchmarks show 3–7% for plain broadcasts versus 10–25% for managed automated flows. **How do I measure WhatsApp campaign results?** Track delivery rate, reply rate, click-through rate, conversion rate, and revenue per recipient per campaign. Ignore open rate as a comparison metric, since WhatsApp opens run near 98% across the board (Twilio's 2026 benchmark report found 98.2%). Attribute revenue with a unique link or discount code per campaign, and compare each campaign against your own previous one rather than an industry average. **Why are my WhatsApp marketing messages not being delivered?** Three common causes in 2026: the recipient is a US (+1) number (marketing templates have been paused to US numbers since April 1, 2025), the recipient hit the ~2 marketing-message daily cap (error 131049), or your list contains non-opted-in contacts dragging down your quality rating. Segment US contacts out of marketing, respect the daily cap, and clean your list to fix most delivery failures. **How often can I send WhatsApp marketing campaigns?** Meta limits each user to roughly two marketing template messages per day across all businesses combined, so over-sending cannibalizes your own deliverability. For most lists, one to three well-segmented marketing sends per week outperforms daily blasts. Use frequency as a quality lever: fewer, more relevant sends keep block rates under 0.5% and protect your quality score. **Do I need the WhatsApp Business API to run campaigns?** Not always. For smaller lists, a WhatsApp Web tool like Blueticks runs scheduled campaigns and opt-out handling from your existing account with no API integration. High-volume marketing, large segmented broadcasts, and template automation push you toward the WhatsApp Business API through a certified provider. Match the tooling to your list size and send volume rather than over-building from day one. *Benchmark note: open, reply, click, conversion, and revenue-per-recipient ranges here are drawn from Chatarmin's 2026 WhatsApp KPI benchmarks and a reported 2026 Twilio Messaging Engagement Benchmark Report. Pricing and policy facts (per-message billing live July 1 2025, US marketing pause, per-user daily cap) reference Meta's WhatsApp Business Platform pricing documentation. Your results vary by list quality, offer, and market, treat these as directional targets.* --- # How to Schedule WhatsApp Messages on iPhone and Android (Without a Third-Party App) > Neither iOS nor Android has a native WhatsApp scheduler — not even WhatsApp Business. Here's the full picture of workarounds, and what actually works in 2026. URL: https://blueticks.co/blog/schedule-whatsapp-messages-iphone-android-without-app Published: 2026-06-03 Author: Daniel Roth Category: productivity [image: Smartphone resting face-down on a wooden desk beside a paper planner showing scheduled times] You searched for how to schedule WhatsApp messages without an app. You want a simple answer. The honest answer is: it depends on your phone, your account type, and what "without an app" actually means to you. This guide goes through every native option in 2026 — no third-party apps, no Chrome extensions — so you know exactly what works, what's a workaround, and where native falls short. ## Does WhatsApp Have a Built-In Feature to Schedule Messages in 2026? As of 2026, WhatsApp does not include a native message scheduler for consumer accounts. There is no "send later" button, no calendar picker, and no scheduled send option anywhere in the standard WhatsApp app on iPhone or Android. If you're looking for a built-in WhatsApp scheduler on the consumer app, it does not exist — on either platform. A common myth says the **WhatsApp Business app** has a native scheduler under a "Tools > Schedule message" menu. It does not. The WhatsApp Business app's only built-in automation is Greeting Messages, Away Messages, and Quick Replies — and those are auto-replies (they fire in response to an incoming message, or are typed manually), not scheduled outbound sends. So consumer *and* Business WhatsApp accounts alike have no native way to send a message at a future time on any platform. | Platform | Consumer WhatsApp | WhatsApp Business app | |---|---|---| | Android | No native scheduler | No (auto-replies only, not a scheduler) | | iPhone (iOS) | No native scheduler | No native scheduler | | WhatsApp Web | No native scheduler | No native scheduler | | WhatsApp Desktop | No native scheduler | No native scheduler | So: scheduling a WhatsApp message **natively** is not possible on any account type or platform today. Every route below is a workaround. ## How Can Android Users Schedule a WhatsApp Message Without WhatsApp's Own Tools? Because neither WhatsApp nor WhatsApp Business has a native scheduler, the closest no-extra-install route on Android is on-device automation. Android's more open architecture lets automation apps simulate a scheduled send by automating taps inside WhatsApp at a set time. The common tools are Tasker, MacroDroid, and SKEDit. Note these *are* separate apps — so this is "without a dedicated WhatsApp scheduler," not literally zero installs — but they don't touch WhatsApp's account or require API access. How the automation approach generally works: 1. Install an automation app (Tasker, MacroDroid, or SKEDit) from the Play Store. 2. Grant it Accessibility permission so it can interact with other apps' interfaces. 3. Create a time-based task that opens a WhatsApp chat (often via a `https://wa.me/[phone-number]?text=[message]` deep link) and then automates the tap on the send button at the scheduled time. **What breaks:** the phone must be powered on and unlocked at send time, the flow leans on Accessibility permissions that some users are wary of granting, and a WhatsApp UI update can break the automated tap until you fix the script. There is also no reliable recurrence beyond what you script yourself. It's workable for the occasional personal reminder, not for anything you depend on. If you need to schedule WhatsApp messages on Android reliably — recurring sends, groups, broadcasts, or delivery you can trust — on-device automation reaches its ceiling quickly, and a browser-based scheduler (covered later) is the steadier path. [image: Android phone on a cafe table next to a coffee cup, screen facing away from camera] ## How Do You Schedule a WhatsApp Message on iPhone Using the Shortcuts App? On iPhone, there is no native WhatsApp scheduling feature — in either the consumer or Business app. The closest built-in option is Apple's Shortcuts app, which can automate opening WhatsApp with a pre-written message at a scheduled time. But it is not true background scheduling. According to [Apple's Shortcuts documentation](https://support.apple.com/guide/shortcuts/welcome/ios), a Shortcuts automation can open an app and pass data to it — but it cannot interact with a third-party app's send button on your behalf. WhatsApp does not expose a "send message" action to Shortcuts. What Shortcuts can do is open a WhatsApp chat with a pre-filled message so you can tap Send yourself. Here is the exact workflow: 1. Open the **Shortcuts** app on your iPhone. 2. Tap **Automation** at the bottom of the screen. 3. Tap the **+** button to create a new automation. 4. Choose **Time of Day** as the trigger. Set the time and frequency (daily, weekly, etc.). 5. Tap **Next**, then **Add Action**. 6. Search for "Open App" and select it. Choose **WhatsApp** as the app. (Alternatively, search for "URL" and use a `https://wa.me/[phone-number]?text=[message]` deep link to open a specific chat with pre-filled text.) 7. Tap **Next**, then disable "Ask Before Running" if you want it to trigger automatically. 8. Tap **Done**. When the automation fires, your iPhone will open WhatsApp — either to the main screen or to the specific chat, depending on whether you used a deep link. Your pre-written message will appear in the text field. **You must tap Send.** The Shortcut cannot do it for you. This is not how to schedule WhatsApp messages on iPhone without any interaction. It is a reminder that opens WhatsApp and prefills a message. The send step is always manual. ## What Are the Real Limitations of iOS Shortcuts for WhatsApp — and Why It Is Not True Scheduling? Apple Shortcuts can open WhatsApp and pre-fill a message, but it cannot send on your behalf. This is a fundamental iOS restriction, not a WhatsApp policy choice. iOS apps run in sandboxes. A Shortcut can launch WhatsApp — it gets foregrounded, your screen turns on, the app is visible. But Shortcuts cannot interact with WhatsApp's interface: it cannot tap the send button, it cannot type into WhatsApp's input field without the deep-link prefill trick, and it cannot operate in the background while your phone is locked. Per [Apple's App Sandbox documentation](https://developer.apple.com/documentation/security/app_sandbox), third-party apps cannot be driven programmatically by another app — including Shortcuts — without explicit API support from that app's developer. WhatsApp does not provide that API for external automation. The practical result: **schedule whatsapp messages on iphone** using only iOS native tools means your phone screen turns on, WhatsApp opens, and you are standing there with a pre-written message waiting for you to tap Send. That's a reminder, not scheduling. The failure mode is also worth noting: "Ask Before Running" must be disabled for the automation to trigger without you tapping a notification first. Even then, iOS may not reliably wake a sleeping iPhone to run the automation if Low Power Mode is active or the device hasn't been used recently. **Summary table: iOS Shortcuts vs. true scheduling** | Capability | iOS Shortcuts + WhatsApp | True scheduled send | |---|---|---| | Opens WhatsApp at set time | Yes | Yes | | Pre-fills message text | Yes (with deep link) | Yes | | Sends message automatically | **No** | Yes | | Works with phone locked/screen off | Unreliable | Yes | | Works for recurring messages | Manual setup each time | Automated | | Runs while phone is off | No | Depends on tool | If you need to schedule WhatsApp messages on iPhone without any manual interaction, iOS Shortcuts is not a solution. It is a partial workaround. [image: iPhone placed face down on a home office desk beside a keyboard and notepad] ## How Can Android Users Schedule WhatsApp Messages Without a Dedicated App (Google Assistant, Built-In Features)? On Android, there are a few paths that don't require installing a third-party app — but each has trade-offs. Android's more open architecture compared to iOS means background automation is technically possible, but WhatsApp's own security measures limit what's achievable without third-party tools. **Google Assistant routines.** Google Assistant supports time-based routines that can send a WhatsApp message at a set time. On some Android devices, the "Send a WhatsApp message to [contact]" action is available in the Google Assistant routine builder. This depends on your Android version, your device manufacturer's Assistant integration, and whether the feature is available in your region. As of mid-2026, this path works on recent Pixel and Samsung devices with Assistant configured — but coverage is inconsistent and Google has not committed to it as a stable long-term feature. **Samsung's Bixby Routines.** Samsung devices include Bixby Routines, which can trigger app openings and some actions on a schedule. As with iOS Shortcuts, the limitation is that Bixby can open WhatsApp but cannot interact with its interface to compose and send a message autonomously. **Android's built-in scheduling (none).** Android itself has no system-level "send WhatsApp message at time X" feature. Unlike SMS, which has a built-in delayed send option in some Android messaging apps, WhatsApp messages cannot be queued at the OS level. **How to schedule WhatsApp messages on Android without app — the honest answer:** there is no native, no-install path. WhatsApp and WhatsApp Business both lack a scheduler, so every Android route is a workaround — Google Assistant or Bixby (which open WhatsApp but generally can't compose and send autonomously), or an automation app like Tasker or MacroDroid (which can simulate the send but need Accessibility permission and break on UI changes, as covered above). One realistic use case: if you only need an occasional reminder that opens a chat with text prefilled, Google Assistant or a deep-link automation gets you close on Android without committing to a full scheduling tool. For reliable 1:1, group, or recurring sends, you're outside what "without an app" can deliver. ## What Are the Key Differences Between Native Scheduling on Android Versus iPhone? Neither platform has a native WhatsApp scheduler — not in consumer WhatsApp and not in WhatsApp Business. The difference is in the *workarounds* available: Android's more open automation model gives it more room to simulate a scheduled send, while iOS keeps apps tightly sandboxed. Here is the comparison across every relevant dimension: | Feature | Android | iPhone (iOS) | |---|---|---| | Consumer WhatsApp native scheduler | No | No | | WhatsApp Business native scheduler | No (auto-replies only) | No (auto-replies only) | | OS-level automation (Shortcuts/Routines) | Partial (Google Assistant, Bixby) | Partial (Shortcuts, no auto-send) | | Automation apps that simulate a send | Yes (Tasker/MacroDroid, with caveats) | No (sandbox blocks it) | | Can send while phone is off | No (requires device on) | No | The fundamental reason for the gap: iOS enforces stricter process isolation than Android. An app like WhatsApp on iOS cannot be driven by another app or system routine to compose and send a message. Android's more permissive model lets automation apps (with Accessibility permission) tap WhatsApp's send button on a timer — though that's fragile and breaks on UI changes, as covered above. According to data from Statista, as of early 2026 Android holds approximately 72% of the global smartphone market share. Most WhatsApp users worldwide are on Android — which means most users asking "can I schedule a message on WhatsApp" are on the platform with at least a partial workaround. iPhone users represent the majority of premium markets like the US, UK, and Australia, and for them the answer is: no native option, and no reliable on-device workaround either. ## When Native Mobile Scheduling Falls Short — and What to Do When You Need More Native options cover a narrow slice of real scheduling needs. Here's where they run out of road, and what the alternative looks like. **Native falls short when:** - You need to schedule WhatsApp messages on iPhone (no native option, no reliable on-device workaround). - You're on any WhatsApp or WhatsApp Business account (none have a native scheduler). - You need to schedule to a group or broadcast list (on-device automation handles this poorly). - You need recurring messages — no native option offers recurrence. - You're working from a desktop or laptop (native scheduling does not exist on WhatsApp Web or Desktop). - You need messages to send reliably while your phone is off. This is where a browser-based tool fills the gap. Our [consumer guide to scheduling WhatsApp messages](https://blueticks.co/blog/schedule-whatsapp-messages) covers the Chrome extension path in detail. If you're operating a WhatsApp Business account and need broadcasts, bulk sends, or API-level control, the [WhatsApp Business scheduling guide](https://blueticks.co/blog/schedule-whatsapp-business-messages) covers that territory. For users who need scheduling that works across both iPhone and Android — without leaning on fragile on-device automation — the practical path is a Chrome extension running on WhatsApp Web. The [Blueticks extension](https://chromewebstore.google.com/detail/blueticks/adgnjhngogijkkppficiiepmjebijinl) adds a scheduler directly to WhatsApp Web: pick a contact, write the message, set the time, and it sends — whether your phone is an iPhone or Android, and regardless of which device you use during the day. **The honest trade-off:** the Chrome extension runs in a browser on a desktop or laptop. If you're phone-only, it requires you to work from a computer at least once to set up the schedule. Messages then send through that computer's WhatsApp Web session. For recurring messages like weekly reminders or monthly follow-ups, this is a one-time setup cost for a long-running schedule. For truly phone-only users who don't have desktop access, the native options described above are the ceiling. One important failure mode: the Chrome extension requires a browser tab with WhatsApp Web to be open and connected. If the tab closes or the machine sleeps, messages queue until the session reconnects. For critical sends, Blueticks' offline gateway mode keeps messages sending even when the laptop is closed — but that's a feature of the tool, not the native WhatsApp options this article focuses on. For [WhatsApp campaigns](https://blueticks.co/campaigns) — scheduling messages to multiple contacts, tracking delivery, and managing responses — the extension path also handles bulk sends without needing API access. That's outside the scope of "without an app," but it's the direction operators move once they outgrow native scheduling limits. [image: Laptop with closed lid at a side angle on a desk, representing browser-based scheduling setup] ## Frequently Asked Questions **Can I schedule a message on WhatsApp without downloading anything?** Not with a true zero-install option. Neither WhatsApp nor WhatsApp Business has a native scheduler. On Android, iOS Shortcuts (iPhone) or Google Assistant/Bixby (Android) can open WhatsApp with a prefilled message at a set time, but you must tap Send manually. Fully automating the send requires a separate automation app (Tasker, MacroDroid) on Android, with the caveats covered above. **Does WhatsApp have an official scheduled message feature?** No. Neither WhatsApp nor the WhatsApp Business app has a native scheduled-message feature on any platform. The "Tools > Schedule message" feature people cite for WhatsApp Business does not exist — the Business app's built-in tools (Greeting, Away, Quick Replies) are auto-replies, not scheduled sends. A personal-account scheduler is reportedly in development, but it is not yet available to users. **How do I schedule WhatsApp messages on Android without a third-party app?** There's no native, no-install path, because neither WhatsApp nor WhatsApp Business has a scheduler. The closest options are Google Assistant or a deep-link automation that opens a chat with text prefilled (you still tap Send), or an automation app like Tasker or MacroDroid that simulates the send at a set time — which needs Accessibility permission and can break on a WhatsApp UI update. For reliable scheduling, a browser-based tool is the steadier route. **Why can't I schedule WhatsApp messages on my iPhone?** iOS's app sandboxing prevents external tools or automations from interacting with WhatsApp to send messages. Apple Shortcuts can open WhatsApp and pre-fill text via a deep link, but cannot tap the send button on your behalf. WhatsApp has not exposed a scheduling API to iOS that would allow true background sending. As of 2026, this is a platform limitation with no native workaround. **Can I schedule a WhatsApp Business message to a group?** Not natively — the WhatsApp Business app has no scheduler at all, for 1:1 chats or groups. On-device automation handles groups poorly. For reliable group scheduling, you need a browser-based tool or the WhatsApp Business API. **What happens if my phone is off when an on-device automation is set to send?** On-device automation (Tasker, MacroDroid, a deep-link routine) requires your phone to be powered on and unlocked at send time. If the device is off or locked, the send won't fire — and there's no cloud backup, since the automation runs entirely on your phone. If reliable delivery while the device is off matters to you, that's a reason to look at browser-based or cloud-backed scheduling tools. --- # How to Schedule WhatsApp Business Messages So They Land On Time, Not at Midnight (2026) > WhatsApp Business has auto-replies but no real outbound scheduler. Here's what works in 2026 for scheduling business messages, broadcasts, and bulk sends. URL: https://blueticks.co/blog/schedule-whatsapp-business-messages Published: 2026-06-02 Author: Daniel Roth Category: productivity [image: Small business owner at a shop counter reviewing a phone with WhatsApp Business open] You've written the perfect follow-up message. You want it to land at 9 AM when your customer opens WhatsApp, not at 11 PM when you're finally clearing your inbox. If you've already read our guide on [scheduling personal WhatsApp messages](https://blueticks.co/blog/schedule-whatsapp-messages), you know the consumer side of the problem. This article is the business version — focused on WhatsApp Business accounts, what the app actually offers for scheduling, where it runs out of road, and what operators are actually doing in 2026 to keep messages going out on time. ## Does WhatsApp Business Have a Native Schedule Message Feature? No. As of mid-2026, the WhatsApp Business app has no native outbound message scheduler — on Android, iOS, WhatsApp Web, or WhatsApp Desktop. There is no "send later" button and no way inside the app to pick a future date and time for a message to go out to a contact. That gap is the core problem this article addresses. It's worth debunking a specific myth, because it circulates widely on SEO blogs: there is **no "Tools > Schedule message" feature** in the WhatsApp Business app. People conflate the app's automation menu with a scheduler, but the two are different things. The WhatsApp Business app's native automation is limited to three reactive tools — Greeting Messages, Away Messages, and Quick Replies. All three are auto-replies: they fire in response to an incoming message (or are typed manually), not on a schedule you set. None of them sends an outbound message to a contact at a future time of your choosing. So if your business needs to line up a message to send tomorrow at 9 AM, reach multiple contacts on a schedule, or schedule from a desktop, the WhatsApp Business app alone cannot do it. The real options — broadcast lists, on-device automation, a WhatsApp Web scheduler, or the API — are covered below. ## How to Schedule Messages for WhatsApp Business in 2026 (the Real Options) Since the app has no native scheduler, "scheduling" a WhatsApp Business message means one of a few practical paths. Here's how each one works and where it breaks. **Option 1 — Broadcast lists (manual send, not scheduling).** The WhatsApp Business app lets you create a broadcast list and send one message to up to 256 contacts at once. This is useful for reaching a saved-contact list, but it is *not* scheduling — you compose and tap Send in the moment, with no "send later" option. Covered in more detail in the broadcasts section below. **Option 2 — On-device automation (for occasional 1:1 sends).** Android automation apps like Tasker, MacroDroid, or SKEDit can simulate a scheduled send by automating taps in WhatsApp at a set time. The caveats are real: the phone must be on and unlocked, the automation relies on Accessibility permissions, and a UI change in WhatsApp can break the flow. It's serviceable for the occasional personal reminder, not for reliable business sends. **Option 3 — A WhatsApp Web scheduler (the reliable path for business).** A browser extension like Blueticks adds a true scheduler to WhatsApp Web — one-time and recurring sends, plus CSV-based bulk campaigns — and fires from the linked browser session. This is the path most operators land on for dependable 1:1, recurring, and broadcast-style scheduling. Full walkthrough further down. **Option 4 — The WhatsApp Business Platform (API).** For structured volume, CRM-driven sends, and audiences beyond a single broadcast list, the API is the graduation point. Covered in its own section below. For individual personal reminders, on-device automation can work in a pinch. For anything a business actually relies on — recurring follow-ups, broadcasts, desktop scheduling — you want a WhatsApp Web scheduler or the API. Stop babysitting the clock. Schedule your WhatsApp Business follow-ups, broadcasts, and reminders to fire at the right hour — even while you are asleep — straight from WhatsApp Web. [Start free →](https://blueticks.co/signup) and line up your first send in a couple of minutes. [image: Small business packing desk with orders, tape dispenser, and a smartphone face-down] ## Can You Schedule Broadcasts and Bulk Messages on WhatsApp Business? No — and this is the most common misconception. WhatsApp Business's broadcast list feature lets you send a message to up to 256 contacts at once, but it has no native scheduling capability. You compose the broadcast and tap Send immediately; there is no "send later" option for broadcasts in the WhatsApp Business app. The 256-contact ceiling is another hard constraint. According to [Meta's WhatsApp Business documentation](https://faq.whatsapp.com/general/contacts/about-broadcast-lists), a single broadcast list supports a maximum of 256 recipients, and messages only reach contacts who have saved your number. For a retail business with thousands of opted-in customers, a single broadcast list covers a fraction of the list — and scheduling even that fraction requires workarounds. The practical gap this creates: | Need | WhatsApp Business app | WhatsApp Business Platform (API) | |---|---|---| | Schedule 1:1 message | No (no native scheduler) | Yes | | Schedule broadcast | No | Yes | | Broadcast beyond 256 contacts | No | Yes | | Recurring message | No | Yes | | Schedule from desktop | No | Yes (via BSP/tool) | For operators who need to **schedule broadcast WhatsApp Business** messages, the app alone is not sufficient. The options are a third-party extension on top of WhatsApp Web, or graduating to the WhatsApp Business Platform (API). ## How Do Business-Hours Auto-Replies and Away Messages Work — and What Are Their Limits? Away Messages and Greeting Messages are WhatsApp Business's built-in automation tools. They're reactive — they fire when an incoming message arrives, not on a schedule you control. **Away Message:** Sends automatically to anyone who messages you during hours you mark as "away." You set your business hours in the app settings, and the Away Message fires outside those windows. Per the [WhatsApp Business Help Center](https://faq.whatsapp.com/general/chats/about-away-message), you can target it at all contacts, contacts not in your address book, or a custom list. **Greeting Message:** Fires when a customer messages you for the first time, or after 14 days of inactivity. It's an opener, not a scheduler. **Quick Replies:** Keyboard shortcuts for saved message templates you send manually. Not automated. These tools handle **whatsapp business hours automation** reasonably well — setting an expectation, offering a callback, providing hours. What they don't do: - Send a message at a time you choose - Reach out to a contact proactively - Operate on a schedule across multiple recipients - Work as a substitute for a recurring follow-up sequence One structural gotcha: if a customer messages you outside business hours, they get the Away Message. If they message again within 24 hours of the first reply, the Away Message does not fire again. WhatsApp throttles it to avoid appearing spammy. This is by design, but it catches operators who expect every off-hours message to get a response. Another limitation worth calling out: Away Messages do not send to WhatsApp groups. If your customer communication happens through a group, the automation doesn't apply there. ## When Does Your Team Need the WhatsApp Business Platform (API) Instead of the App? The WhatsApp Business Platform (API) is the right choice once your operation outgrows what the app can do. The threshold is lower than most people assume. Per [Meta's WhatsApp Business Pricing page](https://business.whatsapp.com/products/business-platform), the API unlocks programmatic sending, CRM integration, multi-agent inbox access, and message template management at scale. According to Meta, more than 200 million businesses use WhatsApp Business tools globally (Meta Q1 2025 earnings) — but the free app serves the majority; the API is for operators with structured volume. Signals that your team needs the API: - You need to send **whatsapp business api scheduled messages** from a CRM (HubSpot, Salesforce, Zoho) rather than manually from the app. - Your broadcast audience exceeds 256 contacts. - You need delivery receipts and read-rate analytics at scale. - Multiple agents need to handle conversations under one business number. - You're running drip sequences or automated follow-up flows triggered by customer actions. The API is not free. Meta charges per conversation — utility, authentication, marketing, and service conversations are each priced differently. As of 2026, marketing conversations (the category covering most scheduled promotional sends) are charged at rates that vary by country. For the current breakdown, see our article on [WhatsApp Business API pricing in 2026](https://blueticks.co/blog/whatsapp-business-api-pricing-2026). One practical note: API access requires going through a Business Solution Provider (BSP) or setting it up via Meta's Cloud API directly. There's no self-serve "unlock API" button in the app. The setup time is typically 1-5 business days including business verification. [image: Two colleagues at a wooden table with a laptop angled away, discussing business workflow] ## What Third-Party Tools Actually Schedule WhatsApp Business Messages Reliably in 2026? For operators who need scheduling on WhatsApp Web without building on the API, a Chrome extension is the most practical option. The reason is structural: WhatsApp Web runs in a browser tab, and a Chrome extension can interact with the page directly — adding a scheduler modal to the message input without requiring API access or phone number verification with Meta. [Blueticks](https://chromewebstore.google.com/detail/blueticks/adgnjhngogijkkppficiiepmjebijinl) is the extension that fills this gap. It works with both WhatsApp and WhatsApp Business accounts, adds a clock icon to every chat's input bar, and supports: - **One-time scheduled messages** — pick date, time, write message, done. - **Recurring messages** — daily, weekly, monthly, or custom intervals. One setup, runs indefinitely. - **Campaigns / bulk send** — upload a CSV of contacts, write a message (with per-contact personalization fields), set a send time. This is where **whatsapp business bulk message** needs get handled without API access. **How it works in practice:** 1. Install the Blueticks Chrome extension from the Chrome Web Store. 2. Open WhatsApp Web (web.whatsapp.com) — it works with Business accounts exactly as it does with personal ones. 3. Open the chat you want to message. 4. Click the clock icon that appears in the message input. 5. Write your message, pick the date and time, and click **Schedule**. For broadcasts to a custom list, use Blueticks' campaign feature: upload a CSV with phone numbers and optional personalization columns, write the message template with `{{name}}` or other field markers, set the send time. It handles the throttling automatically to keep send rates within WhatsApp's acceptable patterns. **The failure mode to know:** The Chrome extension requires a browser tab running WhatsApp Web to be open at send time — unless you enable Blueticks' offline gateway mode, which routes messages through a persistent backend so they send even when your laptop is closed. For critical sends (client reminders, payment follow-ups), enable offline mode. For casual recurring messages where a slight delay is acceptable, the standard extension is fine. A 2024 industry benchmark by Statista found that [WhatsApp has a 98% open rate](https://www.statista.com/statistics/1259226/whatsapp-messages-open-rate/) for business messages — significantly higher than email's typical 20-30%. Timing those messages correctly matters more on a channel where the recipient actually reads what you send. ## How to Schedule Recurring Messages and Follow-Up Sequences for Business Use Cases Recurring scheduling is where the business value compounds. A one-time scheduled message saves 30 seconds. A recurring sequence that runs for 52 weeks without you touching it saves hours. Here are the patterns operators use most: **Weekly payment reminders.** Set a message to a client or customer the day before their invoice is due. Recurring weekly or monthly. Tone: matter-of-fact, short. Example: "Hi {{name}}, just a heads-up — your invoice is due tomorrow. Let me know if anything needs adjusting." **Post-purchase follow-up.** Three days after a sale: "How's the [product] working out? Any questions, I'm here." Not a survey, not an upsell — just a touchpoint that builds retention. Set it once per customer as a one-time scheduled message triggered at purchase. **Lead nurture sequence.** Day 1: intro / confirm interest. Day 3: case study or example. Day 7: direct ask. Three messages, three scheduled sends, done. For operators doing this for [campaigns that convert](https://blueticks.co/blog/whatsapp-campaign-templates-that-convert), the sequence structure matters as much as the copy. **Operational digests.** A daily or weekly message to a team group with a structured update: open orders, key metrics, priorities. Set it once, runs every Monday at 8:30 AM. **Steps to set up a recurring WhatsApp Business message with Blueticks:** 1. Open WhatsApp Web with Blueticks installed. 2. Open the chat (individual or group). 3. Click the clock icon in the message input. 4. Write your message. Use `{{field}}` markers if personalizing. 5. Set the first send date and time. 6. Enable **Custom recurrence** — choose daily, weekly, or monthly, and set the end condition (never, after N occurrences, or by date). 7. Click **Schedule**. All recurring messages appear in the Blueticks dashboard. You can pause, edit, or cancel any of them without affecting others in the sequence. **What breaks in follow-up sequences:** WhatsApp limits how often you can message a contact who hasn't engaged. If you set a 7-message drip sequence to a cold contact who never replies, WhatsApp may rate-limit your number or flag it as spam — particularly if multiple recipients report your messages. For warm leads and existing customers, follow-up sequences work cleanly. For cold outreach at volume, the API with proper opt-in flows is the safer path. [image: Handwritten schedule notebook open beside a closed laptop on a clean desk] ## Frequently Asked Questions **Can I schedule WhatsApp Business messages on iPhone?** No, not natively — and the same is true on Android. The WhatsApp Business app has no native message scheduler on any platform; its built-in tools (Greeting, Away, and Quick Replies) are auto-replies, not scheduled sends. The practical workaround is to schedule from WhatsApp Web on a desktop or laptop browser using the Blueticks Chrome extension — messages scheduled there send regardless of which device you use day-to-day. **Can you schedule a broadcast on WhatsApp Business?** The WhatsApp Business app has no native broadcast scheduling. You can create a broadcast list and send immediately, but there's no "send later" option. To schedule a broadcast WhatsApp Business send, you need either a Chrome extension like Blueticks (which handles it via a CSV campaign upload) or the WhatsApp Business Platform API with a BSP integration. **What is the contact limit for WhatsApp Business broadcasts?** A single WhatsApp Business broadcast list supports a maximum of 256 contacts, and messages only deliver to recipients who have your number saved. This limit is a hard constraint in the Business app — not a paid tier restriction. **Does Blueticks work with WhatsApp Business accounts?** Yes. Blueticks works through WhatsApp Web, which supports both regular WhatsApp and WhatsApp Business accounts. The scheduling, recurring message, and campaign features are available for both account types. **What's the difference between scheduling via a Chrome extension and the API?** The WhatsApp Business app itself has no native scheduler, so the realistic choices are a WhatsApp Web extension or the API. A Chrome extension like Blueticks runs on top of WhatsApp Web, needs no Meta setup or per-message fees, and handles one-time, recurring, and CSV-campaign sends — the faster path for teams under a few hundred contacts. The WhatsApp Business Platform (API) supports programmatic scheduling at scale, CRM integration, broadcasts beyond 256 contacts, and multi-agent handling, but involves per-conversation fees and a setup process through Meta or a BSP. For operators with volume and budget, the API is more capable. **Will scheduling messages get my WhatsApp Business number banned?** Not if you use it for legitimate business communication — follow-ups, reminders, check-ins with opted-in contacts. WhatsApp's Terms of Service prohibit bulk messaging that resembles spam. Scheduling 5 follow-up messages to 50 warm leads is fine. Blasting 5,000 cold numbers with a sales pitch is not, and can result in a ban regardless of the tool used. --- Ready to stop sending manually? [Install Blueticks](https://chromewebstore.google.com/detail/blueticks/adgnjhngogijkkppficiiepmjebijinl) and schedule WhatsApp Business messages directly from WhatsApp Web — no API setup, no phone number re-registration, working in minutes. --- # How One Shopify Store Scaled WhatsApp Ecommerce to 40% of Revenue (2026 Case Study) > Priya's skincare brand was leaking sales to cold abandoned carts and an email list nobody opened. Here's exactly how one Shopify store rebuilt its WhatsApp ecommerce automation and grew the channel to 40% of revenue in 90 days. URL: https://blueticks.co/blog/whatsapp-ecommerce-at-scale-shopify-case-study Published: 2026-06-01 Author: Sofia Alvarez Category: stories > *Lumi & Fern is a composite Shopify store. Its journey reflects patterns Blueticks sees across small direct-to-consumer brands selling on WhatsApp. Names, numbers, and identifying details are illustrative and assembled from common operator experiences, not drawn from a single interviewed customer. The third-party benchmarks cited are real and linked.* [image: Skincare brand founder packing online orders at a workbench, illustrating whatsapp ecommerce automation] Priya Menon was sitting on the floor of her spare bedroom at 9 PM, sealing the 38th order of the day with packing tape, when she opened her email dashboard and saw the number that finally broke her patience: a 19% open rate on the campaign she'd spent two days writing. Nineteen percent. For a list of 11,000 people who had bought from her at least once. Priya runs Lumi & Fern, a small-batch skincare brand she started in Bangalore and sells through a Shopify store to customers across India, the UAE, and Singapore. Two years in, she had a real business: roughly 1,400 orders a month, a product people loved, and a re-order rate good enough to keep the lights on. She also had a problem she couldn't out-work. Her two biggest leaks were invisible. Carts that never converted. And an email channel her customers had quietly stopped reading. "I kept hiring my way out of it," she said. "More ads, more email sequences, a part-timer for support. None of it touched the actual problem, which was that nobody was reading what we sent." This is the story of how she stopped sending more email and rebuilt the whole thing around WhatsApp ecommerce automation instead. Over 90 days, the channel went from a footnote to roughly 40% of revenue. Here's the arc, the numbers, and what broke along the way. ## What does "WhatsApp ecommerce at scale" actually look like in 2026? WhatsApp ecommerce at scale means running the post-click parts of your store, order confirmations, shipping updates, abandoned-cart nudges, post-purchase upsells, and support, through a channel customers actually open, instead of email they ignore. In 2026 that's a realistic strategy: WhatsApp passed 3.3 billion monthly active users early in the year, and message read rates sit far above email's. For Lumi & Fern, "at scale" didn't mean a call center. It meant one founder and one part-time helper running thousands of automated, personalized touches a month without either of them babysitting a screen. The gap that makes this work is engagement. Braze, an enterprise engagement platform, reports an average WhatsApp read rate around 68%. Brevo's 2026 benchmark puts average marketing-email open rates near 20 to 25%. So the same message sent on WhatsApp gets seen roughly three times as often. | Channel metric | Email (2026 benchmark) | WhatsApp (2026 benchmark) | |---|---|---| | Average open / read rate | ~21% (Brevo) | ~68% (Braze) | | Cart-recovery rate | 2–5% | 15–30% | | Messages read within 5 min | low | ~88% | That table is the whole thesis. If you're going to spend effort crafting a message, send it where it gets read. Priya had been pouring her energy into the 21% column. The rebuild moved it to the 68% one. If you want a primer on the message formats that earn opens like these, our guide to [WhatsApp campaign templates that convert](https://blueticks.co/blog/whatsapp-campaign-templates-that-convert) breaks down the structures she ended up using. ## Why did a growing Shopify store bet on WhatsApp instead of more email? She bet on WhatsApp because the math on email had stopped working. Acquisition costs were climbing, her list was large but unresponsive, and the customers who did buy were already messaging her on WhatsApp anyway. The channel her customers preferred and the channel she was investing in were two different places. The trigger was a single week in February. Priya ran two recovery efforts side by side. An automated email sequence to abandoned carts recovered just under 4% of them. A batch of manual WhatsApp messages she sent by hand to a sample of abandoners, "Hey, noticed you left the vitamin C serum, the discount code still works for today," recovered closer to 22%. [image: Small business owner reviewing order paperwork at a desk in a home office] "That was the moment," she said. "I did by hand, badly, in an afternoon, what my email tool couldn't do running all month. The difference wasn't the offer. It was that people saw it." The benchmark backs up what she saw. The Baymard Institute, aggregating data from 50 studies, pegs the average online cart-abandonment rate at roughly 70%. Seven of every ten carts vanish. The leading reason, cited by 48% of US shoppers, is unexpected costs at checkout. For Lumi & Fern, that 70% abandonment on top of a 4% email recovery rate meant the store was leaving most of its potential revenue on the table every single day. WhatsApp's 15 to 30% recovery range, per multiple 2026 commerce reports, represented real money she could actually go get. So she stopped expanding email and made WhatsApp the spine of the customer journey instead. ## How did they connect WhatsApp to Shopify for order notifications and catalog? A WhatsApp Shopify integration in 2026 has two halves: the official catalog connection through Meta Commerce Manager, and the messaging layer that sends order and shipping updates. Lumi & Fern synced their Shopify product feed into Meta Commerce Manager so the catalog appeared natively inside WhatsApp, then layered Blueticks on top of WhatsApp Web to schedule and batch the actual customer messages. The catalog side is Meta's own plumbing. You connect your Shopify catalog to Meta Commerce Manager, products sync on a near-real-time feed, and customers can browse items inside a WhatsApp chat without leaving the app. That part Priya set up once and rarely touched. The messaging side was where her day-to-day lived. For WhatsApp order notifications ecommerce customers expect, order confirmation the moment they buy, a shipping update when it leaves the warehouse, a heads-up the day before delivery, she used a mix of WhatsApp's own confirmations and Blueticks campaigns for the personalized, batched sends. Here's the part worth being honest about, because the commission asked for 2026 reality: Blueticks is a WhatsApp scheduling and campaign tool that runs through WhatsApp Web via a Chrome extension, not a native Shopify webhook app. Priya's workflow was deliberately low-tech glue. Each morning she exported the day's shipped orders from Shopify as a CSV, dropped it into a Blueticks [campaign](https://blueticks.co/campaigns), and sent a personalized "your order's on its way" message to every customer in one batch, each one merged with the customer's name and order number. "People assume there's some giant integration humming in the background," she said. "It's a CSV and a fifteen-minute habit. That's it." [image: Stacked shipping boxes with address labels at a small ecommerce packing station] Order confirmations on WhatsApp see open rates close to 98% and cut "where is my order?" support messages by an estimated 40 to 50%, which freed up the time she used to spend answering the same question forty times a day. ## Which automations recovered the most abandoned carts? The single highest-return automation was the abandoned cart WhatsApp nudge sent 30 minutes after checkout was abandoned, followed by one reminder the next morning. That two-touch sequence did the heavy lifting; a third touch added little and started to annoy people. Recovering carts on WhatsApp depends entirely on having permission to message the customer, which is why opt-in collection mattered more than the message copy. Lumi & Fern added a clear checkbox at checkout, "Get order updates on WhatsApp," and a click-to-WhatsApp button on product pages. Within six weeks, 61% of checkout sessions had opted in. (If you're setting this up, our [WhatsApp opt-in collection guide](https://blueticks.co/blog/whatsapp-opt-in-collection-guide) walks through the compliant ways to do it.) The sequence that won: - **Touch 1, 30 minutes after abandonment:** a short, specific message naming the exact product left behind, with the cart link. No discount yet. - **Touch 2, next morning at 10 AM:** a gentle reminder, this time with a small time-limited incentive, sent as a scheduled Blueticks batch to the previous day's abandoners. "The 30-minute one with no discount converted better than I expected," Priya said. "Half the abandoned carts weren't price-sensitive. They just got distracted. A nudge while it was still fresh was enough." Across the test period, the two-touch WhatsApp sequence recovered 23% of abandoned carts that had opted in, against the roughly 4% her old email flow managed. On a 70% abandonment base, that swing was the largest single revenue change in the whole project. ## How did post-purchase upsell flows lift average order value? The WhatsApp post purchase upsell flow lifted average order value by timing a complementary-product offer to land a few days after the original order arrived, when the customer was actually using the product and most receptive. The trick was patience: pitching at delivery felt pushy; pitching at day 5 felt helpful. Lumi & Fern's best-performing flow was a replenishment-and-pair message. Five days after a serum order was delivered, the customer got a WhatsApp message: a short tip on getting the most from the product, then a suggestion to add the matching moisturizer, with a bundle price. [image: Customer holding a phone face-down beside a skincare bottle on a bathroom counter] Because the catalog was already connected through Meta Commerce Manager, the customer could view and pick the recommended product inside the same chat. Priya sent these as a scheduled Blueticks campaign each day, segmented by which product the customer had bought, using the same CSV-and-merge habit as her shipping updates. "I stopped thinking of it as an upsell," she said. "It's a follow-up from someone who knows what you bought. The conversion came from the timing, not from being clever." The day-5 upsell flow added roughly 14% to average order value across customers who received it, and because it ran on WhatsApp rather than email, far more of them saw it in the first place. ## What happened to their WhatsApp ecommerce conversion rate after 90 days? After 90 days, the channel's WhatsApp ecommerce conversion rate, measured as orders driven by WhatsApp touches divided by customers reached, settled well above what the store ever achieved on email, and WhatsApp grew to roughly 40% of total revenue. The gains came from three compounding sources: recovered carts, post-purchase upsells, and re-orders prompted by replenishment messages. Here are the numbers Priya tracked over the 90-day window. These are her store's self-reported figures, not a controlled study, so read them as directional. | Metric | Before (email-led) | After 90 days (WhatsApp-led) | |---|---|---| | Abandoned-cart recovery rate | ~4% | ~23% | | Average order value | baseline | +14% | | Channel open / read rate | ~19% | ~67% | | Support reply time | 6+ hours | under 20 minutes | | Share of total revenue from channel | ~8% | ~40% | The 40% figure surprised even her. It wasn't that WhatsApp invented new demand. It surfaced demand that email was failing to capture, carts that would have stayed dead, re-orders that would never have been prompted, upsells nobody would have seen. "It didn't feel like a 5x," she said. "It felt like we finally got credit for sales we were already almost making." ## How did they scale WhatsApp customer service without adding headcount? Scaling WhatsApp customer service ecommerce volume without hiring came down to two moves: cutting the inbound questions at the source with proactive order updates, and using scheduled acknowledgements so no message sat unanswered. Lumi & Fern handled thousands of monthly conversations with one founder and one part-timer. The biggest lever was prevention. Once proactive shipping updates went out automatically, the "where is my order?" messages, previously 40 to 50% of all inbound, mostly disappeared. Fewer questions meant the same two people could keep up. For the messages that did come in, Priya leaned on Blueticks-scheduled acknowledgements for anything arriving after hours, so a customer messaging at 11 PM got a warm "got your message, we'll reply by 10 AM" first thing in the morning. WhatsApp's own 24-hour customer service window helped here too: under Meta's 2026 per-message pricing, replies to a customer-initiated conversation within 24 hours are free service messages, so staying responsive cost nothing extra. [image: Two people running a small ecommerce operation together in a compact workspace] "The headcount question answered itself," she said. "When you stop creating the questions, you don't need more people to answer them. We went from drowning to having actual evenings." Reply time on genuine inbound questions dropped from over six hours to under 20 minutes, and customer-satisfaction notes in reviews started mentioning the speed unprompted. ## What broke at scale — and what they would do differently? Plenty broke. The honest version of this story includes a duplicate-message incident, an opt-in scare, and a near-miss with message frequency that almost burned the channel down. Scaling WhatsApp ecommerce automation is mostly about not abusing the access you've earned. The first break was duplication. Early on, Priya sent a shipping-update campaign, then her part-timer manually messaged a few of the same customers. Some people got the same update twice in ten minutes. The fix was a shared rule: one person owns each scheduled campaign, and manual replies happen only inside live conversations, never as broadcasts. The second was frequency. In month two she got greedy, abandoned-cart nudge, shipping update, upsell, plus a promo, and a handful of customers replied with the same word: "stop." That was the warning. WhatsApp is a permission channel, and the unsubscribe button is the customer's thumb. She cut back to a strict ceiling of messages per customer per week and treated promotional sends as rare. "The thing that scares me about WhatsApp is also what makes it work," she said. "People read everything. So if you waste their attention, they punish you instantly. Email lets you be lazy. WhatsApp doesn't." What she'd do differently: collect opt-ins from day one rather than retrofitting them, and resist the urge to add a third and fourth cart-recovery touch. Two touches captured nearly all the recoverable revenue; more just raised opt-outs. ## How can your store replicate this playbook step by step? You can replicate this with a Shopify store, WhatsApp Business, and a scheduling tool, the core moves don't require enterprise software. The playbook is: connect your catalog, collect opt-ins, automate the order journey, run a two-touch cart recovery, add a delayed upsell, and protect the channel with frequency limits. Here's the sequence Priya would hand a friend starting today: 1. **Connect your Shopify catalog to Meta Commerce Manager** so products appear natively inside WhatsApp chats. 2. **Collect opt-ins everywhere**, a checkout checkbox and a click-to-WhatsApp button on product pages. This is the foundation; without permission, nothing else is allowed. Use the [opt-in collection guide](https://blueticks.co/blog/whatsapp-opt-in-collection-guide) to do it compliantly. 3. **Automate order and shipping updates.** Export shipped orders daily and send a personalized batch so every customer gets a confirmation and a "on its way" message. 4. **Run a two-touch abandoned cart sequence**, a no-discount nudge at 30 minutes, a gentle incentive the next morning. 5. **Add a day-5 post-purchase upsell** suggesting a complementary product while the customer is actively using what they bought. 6. **Set a weekly message ceiling** per customer and treat promos as rare. Protect the open rate that makes the whole thing work. For the message copy at each step, the [campaign templates that convert](https://blueticks.co/blog/whatsapp-campaign-templates-that-convert) guide gives you tested structures, and you can build and schedule the batches themselves from the [Blueticks campaigns dashboard](https://blueticks.co/campaigns). The tooling here is deliberately light. Priya ran all of it through WhatsApp Web with the Blueticks Chrome extension, scheduling sends and managing campaigns from CSV exports. No API contract, no developer. **Want to send your first scheduled WhatsApp campaign today?** Install the Blueticks Chrome extension in under two minutes and schedule your first abandoned-cart message before you close your laptop. [Install Blueticks — free on Chrome Web Store](https://chromewebstore.google.com/detail/blueticks/adgnjhngogijkkppficiiepmjebijinl) ## Frequently Asked Questions **Do I need the WhatsApp Business API to run WhatsApp ecommerce automation?** Not to start. For native catalog browsing inside WhatsApp you connect your Shopify catalog to Meta Commerce Manager, which is free. For the messaging itself, smaller stores can schedule order updates, cart recovery, and campaigns through WhatsApp Web using the Blueticks Chrome extension, no API account or per-message fees required. Higher-volume stores often graduate to the WhatsApp Business Platform, which since July 2025 bills per message by category. **How much does WhatsApp Business messaging cost in 2026?** If you use the WhatsApp Business Platform (API), Meta switched to per-message pricing on July 1, 2025. Messages are billed by category, marketing, utility, and authentication, with rates varying by country. Service messages sent inside the 24-hour customer-service window opened by a customer's own message are free. If you schedule through WhatsApp Web with a tool like Blueticks instead, you're sending as a regular WhatsApp Business user with no per-message platform fee. **What abandoned-cart recovery rate is realistic on WhatsApp?** Multiple 2026 commerce reports put WhatsApp abandoned-cart recovery in the 15 to 30% range, versus 2 to 5% for email. The single biggest factor is opt-in coverage, you can only message customers who agreed. A two-touch sequence (a 30-minute nudge plus a next-morning reminder) typically captures most of the recoverable revenue without raising opt-outs. **How does a Shopify store connect its product catalog to WhatsApp?** You connect your Shopify catalog to Meta Commerce Manager, which syncs your product feed on a near-real-time basis so items appear inside WhatsApp chats. Customers can then browse and select products without leaving the conversation. This is Meta's official catalog plumbing and is separate from whichever tool you use to send messages. **Can one small team really handle WhatsApp at this volume?** Yes, if you cut inbound questions at the source. Proactive shipping updates eliminate most "where is my order?" messages, which for many stores are 40 to 50% of all support volume. Combine that with scheduled after-hours acknowledgements and a strict weekly message ceiling, and a two-person team can manage thousands of conversations a month, as Lumi & Fern did, without adding headcount. --- # WhatsApp Opt-In Collection: 9 Channels, Conversion Rates, and Meta's 2025 Rules > Meta rewrote the opt-in rulebook in April 2025. Here are the 9 channels that actually build a compliant WhatsApp list — with conversion rates, required wording, and what changed. URL: https://blueticks.co/blog/whatsapp-opt-in-collection-guide Published: 2026-05-31 Author: Maya Cohen Category: marketing [image: Person signing a paper consent form at a retail counter with a phone face-down beside them] You spent months building your WhatsApp contact list. Then Meta changed the rules in April 2025 — and half your US subscribers became unreachable overnight. If you're still using a single checkbox from your checkout page and calling it "compliant," you're one quality-rating drop away from a campaign suspension. This guide covers the nine channels that build a real, Meta-compliant WhatsApp opt-in list, what conversion rate each one should hit, and exactly what changed in 2025 that you need to act on now. ## What Meta requires for a valid WhatsApp opt-in in 2026 A valid WhatsApp opt-in needs four things: your business name, an explicit mention of WhatsApp as the channel, a description of the message types the user will receive, and a clear opt-out path. Missing any one of these four elements means your consent is non-compliant — regardless of where you collected it. Per Meta's WhatsApp Business Platform documentation, a compliant opt-in must satisfy these conditions simultaneously: - **Business name clearly stated** — "From [Your Business Name]" must appear in or near the consent prompt, not buried in a footer - **Channel specificity** — The word "WhatsApp" must appear. "Text messages" or "mobile updates" is not sufficient - **Message type disclosure** — Tell them what they're signing up for: order updates, promotions, restock alerts, or a combination - **Opt-out mechanism** — Users must know they can stop. "Reply STOP to unsubscribe" has become the standard formulation One constraint that catches businesses off guard: **opt-ins cannot be collected through WhatsApp itself**, per Infobip's documentation of the Meta platform rules. You cannot cold-message someone on WhatsApp to ask for opt-in consent — consent must come before that first outbound template. The required language is more specific than most businesses realize. The Klaviyo/Meta canonical template reads: *"By replying YES to this message, you agree to receive marketing and/or informational messages from [Company Name]. Reply STOP to opt out."* The key elements are a verb-of-agreement ("I agree," "Yes, sign me up"), your exact business name, and the opt-out instruction. ## The 9 channels that collect WhatsApp opt-ins — and what conversion rate each should hit Nine proven channels exist for WhatsApp consent collection, ranging from website forms (1–8% of visitors) to CTWA ads (35–55% click-to-conversation rate) to post-purchase checkouts (15–30% of buyers). Your highest-volume channel isn't always your highest-converting one — matching channel to intent is what drives list quality. Here are all nine, with realistic benchmarks drawn from Chatarmin's KPI benchmarks and industry usage data: [image: QR code displayed on a product receipt sitting on a wooden retail counter] ### 1. Website popup or banner **Conversion rate: 3–8% of visitors** (top performers hit 10–15% with exit-intent triggers and incentives) A dedicated opt-in popup is the single highest-volume acquisition channel for most e-commerce brands. The mechanics: display the popup on high-intent pages (product, cart, blog), keep the value prop in one sentence, and make the checkbox unchecked by default. Timed delay of 8–12 seconds or exit intent outperforms on-load. If your site popup converts below 2%, the incentive is the problem — a 10%-off offer or early-access promise routinely doubles opt-in rates. **Example wording:** "Get order updates and exclusive offers on WhatsApp. By checking this box, you agree to receive WhatsApp messages from [Brand]. Msg frequency varies. Reply STOP to opt out." ### 2. Checkout opt-in checkbox **Conversion rate: 15–30% of buyers** The checkout page is your warmest acquisition moment — the customer just trusted you with their payment info. A simple, unchecked checkbox next to the phone number field ("Send my order updates via WhatsApp") consistently converts at 15–30% because the value proposition is immediate and concrete. Keep the language transactional at checkout; upgrade to marketing consent in a follow-up welcome flow. ### 3. Post-purchase thank-you page **Conversion rate: 20–35% of buyers** The thank-you page is underused. The customer just completed a purchase — they're at peak trust. A clear "Stay updated on your order via WhatsApp" prompt with a one-tap wa.me link converts at 20–35%. This is also the best moment to ask for marketing consent as a separate step, because the context is service-first: the customer wants to track their package. ### 4. Click-to-WhatsApp (CTWA) ads **Conversion rate: 35–55% click-to-conversation** CTWA ads on Facebook and Instagram bypass the friction of a form entirely. The user sees the ad, taps the button, and lands inside a WhatsApp conversation with your business. Between 35–55% of ad clicks turn into actual conversations (per Chatarmin's benchmark data), compared to 2–5% CTR for standard click-to-website ads. The session that opens is classified as a service conversation under the post-July 2025 per-message billing model — which means the first 72 hours of that entry-point window carry no template cost. See the [WhatsApp Business API pricing guide](/blog/whatsapp-business-api-pricing-2026) for the full entry-point pricing breakdown. The critical compliance step: configure your automated welcome message to include an explicit opt-in prompt for future marketing templates. The ad click grants implicit consent for that conversation session only. To send marketing templates later, capture explicit consent in that first exchange. ### 5. QR codes (offline and digital) **Conversion rate: 5–15% of scans (offline); 10–20% in email or SMS** QR codes placed on product packaging, receipts, in-store displays, or event materials route customers directly into a WhatsApp chat with a pre-filled message. Offline QR codes are particularly strong for retail and hospitality — a brand placing them on receipts in a 50-location chain can add thousands of opt-ins per month at near-zero acquisition cost. In email or SMS, an embedded QR code or wa.me link to "move the conversation to WhatsApp" converts at 10–20% of recipients who click. French retailer Carrefour saw a 35% increase in engagement compared to email catalogues after routing customers from in-store QR codes to WhatsApp, per industry benchmarks. ### 6. Email or SMS migration campaigns **Conversion rate: 8–18% of existing subscribers** If you already have an email or SMS list, a migration campaign — "Continue this conversation on WhatsApp for faster replies" — can move 8–18% of existing subscribers to the higher-engagement channel. The value proposition needs to be explicit: faster order support, exclusive deals, or content that lives only on WhatsApp. The welcome message sent after the migration opt-in must still include proper consent language. ### 7. Voice IVR **Conversion rate: 5–12% of callers offered the option** Interactive voice response is effective for businesses with high inbound call volume: telcos, banks, insurance providers, utilities. A prompt at the end of a support call ("Press 2 to receive your case summary and future support on WhatsApp") captures consent in a context where the customer is already engaged. The IVR system logs the keypress as the consent record. Conversion rates of 5–12% of callers offered the prompt are realistic without any additional incentive. ### 8. Customer service / live agent handoff **Conversion rate: 25–45% when offered at resolution** A human agent or chatbot asking "Would you like to continue updates via WhatsApp?" at the close of a support interaction converts at 25–45%, according to industry operator data. This is the highest-intent moment outside of checkout — the customer just had a positive (or resolved) support experience. Timing matters: ask at resolution, not at the start of the conversation. ### 9. ATM, banking apps, and kiosk prompts **Conversion rate: 3–8% of customers shown the prompt** Banks, utilities, and government services increasingly use ATM screens and in-app prompts to collect WhatsApp consent for account alerts and service notifications. The conversion rate is lower (3–8%) because the proposition is narrower (account alerts, not promotions), but the resulting list is highly engaged and has very low unsubscribe rates. ## How to write opt-in language that passes Meta's wording requirements Meta's opt-in language requirements come down to six words: **who, what, where, why, how much, and how to stop.** Your consent prompt needs to identify your business, name WhatsApp as the channel, describe the message types, indicate frequency, and include an opt-out instruction — all before the user taps agree. Here is the Meta-compliant structure: > "By checking this box, you agree to receive [message types: e.g., order updates, promotions, restock alerts] via **WhatsApp** from **[Business Name]**. Message frequency varies. Reply **STOP** to opt out." Three things that disqualify your consent language: 1. **Pre-checked boxes** — The user must actively opt in. A pre-checked checkbox is not valid consent under Meta policy or GDPR. 2. **Bundled consent** — "I agree to the Terms of Service and to receive WhatsApp messages" in a single checkbox violates GDPR's specificity requirement. WhatsApp consent must be a separate, standalone action. 3. **Generic channel language** — "Receive mobile updates" or "text message notifications" does not satisfy the requirement to name WhatsApp specifically. The frequency disclosure does not need to be exact. "Message frequency varies" is acceptable; "Up to 4 messages per month" is better for user experience. ## Double opt-in on WhatsApp Business API: when is it mandatory? Double opt-in (DOI) is a two-step consent flow: you send a template asking the user to confirm ("Reply YES to subscribe"), and they become a confirmed opt-in only after replying. Meta does not globally mandate double opt-in — a single opt-in is sufficient if the four required elements are present. However, DOI is effectively required for businesses operating under GDPR in Germany, Austria, and the broader EU where burden-of-proof for consent is highest. The DOI flow works as follows: 1. User submits their phone number through one of the nine channels above 2. They receive a Meta-approved template message: *"By replying YES, you agree to receive marketing and/or informational messages from [Company]. Reply STOP to opt out."* 3. Upon replying YES (or JA, OUI, SÍ — the keyword list covers major languages), the subscription confirmation sends and they're active in your list In testing by outdoor apparel brand Jack Wolfskin (per hello-charles.com), **90% of users who received a double opt-in request completed it** — meaning the drop-off from single to double opt-in is far lower than most marketers fear, particularly when the welcome message makes the value prop clear. When DOI is worth implementing regardless of legal requirement: any list you plan to use for high-frequency marketing sends, any audience segment you acquired via a broad lead-gen campaign where intent quality is mixed, and any migration from a channel (email, SMS) where your consent records are more than 18 months old. ## How a CTWA ad creates a compliant opt-in automatically A click-to-WhatsApp ad turns an ad click into an opt-in event — but only if you configure the welcome message correctly. The click itself is implicit consent for the immediate session. To make it a durable opt-in for future marketing templates, you need explicit confirmation inside that first conversation. [image: A hand reaching toward a touchscreen kiosk display in a modern retail store] Here is the compliant CTWA opt-in flow: 1. User sees your Facebook or Instagram ad and taps the "Send Message" button 2. WhatsApp opens with a pre-filled message (you define this in Ads Manager). The user taps send. 3. Your automated welcome message fires immediately: *"Hi! Thanks for reaching out to [Brand]. To send you updates, exclusive offers, and [content type] on WhatsApp, just reply YES — or reply STOP at any time to opt out."* 4. User replies YES → they are a confirmed opt-in subscriber Why CTWA is powerful beyond the opt-in: the conversation that opens is classified as a **service/entry-point window** under Meta's post-July 2025 per-message billing model. Per the [WhatsApp Business API pricing breakdown](/blog/whatsapp-business-api-pricing-2026), the 72-hour window that opens from a CTWA click carries no template message cost — all message categories send free during that window. That means your first follow-up nurture sequence (within 72 hours) costs nothing in conversation fees. CTWA ad cost benchmarks: cost per conversation ranges from €1.50 to €8.00 depending on vertical and audience targeting, per Chatarmin's 2026 KPI report — roughly 2–3x the cost of a website click but with a 35–55% conversation rate versus 2–5% for standard click-to-website. ## WhatsApp website opt-in widget: implementation without killing page speed Adding a WhatsApp signup widget or floating button to your website requires one JavaScript snippet — but unoptimized third-party chat widgets are among the top causes of Core Web Vitals failures. Here is how to add WhatsApp opt-in collection without hurting your Lighthouse score. **Option 1: Native checkbox + wa.me redirect (zero JS overhead)** The lightest implementation requires no third-party script at all: 1. Add a phone number field and a WhatsApp consent checkbox to your existing form 2. On submit, store the number with a consent timestamp in your CRM 3. Trigger a wa.me link open to initiate the opt-in confirmation message No widget to load. No Core Web Vitals impact. The trade-off: the user experience is two-step (form submit, then WhatsApp opens). **Option 2: Lazy-loaded floating button** If you want the floating WhatsApp icon, load it with `loading="lazy"` or defer the script until after the LCP event fires. Use `Intersection Observer` to only initialize the widget when it scrolls into view. This prevents the third-party script from blocking render. **Option 3: Dedicated opt-in landing page** For CTWA campaigns and paid traffic, a standalone `/whatsapp-signup` landing page with a single-focus form (phone number + consent checkbox + submit) consistently outperforms embedded widgets. No competing CTAs, no navigation. Treat it like a squeeze page: headline states the value, subhead states the message frequency, button says "Subscribe on WhatsApp." For site-wide deployment, [Blueticks's campaign management tools](/campaigns) handle list segmentation, scheduling, and opt-out processing in one place — so you don't need to stitch together separate tools for consent recording and send scheduling. ## What changed in April 2025 — and what you need to do today [image: Marketing manager reviewing printed campaign compliance checklist at a tidy office desk] April 2025 was the single largest policy shift in WhatsApp Business Platform history. Three changes hit simultaneously, and any one of them can pause your campaigns or damage your quality rating if you haven't adapted. ### Change 1: Marketing templates to US numbers are paused Since April 1, 2025, **marketing template messages to US phone numbers (+1) are not delivered**, per Meta's platform documentation (sourced from GoHighLevel's platform changelog and Cheerio AI's breakdown). Only utility templates (order confirmations, shipping updates, appointment reminders) and authentication templates continue to function for US recipients. This is not a ban on WhatsApp Business in the US — service conversations (user-initiated, 24-hour window) still work normally. But if you are running broadcast marketing campaigns to a US list, those messages are silently undelivered. The platform returns no error on your end that looks like a ban; messages simply don't reach US numbers. **What to do:** Segment your list by country code. Redirect US contacts to utility flows (transactional triggers) or email for marketing content. If your product or service requires US marketing outreach, monitor Meta's official changelog for when the pause lifts. ### Change 2: The 2-marketing-messages-per-day cap Meta implemented a platform-wide cap: each user can receive approximately **2 marketing template messages per day across all businesses combined**. This is not 2 messages from your brand — it is 2 total from every WhatsApp-connected business that user receives messages from. When the cap is hit, your template returns **error code 131049** ("Marketing limit reached for this user"). Retrying immediately fails. The cap resets at the next calendar day. The practical implication: brands sending daily broadcast blasts are hitting this cap for a meaningful percentage of their list. Per Chatarmin's analysis, one well-timed personalized message achieves more than three generic blasts — not just in engagement terms, but because the third blast simply isn't delivered. ### Change 3: One-click unsubscribe is now required in all marketing templates Every marketing template submitted after April 2025 must include an opt-out mechanism. The platform-standard implementation is a footer line: *"Reply STOP to unsubscribe."* The implementation steps for existing templates: 1. Go to your Meta Business Manager → WhatsApp Manager → Message Templates 2. Edit any marketing template missing the footer 3. Add a footer component with "Reply STOP to unsubscribe" (or equivalent in your primary language) 4. Resubmit for approval — approval time is typically 1–3 hours for template edits Templates that include the opt-out footer also perform better on Meta's quality sampling. Users who can easily unsubscribe are less likely to block your number, and blocks are the primary input to your quality rating score. To handle unsubscribes programmatically, configure a webhook to receive the `messages.statuses` event with `type: "user_preference_change"` — this fires when a user opts out via the platform preference panel (the "Offers and announcements" setting Meta rolled out alongside the April changes). ## Managing, segmenting, and re-permissioning your opt-in list at scale A compliant opt-in list is not a static asset — it degrades. Phone numbers churn, opt-out events accumulate, and consent records become stale if you don't timestamp and version them. Managing a list above 10,000 contacts requires three operational practices: segmentation by acquisition channel, consent record timestamping, and periodic re-permission campaigns. [image: Marketing analyst reviewing printed WhatsApp campaign performance reports spread on a desk] ### Segmentation by acquisition channel Different channels produce different audience quality. A CTWA list from a broad "win a prize" campaign has much lower engagement quality than a checkout opt-in list from buyers who shipped in the last 90 days. Segment these audiences from day one and track their quality metrics separately: reply rate, block rate, and error 131049 frequency. Your checkout opt-in list should have a block rate under 0.5%; your QR code / lead-gen list may run 2–5%. [Blueticks's campaign tools](/campaigns) let you tag opt-ins by source at collection time and filter audience segments when scheduling sends, so you can apply different message frequencies to different cohorts. ### Consent record timestamping Store three fields with every opt-in record: the phone number, the consent timestamp (ISO 8601), and the collection source (checkout, CTWA, popup, etc.). This data becomes your defence under GDPR audits and Meta policy disputes. When a user claims they never opted in, you need to produce the exact timestamp and the form/ad they came through. ### Re-permission campaigns Any contact you haven't messaged in 180+ days should go through a re-permission flow before your next broadcast. The flow: 1. Send a single utility or authentication template (outside the marketing cap) reminding them of your brand 2. Ask them to reply YES to continue receiving messages 3. Archive non-responders after 7 days Interakt's analysis of WhatsApp API usage found that list hygiene — removing or re-permissioning stale contacts — is the single highest-leverage action for improving quality ratings and avoiding campaign pauses. A list of 5,000 active, recently re-permissioned contacts outperforms 50,000 cold opt-ins every time on both deliverability and quality score. ## Frequently Asked Questions **Can I add customers to WhatsApp from my existing phone contacts without an opt-in?** No. Uploading a contact list and sending them marketing templates without documented consent is a policy violation and will trigger account quality warnings. Every recipient must have actively opted in through one of the approved channels before you send any outbound template message. **What is the difference between a single opt-in and a double opt-in on WhatsApp?** A single opt-in is a one-step process: the user checks a box or fills in a form and is immediately added to your list. A double opt-in adds a confirmation step: you send a template message asking them to reply YES before activating their subscription. Double opt-in is not required by Meta globally but is effectively mandatory for EU businesses under GDPR where you need documented, verifiable consent. **Does clicking a WhatsApp chat button on my website count as opt-in?** Clicking a wa.me link or a WhatsApp chat button and sending a message counts as implicit consent for that specific conversation session — the 24-hour service window. It does not automatically constitute opt-in consent for future outbound marketing templates. You need to capture explicit consent during that first exchange before adding the contact to your marketing list. **What happens if I send marketing templates to US numbers after April 2025?** Your templates will not be delivered to +1 US numbers. The messages will not throw an account-level error, but they simply won't reach the recipient. Utility and authentication templates continue to work normally for US contacts. Monitor Meta's developer changelog for updates on when the US marketing template pause is lifted. **How do I handle the error code 131049 when sending campaigns?** Error 131049 means the recipient has hit the per-user daily marketing message cap (~2 messages across all businesses). You cannot retry the same recipient until the cap resets the following day. The correct response is to reduce send frequency, segment your most-engaged contacts for priority sends, and deprioritize cold or low-engagement contacts in high-volume broadcast campaigns. **Does Blueticks support one-click unsubscribe and opt-out handling?** Yes. [Install the Blueticks Chrome extension](https://chromewebstore.google.com/detail/blueticks/adgnjhngogijkkppficiiepmjebijinl) to manage opt-out processing, segment your list by consent source, and schedule compliant campaign sends — all from your existing WhatsApp Business account without needing to stand up a separate API integration. *Footnote: Conversion rate ranges in the 9-channels section are illustrative benchmarks drawn from Chatarmin's KPI report, hello-charles.com operator data, and general industry figures. Actual rates vary by industry, audience quality, and offer strength. Test with small sends before scaling.* --- # WhatsApp Business Multiple Numbers: Every Option Explained (2026) > One WhatsApp Business number is rarely enough. Here's every legitimate way to run more — and where each option breaks down. URL: https://blueticks.co/blog/whatsapp-business-multiple-numbers Published: 2026-05-30 Author: Avi Kohen Category: industry [image: hero two phones desk] Running more than one WhatsApp Business number sounds simple. In practice, it touches four different product surfaces — each with its own rules, limits, and failure modes. Get the wrong setup and you are either flying solo when you need a team, or hitting policy walls you did not know existed. This guide covers every option WhatsApp offers in 2026: what the platform actually permits, which products support it, and what the API unlocks that the app never will. ## What WhatsApp Actually Permits in 2026 WhatsApp runs on a "one account, one phone number" model at its core. That has not changed. What has changed is how many *devices* and *numbers* you can manage simultaneously — and the answer differs depending on which WhatsApp product you are using. Three distinct mechanisms let you work across more than one number or device: 1. **Linked Devices (Companion Mode)** — one number, up to four additional devices 2. **Multiple Accounts** — two numbers on one phone (dual-SIM or eSIM required) 3. **WhatsApp Business API** — multiple numbers managed programmatically, no device limit Each serves a different problem. None of them are the same thing. Per [WhatsApp's features page](https://www.whatsapp.com/features/), "linked devices provide a reliable, secure way to access WhatsApp from any of your devices" — but that phrasing is about access, not about running separate numbers in parallel. Understand the distinction before you build a workflow around the wrong product. ## Companion Mode and Linked Devices: How the 4-Device Limit Works WhatsApp's Companion Mode — announced globally on [April 25, 2023](https://blog.whatsapp.com/one-whatsapp-account-now-across-multiple-phones) — lets you link one WhatsApp account to up to four additional phones. Those linked phones operate alongside your primary device, receiving messages and calls independently. The critical detail: this is *one number, multiple screens*. You are not managing a second phone number. Every message sent from a linked device comes from the same account, the same number. **What the 4-device limit covers:** Per the WhatsApp blog post, you can "link your phone as one of up to four additional devices" — matching the same limit that applies to linked tablets and desktop apps. In total that gives you five active surfaces: the primary phone plus four companions. **The primary phone requirement:** Your primary phone still anchors the account. According to WhatsApp's Help Center, linked devices automatically log out if the primary phone remains inactive for an extended period. There is also a 14-day rule: log into WhatsApp on your primary phone at least once every 14 days to keep companion devices connected. **For WhatsApp Business:** The Business app carries the same linked-device structure. WhatsApp's Help Center maintains a [dedicated article on linked devices for the Business app](https://faq.whatsapp.com/647349420360876) with the same four-companion limit. The practical benefit the April 2023 blog post specifically called out: small business owners can have additional employees respond to customers directly from their own phones under the same WhatsApp Business account. That is genuinely useful for a two- or three-person operation. It starts to strain when you need separate numbers for separate brands, departments, or regions — which is where the other options matter. [image: hands two phones side by side] ## Two Numbers on One Phone: The Dual-SIM Workaround WhatsApp now supports two accounts running simultaneously on a single device — one per SIM slot or eSIM profile. This is the "multiple accounts" feature, and it is distinct from Companion Mode. [WhatsApp announced the feature for Android in October 2023](https://blog.whatsapp.com/multiple-accounts-coming-to-whatsapp), with setup accessible directly from WhatsApp Settings → tap the arrow next to your name → "Add account." iOS reached parity in March 2026, confirmed in [WhatsApp's feature roundup post](https://blog.whatsapp.com/new-feature-roundup-free-up-space-multiple-accounts-cross-platform-transfer-and-more). **What it requires:** A second phone number backed by a physical SIM, a multi-SIM slot, or an active eSIM profile on your device. You cannot add a second WhatsApp account using a VoIP-only number in most cases — the number needs to be able to receive an SMS or voice verification call. **What it actually gives you:** Two fully independent WhatsApp identities on one device. Each account has its own contacts, privacy settings, and notification profile. You can switch between them without logging out. **What it does not give you:** Shared inbox. Team access. Automation. Analytics. If you are managing customer conversations at any volume, two accounts on one phone is a personal productivity tool, not a business operations platform. It also does not scale: the feature supports exactly two accounts, not three or four. For most solo operators or freelancers keeping work and personal life separate, this is a clean solution. For any team-based or multi-channel operation, it is the wrong tool. You can [schedule messages from each account separately with Blueticks](https://blueticks.co/scheduler) — but the two accounts remain fully siloed with no way to manage them from a single dashboard. ## WhatsApp Business App vs. WhatsApp Business API: Which Supports Multiple Numbers? This is the core question most people are actually asking when they search "whatsapp business multiple numbers." The answer depends on which product you are using. | Feature | WhatsApp Business App | WhatsApp Business API (Cloud API) | |---|---|---| | Numbers per device | 1 (+ dual-SIM workaround for 2) | Unlimited per WABA (subject to portfolio limits) | | Linked devices | Up to 4 companion devices | No device-based access; API-only | | Team access | Via linked devices (shared login) | Role-based access through BSP dashboard | | Automation | None | Full programmatic send/receive | | Analytics | Basic (read receipts) | Message-level delivery, read, and error data | | Onboarding | Free, self-serve | Requires a Business Solution Provider or direct WABA | | Scale | Small business, single operator | Medium to enterprise | [WhatsAppBusiness.com](https://whatsappbusiness.com/) describes the split plainly: the Business App is "for small businesses who personally manage conversations," while the Business Platform is "for medium to large businesses communicating with customers at scale." The Business App does not support running multiple phone numbers under a single management interface. Full stop. You can use Companion Mode to share *access* to one number across a small team, but you cannot add a second number to the same app interface and switch between them the way you would in a CRM. The API is where multiple numbers become a first-class concept. ## Managing Multiple Numbers at Scale: What the API Unlocks The WhatsApp Business API (now exclusively the Cloud API, as of July 2024 when Meta required all new registrations to use Cloud API following the On-Premises API sunset) treats phone numbers as programmable objects within a WhatsApp Business Account (WABA). **Phone number structure:** According to Meta's [Phone Number Management API documentation](https://developers.facebook.com/documentation/business-messaging/whatsapp/reference/whatsapp-business-account/phone-number-management-api), each registered number inside a WABA gets a unique phone number ID. You call `GET /{WABA-ID}/phone_numbers` to retrieve all numbers, and `POST /{WABA-ID}/phone_numbers` to register a new one. Sending a message means specifying which phone number ID is the sender — so routing across numbers is a parameter, not a product limitation. **Portfolio-level limits:** Meta's [business phone numbers documentation](https://developers.facebook.com/documentation/business-messaging/whatsapp/business-phone-numbers/phone-numbers) sets out the initial constraints: new business portfolios start with a cap of 2 registered phone numbers. That cap increases to 20 automatically once your business becomes verified *or* once you reach the 2,000-message messaging tier. Limits beyond 20 require direct engagement with Meta. **Messaging tiers per number:** Each registered number starts at 250 outbound messages per day to unique users. According to Meta's [messaging limits documentation](https://developers.facebook.com/documentation/business-messaging/whatsapp/messaging-limits), tier advancement follows usage: hit 50% of your current limit within a rolling 7-day window and you move up. Tiers run from TIER_50 up to TIER_UNLIMITED. Messaging limits are calculated at the business portfolio level and shared across all WABAs within that portfolio — a detail that matters when you are running multiple numbers at high volume. **What this enables for multiple-number operations:** - Separate numbers for different product lines, brands, or regional markets — each with its own messaging analytics - Shared or segmented team inboxes via a Business Solution Provider dashboard - Campaign sends routed from a specific number to maintain sender identity - Automated flows (order confirmations, appointment reminders) running in parallel across numbers Running campaigns across multiple numbers is exactly where tools like [Blueticks Campaigns](https://blueticks.co/campaigns) integrate with the API layer — letting you define which number a campaign fires from without managing it at the raw API level. Need to schedule and send across more than one WhatsApp number without building on the API? Blueticks handles scheduled sends and campaigns per number, no verification required — [start free →](https://blueticks.co/signup). [image: business owner laptop notebook workspace] ## Practical Decision Matrix: Which Setup Is Right for Your Business? | Your situation | Best option | |---|---| | Solo operator, personal + work separation | Multiple Accounts (dual-SIM or eSIM on one phone) | | Small team (2-4 people), one brand, one number | Business App + Companion Mode (link team members' phones) | | Small team, want scheduling and reminders | Business App + Blueticks extension | | Multiple departments, one brand | WhatsApp Business API, single WABA, multiple numbers | | Multiple brands or regional markets | WhatsApp Business API, separate WABAs or multiple numbers per WABA | | High-volume outbound campaigns | WhatsApp Business API with Campaign tooling | | Just want two numbers on one device (no team) | Multiple Accounts feature (2-account max) | The Business App is the right starting point if you are managing conversations personally and your team is small enough to share one linked account. The API is the right answer the moment you need separate sender identities, high volume, or automation that runs without anyone being logged in. One thing the decision matrix cannot tell you: the API has real onboarding friction. You will need a Business Solution Provider (BSP) or a direct WABA setup through Meta's Embedded Signup flow. That is not a weekend project. Factor the setup time against the scale you actually need. ## Scheduling and Campaigns Across Multiple Numbers For API-connected setups, scheduling is one of the first operational wins. Rather than a team member staying online to send a time-sensitive message, you queue it via the API and the platform delivers it at the specified time. The [WhatsApp Business API pricing structure](https://blueticks.co/blog/whatsapp-business-api-pricing-2026) matters here: scheduled outbound messages that are template-based (marketing, utility, or authentication) incur per-message charges. Service messages, sent within a customer-initiated 24-hour window, remain free. Good scheduling discipline — batching utility messages within open service windows when possible — can materially reduce your per-number operational cost. For Business App users without API access, [Blueticks Scheduler](https://blueticks.co/scheduler) handles scheduling for one-time and recurring messages directly through WhatsApp Web. This works per-account, so if you are using the dual-account setup, you will manage schedules separately per number. [image: person reviewing calendar planner desk] ## Common Pitfalls and Policy Risks to Know **Companion Mode inactivity logout.** If your primary phone goes offline for an extended period — the WhatsApp Blog notes this specifically — companion devices lose access. For a business running on a shared account where the primary phone belongs to one employee who then goes on leave, this is an operational risk. Plan your primary device ownership carefully. **Third-party multi-account apps carry real ban risk.** WhatsApp's Terms of Service prohibit using unofficial clients or modified versions to access the platform. Apps that claim to run three or four WhatsApp Business numbers on one phone without the API are almost certainly using unauthorized access methods. Account bans are enforced and not appealed easily. **Dual-SIM workaround is not a team solution.** Two accounts on one phone share one screen and one set of hands. It does not give a second team member independent access. **Phone number cap at 20 is not unlimited.** If your business model requires 50+ sending numbers — regional franchises, for example — you will need to discuss higher limits with Meta directly. Do not build a 50-number architecture assuming the default cap covers it. **Messaging limit pooling at the portfolio level.** Meta's documentation confirms that messaging limits are shared across all phone numbers within a business portfolio. A single high-volume number can exhaust the shared pool and throttle every other number in your WABA. Monitor per-number volume independently and budget the portfolio limit across your number set. **On-Premises API is gone.** Any integration built before July 2024 that still references the On-Premises API needs migration. Meta's sunset documentation confirms new registrations have been Cloud API-only since July 2024, with the On-Premises API no longer available to current users after October 2025. [image: business owner hand near phone focused] ## Frequently Asked Questions **Can I run two WhatsApp Business numbers on one phone without the API?** Yes, but only two, and only if your phone supports dual SIM or eSIM. WhatsApp's multiple accounts feature — available on Android since October 2023 and on iOS as of March 2026 — lets you maintain two fully independent accounts simultaneously. Both need their own phone numbers. You cannot add a third account through this method. **How many linked devices can I have on one WhatsApp Business account?** Up to four companion devices in addition to your primary phone, per WhatsApp's Help Center. This applies to both the standard WhatsApp app and the WhatsApp Business app. Linked devices share the same account and number — they do not give you additional phone numbers. **Does the WhatsApp Business API support multiple phone numbers?** Yes. The Cloud API treats phone numbers as objects within a WhatsApp Business Account (WABA). New business portfolios start with a cap of 2 registered numbers, which increases to 20 after business verification or reaching the 2,000-message tier. Numbers beyond 20 require direct arrangement with Meta. **Do I need a Business Solution Provider to use multiple numbers via the API?** Not necessarily. Meta's Embedded Signup flow allows direct WABA creation, but most businesses working at scale use a BSP for dashboard tooling, inbox management, and support. For raw API access, you can register a WABA directly through Meta's developer portal. **What happens to Companion Mode devices if my primary phone goes offline?** Companion devices can continue operating independently for a period when the primary phone is offline. However, WhatsApp's blog notes that if the primary device remains inactive for an extended time, all companion devices will be logged out automatically. You also need to reconnect your primary phone at least once every 14 days to keep companion access active. --- # Inside the Blueticks AI Support Agent: 24/7 WhatsApp Answers, Trained on Your Knowledge Base > Your customers send questions on WhatsApp at midnight. Your team isn't there. Here's how the Blueticks AI Support Agent handles those conversations — and when it hands off to a human. URL: https://blueticks.co/blog/blueticks-ai-support-agent Published: 2026-05-29 Author: Priya Nair Category: updates Your customers don't stop having questions at 5 PM. They message on weekends, late at night, and across time zones you're not covering. A human support team can't be online around the clock without serious cost. An ai whatsapp bot that actually knows your business — your pricing, your return policy, your troubleshooting steps — can be. The Blueticks AI Support Agent is built on top of the Blueticks Bot System. It combines a knowledge base of your documents with an Agent Node that reads incoming WhatsApp messages, searches that knowledge base, and sends back grounded answers. No hallucinated policies. No generic deflections. The answers come from what you uploaded. [image: Support operator at a clean desk reviewing customer messages on a laptop in a bright office] This article walks through how the system works, how to set it up, when it escalates to a human, and what it genuinely cannot do. If you're evaluating this for a business, you need the honest version — that's what follows. ## What the Agent Actually Does — The Full User Flow When a customer sends a message to your WhatsApp number, the Trigger Node activates the bot flow. The message passes to the Agent Node, which searches your knowledge base for relevant content, formulates a response using that content, and sends the reply — typically within seconds. From the customer's side, it reads like a normal WhatsApp conversation. There's no "chatbot flavor" indicator in the UI. The response style is whatever you configured: formal, casual, somewhere in between. From your side, you get: - Automated responses to common product questions, troubleshooting queries, pricing requests, and policy lookups - A dashboard showing the number of conversations handled, average response time, common questions, and how often the bot hands off to a human - Conversation transcripts you can review to improve the knowledge base over time The bot operates through the Chrome extension running alongside WhatsApp Web. That means it requires your browser session to be active — or you to be on the Pro plan with the offline gateway enabled, which handles delivery when your machine is off. One important design note: the Agent Node is an endpoint in the flow, not a pass-through. Once the agent is handling a conversation, it operates autonomously. It doesn't exit to other nodes. If it can't answer something, it follows your configured handoff rules — more on that below. For a full walkthrough of the feature, see [the AI Support Agent guide](https://blueticks.co/ai-support-agent). ## How It Answers — Knowledge Base Ingestion and Multilingual Support The agent's answer quality is directly proportional to what's in the knowledge base. This is worth repeating because it's the biggest variable in whether the feature works for you. [image: Neatly organized folders and printed documents on a wooden desk ready for digitization] The knowledge base accepts uploaded documents. Supported formats, per the [knowledge base documentation](https://blueticks.co/guides/ai-support-agent): - PDF (`.pdf`) - Microsoft Word (`.doc`, `.docx`) - HTML files (`.html`, `.htm`) - Markdown (`.md`, `.markdown`) - Plain text (`.txt`) When you upload a file, the system extracts the text, chunks it, and indexes it using semantic embeddings. Documents are searchable within minutes. When a customer asks a question, the agent queries the index, ranks chunks by relevance, and uses the top results to formulate the response. **What this means practically:** If your product catalog is in a PDF and a customer asks "do you ship to Germany?", the agent finds the relevant section and answers based on it. If shipping policy isn't in any document, the agent will say it doesn't know — which is the correct behavior. You can configure a fallback message for unanswered questions. **A note on URL ingestion:** The setup wizard in the product mentions website URLs as a potential knowledge base source. The underlying knowledge base documentation is explicit that URL crawling is not currently supported — only file uploads work. If your content lives on a website, export it to PDF or HTML and upload that file. **Multilingual support** works at the document level. The agent can respond in the language the customer writes in, but answer quality improves when the underlying knowledge base includes documents in that language. If your KB is English-only and a customer writes in Spanish, the agent will attempt to answer from English sources — with varying accuracy. For businesses serving non-English markets, uploading translated documentation produces noticeably better results. ## Setting It Up — Step by Step Setup takes three meaningful phases: installation, knowledge base creation, and agent configuration. Here's the sequence. [image: Person typing at a laptop in a home office with a notepad beside them during daytime] ### Phase 1: Install and Activate 1. Install the [Blueticks Chrome extension](https://chromewebstore.google.com/detail/blueticks/adgnjhngogijkkppficiiepmjebijinl) if you haven't already. 2. Open WhatsApp Web in Chrome. 3. Click the Blueticks icon in your browser toolbar. 4. Select **AI Support Agent** from the menu. 5. Toggle the agent to **Active**. ### Phase 2: Build the Knowledge Base From the AI Support Agent dashboard, go to **Knowledge Base** and upload your documents. Practical starting point: a FAQ document, your product or service catalog, and any pricing or policy page you'd normally direct customers to. The docs recommend starting with the most frequently needed content rather than trying to upload everything at once. Upload, run a test query using the **Test Query** feature on each document, and verify the answers look right before going live. A few guidelines from the documentation that hold up in practice: - Use clear, direct language in your documents. Well-structured docs produce better retrieval. - Organize content into separate knowledge bases by topic if you have distinct product lines or service areas. - Large documents are automatically chunked, so you don't need to pre-split them — but very dense technical documents may require more precise customer questions to surface the right section. Keep your [knowledge base](https://blueticks.co/guides/ai-support-agent) current. If your pricing changes and the old document is still indexed, the agent will quote the old price. ### Phase 3: Configure Agent Behavior In **Agent Settings**, configure: - **Greeting message** — what the agent says when a conversation starts - **Working hours** — when to engage vs. when to send a "we'll get back to you" message - **Handoff triggers** — the conditions under which the conversation transfers to a human agent - **Response style** — formal or casual tone - **Languages** — which languages the agent should respond in The Agent Node also lets you choose from pre-built system prompt templates: Customer Support (General FAQs), Product or Service Information Assistant, Returns/Warranty/Policy Info Assistant, and others. Pick the one closest to your use case and customize it with your company name and any specific constraints. The system prompt is not visible to customers, but it shapes every response. Worth spending time on. If you tell the agent "do not speculate on delivery dates," it won't. ### Phase 4: Test Before Going Live Use the **Test Agent** feature to run simulated customer queries before the agent handles real conversations. Then conduct a live test from a second WhatsApp account. Verify that edge cases — unusual questions, questions with no answer in the KB, multi-part questions — produce reasonable responses or appropriate handoffs. The Blueticks [whatsapp support automation](https://blueticks.co/scheduler) documentation recommends starting with an Allow List (restricting access to your own number) in the Trigger Node settings during testing, then opening access once you're satisfied. ## When It Escalates — Human Handoff Logic The Agent Node is designed with a clear principle: complex, nuanced issues require human intervention, and the system should route them there without friction. You configure handoff triggers in Agent Settings. These are conditions — a customer asking for a refund, expressing frustration, or asking a question the agent flags as outside its scope — that transfer the conversation to a human agent. The transition is meant to be smooth: the human picks up the conversation with context from what was already exchanged. How you set handoff triggers determines how well this works. Too loose and the agent hands off constantly, defeating the automation. Too strict and customers with legitimate complex needs wait for a bot that can't help them. The documentation recommends having human agents available for handoffs even while the AI Support Agent is running. The bot handles volume. Humans handle exceptions. That's the division of labor the system is designed for. One configuration worth noting: the Trigger Node supports both block lists and allow lists, so you can exclude specific contacts from hitting the bot at all — for instance, high-value clients you always want to handle personally. A best practice called out explicitly in the product docs: disclose to customers that they're talking to an AI. The product doesn't enforce this, but it's the right call for trust and for compliance depending on your market. ## What It Doesn't Do — Honest Limits The AI Support Agent is useful. It's also not a general-purpose AI assistant, and there are gaps worth knowing before you build a workflow around it. [image: Business person reviewing notes and thinking at a quiet cafe table with a closed laptop] **It doesn't know what you haven't uploaded.** The agent answers from the knowledge base. If a customer asks something your documents don't cover, the agent either says it doesn't know or triggers a handoff. It doesn't synthesize answers from general web knowledge or make things up — which is actually the behavior you want for a support bot. **It doesn't crawl URLs.** As noted above, the knowledge base is file-upload only. No live web crawling, no syncing from a help center URL. **It's browser-dependent on most plans.** The Chrome extension requires an active WhatsApp Web session to send responses. On the Free, Basic, and Standard plans, if your machine is off, the bot is off. Automated whatsapp replies through the AI Support Agent require the offline gateway, which is a Pro plan feature. **Multilingual quality varies.** The agent can respond in multiple languages, but accuracy depends on having source documents in those languages. English-only knowledge bases serving non-English customers will produce inconsistent results. **Agent Nodes consume credits per tool call.** Each time the agent searches the knowledge base or uses another tool, it costs one credit. A single customer interaction may involve multiple tool calls — meaning a multi-step conversation uses more credits than a simple Q&A. Credit allocations by plan: 50 (Basic), 100 (Standard), 200 (Pro). Monitor usage during early deployment to size your plan correctly. **No beta label, but expect iteration.** The product docs don't call this a beta feature. That said, any AI system's answer quality is a moving target — it depends on your KB, your system prompt, and ongoing refinement. Budget time for tuning after launch. ## Three Real-World Scenarios These scenarios are based on the documented capabilities and the use cases the product explicitly describes. **Scenario 1: E-commerce product questions** A customer messages at 10 PM asking whether a product is compatible with a specific device. The agent searches the product catalog PDF, finds the compatibility table, and replies with the relevant row. If the catalog doesn't have that specific device listed, the agent says so and offers to connect the customer with a human during business hours. **Scenario 2: Service business FAQ automation** A salon or clinic receives the same questions every day: "What are your hours?", "How do I book?", "What's your cancellation policy?" The agent handles all of these from an FAQ document uploaded to the knowledge base. The human team only sees conversations that escalated — unusual requests, complaints, special bookings. **Scenario 3: Internal team knowledge assistant** Using the same bot system with an Allow List restricted to staff numbers, a team uses the agent to answer internal procedure questions. An employee asks "what's the process for submitting an expense above $500?" The agent finds the relevant section in the uploaded employee handbook and responds. The knowledge base documentation notes internal procedures as one of the explicitly supported use cases. ## Pricing and Plans The AI Support Agent feature is available on paid plans. The relevant cost factor is AI credits — each agent interaction consumes credits based on tool calls made. | Plan | Price (annual) | AI Credits | Offline Sending | |------|----------------|------------|-----------------| | Free | $0 | 0 | No | | Basic | $7/user/month | 50 | No | | Standard | $20/user/month | 100 | No | | Pro | $45/user/month | 200 | Yes | For businesses running the AI Support Agent at volume, the credit allocation matters. A conversation that involves three knowledge base lookups costs three credits. On the Standard plan, 100 credits covers roughly 33 such conversations per billing cycle. Heavy usage needs the Pro plan — or monitoring to ensure you're not depleting credits mid-month. The offline sending requirement is the other meaningful constraint. If you want the bot to respond to messages that arrive while your browser is closed, that's the Pro plan. For businesses where someone is always at a desktop anyway, Standard or Basic may be sufficient. All plans include a 30-day money-back guarantee. Pricing is per user, so multi-seat teams multiply accordingly. [Install the Blueticks extension](https://chromewebstore.google.com/detail/blueticks/adgnjhngogijkkppficiiepmjebijinl) to get started. ## Frequently Asked Questions **Does the Blueticks AI Support Agent work with WhatsApp Business accounts?** Yes. The bot system operates through WhatsApp Web, which supports both personal WhatsApp and WhatsApp Business accounts. Setup is identical for both. **Can I run the AI Support Agent on multiple WhatsApp numbers?** The system is per-user, and each user connects one WhatsApp account. For multiple numbers, you'd need multiple seats. Pricing scales per user on all plans. **What happens to customer messages — are they stored on Blueticks servers?** Per the product's privacy documentation, messages, numbers, contacts, and chats are not stored on Blueticks servers. Knowledge base documents are encrypted. Review the full privacy policy for specifics applicable to your jurisdiction. **How many documents can I upload to the knowledge base?** The documentation notes that knowledge base storage limits apply based on your plan, but specific per-plan limits aren't published in the current docs. Contact support at support@blueticks.co for current limits before committing to a large KB migration. **What if the agent can't answer a question?** The agent is configured to say it doesn't know and trigger a handoff rather than generate a speculative answer. This behavior is reinforced by the system prompt — explicitly telling the agent not to speculate produces consistent results. The example system prompt in the documentation reads: "if you don't know, say you'll forward the request to a human." **Is the AI Support Agent available on mobile?** The Blueticks extension runs in Chrome on desktop. WhatsApp Web mobile browser support is limited. For automated replies from a mobile device, the workflow requires routing through a desktop Chrome session. --- # How Hadar Tours Cut Their WhatsApp Reply Time From 6 Hours to 12 Minutes > Noa's travel agency was losing bookings to a 6-hour reply window. Here's exactly how a small team restructured their WhatsApp customer service workflow and brought average reply time down to 12 minutes. URL: https://blueticks.co/blog/hadar-tours-whatsapp-reply-time-case-study Published: 2026-05-29 Author: Sofia Alvarez Category: stories > *Hadar Tours is a composite small travel agency; their workflow reflects patterns Blueticks sees across small operators. Names and identifying details are illustrative, not drawn from a single interviewed customer.* [image: Travel agency owner reviewing booking notes at a cluttered desk in a small Tel Aviv office] Noa Ziv picked up her phone at 11:47 PM on a Tuesday and felt the familiar sink in her stomach. Fourteen unread WhatsApp messages. Two from the same client she had missed the night before. One from a couple asking about October availability for a Petra tour — sent at 2 PM. It was nearly midnight. "They probably booked with someone else already," she said to herself. She was right. Noa co-runs Hadar Tours, a 4-person travel agency based in Tel Aviv, specialising in small-group itineraries across Jordan, Egypt, and Sinai. The work is personal — she and her team know most of their clients by name. But the communication volume had quietly grown past what four people could handle in a working day. By the time early 2024 arrived, the cracks were showing. ## The Business Behind the Missed Messages Hadar Tours operates exactly the way most boutique agencies do: lots of WhatsApp, a shared phone, a notebook for bookings, and a strong reliance on word-of-mouth referrals. The team of four handled everything from itinerary planning to visa questions to last-minute re-routing for stranded travelers. WhatsApp was the lifeblood of the operation. Roughly 90% of new booking enquiries came in through it. Existing clients used it for updates, changes, and the occasional 1 AM panic about a lost passport. What made the business work also made it fragile. There was no structure. No shared inbox. No way to know who had replied to which message. One phone passed between two people. And no coverage at all between 6 PM and 9 AM. "We thought it was fine," Noa said. "You reply when you can, people understand. That's what we told ourselves." The industry data tells a different story. According to research compiled by Lead Response Management and widely cited by HubSpot, leads contacted within 5 minutes of reaching out are **21 times more likely to convert** than those reached after 30 minutes. Separately, 66% of buyers expect a response within 10 minutes to any sales or customer service inquiry. For a travel agency where a potential client is almost certainly messaging three other operators at the same time, those numbers hit differently. Hadar Tours was averaging a 6-hour reply window. Some messages didn't get answered until the next morning. ## The Before State — One Phone, Zero Coverage, Four People Before any change, here is what the operation looked like: **Who handled WhatsApp:** Primarily Noa and one other team member, Elan. The other two staff focused on itinerary production and logistics. Nobody had a dedicated role for customer communication. **What the volume looked like:** On a typical weekday, the shared number received 25–40 incoming messages. On days after sending a newsletter or post, that could spike to 80. **When things fell through:** Evenings and weekends were dead zones. Messages that arrived after 6 PM waited. If a lead sent an enquiry at 7 PM on a Friday, they heard nothing until Sunday morning at earliest — and that only happened if Noa happened to check over the weekend. **How much it cost:** Hard to say exactly, because unmeasured losses are invisible. But Noa tracked one metric informally: how often a new contact said "I also messaged another agency." In Q1 2024, she estimated that happened in roughly 40% of new enquiries. Some of those were dual-booking. Some were comparisons. But at least a portion were lost to faster competitors. "I started keeping a rough tally," Noa said. "I'd write 'too slow' in my notebook next to a name when I could tell the booking went somewhere else. By March it was a full column." [image: Handwritten booking notebook open on a desk with columns of client names and travel dates] ## The Change — Templates, Scheduled Messages, and an On-Call Rotation Hadar Tours didn't overhaul their entire operation. They made three targeted changes over the course of one week in April 2024, using Blueticks alongside their existing WhatsApp Business setup. **Change 1: Instant acknowledgement templates** The first thing they fixed was the silence problem. When a new enquiry came in outside working hours, it went unanswered for hours. The team built three message templates — one for new enquiry acknowledgements, one for existing client check-ins, one for "we're on it" updates when a booking had a complication. Using [Blueticks' message scheduler](https://blueticks.co/scheduler), Noa set up time-delayed sends so that any enquiry received after 6 PM got an acknowledgement message the following morning at 8:00 AM sharp, before anyone had even sat down at their desk. The message was warm, specific, and signed with a real name. It told the client exactly when to expect a full reply. "It sounds small," said Elan. "But the number of people who replied 'thanks for getting back to me so quickly' — when we hadn't even properly replied yet — was kind of shocking." **Change 2: Recurring morning summaries** The second change used Blueticks' [recurring message feature](https://blueticks.co/scheduler) to send each team member a 9 AM summary reminder of open threads. This wasn't automated follow-up to clients — it was an internal nudge. A short message listing which chats had gone more than 18 hours without a response, sent directly to Noa's personal WhatsApp each morning. This is a simple use of the scheduling tool, but it closed a real gap: the mental overhead of remembering who was waiting. Instead of relying on memory or scrolling through chat history, Noa had a short list every morning. It took Elan about 20 minutes to set up. **Change 3: A two-person on-call rotation** The third change had nothing to do with software. They assigned one team member per week to handle any WhatsApp message that arrived after 5 PM, with an expectation of a reply within 90 minutes. Not a full response — just an acknowledgement and a time-to-expect-more. Blueticks' [campaign tool](https://blueticks.co/campaigns) helped them draft and send batch updates to existing clients during busy periods, freeing up response capacity for new leads. The combination of these three changes restructured the entire WhatsApp customer service workflow without hiring anyone or buying expensive infrastructure. [image: Small team of four collaborating around a table in a compact travel agency office] ## The First Week — What Broke It would make a cleaner story to say everything worked immediately. It didn't. The first scheduled acknowledgement message went out at 8 AM to a client who had already called the office at 7:45 and booked elsewhere by 8:10. The timing felt off. The team adjusted: acknowledgements for messages received before 9 PM went out the same evening at 9:15, giving a 3–4 hour window instead of waiting overnight. Elan also discovered a coordination issue: two team members sent manual replies to the same client on the same morning, not realising the scheduled message had already gone out. "The client got three messages from us in 20 minutes," Noa said. "She was very gracious about it. We were mortified." The fix was a simple log — a shared note in their booking system flagging which contacts had already received a Blueticks-scheduled message. Low-tech, but it eliminated the duplication within 48 hours. By day five, the rhythm was stable. "After the first week you stop thinking about it," Elan said. "The messages go when they're supposed to go. You focus on the actual bookings." ## The Numbers — Reply Time, Conversion, and Client Feedback Hadar Tours tracked three metrics over the 90 days following the setup. **Average reply time:** Dropped from 6.2 hours (Q1 2024 baseline) to 12 minutes in Q2 2024. This was measured as the time between an inbound message and the first outbound response — including the scheduled acknowledgement messages. The 12-minute figure reflects those automated first touches, which were structurally indistinguishable from a manual reply from the client's perspective. **Booking conversion from new enquiries:** Increased from an estimated 28% to 41% over the same period. This is a self-reported estimate from Noa's tracking, not a controlled study, so interpret it as directional. The pattern — more enquiries getting a timely response, fewer going cold — is consistent with what the research suggests. A travel-agency industry example cited in WhatsApp business literature shows that reducing average response time from 30 minutes to 5 minutes increased customer satisfaction scores by 20%; Hadar Tours saw a similar directional shift. **Client feedback:** Three clients in the first month explicitly mentioned the response speed in positive reviews or referral messages. One said: "I messaged four agencies. You were the only one who came back to me the same evening." That client booked a 9-day Jordan itinerary. [image: Travel agent on a phone call at their desk, looking at a paper notebook with a relaxed expression] The data aligns with a broader pattern. Interakt's WhatsApp Business API benchmark research found that automated follow-ups sent within 24 hours of initial contact increased conversion probability by 27%. Hadar Tours' setup delivered that first touch in minutes, not hours. ## What Small Operations Can Learn From This Hadar Tours is not unusual. Most small agencies, tour operators, and service businesses running on WhatsApp have the same problem: the volume is manageable, right up until it isn't, and the collapse happens gradually. A few things that work at this scale: **Start with acknowledgement, not automation.** The biggest single improvement was not a sophisticated bot or AI agent. It was a scheduled message that said "Got your message — Noa will reply by 10 AM." That alone changed client perception. Build your [WhatsApp business setup](https://blueticks.co/guides/getting-started) around first-touch speed before worrying about anything else. **Protect your evenings with a timer, not a policy.** Telling yourself "I'll reply after dinner" doesn't work. A scheduled message that goes out at 9 PM for everything received after 6 does. The difference is that the timer runs without your involvement. **Measure one thing.** Noa tracked reply time and booking conversions. Two metrics, consistent methods, 90-day horizon. That was enough to know the change worked. Don't build a dashboard. Track one thing manually for three months. **Rotation beats heroism.** One person handling everything evenings and weekends burns out within a month. One person on rotation per week — with clear scope (acknowledgements only, not full replies) — is sustainable. Combine it with scheduled messages for anything routine, and your [whatsapp small business workflow](https://blueticks.co/scheduler) becomes genuinely manageable. "We're still four people," Noa said. "We didn't hire anyone. We just stopped letting messages disappear into the night." [image: Travel agency owner at her desk early morning with a coffee cup and open notebook, starting the day] ## FAQ **How long does it take to set up a WhatsApp scheduling workflow for a small agency?** For a basic setup — acknowledgement templates, one recurring internal reminder, and a morning send schedule — expect 60–90 minutes total. Most of that time goes into writing the templates, not configuring the tool. Blueticks' Chrome extension installs in under two minutes and works directly through WhatsApp Web. **Does scheduling WhatsApp messages require a WhatsApp Business API account?** Not with Blueticks. The Chrome extension works with standard WhatsApp Web — no API registration or monthly API fees required. If you need 24/7 delivery without keeping a browser open, the Pro plan's Gateway Engine handles that, but for most small teams starting out, the free extension is sufficient. See our [step-by-step scheduling guide](https://blueticks.co/blog/schedule-whatsapp-messages) for the full setup walkthrough. **What's a realistic reply-time target for a 4-person travel agency?** Industry research suggests that responding within 10 minutes is the threshold where most customers feel satisfied (HubSpot, 2023). Getting from 6 hours to under 10 minutes requires scheduled first-touch messages for out-of-hours enquiries — you cannot achieve that target manually with a small team. A hybrid approach (automated acknowledgement + manual follow-up within 2 hours) is a practical target. **Can I use Blueticks to send booking confirmations and travel updates as well as reply to enquiries?** Yes. Blueticks' campaign tool supports personalised bulk sends to multiple contacts from a CSV or Excel file. This is useful for sending itinerary reminders, departure day checklists, or seasonal promotions to your existing client list. You can also schedule one-time messages to individual contacts — useful for pre-trip briefings timed to go out exactly 48 hours before departure. **What if a client replies to a scheduled message before the team is online?** Scheduled messages via Blueticks are sent through WhatsApp Web (or the Gateway Engine). Any reply lands in the same WhatsApp thread and is visible to whoever is monitoring the account. The scheduling tool handles outbound timing; incoming messages still require a human (or a WhatsApp Business auto-reply, which is a separate WhatsApp Business feature). Combining scheduled outbound messages with WhatsApp Business's built-in away message for incoming enquiries gives you the best coverage. **Ready to stop losing bookings to slow replies?** Install Blueticks for Chrome in under two minutes and schedule your first WhatsApp acknowledgement message before the end of the day. [Install Blueticks — free on Chrome Web Store](https://chromewebstore.google.com/detail/blueticks/adgnjhngogijkkppficiiepmjebijinl) --- # What Do Blue Ticks Mean on WhatsApp? (2026 Guide) > One tick, two ticks, blue ticks. Each state tells you something different about your message. Here's exactly what WhatsApp's tick system means and how to use it. URL: https://blueticks.co/blog/what-do-blue-ticks-mean-on-whatsapp Published: 2026-05-29 Author: Daniel Roth Category: productivity You sent the message. Then you waited. Two grey ticks sat there for hours. Were they ignoring you, or had the message not even landed yet? If you've ever had that uncertainty, you already know why WhatsApp's tick system matters. This guide breaks down every state, every edge case, and what to do when the ticks stop behaving. [image: Close-up of a hand holding a smartphone on a wooden desk suggesting waiting for a read receipt] ## What do blue ticks mean on WhatsApp? Two blue ticks on WhatsApp mean the recipient opened the chat and your message was displayed on their screen. One grey tick means the message reached WhatsApp's servers; two grey ticks mean it was delivered to their device but not yet opened. - **One grey tick** — sent to WhatsApp's servers - **Two grey ticks** — delivered to their device, not yet opened - **Two blue ticks** — opened and read (WhatsApp calls this the "read receipt") ### The three tick states in detail **One grey tick** means your message left your device and reached WhatsApp's servers. That's it. The recipient's phone has not received it yet. This happens when their phone is off, they have no internet connection, or they've been offline long enough for delivery to queue. **Two grey ticks** means the message was delivered to the recipient's device. Their phone received it. But they haven't opened the chat yet, or they've disabled read receipts (more on that below). **Two blue ticks** (the double blue tick WhatsApp is known for) means the recipient opened the conversation and the message was displayed on screen. WhatsApp calls this a "read receipt." The distinction between delivered and read is the one that trips people up. A message sitting on someone's phone with two grey ticks has been received. They may have seen the notification. They may have read it in the notification banner, which does not trigger blue ticks. The only way blue ticks fire is if they open the chat itself. Practical implication: if you see two grey ticks an hour after sending, they're online but haven't opened your chat. If you see one grey tick for more than a few minutes, their phone is offline or they've blocked you (though blocking shows different behavior, covered in the FAQ). ## Why Are They Called Blue Ticks? The phrase "blue tick" comes directly from WhatsApp's UI. The read receipt icon is literally two checkmarks rendered in a specific shade of blue, which WhatsApp refers to as the read state. The term went mainstream around 2013 when WhatsApp introduced color-coded receipts. Before that, ticks existed but were all grey. Adding blue as a "read" signal created a cultural shorthand. "Left on read" entered the vocabulary. "Blue-ticking" someone became a verb meaning deliberate non-reply after reading. Blueticks, the scheduling tool you're reading this on, takes its name from exactly that moment, the point at which a message goes from delivered to actually seen. The product's premise is that delivery alone is not enough; timing your send so the message gets read is what matters. The brand name is a direct reference to that second-stage WhatsApp tick. ## When Blue Ticks Don't Appear — Common Reasons This is where the WhatsApp message delivered vs read picture gets complicated. Several situations produce two grey ticks with no blue, even when the person has clearly seen your message. **Read receipts are turned off.** This is the most common reason. The recipient has gone into settings and disabled read receipts. Their ticks will never turn blue for you. You also won't see blue on your end for their messages. The setting is mutual. **They read via notification preview.** Notification banners on iOS and Android often show the full message text. Someone can read your message completely without opening the app. Grey ticks stay grey. **They used WhatsApp on a device where the chat wasn't synced.** WhatsApp Web and multi-device setups can create gaps. If the message was delivered to their phone but they only opened it on a tablet that hadn't synced properly, behavior gets inconsistent. **They have you muted.** Muting a chat doesn't prevent blue ticks, but it does mean they're less likely to open the chat promptly. You may see delivery but a long delay before read. **You've been blocked.** If someone blocks you, messages show one grey tick indefinitely. They never deliver. This looks identical to them being offline, which is deliberate on WhatsApp's part. **What breaks most often:** automated or bulk messages sent via the WhatsApp API to business accounts. Read receipts for business-to-customer messages depend on the customer's settings and device state. If you're running campaigns and seeing unexpectedly low "read" rates, assume a significant portion of recipients have receipts disabled or are reading via notification. [image: Person glancing at a phone notification banner without opening the app] ## How to Turn Read Receipts On or Off This is one of the most searched WhatsApp settings. Here's how to do it on both platforms. **On iPhone (iOS):** 1. Open WhatsApp. 2. Tap the Settings icon (bottom right). 3. Tap Privacy. 4. Find "Read Receipts" and toggle it off. **On Android:** 1. Open WhatsApp. 2. Tap the three dots (top right), then Settings. 3. Tap Privacy. 4. Toggle "Read Receipts" off. **Important gotchas before you turn them off:** - The setting is mutual. Turn off read receipts and you also lose the ability to see when others have read your messages. There's no way to hide your own receipts while still seeing everyone else's. - It does not apply to group chats. In groups, read receipts are always on. You cannot disable them. WhatsApp shows who has received and read each message in a group regardless of individual privacy settings. - Voice messages are exempt. If you send a voice note, the ticks still turn blue when it's played, even if text read receipts are off. If you want to selectively hide read receipts, the workaround is to read messages in Airplane mode before turning data back on. This works but breaks notifications and requires you to catch messages before connectivity resumes. It's a clumsy habit to maintain. ## Blue Ticks in Group Chats — How They Work Differently Group chat behavior for the double blue tick WhatsApp system is different enough that it needs its own section. **Delivery in groups:** Two grey ticks appear when the message has been delivered to at least one person in the group. Not all of them. **Read in groups:** Two blue ticks appear when every member of the group has received the message, not just when one person reads it. This is the part that surprises people. Your ticks may stay grey for a while in a large group because one member with a spotty connection hasn't received the message yet. To see a breakdown of who has received and read your message: 1. Open the group chat. 2. Long-press the message. 3. Tap the info icon (the "i" in a circle). This gives you a list: "Read by" and "Delivered to." Names appear with timestamps. It's the only way to understand partial delivery in a large group. **Practical note for teams using WhatsApp groups:** if you're sending time-sensitive information to a work group, two grey ticks does not mean nobody saw it. Someone may have read it in their notification bar. Check the message info view before assuming non-delivery. [image: Small group of coworkers around a table each checking their phones in a casual office] ## Blue Ticks for Business — Why Timing Matters For personal messages, a blue tick is mostly a social signal. For business, it's a metric with revenue implications. Read receipts WhatsApp tracking tells you whether your messages are landing when people are paying attention. The same message sent at different times can produce dramatically different read rates. A booking reminder sent at 9 AM has a different fate than one sent at 11 PM. This is especially relevant for: - **Appointment reminders:** Sending 24 hours before the appointment, during a time the person is typically available, means the blue tick lands in a window where they can still act on it. - **Follow-ups:** A follow-up that arrives while someone is commuting is more likely to get read immediately than one that arrives during a meeting. - **Support messages:** Time zone mismatches in customer support mean late-night sends often sit grey until the next day's morning routine. The difference between "delivered" and "read" is not just semantic. A message the customer doesn't open is a message that didn't work, regardless of whether WhatsApp shows two grey ticks. ## Schedule WhatsApp Messages to Get Read (Not Just Delivered) Timing your sends manually works until it doesn't. You're not going to wake up at 8 AM on a Sunday to hit send on a client reminder. You're not going to remember to follow up on Thursday afternoon while you're in a meeting. The approach that actually holds up: schedule the message to go at the right time, then let the system handle delivery. Here's how to set up scheduled sends with [Blueticks](https://blueticks.co/scheduler): 1. Install the [Blueticks Chrome extension](https://chromewebstore.google.com/detail/blueticks/adgnjhngogijkkppficiiepmjebijinl) from the Chrome Web Store. 2. Open WhatsApp Web in Chrome. 3. Open the chat you want to send to. 4. Click the Blueticks clock icon next to the message input. 5. Pick your send date and time. 6. Write your message. 7. Confirm the schedule. The message goes out at the time you set, even if you've closed the tab. Blueticks runs the send from its own infrastructure, not from your browser staying open. For recurring sends (weekly check-ins, monthly invoices, appointment series), the recurring scheduler lets you set a pattern once and walk away. Each send gets its own delivery and read tracking. [image: Person working at a laptop in a home office focused on the screen while a phone sits beside the keyboard] The practical gotcha here: read receipts WhatsApp provides tell you when messages land, but not why someone didn't reply. Scheduling gets the message there at the right moment. What happens after the blue tick is still up to the message. For a detailed walkthrough of all scheduling options including mobile workflows, see the [full scheduling guide](https://blueticks.co/blog/schedule-whatsapp-messages). If you're setting up Blueticks for the first time, the [getting started guide](https://blueticks.co/guides/getting-started) covers the initial setup in about five minutes. ## Frequently Asked Questions **If someone turned off read receipts, will I ever see blue ticks?** No. If the recipient has disabled read receipts in their privacy settings, your ticks will stop at two grey regardless of whether they read the message. There's no way to override someone else's privacy setting. **Can I see blue ticks on WhatsApp Web?** Yes. WhatsApp Web shows the same tick states as the mobile app. The behavior is identical. If you're using WhatsApp Web for business messaging, ticks work the same way. **Why did my message show blue ticks but the person says they never saw it?** Blue ticks fire when the chat is opened and the message is displayed, not when the person actively reads and registers it. If they opened the chat briefly and scrolled past, the ticks still turn blue. This is the gap between "technically read" and "actually processed." **Does blocking affect ticks?** Yes. If you've been blocked, your messages will show one grey tick indefinitely. They won't progress to two grey ticks because delivery to the blocked person's device is prevented. WhatsApp does not send a blocked notification, so this looks the same as the person being persistently offline. **Do blue ticks work for WhatsApp Business accounts?** Yes, with the same limitations. WhatsApp Business accounts can see read receipts, and customers can disable receipts on their end. Business API messages have additional variables including template message formatting, which can affect how quickly recipients open and trigger the read state. --- # WhatsApp Business API Pricing in 2026: Conversation Categories, Costs, and What Changed > WhatsApp Business API billing changed fundamentally in 2025 — from per-conversation to per-message. Here's what the 2026 rate card actually looks like, and what it means for your costs. URL: https://blueticks.co/blog/whatsapp-business-api-pricing-2026 Published: 2026-05-29 Author: Avi Kohen Category: industry [image: Business analyst reviewing WhatsApp Business API pricing documents at a desk] You've probably seen the complaints on LinkedIn: "Our WhatsApp bill doubled overnight." Or the opposite: "We switched to service-first messaging and our costs dropped 80%." Both are true. Meta restructured WhatsApp Business API billing twice between November 2024 and January 2026, and the changes favor some patterns heavily over others. This article maps the actual rate card, explains the category logic, and shows you which side of that equation you're likely on. ## The Four Conversation Categories — What They Actually Cover Meta's WhatsApp Business Platform organizes all business messages into four categories. The names haven't changed recently — they are marketing, utility, authentication, and service — but the billing logic behind each one shifted significantly starting July 1, 2025. Understanding what belongs in each bucket is the foundation for understanding your bill. **Marketing messages** are any template messages that aren't transactional. Promotional offers, product announcements, re-engagement campaigns, newsletters, and anything your business initiates that the customer didn't specifically request. This is the highest-cost category in every market, and the one with the most policy surface area. It's also the category subject to Meta's per-user frequency caps (more on that in the compliance section). **Utility messages** cover transactional communication tied to a customer action: order confirmations, payment receipts, shipping updates, account alerts, appointment reminders for a service already booked. The key is that the trigger is a prior customer action. If you're confirming a purchase, that's utility. If you're nudging someone to complete a purchase they abandoned, that's marketing. Get the category wrong on your template and Meta will reject it or reclassify it at review. **Authentication messages** are a specialized subset: one-time passwords (OTPs), login verification codes, multi-factor authentication prompts. Meta prices these aggressively in most markets because they want businesses using WhatsApp as an auth channel rather than SMS. The exception is authentication-international, which applies when you send OTPs to phone numbers in markets outside your registered business jurisdiction — those rates are significantly higher and apply to a list of markets including Egypt, Malaysia, Nigeria, Pakistan, Saudi Arabia, South Africa, and UAE (expanded February 1, 2025). **Service messages** are all messages exchanged within a customer-initiated conversation window — the 24-hour window that opens when a user messages you first. This category costs nothing. Meta made service conversations fully free and unlimited on November 1, 2024, removing the previous cap of 1,000 free monthly service conversations. Any reply you send within an open service window, including utility templates, is free. [Learn how Blueticks handles campaign templates across categories →](https://blueticks.co/campaigns) ## 2026 Rate Card: What You Actually Pay Per Message [image: Close-up of printed rate tables and a calculator on a business analyst's desk] Effective July 1, 2025, Meta charges per delivered template message — not per 24-hour conversation window. The table below reflects rates as published by Meta's official documentation and corroborated by Meta's authorized business solution provider (BSP) published rate cards, current as of Meta's most recent rate adjustment in January 2026. ### United States | Category | Per-message rate | |---|---| | Marketing | $0.025 | | Utility | $0.004 | | Authentication | $0.004 | | Service | Free | *Source: Meta's WhatsApp Business Platform pricing documentation, as reported by BSP rate cards current January 2026.* ### India | Category | Per-message rate | |---|---| | Marketing | ₹0.8631 (~$0.010) | | Utility | ₹0.115 (~$0.0014) | | Authentication | ₹0.115 (~$0.0014) | | Service | Free | India switched to local currency billing in January 2026. The marketing rate increased approximately 10% from the previous ₹0.7846 rate — a significant jump for high-volume India senders. ### Brazil | Category | Per-message rate | |---|---| | Marketing | $0.0625 | | Utility | $0.0068 | | Authentication | $0.0068 | | Service | Free | Brazil is still on USD billing as of May 2026; local BRL billing is planned for the second half of 2026, according to the January 2026 currency rollout announcement. ### United Kingdom | Category | Per-message rate | |---|---| | Marketing | £0.0382 (~$0.048) | | Utility | £0.0159 (~$0.020) | | Authentication | £0.0159 (~$0.020) | | Service | Free | For reference, Germany sits at €0.1131 per marketing message — among the highest in the world, consistent with Europe's generally elevated rates. If you're sending to Western Europe at any volume, the per-message model hits hard on marketing. **One critical caveat:** these are Meta's base fees. Your actual bill also includes your BSP's markup — typically $0.003–$0.010 per message for larger BSPs, sometimes higher for smaller platforms. Your total cost per message will be higher than the Meta rates above. ## What Changed: From Conversation Windows to Per-Message Billing [image: Professional reviewing a printed timeline on a conference table with documents and notes] The simplest way to understand the 2026 pricing landscape is to understand what replaced what. There were three significant changes over 18 months. **November 1, 2024: Service conversations became free and unlimited.** Previously, you received 1,000 free service conversations per month across your WhatsApp Business Account; after that threshold, you paid per conversation. Meta eliminated the cap entirely. Support-heavy operations — customer service teams, help desks, two-way engagement campaigns — effectively stopped paying for the majority of their WhatsApp usage on that date. **July 1, 2025: Per-conversation billing ended for template messages.** The old model billed you once for a 24-hour conversation window, regardless of how many template messages you sent within it. A business could send a marketing template and three follow-up utility templates in one day and pay a single conversation fee. Under the per-message model, each delivered template message is an individual charge. For businesses that sent multiple templates per conversation, costs went up. For businesses that sent one-and-done campaigns, the change was neutral or slightly cheaper. Meta's developer documentation formally deprecated the conversation-based pricing model as of July 1, 2025, though some markets saw a phased rollout. **January 1, 2026: Regional rate adjustments and local currency billing.** Meta updated rates in multiple markets: India marketing rates increased approximately 10%, North America utility and authentication rates decreased, and France and Egypt saw marketing rate reductions. India began billing in INR. Ten additional currencies are scheduled to launch through 2026, with BRL planned for the second half. Per Meta's published pricing updates documentation at developers.facebook.com/docs/whatsapp/pricing/updates-to-pricing/, these adjustments are described as ongoing — rates are not static. Build any cost model with the assumption of quarterly reviews. [Blueticks.co scheduler overview — batch and schedule messages by category →](https://blueticks.co/scheduler) ## Free Entry Points: Three Ways to Send Without Paying Not every WhatsApp Business message costs money. There are three distinct scenarios where Meta charges nothing, and they're worth understanding precisely because they're often misrepresented. **1. The 24-hour customer service window (CSW).** When a user sends your business any message, a service window opens. For the next 24 hours from that user's last message, you can send free-form messages and utility templates at no charge. The clock resets each time the customer replies. An active back-and-forth conversation can remain free indefinitely as long as responses happen within 24-hour intervals. **2. Utility templates within an open service window.** This is the nuance most businesses miss. Utility template messages — the ones that typically carry a $0.004–$0.0068 charge — are completely free if sent while a service window is already open. If a customer contacts you about an order and you respond with a shipping update template, you pay nothing. The same template sent proactively to a customer with no open window costs the standard utility rate. **3. The 72-hour free entry point (FEP) window.** When a user taps a Click-to-WhatsApp (CTWA) ad on Facebook or Instagram, or clicks a WhatsApp button on a Facebook Page, and you respond within 24 hours, a free entry point window opens. This window lasts 72 hours from your first delivered response and covers all message categories — including marketing templates, which are otherwise the most expensive. A user who clicks a WhatsApp ad and receives a promotional sequence in response costs you nothing on the Meta side for the duration of that 72-hour window. The practical implication: Click-to-WhatsApp ads are the most cost-effective channel for sending marketing templates at scale, especially in high-cost markets like the UK or Brazil. You pay for the ad, not the WhatsApp messages. ## What This Means for Small Operators (Under 1,000 Conversations per Month) [image: Small business owner working at a minimalist desk with a notepad and phone face-down] If you're running a business that receives customer inquiries — appointments, support requests, product questions — and you're primarily responding rather than broadcasting, the November 2024 change almost certainly reduced your costs to near-zero on the Meta side. Under the old model, 1,000 service conversations per month was a real ceiling for small businesses. Hit it and you started paying per conversation. Under the current model, that ceiling is gone. As long as customers are messaging you first, your replies are free. Where small operators still pay is outbound template messages. If you're sending appointment reminders, payment confirmations, or delivery updates without an open service window, those are utility templates and carry the standard rate ($0.004 in the US, ₹0.115 in India). At 500 messages per month, the math is simple: $2 in the US, ₹57.50 in India. The Meta fee is not the problem at this volume — the BSP's monthly seat fee typically costs more than your message volume. The practical advice: check whether your outbound template messages could be sent within an open service window instead. If customers typically contact you before you send a confirmation or reminder, hold the template until after they message and send it cost-free. [See how Blueticks schedules messages and reminders for small teams →](https://blueticks.co/) ## What This Means for High-Volume Senders At scale, the per-message model creates pressure that didn't exist under conversation-based billing — and it also creates a volume discount opportunity. **Volume tiers for utility and authentication messages.** Meta introduced volume-based pricing tiers effective July 1, 2025, but only for utility and authentication categories. Marketing messages have no volume tiers. Here's what the India utility tier structure looks like (in INR, effective July 2025 per Meta's published documentation): | Monthly volume | Rate per message | Discount | |---|---|---| | 0 – 750,000 | ₹0.115 | Baseline | | 750,001 – 15M | ₹0.1081 | 6% | | 15M – 20M | ₹0.1012 | 12% | | 20M – 50M | ₹0.0943 | 18% | | 50M – 100M | ₹0.0874 | 24% | | 100M+ | ₹0.0805 | 30% | Volume tiers reset monthly, apply per country-category combination, and count only paid messages. Similar tier structures exist across other markets; the thresholds and percentages vary. Authentication messages follow the same tier structure. **Marketing sends are a different problem.** High-volume marketing senders face two constraints that utility senders don't: no volume discount path, and Meta's per-user frequency cap. You cannot unlock cheaper marketing rates by sending more of them. At $0.025 per message in the US, sending 100,000 marketing messages costs $2,500 in Meta fees alone — plus BSP markup, plus the list cost. At that scale, the 72-hour CTWA window becomes strategically significant: shifting even a portion of your marketing volume into CTWA-originated conversations can substantially reduce that line item. ## Compliance: Meta's Anti-Spam Policies and Rate Limits [image: Enterprise workspace with phone, documents, and compliance review materials on a desk] Pricing is only one axis. Meta's compliance framework determines whether you can send at all. **Messaging tier limits.** Every WhatsApp Business Account starts at a daily messaging limit based on verification status. As of October 2025, limits are portfolio-based rather than per-number, meaning all phone numbers in a Business Manager share the highest achieved tier. New numbers inherit the portfolio's strongest tier immediately. The five tiers: - Tier 0 (unverified): 250 unique users/day - Tier 1 (verified): 1,000 unique users/day - Tier 2: 10,000/day - Tier 3: 100,000/day - Tier 4: Unlimited (up to 1,000 messages/second throughput) Meta evaluates tier advancement every 6 hours, accelerated from the previous 24–48 hour cycle. Advancement requires using at least 50% of your current limit within a rolling 7-day window while maintaining acceptable quality ratings. **Quality ratings.** Meta monitors how users respond to your messages. Blocks, spam reports, and low engagement pull your quality rating down through three levels: Green (healthy), Yellow (warning), Red (at risk). As of 2026, a Red rating prevents tier advancement but no longer triggers an automatic immediate downgrade — it gives you a correction window. That's a meaningful change from prior behavior, where Red could mean limit reductions within 24 hours. **Per-user frequency capping.** This is the compliance layer most businesses don't discover until their error logs fill up. Meta caps how many marketing template messages a single user can receive across all businesses combined in a 24-hour window — approximately 2 per user per day. The Cloud API returns error code 131049 when your message is blocked for this reason. This limit cannot be worked around by using additional phone numbers or different BSPs. It's enforced at the user level by Meta's infrastructure. The practical implication for bulk marketing senders: your deliverability depends partially on what your recipients are receiving from other brands. If your users are also receiving marketing templates from other WhatsApp senders, your messages compete for those 2 daily slots. The only reliable response is to send higher-quality, better-timed messages that are less likely to trigger blocks — which also protects your quality rating in a virtuous cycle. ## FAQ **What are the four WhatsApp API conversation categories in 2026?** Marketing, utility, authentication, and service. Marketing covers promotional content; utility covers transactional messages tied to customer actions; authentication covers OTPs and verification codes; service covers all messages within a customer-initiated 24-hour window and is free. **When did Meta switch from per-conversation to per-message pricing?** July 1, 2025. Prior to that date, Meta charged once per 24-hour conversation window regardless of how many template messages were sent within it. The shift means each delivered template message now carries an individual charge. **Is there a free tier for WhatsApp Business API?** Not a formal monthly free allotment for template messages. However, service conversations (customer-initiated) are free and unlimited since November 1, 2024. Utility templates sent within an open service window are also free. The 72-hour free entry point window (triggered by Click-to-WhatsApp ads) makes all message categories free for that duration. **How much does a marketing message cost in the US on WhatsApp API?** $0.025 per delivered message as of Meta's January 2026 rate card, plus your BSP's per-message markup (typically $0.003–$0.010). Marketing messages receive no volume discount. **What happens if I send too many marketing messages?** Two separate limits apply. First, Meta enforces a per-user frequency cap of approximately 2 marketing messages per day across all businesses; messages blocked for this reason return error code 131049. Second, your account-level messaging tier limits how many unique users you can message per day — starting at 1,000 for verified accounts and scaling through tiers. Your quality rating (based on block rates and spam reports) determines whether you can advance to higher tiers. *Pricing data in this article reflects Meta's published rate cards as reported by Meta's official developer documentation and authorized BSP rate disclosures, current as of Meta's January 2026 rate adjustment. Rates are subject to change; verify current figures at developers.facebook.com/docs/whatsapp/pricing before building cost models. BSP markups are not included in the figures above and vary by provider.* **Don't want a per-message bill?** If you don't need the full API, Blueticks sends WhatsApp campaigns and scheduled messages from your own number — no per-conversation fees, no BSP markup, and no Meta business verification. [Start free →](https://blueticks.co/signup) --- # 7 WhatsApp Campaign Messages That Get Replies (2026 Templates) > Most WhatsApp campaigns get blocked before they get read. Here are seven battle-tested templates — with exact message copy, send timing, and open/reply rate expectations — that actually move people to act. URL: https://blueticks.co/blog/whatsapp-campaign-templates-that-convert Published: 2026-05-29 Author: Maya Cohen Category: marketing [image: Marketing professional reviewing WhatsApp campaign results on a smartphone at a modern desk] Your WhatsApp campaign has a 98% chance of being opened. It also has a very good chance of being ignored, reported as spam, or triggering an unsubscribe before you finish the second sentence. The open rate is table stakes. The reply rate — and the conversion behind it — is the number that pays your bills. This article gives you seven whatsapp campaign templates tested across real e-commerce and B2B sends, complete with exact message copy, the right send window, and honest benchmarks on what to expect. ## Why Most WhatsApp Campaigns Get Ignored (The Spam Tax You're Already Paying) Meta now limits recipients to roughly two marketing messages per day across all brands combined. That is not two from you. That is two total — from every business messaging them on the platform. If your message is the third, it does not arrive. This is the "spam tax." Every poorly targeted blast from every business on the platform erodes your delivery window. And the businesses who pay the heaviest spam tax are the ones using generic copy — the "🔥 BIG SALE TODAY 🔥" messages that trigger blocks before they trigger purchases. The good news: Meta's conversation-category pricing model, which switched from per-window to **per-message billing on July 1, 2025**, punishes bulk spray-and-pray even harder financially. In Germany, each marketing template message now costs approximately €0.11. In the US, it's around $0.025 per message. In India, roughly $0.009. (Source: [WhatsApp Business API Pricing 2026 — Engagelab](https://www.engagelab.com/blog/whatsapp-business-api-pricing).) Every wasted send is a real line item. Precision beats volume. A 600-person segmented list with a 22% reply rate outperforms a 6,000-person blast with a 1% reply rate — in revenue and in platform standing. One more structural change to know: In 2025, Meta removed free broadcast messaging for marketing campaigns from the standard WhatsApp Business App. If you are running campaigns to more than 256 contacts, you need the WhatsApp Business API through a certified Business Solution Provider (BSP), or the paid Business Broadcast tier. The free [WhatsApp broadcast list](https://blueticks.co/campaigns) is now restricted to informational, non-marketing content for saved contacts only. With that context locked, here are the seven templates worth sending. ## Template 1 — Flash Sale: Create Urgency Without Sounding Desperate **When to send:** 8–10 AM on the day of the sale. A second message at 4 PM if the sale ends at midnight. **Why it works:** A hard deadline with a specific SKU or discount number anchors the message to action. Vague "great deals" language gets skipped. Specific product + specific expiry converts. ``` Hi {{first_name}}, Our summer drop just went live — 30% off everything in the [Category] range until midnight tonight. No code needed. Tap below to shop: [SHOP NOW →] This offer expires at 11:59 PM. After that, full price. Reply STOP to unsubscribe. ``` **Timing note:** Send between 8–10 AM local time. According to Chatarmin's WhatsApp KPI study across 30+ e-commerce brands, broadcast messages sent in the morning drive open rates of 60–80%. Add an interactive CTA button — buttons lift CTR by 40–60% over plain-text links. **Expected results (illustrative range):** Open rate 65–80%; reply/click rate 8–14%; conversion 3–6%. Flash-sale messages with product images + CTA buttons consistently outperform text-only formats. ## Template 2 — Abandoned-Cart Recovery: Send Within 60 Minutes or Don't Bother Globally, roughly 70% of online carts are abandoned. On mobile, that figure climbs to 85%. WhatsApp is the highest-performing recovery channel because, unlike email, the message sits in a thread the customer already uses. The open rate is near-certain. The question is whether the message earns the tap. The rule: **send the first recovery message within 60 minutes of abandonment.** Businesses that hit the 60-minute window recover 25–30% of those carts. Waiting 24 hours drops that to single digits. [image: Close-up of hands near a laptop with a small shopping bag on a wooden desk] ``` Hi {{first_name}}, You left something behind. 👀 Your [Product Name] is still in your cart — but we only have [X] units left in stock. [Complete your order →] Need help deciding? Reply to this message and we'll sort it. Reply STOP to unsubscribe. ``` **Timing sequence for maximum recovery:** 1. **Message 1:** 45–60 minutes after abandonment 2. **Message 2:** 24 hours later (add a small incentive: "Here's 10% off if you need it") 3. **Message 3:** 72 hours later (final notice, scarcity + social proof) **Expected results:** Well-structured 3-message sequences recover 25–45% of abandoned carts (per [CampaignHQ data](https://blog.campaignhq.co/whatsapp-abandoned-cart-recovery)). A single message recovers 10–20%. The gap is significant enough that if your platform doesn't support automated sequences, that's the first thing to fix. Blueticks's [campaign scheduler](https://blueticks.co/scheduler) supports recurring and timed sends — useful for mapping out the 1-hour, 24-hour, and 72-hour drip without manual intervention. ## Template 3 — Re-Engagement / Win-Back: The Honest Ask For a fictional clothing brand, let's call them Meridian Apparel, here is what happened when they sent a standard promotional blast to their 90-day dormant segment: 3.2% click rate, 0.8% conversion. The message looked like every other flash-sale alert. The segment had seen 14 of them. They rewrote it as an honest re-engagement note. No emoji storm. No fake urgency. Just a direct acknowledgment that the customer had gone quiet. The result: 11% click rate, 2.9% conversion — on the same dormant list. (Synthetic example; numbers are realistic for the segment type based on Chatarmin's benchmark ranges.) ``` Hi {{first_name}}, We haven't heard from you in a while — and we get it. Inboxes get crowded. If you're still interested in [Product Category], we've added [X new products / a new feature / a special offer] since you last visited. Here's a little something for coming back: [USE CODE: BACK15 →] Code expires in 48 hours. Reply STOP to unsubscribe. ``` **When to send:** 90-day dormant segment, morning window. Do not send this message to active buyers — it reads as tone-deaf if they ordered last week. **Expected results:** Re-engagement messages to properly segmented dormant lists typically achieve 50–65% open rates and 8–15% click rates. The reply-to-revenue path depends heavily on the incentive, but a 10–15% code has a strong enough pull for most categories. ## Template 4 — New Product Launch: Give VIPs the First Look **The trap:** announcing a new product as a broadcast to your entire list. It lands like spam because most recipients have no context for why they specifically should care about this product. **The fix:** segment by purchase history. Send the new product launch only to customers who previously bought in the same category. Open rate climbs. Unsubscribes drop. [image: Hands unpacking a premium product from a white box on a marble surface] ``` Hi {{first_name}}, [Product Name] just launched — and because you previously bought [Related Product], we thought you'd want to be first. It's available now: [SEE [PRODUCT NAME] →] We made it for people who [specific use case / pain point]. Takes [time/effort] to [result]. Reply STOP to unsubscribe. ``` **Timing:** Launch day, 9 AM. If you have a waitlist, send 30 minutes before the public goes live — that delta matters to buyers who care about exclusivity. **Expected results (illustrative):** Category-matched segments typically deliver 70–85% open rates and 12–20% click rates on new product announcements. Broad-list launches average 40–55% opens and 5–9% clicks. Internal link: For managing who gets what message and when, [Blueticks campaigns](https://blueticks.co/campaigns) lets you import segmented CSV lists and personalize each send with first name and product data. ## Template 5 — Event Reminder: Three Messages, Not One Single-message event reminders have a 20–35% no-show rate even after confirmation. The reason: one reminder, sent once, gets buried. A three-message sequence — initial confirmation, 24-hour reminder, 1-hour heads-up — drops no-shows to 8–12% in services businesses that have measured it. ``` // Message 1 — Day of booking Hi {{first_name}}, You're confirmed for [Event Name] on [Date] at [Time]. 📍 [Location or link] We'll remind you the night before. See you there. Reply STOP to unsubscribe. // Message 2 — 24 hours before Hi {{first_name}}, Tomorrow at [Time]: [Event Name]. [Add to Calendar →] | [Get Directions →] Any questions before then? Reply here. // Message 3 — 1 hour before [First_name], you're up in 1 hour. [Event Name] starts at [Time]. [Join link / Directions] ``` **Expected results:** Sequence open rates track at 75–90% (each message in a sequence benefits from the established conversation thread). No-show reduction of 40–60% versus single-reminder sends is achievable for service businesses and webinars. ## Template 6 — VIP Early Access: Make the Privilege Feel Real VIP messages fail when they do not feel exclusive. "You're a valued customer" followed by the same offer everyone else gets is not VIP access — it is a segment label on a bulk blast. Recipients have learned to ignore it. Real exclusivity means the list is small, the window is genuine (the offer actually closes before the public gets it), and the copy reflects what makes this person a VIP specifically. [image: Exclusive VIP envelope and card on a dark desk symbolizing early access invitation] ``` Hi {{first_name}}, Before we open this to everyone else — you get first access. [Product / Sale / Event] goes live for the public on [Date+48hrs]. You can get in now: [ACCESS EARLY →] You're getting this because you've been with us since [year / because you're in our top tier]. We appreciate that. This link expires in 24 hours. Reply STOP to unsubscribe. ``` **Timing:** Send 48–72 hours before the public launch. The gap has to be real. If VIPs can access it 20 minutes before everyone else, they will notice — and it poisons future VIP sends. **Expected results (illustrative):** VIP segments consistently outperform broad lists. Open rates of 75–90% are common for genuinely small, earned VIP tiers. Click rates of 20–35% are achievable when the early-access window is real and the product is relevant to past purchase history. ## Template 7 — Post-Purchase Upsell: Strike at Day 7, Not Day 30 The best time to sell a complementary product is seven days after the original purchase — when satisfaction is still high, the product is in active use, and the customer has formed an opinion on whether it works. Day 30 is too cold. Day 1 is too soon (the order might not have arrived yet). [image: Customer holding a product package while receiving a message notification on a phone] ``` Hi {{first_name}}, How's the [Product Name] treating you so far? Customers who bought it usually pair it with [Complementary Product] — and 8 in 10 say it makes a noticeable difference. This week only, it's [X]% off for existing customers: [ADD [COMPLEMENTARY PRODUCT] →] Reply STOP to unsubscribe. ``` **Why the social-proof line matters:** "8 in 10 customers say..." is a factual anchor that turns a sales message into a recommendation. Use real data from your reviews or support tickets. If you don't have the number yet, use a vaguer but honest version: "Most customers who bought [X] also grab [Y] within the first month." **Expected results:** Post-purchase upsell messages sent at day 7 achieve open rates of 70–85% and click rates of 12–22%, with conversion rates of 5–12% depending on price delta between original and upsell item (lower delta = higher conversion). ## What Changes in 2026: Opt-In Friction and Conversation-Category Pricing Two structural shifts define WhatsApp marketing in 2026. You need to understand both to avoid wasting budget. ### The Per-Message Pricing Shift (July 2025) Before July 1, 2025, WhatsApp Business API billing was conversation-based: one flat fee covered any number of template messages sent within a 24-hour window. That model is gone. As of July 2025, **every delivered marketing template message is a separate line item.** Per-message marketing rates as of Q2 2026 (approximate, varies by recipient country): | Country | Rate per marketing message | |---|---| | United States | $0.025 | | United Kingdom | ~$0.048 | | Germany | ~$0.124 | | Brazil | $0.0625 | | India | ~$0.009 | | Mexico | $0.0305 | Source: [WhatsApp Business API Pricing 2026 — Engagelab](https://www.engagelab.com/blog/whatsapp-business-api-pricing). Rates are subject to change; verify against Meta's current pricing documentation before budgeting. Marketing messages carry **no volume discounts** — unlike utility and authentication messages, which qualify for 5–20% tiered reductions at 10K+ volumes. For high-volume marketing sends in expensive markets (Germany, Netherlands, UK), this pricing model makes tight segmentation a direct cost control lever. ### The US Marketing Pause Starting April 1, 2025, Meta paused all marketing template messages to US (+1) phone numbers. Only Utility and Authentication messages are currently permitted for US recipients, regardless of opt-in status. If a significant portion of your list is US-based, shift those contacts to utility-category messages (transactional, support-based) until Meta lifts the restriction. ### Opt-In Friction Is Now a Gatekeeping Mechanism Meta's March 2025 update introduced "consent fatigue" protections: even if a user has technically opted in, WhatsApp may block your message if that user has already received two marketing messages from other businesses today. This is not something you can engineer around — it is a platform-level gate. What you can control: 1. **Explicit, named opt-in.** Your consent flow must state the business name, the WhatsApp channel specifically, and the message type. "I agree to receive updates from [Brand] on WhatsApp" is the minimum. A pre-checked checkbox does not count. 2. **Marketing Opt-Out Button.** Meta now requires an official one-click unsubscribe button in marketing templates. "Reply STOP" alone no longer satisfies the requirement via the API. 3. **Contact quality over list size.** A 2,000-person list of people who actively opted in for promotional messages will out-deliver a 20,000-person list of loosely consented contacts — both in open rate and in platform standing. The [promotional whatsapp message](https://blueticks.co/campaigns) tools that survive 2026 are the ones built on clean lists with real consent flows, not scraped contacts or purchased numbers. For a deeper look at the scheduling side of campaign execution, see the [full scheduling guide](https://blueticks.co/blog/schedule-whatsapp-messages). ## FAQ **What is a WhatsApp campaign template?** A WhatsApp campaign template (also called a Message Template or HSM — Highly Structured Message) is a pre-approved message format required for outbound marketing communication via the WhatsApp Business API. Meta reviews and approves each template before it can be sent. The approval ensures messages are not spam, include opt-out language, and fall within permitted categories (marketing, utility, authentication, or service). **What is a good open rate for a WhatsApp business campaign?** Industry benchmarks for WhatsApp campaign open rates range from 60–80% for broad broadcast campaigns, up to 85–98% for highly segmented or transactional sends. By comparison, email marketing averages 20–25%. The gap is real, but it only holds when you have genuine opt-ins — a purchased or scraped list will see open rates collapse toward email-level numbers because undelivered messages count against your quality score. **What is a WhatsApp broadcast list and how does it differ from the Business API?** A WhatsApp broadcast list is a free feature in the WhatsApp and WhatsApp Business apps that lets you send a message to up to 256 saved contacts at once. Each recipient sees it as a direct message, not a group. Since 2025, Meta restricts free broadcast lists to non-marketing, informational content. For marketing campaigns — promotional offers, flash sales, win-back messages — you need the WhatsApp Business API through a certified BSP, or Meta's paid Business Broadcast tier. The API removes the 256-contact ceiling and adds segmentation, automation, analytics, and template approval workflows. **How do I avoid my WhatsApp marketing messages being blocked?** Four controls matter most: (1) maintain a verified opt-in list with explicit consent, (2) use Meta-approved templates with a one-click opt-out button, (3) send to tightly segmented lists rather than your full contact base, and (4) monitor your quality score in Meta Business Manager — a high "Flagged" or "Low" quality rating means your messages are getting reported. Frequency is also a lever: Meta's per-user daily cap of approximately two marketing messages means sending every day actively cannibalizes your own deliverability. **What is the best time to send a WhatsApp marketing message?** For e-commerce promotional messages, 8–10 AM local time consistently outperforms afternoon and evening sends in open rate and click-through rate. For B2B use cases, mid-morning on Tuesday through Thursday mirrors the best-performing email time slots. Avoid Friday afternoon and Sunday morning — lower intent and higher ignore rates. Event reminders are the exception: the 1-hour-before reminder performs regardless of time of day because it is triggered by a known upcoming event, not cold outreach. *One footnote on the benchmarks in this article: open rates, CTRs, and conversion ranges are drawn from Chatarmin's 30+ brand KPI study, CampaignHQ case data, and Engagelab's pricing analysis. Your results will vary based on list quality, opt-in source, product price point, and market. Use these as directional targets, not guarantees.* **Want to schedule your WhatsApp campaigns without leaving WhatsApp Web?** Blueticks runs directly in your browser — no API integration required for smaller lists. [Install the Chrome extension](https://chromewebstore.google.com/detail/blueticks/adgnjhngogijkkppficiiepmjebijinl) and send your first campaign in under 10 minutes. --- # How to Schedule WhatsApp Messages in 2026 (Step-by-Step Guide) > Native scheduling is barely a thing. Here's how to set up reliable one-time and recurring WhatsApp messages on desktop and mobile in 2026. URL: https://blueticks.co/blog/schedule-whatsapp-messages Published: 2026-05-28 Author: Daniel Roth Category: productivity You need a message to go out at 9 AM on Monday. You're not going to be awake at 9 AM on Monday. Or you are, but you're not going to remember. This guide covers every way to schedule WhatsApp messages in 2026 — native options, third-party tools, desktop and mobile — so you can stop relying on memory and start sending on time. [image: Modern desk workspace with laptop and smartphone ready for scheduling WhatsApp messages] ## Can You Schedule WhatsApp Messages Natively? The short answer: barely. WhatsApp has no built-in scheduler. There's no calendar icon, no "send later" option, nothing. On WhatsApp Business, you get Greeting Messages and Away Messages — automated replies triggered by incoming messages, not messages you send at a time you choose. On Android, some users use third-party apps that hook into WhatsApp's notification layer. On iPhone, that path is blocked — iOS doesn't allow background automation for third-party apps the same way. If you want a real WhatsApp scheduled message — one that goes out at a specific date and time, to a specific contact or group, with the message you wrote — you need a tool built for it. The most reliable option in 2026 is a Chrome extension that runs alongside WhatsApp Web. More on that in a moment. ## Why People Need to Schedule WhatsApp Messages The people who ask "how to schedule a message on WhatsApp" aren't all doing the same thing. Here are the most common situations: **Time zone gaps.** Your client is in London, you're in Tel Aviv. You write the follow-up at 11 PM your time, but you don't want to send it until 9 AM their time. Without scheduling, you either send it and look needy, or you forget. **Recurring reminders.** A weekly team standup reminder. A monthly invoice nudge. A daily check-in with a sales rep. These messages don't need to be composed fresh every time — they need to go out on a schedule. **Off-hours availability.** Small business owners who want to be responsive without being available 24/7 use scheduled messages to cover evening and weekend windows. **Campaign coordination.** If you're sending promotional messages to multiple contacts, timing matters. You want them to land during business hours, not at 2 AM. A timed WhatsApp message isn't a gimmick. For anyone running a business on WhatsApp, it's a basic workflow requirement. [image: Small business owner using a smartphone at a quiet cafe after closing hours] ## How to Schedule WhatsApp Messages on Desktop (Chrome Extension) The most practical way to schedule WhatsApp messages in 2026 is through the [Blueticks WhatsApp scheduler Chrome extension](https://blueticks.co/). It runs directly inside WhatsApp Web, so there's no separate app to manage and no API access required. [image: Overhead desk flat-lay with a closed laptop and a notebook of scheduled send times] Here's how it works. **Setup:** Install the extension from the Chrome Web Store. Open WhatsApp Web. You'll see a clock icon appear in the message input area of every chat. ### Scheduling a Single Message 1. Open any chat — individual contact, group, or community. 2. Click the clock icon in the message input bar. 3. Type your message in the text field inside the scheduler modal. 4. Pick the date using the calendar. 5. Set the time. 6. Click **Schedule**. That's it. The message queues and sends at the time you set, even if you've closed the tab — as long as your computer is on and connected. If you need messages to send while your machine is off, there's an offline mode powered by a persistent gateway. Details on [Blueticks features](https://blueticks.co/features). One thing worth knowing: scheduled messages show up in your Blueticks dashboard, not in WhatsApp's native chat. You can edit or cancel them before they send. ### Setting Up a Recurring Scheduled Message Recurring scheduling is where the whatsapp scheduler chrome extension earns its keep. Instead of creating the same message every week, you set it once. 1. Open the scheduler modal (same clock icon). 2. Write your message. 3. Set the first send date and time. 4. Check **Custom recurrence**. 5. Choose your pattern: daily, weekly, monthly, or a custom interval. 6. Click **Schedule**. From that point, Blueticks handles the rest. A weekly payment reminder, a Monday morning team update, a monthly client check-in — all running without you touching it. You can see all your recurring messages in the [scheduler dashboard](https://blueticks.co/guides/scheduler), where you can pause or cancel any of them. [Install the Blueticks Chrome extension](https://chromewebstore.google.com/detail/blueticks/adgnjhngogijkkppficiiepmjebijinl) to get started. [image: Paper wall calendar marked with sticky notes for recurring scheduled WhatsApp messages] ## How to Schedule WhatsApp Messages on Android Android gives you more flexibility than iOS because apps can run background tasks. That said, the options vary in reliability. **Option 1: SKEDit or similar scheduling apps.** Apps like SKEDit integrate with WhatsApp through Android's accessibility services. You write the message, set a time, and the app opens WhatsApp and sends it automatically. This works, but it requires accessibility permissions and the phone needs to be on and unlocked at the send time. **Option 2: WhatsApp Business automation.** WhatsApp Business on Android supports scheduled greeting and away messages, but these are reactive — they respond to incoming messages, not scheduled outbound sends. **Option 3: Use the desktop extension on Chrome for Android.** Chrome for Android supports extensions in a limited way, but the WhatsApp Web experience on mobile browsers isn't great. For mobile-first users, the desktop remains the more reliable path for a proper whatsapp schedule message workflow. **Honest take:** If Android scheduling is a core need, the Chrome-based desktop approach is more stable than relying on accessibility service automations, which can break with WhatsApp updates. ## How to Schedule WhatsApp Messages on iPhone (iOS) iOS is more restrictive. Apple doesn't allow third-party apps to send messages through WhatsApp in the background — the app has to be open and foregrounded. Some workarounds: **Shortcuts app.** Apple Shortcuts can be set to trigger at a specific time and open a WhatsApp chat with a pre-filled message. But you still have to tap Send manually. It's a reminder, not a scheduler. **WhatsApp Business Auto-Reply.** Same limitation as Android — reactive only. **The practical solution for iPhone users** who need real scheduled messaging is to do it from a desktop or laptop using WhatsApp Web and the Blueticks extension. Once a message is scheduled there, it sends regardless of whether your iPhone is involved. If you're managing WhatsApp for a business from your phone most of the time, this is worth reconsidering. A browser-based scheduler running on any computer you have access to covers the gap. [image: Hand reaching for a smartphone resting face-down on a wooden table] ## WhatsApp Business Scheduling — What's Different WhatsApp Business adds a few automation tools that regular WhatsApp doesn't have. Here's what they actually do: | Feature | What it does | Scheduled outbound? | |---|---|---| | Greeting Message | Auto-reply when someone messages you for the first time | No | | Away Message | Auto-reply outside business hours | No | | Quick Replies | Saved message templates, sent manually | No | | Labels | Organize chats by contact type | No | None of these let you send a message to a contact at a time you choose. They're inbound automation, not outbound scheduling. For WhatsApp Business users who need outbound scheduling, the same Chrome extension approach applies. Blueticks works with both regular WhatsApp and WhatsApp Business accounts through WhatsApp Web. One practical difference: WhatsApp Business users often have larger contact lists and more structured outreach needs. For those cases, [Blueticks campaigns](https://blueticks.co/guides/scheduler) let you schedule a message to go to multiple contacts at once — with personalization per recipient. ## Tips for Reliable Scheduled Messages on WhatsApp Scheduling a message is only useful if it actually sends. Here's what causes failures and how to avoid them. **Keep your computer on.** The Chrome extension approach requires the machine running WhatsApp Web to be on at send time. If your computer sleeps or goes offline, the message queues until the connection restores. For critical sends, use a machine that stays on, or enable Blueticks' offline gateway mode so messages send even when your browser is closed. **Don't use multiple WhatsApp Web tabs.** WhatsApp limits you to one active web session. If you open WhatsApp Web in a second tab or browser, the first session disconnects and queued messages won't send. **Check your connection before a scheduled send.** If your WhatsApp Web session logs out — which happens if you log out from your phone — scheduled messages won't go out. Takes 10 seconds to verify the session is active before a high-stakes send. **Test with a self-reminder first.** WhatsApp lets you message yourself. Before scheduling an important client message, schedule a test to your own number 5 minutes out. If it arrives, your setup is working. **Use recurring schedules for predictable patterns.** Don't create 52 individual messages for a weekly reminder. Set one recurring message. It's easier to manage and less likely to have a gap if you miss recreating it one week. **Keep messages short.** WhatsApp has no hard character limit, but very long scheduled messages — especially with media — take slightly longer to process. For anything important, under 500 characters sends without any delays. > A note on WhatsApp's terms: WhatsApp's terms of service prohibit bulk messaging and automation that mimics spam behavior. Using scheduling for legitimate business communication — reminders, follow-ups, coordinated announcements — is within normal use. Using it to blast thousands of cold messages is not, and can result in your number being banned. ## Frequently Asked Questions **Can I schedule a WhatsApp message without the recipient knowing?** Yes. Scheduled messages arrive exactly like manually sent messages. There's no indicator in the chat that the message was scheduled. The recipient sees a normal message. **Does the Chrome extension work with WhatsApp Business?** Yes. Blueticks works with both personal WhatsApp accounts and WhatsApp Business accounts. You use it through WhatsApp Web, and it supports both account types. **What happens if my computer is off when a message is scheduled to send?** With the standard extension, the message will send when your computer comes back online and WhatsApp Web reconnects. If you need guaranteed delivery while your machine is off, Blueticks' offline gateway mode runs on a persistent cloud connection and sends regardless of your machine's status. **Can I schedule WhatsApp messages to a group?** Yes. The scheduler works with individual contacts, groups, channels, and communities. The same scheduling flow applies to all chat types. **Is there a free way to schedule WhatsApp messages?** The Blueticks extension has a free plan that covers basic scheduling. If you need recurring messages, offline delivery, or high-volume scheduling, there are paid tiers. For most small business use cases, the free plan covers the core need.