Number health: best practices and restrictions

WhatsApp uses algorithms to detect automated behavior. When the system decides a number is sending messages in an unnatural way, it can restrict or ban the number. The best practices below help keep your number working longer. The logic is simple: the more your usage looks like a real person’s, the lower the risk of a restriction. If you landed here looking for why your WhatsApp Business got blocked, or how to avoid a WhatsApp ban, start with the WhatsApp Web mental model in the next section. It is what reduces bans the most in practice.

These recommendations apply mainly to unofficial instances (QR code). WABA (official) instances follow Meta’s policies directly and have a much lower ban risk. Even so, good content and opt-in practices apply to both types.

Complete profile

Fill in the WhatsApp Business profile with as much information as possible:

Profile picture (logo or professional photo)
Business name
Business description
Address
Business hours
Contact email
Website

A complete profile increases the algorithm’s trust in the number. Empty or incomplete profiles are a signal of a disposable account.

Turn on the security PIN (two-step verification) in WhatsApp. Beyond protecting against cloning, it tells the system this is a legitimate account that cares about security.

Think like WhatsApp Web: multiple connections per number

Most ban problems do not come from the API. They come from trying to make a single number behave like dozens of people at once. To avoid that, it helps to understand how WhatsApp itself was designed. WhatsApp lets you link up to 4 devices to a single number, on top of the main phone. It is the mechanism behind WhatsApp Web and WhatsApp Desktop: you open the same number on the work laptop, the home computer, and the tablet, and all of them chat through the same account. This is legitimate, expected usage. Each of those connections is an instance from the point of view of WhatsApp’s network. When you create an instance on Zapster, you are taking one of those linked-device slots. The problem shows up when a single instance tries to serve too many people. To the algorithm, one instance replying to 400 conversations a day looks like one impossibly overloaded person, and that is a classic signal of abusive automation. Nobody types to 400 contacts alone in a day without stopping. The best practice is to distribute. Open 2 to 4 instances of the same number on Zapster and split the conversations between them. Each instance then works like a virtual “agent”:

❌ 1 instance handling 400 conversations/day on its own → looks like a bot.
✅ 4 instances of the same number handling 100 conversations/day each → looks like a team of 4 human agents using WhatsApp Web.

The total volume is the same. What changes is the distribution: instead of one impossible human, the pattern looks like several plausible humans.

To automate this balancing, we are developing a Smart Sending Mode with an instance pool that distributes conversations between instances of the same number automatically. Until it ships, you can achieve the same effect by creating the instances manually and routing in your code. See Instances to understand the connection types.

The most common mistake: connect and start blasting

This is the mistake that most often triggers a restriction on a new number, and almost nobody sees it as a mistake: create the instance, scan the QR code, and, in the same minute, blast messages to a list of contacts who have never spoken to you. From your point of view, the number “is working”. From WhatsApp’s point of view, a number that just appeared is already reaching out to dozens of strangers, which is exactly the pattern of an account created for spam.

Replying is safe; starting a new conversation is where the risk lives

WhatsApp treats two things very differently:

Replying to someone who reached out to you: someone messaged you and you replied. Very low risk. It is the most natural usage there is.
Starting a conversation with a new contact (the “reach-out”): you approach someone who has never written to you. This is where the algorithm pays attention, because it is what a spammer does.

When a number is “under suspicion” (a freshly created connection, a history of restrictions, or an unusual volume of new conversations in a short time), WhatsApp applies a time lock: the number can still reply to already-open conversations, but starting a new conversation is blocked for a period. That period ranges from a few hours to several days: 7-day or 14-day restrictions are common.

This lock usually hits only the API connection (the linked device), not the phone. That is why you see a confusing scene: the number sends messages normally through the app on the phone, but the instance fails to send. It is not an API bug: it is the restriction acting specifically on the connection that was reaching out to new contacts.

Warmup: the first days define the rest

A new number is like a new account anywhere: it has to build reputation before asking for trust. Treat the first hours and days as a warmup period. In the first hours / first day:

Prioritize replying to inbound messages. Every conversation that starts from the other side counts in your favor.
Avoid starting cold conversations in bulk. If you must start any, keep them few and spaced out.
No creating groups, adding participants in bulk, or bulk blasting: these are the highest-risk actions right after connecting.

Throughout the first week:

Ramp the volume up gradually, not from zero to the target volume all at once.
Keep a healthy ratio between the conversations you receive and the ones you start. A number that only starts and never receives is suspicious; a number that talks in both directions looks real.

The most effective warmup tactic is to make the number receive real conversations before it starts blasting. Put the number in your bio, on your site, in a click-to-WhatsApp ad, in your email footer. Every person who reaches out to you first generates exactly the kind of interaction (inbound → reply) that matures the number fastest and with the least risk.

Reconnecting is not the same as a new number

It is important not to confuse the two cases:

You only restarted the instance (reconnected the same number that was already running healthy) → no need to warm up from scratch. The number’s history still counts; keep the normal pace.
A new number or one that just came out of a restriction → then the warmup care applies fully. A number fresh out of a restriction comes back “sensitive”, and a relapse into the same pattern tends to bring a longer lock.

Ask to be added to contacts

Whenever possible, ask the recipient to add the instance’s number to their phone contacts. When someone saves your number, WhatsApp understands there is a real relationship between you. This raises the number’s “score” and lowers the chance that your messages get marked as spam. In practice, you can include a line like:

“To make sure our messages always reach you, save this number in your contacts.”

Cadence between messages

Do not send messages in bursts. WhatsApp detects bulk sends easily. Interval recommendations:

Scenario	Minimum interval	Ideal
Sending to a contact list	30 seconds	45 to 60 seconds
Follow-up after an interaction	10 seconds	20 to 30 seconds
Automatic replies (chatbot)	3 to 5 seconds	5 to 10 seconds

The longer the interval, the better. If you need to send to 100 contacts, wait at least 30 seconds between each send. That means the batch takes about 50 minutes to finish. It seems slow, but it is what keeps the number alive.

Sending more than 1 message per second to different recipients is one of the behaviors that most often triggers a restriction. Always avoid it.

Human window: one conversation at a time per instance

Notice how a real person uses WhatsApp Web. They focus on one contact, exchange a few messages, resolve that topic, and only then move to the next. They do not answer 5 conversations in parallel, word by word, at the same time. That sequential focus is the signature of a real human. The best practice is to reproduce this per instance: handle one conversation at a time, within an active “window”. A simple pattern that works well is the per-contact debounce: a window of about 1 minute dedicated to a contact before moving to the next. When another contact writes in the middle of that window, you do not handle it in parallel. You reply with something short like “I will get back to you in a moment” and put that contact in the queue. The flow, in words:

A message arrives.
Is there already an active window on this instance?
- Yes → queue the contact and reply with a wait message.
- No → open the window for that contact and reply normally.
At the end of the window (or when the topic is resolved), take the next one from the queue.

The important point: this reduces bans without reducing the total volume. You keep serving the same number of people. Only the distribution over time changes, which avoids the pattern of a bot talking to everyone at once.

The Smart Sending Mode (in development) will handle this queue and the per-contact debounce natively, together with the instance pool.

Presence in parallel is poison

Before sending a message, use the presence update endpoint to simulate human behavior:

# Simulate "typing..." for 5 seconds before sending
curl -X PATCH https://api.zapsterapi.com/v1/wa/instances/YOUR_INSTANCE/presence \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "recipient": "5511999999999",
    "status": "typing",
    "duration_strategy": "maximum_duration",
    "max_duration": 5
  }'

The recipient will see “typing…” for 5 seconds before receiving the message. This makes the send feel more natural, both for the recipient and for the algorithm. For audio, use "status": "recording" to show “recording audio…”. You can also use "duration_strategy": "until_next_message" to keep the status active until the message is actually sent. This works well when the processing time varies (as in AI replies).

Why parallelizing presence gives the bot away

Here is the mistake that most often takes a number down: firing presence: typing (or recording) to two recipients at the same time on the same instance. Think about what that represents: a single person “typing…” to John and to Mary in the same second. No human types to two people simultaneously. It is a bot signal there is no way to disguise. The solution is to serialize presence per instance: process the queue one at a time, with your presence, and only fire the next one when the previous finishes. Anti-pattern (presence in parallel, all at once):

// ❌ Do NOT do this: fires "typing..." to everyone at once
await Promise.all(
  contacts.map(async (contact) => {
    await setPresence(contact.phone, 'typing'); // everyone "typing" together
    await sendMessage(contact.phone, contact.text);
  }),
);

Correct (one conversation at a time, serialized presence):

// ✅ Serialize: only start "typing" for the next when the current one finishes
async function setPresence(phone, status) {
  await fetch(`https://api.zapsterapi.com/v1/wa/instances/YOUR_INSTANCE/presence`, {
    method: 'PATCH',
    headers: {
      Authorization: 'Bearer YOUR_TOKEN',
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({
      recipient: phone,
      status,
      // keeps "typing..." until the message actually goes out
      duration_strategy: 'until_next_message',
    }),
  });
}

for (const contact of contacts) {
  await setPresence(contact.phone, 'typing');
  await sendMessage(contact.phone, contact.text);
  await new Promise((r) => setTimeout(r, 45000)); // interval between conversations
}

duration_strategy: 'until_next_message' is an ally here: it holds “typing…” for however long your processing takes and ends it on send, without you timing anything. Combined with serialization, presence stays naturally aligned with one conversation at a time.

Use the original device regularly

Meta disconnects linked devices that stay inactive for more than 14 days. That means if nobody opens the WhatsApp app on the original phone for 14 days, the instance’s connection can drop. Recommendation: at least once a week, open WhatsApp on the phone where the number is registered. You do not need to do anything complex:

Open the app
Browse through the conversations
Send a message to someone (it can be to yourself on another number)
Check for pending app updates

This periodic usage keeps the link active and avoids unexpected disconnections.

Reference: About linked devices on WhatsApp Business

Personalize your messages

Identical messages sent to many people are one of the strongest signals of automation. WhatsApp compares the content of messages sent by a number and detects repetitive patterns. Bad:

Hi! We have a special promotion for you. Visit our site.

(the same message to 200 people) Good:

Hi John! I saw you were interested in the Pro plan last week.
Still evaluating it? I can help with any questions.

(a personalized message with name and context) On the Zapster API, you build the message dynamically in your code before sending. Each request to POST /v1/wa/messages can carry a different text:

const contacts = [
  { phone: '5511999999999', name: 'John', interest: 'the Pro plan' },
  { phone: '5511888888888', name: 'Mary', interest: 'the N8n integration' },
];

for (const contact of contacts) {
  await fetch('https://api.zapsterapi.com/v1/wa/messages', {
    method: 'POST',
    headers: {
      'Authorization': 'Bearer YOUR_TOKEN',
      'X-Instance-ID': 'YOUR_INSTANCE',
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({
      recipient: contact.phone,
      text: `Hi ${contact.name}! I saw you were interested in ${contact.interest}. Can I help?`,
    }),
  });

  // Wait between sends
  await new Promise(r => setTimeout(r, 45000)); // 45 seconds
}

Opt-in and opt-out

Send messages only to people who gave consent. People who do not expect your messages will report them as spam, and that drops the number’s score quickly. Opt-in: have some form of consent before sending. It can be a form on your site, an email confirmation, or a prior interaction on WhatsApp itself. Opt-out: always give the option to stop receiving messages. Include something like:

“If you no longer want to receive our messages, reply STOP.”

And respect it when someone asks to leave. Continuing to send to someone who asked to stop is the fastest path to a restriction.

Contact list hygiene

Before sending to a list, check that the numbers are valid:

Use the recipient lookup endpoint to check whether the number is on WhatsApp
Remove numbers that have not replied for months
Remove numbers that requested opt-out
Remove duplicates

Sending to invalid or inactive numbers generates silent failures that WhatsApp counts against you.

Send times

Sending messages in the middle of the night or at odd hours generates more reports. Prefer business hours:

Time	Recommendation
8 AM to 12 PM	Good
12 PM to 2 PM	Acceptable (lunch time, lower read rate)
2 PM to 6 PM	Good
6 PM to 8 PM	Acceptable
8 PM to 8 AM	Avoid
Weekends	Avoid for commercial messages

With scheduled messages, you can prepare the send outside business hours and let Zapster fire it at the right moment.

What to do if you get restricted

If the number is temporarily restricted:

Stop immediately sending automated messages.
Wait for the restriction period to pass. The duration varies a lot: it can be from a few hours to 7 or 14 days, depending on the number’s history and the type of behavior that triggered the lock (new-conversation restrictions tend to be the longest).
Come back slowly with reduced volume and longer intervals, and, if the number was new or a repeat offender, resume the warmup (see “The most common mistake: connect and start blasting”), prioritizing inbound replies before starting conversations.
Review your practices before returning to the previous volume.

If the number is permanently banned:

In most cases the number cannot be recovered.
Consider migrating to a WABA (official) instance, which does not carry this risk.
If you need a new unofficial number, start with low volume and follow all the practices above from the beginning.

Workflow self-audit (the 80/20 rule)

Before concluding that “the API is banning my number”, audit your own flow. In practice, the cause is almost always in the workflow design, not in the tool. It is worth applying the 80/20 rule here: 80% of the work is planning and analyzing the flow, 20% is executing the code. Those who invert this ratio (throw code into production and only investigate afterward) tend to burn numbers in the process. Run your flow through these questions:

How many instances do I keep per number? Am I using the WhatsApp Web model (up to 4 devices) or overloading a single one?
Does my agent/bot answer several conversations in parallel? Or handle one at a time?
Do I have concurrency control (queue, lock, per-contact debounce)? Or does everything fire at once?
Where do I send presence: typing? Is it serialized per instance or parallel?
What is the average interval between sends to the same contact?
Does my daily volume match “X human agents working from 9 AM to 6 PM”? Or does it only make sense if it were a bot?

This kind of audit is a great task to delegate to an LLM (Claude, ChatGPT). Describe your current workflow (how many instances, how the bot queues, where it fires presence) and ask the model to point out where the pattern departs from a human using WhatsApp Web.

Worth an honest framing: you own the design of your system. Zapster provides the tools (instances, presence, scheduling, queue), not the strategy for how you combine them. A well-designed workflow keeps the number healthy with the same tools a poorly designed workflow uses to burn it.

Quick checklist

Use this list before starting a high-volume send:

Introduction

Concepts

Guides

Number health: best practices and restrictions

Complete profile

Think like WhatsApp Web: multiple connections per number

The most common mistake: connect and start blasting

Replying is safe; starting a new conversation is where the risk lives

Warmup: the first days define the rest

Reconnecting is not the same as a new number

Ask to be added to contacts

Cadence between messages

Human window: one conversation at a time per instance

Presence in parallel is poison

Why parallelizing presence gives the bot away

Use the original device regularly

Personalize your messages

Opt-in and opt-out

Contact list hygiene

Send times

What to do if you get restricted

Workflow self-audit (the 80/20 rule)

Quick checklist

References

​Complete profile

​Think like WhatsApp Web: multiple connections per number

​The most common mistake: connect and start blasting

​Replying is safe; starting a new conversation is where the risk lives

​Warmup: the first days define the rest

​Reconnecting is not the same as a new number

​Ask to be added to contacts

​Cadence between messages

​Human window: one conversation at a time per instance

​Presence in parallel is poison

​Why parallelizing presence gives the bot away

​Use the original device regularly

​Personalize your messages

​Opt-in and opt-out

​Contact list hygiene

​Send times

​What to do if you get restricted

​Workflow self-audit (the 80/20 rule)

​Quick checklist

​References

Complete profile

Think like WhatsApp Web: multiple connections per number

The most common mistake: connect and start blasting

Replying is safe; starting a new conversation is where the risk lives

Warmup: the first days define the rest

Reconnecting is not the same as a new number

Ask to be added to contacts

Cadence between messages

Human window: one conversation at a time per instance

Presence in parallel is poison

Why parallelizing presence gives the bot away

Use the original device regularly

Personalize your messages

Opt-in and opt-out

Contact list hygiene

Send times

What to do if you get restricted

Workflow self-audit (the 80/20 rule)

Quick checklist

References