We treat your WhatsApp like medical records: read-only access, isolated workspaces, deletable on demand.
Our codebase contains zero send/pin/archive/delete WhatsApp calls. The only methods we ever invoke are getChats and fetchMessages. Auditable on request.
Your WhatsApp session lives in its own Linux container with its own memory, disk, and network namespace. Other users cannot see or touch it โ physically separated.
Every message and digest is stored in Supabase Postgres, encrypted at rest by AWS KMS. Transport is TLS 1.3 only. Service-role keys never leave the server.
Cached in Supabase to enable incremental syncs and the message-thread reader. Never shared with third parties.
The AI-generated summary of each group's activity, plus the action items and their state (pending/done).
Your schedule, muted groups, account email. That's it. No payment data โ Stripe holds that.
From your dashboard โ Settings โ Delete account: every row in WhatsApp Wizzard_* tied to your user_id is deleted, your worker is shut down and its disk wiped, and your WhatsApp linked-device session is unlinked. Takes < 60 seconds. We keep nothing.
WhatsApp Wizzard connects to your account via the same linked-device protocol WhatsApp Web uses. This is technically not allowed by WhatsApp's terms of service โ they don't sanction third-party automation. There is no official API for reading your personal groups and DMs, anywhere.
WhatsApp's automated systems sometimes detect the connection patterns of a third-party Web client and respond with one of:
What we do to minimise risk:
What we cannot guarantee:
Our honest recommendation: use WhatsApp Wizzard with a number that's been actively used for 3+ months on WhatsApp. If a temporary restriction (24-72h) on that number's Web access only would significantly disrupt you, this isn't the right tool. For most business operators with established numbers, the risk is small and worth it. For brand-new or critical-only personal numbers, it isn't.