Every unofficial WhatsApp API — Wapito, its competitors, the open-source libraries underneath all of them — links a real WhatsApp account and drives it the way the phone does. That is what makes messaging without a template, creating groups and posting to Channels possible at all. It is also why the account can be banned, and why the marketing around "ban-proof" numbers is the most dishonest corner of this industry. This is the long version of our anti-ban advice: how WhatsApp seems to decide, what the numbers in our controls are and why they are what they are, a day-by-day plan for a new number, and what to do when the ban arrives anyway. The short version lives in the docs.
Start with the premise nobody puts on a pricing page
WhatsApp's terms do not permit automated or bulk messaging through the consumer app, and every linked-number API is, as far as WhatsApp is concerned, a very well-behaved consumer app. The platform is not trying to detect software; it cannot tell a Python script from a fast typist, and it does not need to. It is trying to detect spam, and it does that with the signals spam produces: complaints, one-directional traffic, sudden volume from young accounts, identical content, and people being put into groups they never asked to join.
That framing matters because it tells you what a provider can and cannot do. A provider can make the traffic it sends look like a person's — paced, varied, reactive, respectful of the warnings WhatsApp sends back. A provider cannot make unwanted messages wanted. So the honest promise is a narrow one: good defaults you cannot switch off, limits that refuse a bad idea before WhatsApp notices it, and fast, clear signals when the number is in trouble. Anything broader is a promise about WhatsApp's decisions, which nobody outside Meta gets to make.
How the ban decision seems to work
Meta does not publish the rules, and they change. What follows is consistent with what teams running linked numbers have observed for years, and with our own logs.
Reports dominate. When a recipient taps Report, WhatsApp receives the last several messages you sent them, and a report is a human saying "I did not want this". A young number can be gone after a handful; an old number with a long history of two-way conversations absorbs far more. The practical corollary: the messages most likely to be reported are the ones to people who do not know you, and the most reported action of all is adding someone to a group.
Ratios matter more than totals. A number that sends 500 messages a day and receives 400 replies looks like a busy shop. A number that sends 500 and receives 4 looks like a broadcaster. The absolute number matters less than the share of conversations the other side started or continued.
Age and history are a buffer. Accounts accumulate trust: time since registration, contacts saved, groups joined, calls made, a profile name and photo, the same device, a stable network. A freshly bought virtual number linked from a datacenter with an empty profile has none of that buffer and is judged on its first hundred messages.
Timing and shape are secondary signals. Perfectly regular intervals, sends at 3 a.m. local time, no "typing…" indicator, identical text with a link in the first line — none of these ban a number alone, but each one lowers the number of reports it takes.
WhatsApp warns before it bans, sometimes. The timelock — a state in which the number may
reply but may not start new conversations for a period — is a warning shot. So is a burst of
failed delivery receipts. Numbers that respond to the warning by slowing down usually survive;
numbers that route around it usually do not.
The four controls, and where the numbers come from
Wapito applies four controls to every channel, on every plan, and none of them can be raised by paying more. Here is each one with its numbers and the reasoning behind them.
1. Send pacing: 1.5 seconds plus jitter
Every channel has one send queue. Messages leave it about send_delay_ms apart — 1,500 ms by
default, never below 500 ms on Sandbox — plus a random 0–1,500 ms of jitter, so the gaps are
never identical. A human on a phone sends a short message every few seconds at most, and rarely
at a metronome's rhythm; the queue reproduces that. A producer that pushes faster than the queue
drains is refused with 429 send_rate_limited once a call would wait more than twenty seconds,
which is the platform's way of saying the number is at its natural ceiling.
2. Typing simulation: 60 ms per character, capped at 8 seconds
With typing_simulation: "auto", or a typing_time on an individual send, the recipient sees
"typing…" for a duration proportional to the message before it arrives, and a reply to an
inbound message marks it read first. Sixty milliseconds a character is roughly a fast phone
typist; the eight-second cap keeps long messages from stalling the queue. On Sandbox, a channel
sending more than twenty messages a minute without typing_time has typing switched on for it.
3. The warm-up ladder: 50 → 100 → 200 → 350 → 500 → 750 → 1,000
A newly linked number may send fifty messages on its first day, a hundred on the second, then
200, 350, 500, 750 and 1,000, and only from the eighth day is it bound by the plan alone. The
curve is what a genuinely growing account looks like — roughly doubling early, then flattening —
and it follows the phone number, not the channel: a disconnect, a reconnect or an engine switch
does not reset it, and a different number linked to the same channel starts from day zero. A send
past the day's rung answers 429 warmup_limit with the rung and the day in details.
4. The cold-send guard: 10, 20, then 60 or 20 an hour
A recipient is cold when they have never messaged the number, or when your first message to them
is less than 24 hours old and they have not replied. Each hour a channel may start only so many
cold conversations: ten on days 0–1, twenty on days 2–6, then sixty on Premium and twenty on
Sandbox. Follow-ups to a cold recipient you already wrote to this hour cost nothing; once the
hour's budget is spent, every cold send — follow-ups included — answers 429 cold_send_limit
until it resets, while replies to people who wrote to you flow unchanged. Groups and Channels are
never cold, because nobody reports a broadcast they subscribed to.
This is the control that makes "reply-first" a property of the platform rather than a line in a guide, and it is the one that surprises teams arriving from a library. It is set where it is because sixty new conversations an hour is already a lot for a human, and because the first message to a stranger is the message most likely to be reported.
And the one WhatsApp applies itself
When WhatsApp timelocks a number, Wapito reads it from the engine, exposes it in
GET /channel/limits, answers cold sends with 423 reachout_timelocked and lets replies through.
The right response to a timelock is to send less for a few days, not to find a way to send the
same amount.
A plan for a new number, day by day
A week before linking. Use a real SIM with some history if you can; a number that has made calls and received texts is not a number bought this morning. Install WhatsApp on a real phone, set a profile name and photo, save a few dozen contacts, join a group or two, exchange messages with people who know you. Give the account a life before it gets a job.
Day 0. Link the number by pairing code or QR,
then send fewer messages than you are allowed to — and only to people who already have a
conversation with the number. Test the webhooks. Subscribe to the channel event now, so a ban
reaches your on-call rather than your inbox.
Days 1–6. Let the ladder climb without pushing it. Answer every reply promptly; two-way traffic is the buffer you are building. Keep the phone itself in use: reading, replying, calling. If you must reach people who have not written to you, keep to the hourly cold budget and vary the wording of every message.
Week 2 onward. Bring production traffic in gradually. Watch the ratio of failed delivery
receipts, the volume of inbound messages, and timelock in the limits endpoint. If any of the
three moves the wrong way, halve the volume for a few days.
Designing the traffic so it is wanted
The controls bound the shape of the traffic. What is in the messages is up to you, and it decides the report rate.
Make the customer speak first. A wa.me link on the website, a QR code on the receipt, a
keyword in an ad, a "message us on WhatsApp" button at the end of a form — anything that makes the
customer's message the trigger. Once they have written, the cold-send guard never applies to
that conversation, and the traffic is exactly the kind WhatsApp likes.
Ask, and honour "stop". People who opted in report far less, and people whose "STOP" was obeyed almost never do. Record opt-outs against the account identifier, not just the phone number, so a later message from the same person's LID is caught.
Write like a person, every time. Use the name, vary the sentences, put the link in the second message if you need a link at all, avoid sending outside the recipient's waking hours, and never send the same paragraph to a thousand people. If a message would look like spam on your own phone, it looks like spam on theirs.
Prefer invitations to adds. For groups, share an invite link and let people join rather than adding them yourself; a member who chose to join does not report the group. Keep what you send to a group to what its members signed up for.
Check numbers the way the platform paces them. Bulk number checks are throttled — fifty per request, low concurrency, a daily quota — because verifying a large list of strangers is itself a signal that a list of strangers is about to be messaged. Check what you need, when you need it.
Watching the number
Three signals tell you the number is in trouble before WhatsApp does, and all three are in the API:
- The share of
messages.statusevents withstatus: "failed". A few are normal; a rising share means messages are not being accepted for delivery. - Inbound volume. A number that used to receive replies and suddenly does not has either lost its audience or lost its standing.
timelock.activeinGET /channel/limits, and423 reachout_timelockedin your error logs.
And the one signal that tells you it is over: the channel event with reason: "banned". Wapito
stops the session, marks the channel banned and e-mails the account owner within about a minute
of the engine reporting it.
When it happens anyway
Sometimes it will. WhatsApp bans numbers that did nothing on this list, and it bans them for things nobody has yet identified; anyone who says their customers never get banned is either new or not telling you.
A temporary ban shows a countdown in the app, usually hours to a few days. Wait it out, link the number again, and come back at a fraction of the old volume; the ladder does not restart for the same number, so the restraint is yours to apply. A permanent ban shows a Request a review button. The review is between you and WhatsApp — a provider has no channel to Meta and no appeal to run for you — and it rarely succeeds for numbers that were, in fact, broadcasting. Move the channel to a new number, which restarts the ladder, and change the behaviour that led here first.
Do not respond to a ban by buying ten numbers and rotating through them. Number farms are the pattern the platform is best at recognising, they burn faster with each generation, and they convert a recoverable situation into a permanent one for every number involved.
What no provider can promise you
- That your number will not be banned. Not with a proxy, not with "warmed" numbers, not with an "anti-ban algorithm". The judgement is WhatsApp's.
- That a ban can be reversed. There is no back channel.
- That bulk cold outreach can be made safe. It can be made slower, which helps; it cannot be made wanted, which is what matters.
- That a control can be switched off for the right price. If a provider offers to lift its pacing for a premium tier, it is selling you a faster ban.
What a provider can promise — what Wapito promises — is that every one of the controls above is on for every channel, that the limits say no before WhatsApp does, that a timelock or a ban is reported to you within a minute, and that this page will keep saying so.
The checklist
- A real number with history, a profile name and photo, used by a human before it is linked.
- Linked by pairing code, tested with your own second phone,
channelevent subscribed. - Traffic that the customer starts: links, QR codes, keywords, forms.
- Opt-in recorded, opt-out honoured, keyed on the account identifier.
- Varied wording, no link in the first message, sends in waking hours.
- Invite links instead of group adds; announcements members asked for.
- Number checks only for numbers you are about to message.
- Failed-receipt ratio, inbound volume and
timelockon a dashboard someone looks at. - A plan for the ban: who gets the
channelevent, what stops, which number takes over.