Security and data handling
Linking a WhatsApp number to somebody else's server is a real decision. This page says exactly what that server keeps, where it runs, who can reach it and how long anything survives — in the same numbers the privacy policy commits to.
What we store
An inbound message is transformed into an event, delivered to your webhook, and the raw copy is deleted by the retention job about two hours later, once the engine can no longer resend it. The WhatsApp engine keeps a linked number's message history in its own database, which the history endpoints read; on the default engine a daily job deletes it once the device is unlinked, and on every engine it goes with the channel. Nothing in the dashboard lets us browse your conversations.
- WhatsApp session credentials
- The device keys until the number is logged out; the rest of the session until the channel is deleted
- Message history the engine keeps for a linked number (messages, chats, groups, labels)
- While the number is linked. On the default engine (GOWS), a daily job deletes it once WhatsApp has unlinked the device (logout, ban or unlink from the phone); on the optional NOWEB engine it stays until the channel is deleted. Always with the channel
- Unused channels: never linked, or logged out or banned
- From 1 December 2026, deleted by a daily job: 14 days after creation if never linked (warning email on day 10), and 30 days after a logout or ban (warning email on day 23). A warning sent before 1 December 2026 gives at least 30 days
- Channel API tokens
- Until you rotate the token or delete the channel
- Message media (images, audio, documents)
- 24 hours on Sandbox, 7 days on Premium
- Raw inbound engine events
- Within 2 hours 10 minutes of processing (connection-status changes: 3 days)
- Webhook jobs and delivery attempts
- 30 days
- API request log (method, route, status, duration, IP)
- 14 days
- The Logs tab’s webhook delivery list (event type, endpoint URL, status, status code, error, attempts, times)
- Trimmed every night to the newest 50 per channel and the last 30 days
- Service logs of the API, the web server in front of it, the WhatsApp engine, the database and the cloud functions
- 30 days in Google Cloud Logging. On the VM, Docker also keeps the newest 100 MB of each container’s log until the container is next replaced, which for a quiet one can reach back several weeks
- Free number checker counts (IP address, day, number of checks)
- 2 days, then deleted within about a day (counts from before 9 November 2026: deleted by that date)
- Rate-limit counters
- 2 days
- Usage counters (sent, received, requests, checks per day; requests per month)
- Firestore, for the Usage tab: the last 31 days (older days are deleted every night). Postgres, for GET /v1/usage and quota enforcement: kept with no end date yet while the channel exists, and deleted with the channel, except the counter of a day not yet copied to Firestore
- Account record (email, plan, channel list, billing state, how you first found Wapito)
- Until you delete your account
- Email send records (one per notice the service sends you)
- 7 days, then deleted within about a day (one made before 9 November 2026: up to 31 days)
- Copies of the emails the service sends: the notices to you, and the alerts to the Wapito team about sign-ups, new channels, payments and bans, which name your email address and, for a sign-up, how you first found Wapito
- Until deleted from the mailbox
- Payment records (amount, date, invoice id)
- As long as tax law requires, typically seven years
- Daily snapshots of the whole VM disk
- 14 days
- Nightly backups of the Postgres databases and engine session files on the VM
- 21 days, then 7 more days deleted but still restorable: gone for good about 29 days after it was made
Where each of these lives and why it exists at all is spelled out, row by row, in the privacy policy — the same periods, as a commitment rather than a description.
Deleting a channel unlinks the WhatsApp session, drops its credentials and cancels its subscription. Deleting your account removes the account record and every channel on it; payment records survive only as long as tax law requires them to.
API tokens
A channel token is shown once, when the channel is created or the token is rotated. We store only its SHA-256 hash, in a private subcollection the browser cannot read even as the owner — so a copy of our database contains nothing that can call the API. Rotating a token invalidates the old one within seconds, and there is no endpoint anywhere that returns a token you already have.
Signed webhooks
Every delivery carries X-Wapito-Signature: t=<ms>,v1=<hex>, an HMAC-SHA256 of the timestamp and the raw request body under your own webhook secret. Verify it before you trust a payload, and reject anything whose timestamp is old — that is what stops somebody replaying a real event at your endpoint.
Where it runs
The API, the WhatsApp engine and Postgres run in Docker on a single Google Compute Engine virtual machine in us-central1, behind TLS terminated by Caddy. The engine is never exposed to the internet: it is reachable only from the API container on a private Docker network. Accounts, channel configuration and usage counters live in Firestore; static pages are served by Firebase Hosting. Backups of Postgres are taken nightly and restore is rehearsed rather than assumed.
Access and secrets
Secrets — Stripe keys, the media signing secret, engine credentials — are environment configuration on the VM and in Cloud Functions, never in the repository and never in the browser bundle. Firestore rules make channel documents readable only by their owner, and make every field that matters (status, plan, token preview) writable only by the API service. Administrative access is limited to the people who operate the service, and production access is used for incidents, not curiosity.
Outbound requests and hostile targets
A webhook URL is somebody else's server, and a webhook system is a request-forging engine if it is careless. Wapito accepts only HTTPS URLs that resolve to public addresses, re-checks the resolved address at send time, times a delivery out after ten seconds, stores at most a 512-character excerpt of the response, and opens a circuit breaker on an endpoint that keeps failing rather than hammering it.
Who else touches the data
Three processors, each with a narrow job: Google Cloud and Firebase, Stripe and Zoho Mail. What each one receives from Wapito, and nothing more, is listed in the privacy policy.
Nothing is sold, and no customer data is used to train anything. WhatsApp itself is of course in the path — it is their network — and Wapito is not affiliated with, endorsed by or certified by WhatsApp or Meta Platforms, Inc.
What we do not claim
Wapito has no SOC 2 report, no ISO 27001 certificate and no penetration-test letter to hand you. It runs on one virtual machine, which means a hardware failure is downtime rather than a transparent failover. If your compliance process needs any of those, it needs a different vendor today — and we would rather you found that out on this page than in month four.
Reporting a vulnerability
Email security@wapito.com with what you found and how to reproduce it. We aim to acknowledge within two business days and to tell you what we are doing about it within five. Please give us a reasonable window before publishing, do not access other people's data while testing, and do not run load or denial-of-service tests against the production host. There is no paid bug bounty yet; there is credit on the changelog and a fast, straight answer.