Automating a phone number you do not own: four invariants

If your product connects to WhatsApp through the linked-device protocol, your code operates a phone number that belongs to someone else. A small business owner scans a QR code and hands you their working line, the one printed on their van and saved in every customer's contacts.

The cost of a mistake is not a 500 in your dashboard. It is a ban, and a ban is not something you can refund. Only the messenger lifts it, on the owner's appeal, on their timeline.

What surprises most teams is that the anti-fraud system does not only read outgoing text. It watches how your protocol client behaves. A number can be flagged after two messages in a week if the client around it looks wrong.

Below are four invariants I now treat as non-negotiable for any system of this kind. None of them are about content.

1. Reaction is allowed, initiative is not

Replying to an incoming message is fine. Everything your process starts on its own is suspect.

Never let automation tear down a live session, request a fresh QR, wipe stored credentials, or scan the server for numbers on a schedule. Those actions belong to an explicit human click in your UI, and nowhere else.

The dangerous code is always well-intentioned. It reads like this:

// looks caring, behaves like an unstable client
if (Date.now() - lastInbound > SILENCE_THRESHOLD) {
  await restartSession(sessionId);
}

The intent is "the channel has been quiet, let me reconnect just in case". From the outside, a client that re-authenticates a healthy session three times in a morning is indistinguishable from a compromised or emulated one.

Silence is usually just a quiet Tuesday. If you need a