One QR scan per number. About a minute each.

What happens to a message after it arrives

Every event WhatsApp hands us is durably committed to an append-only event log before it is acknowledged. Nothing downstream sees a message until that write has returned. It is the ordering that matters: acknowledge first and you have promised to keep something you have not yet written down, and the window between the two is exactly where messages go missing.

Everything after the log is a consumer with its own cursor: the conversation view, the metrics, the media downloader. Each tracks its own position independently, so one falling over does not stall the others, and a consumer that dies mid-batch resumes from its last committed offset rather than from wherever it happened to be in memory. Recovery is replay, not reconstruction.

One writer per number, enforced rather than assumed

A linked number is held by exactly one process at a time. That is enforced with an advisory lock in the database and a fencing token carried on every write: a process that loses the lock and does not yet know it finds its writes rejected by the database, because the token it is carrying is stale. Two processes each believing they own the same session is how an archive ends up with duplicates and gaps simultaneously, and convention is not a defence against it.

Delivered at least once, recorded exactly once

Any capture pipeline worth trusting will deliver some events more than once, and that is the correct failure mode, because the alternative is losing them. Turning at-least-once delivery into exactly-once recording takes two independent mechanisms: a short-lived idempotency guard that rejects a message id already seen on that number, and a uniqueness constraint in the database that would reject the duplicate anyway if the guard were unavailable. Belt and braces on purpose. "Exactly once" asserted through a single mechanism is a claim about a happy path, not a property of a system.

Immutable by construction, not by policy

The archive accepts inserts and nothing else. Original message text and send time cannot be updated after they are written; the database refuses, not the application. A deletion or an edit arrives as a new event plus a flag; it never rewrites what was already recorded.

Records on a number are additionally chained: each commits to a hash of the one before it, so the sequence is tamper-evident. Removing or altering a record breaks the chain at that point, and the break is detectable by recomputing it, which you can do yourself, without trusting us. Chain heads are periodically anchored to write-once storage, so a compromise of the primary database cannot quietly rewrite history behind you.

Attachments are captured, not linked

Media is fetched eagerly, on arrival, into your own object storage under a per-tenant encryption key, with object lock applied. The key needed to decrypt what WhatsApp sent exists at rest only while the transfer is still in flight, and is destroyed the moment the object is verified in storage.

The alternative, resolving a link to WhatsApp's servers at the moment you click it, is the common design, and it is not an archive. An attachment you can only see for as long as somebody else chooses to host it is a bookmark.

The AI reads the archive, never the phone

On Team and above, AI assessments read the customer threads your CRM matches and put what needs a manager at the top of the queue, each item quoting its message. They read from the archive after a message is captured, and they cannot send messages. How AI assessments work.

What your reps have to do

Hand over the company phone for a minute, and scan the code again on the rare occasion a session drops. That is the entire list. There is no app, no profile to install, no number change, and no difference in how they use WhatsApp afterwards.

They should also read the page we wrote for them before you roll this out. Rollouts that skip that step are the ones that turn into an argument.