Privacy Policy
What personal data Wapito processes for your account and your linked WhatsApp numbers, why it is processed, exactly how long each kind is kept, who else touches it and what you can ask us to do about it.
1. Who this policy is from
This policy explains what Wapito does with personal data when you use the dashboard, the REST API and the webhook delivery service. Wapito is operated by an independent team; the registered entity and address will be named here once the selling entity is registered, and until then this draft is under legal review. Questions go to support@wapito.com.
It covers two different relationships. For your own account data we are the controller and decide what happens to it. For the WhatsApp traffic flowing through your channels we are your processor: you decide what is sent to whom, and we act on your instructions.
2. What we collect
Only what the service needs to work. There is no advertising profile, no data broker and no enrichment of your contact lists.
- Account data: the email address you sign in with, your display name if you give one, your authentication records from Firebase Auth, and how you first found Wapito — the campaign tags of the link you arrived by, the site or app that sent you (its address without the path), the page you landed on and your Google Analytics client id.
- Channel configuration: the name you gave the channel, the WhatsApp number once it is linked, webhook URLs and their secrets, event filters, proxy settings and the SHA-256 hash of the channel token.
- Message traffic in transit: the messages and events your channel sends and receives, processed to deliver them to your webhook and, for media, stored briefly so your endpoint can fetch the file.
- Operational data: API request metadata (method, route, status code, duration, request id, IP address), webhook delivery attempts and their response codes, rate-limit counters, daily usage totals, a record of each email the service sends and the copy of it the sending mailbox keeps, and the service logs of the API, the engine, the database and the cloud functions.
- Billing data: your Stripe customer and subscription identifiers, invoice records and payment status. Card numbers are entered on Stripe and never reach us.
- Website data: the analytics events described below, and the preferences your browser stores locally such as theme and the code language you last selected.
3. Why we process it, and on what basis
To provide the service you asked for — creating channels, linking numbers, sending messages, delivering events — which is performance of our contract with you.
To bill you, to keep accounting records and to answer tax and legal obligations, which is a legal obligation or contract performance as the case may be.
To keep the service working and safe: debugging, capacity planning, enforcing quotas, detecting abuse and unsolicited bulk messaging, and investigating bans. That is our legitimate interest in running a service that is not overrun by spam, balanced against your interests.
To send you service email you cannot reasonably opt out of — a channel that has disconnected, a trial about to end, a failed payment, a security notice. Marketing email, if we ever send any, will be opt-in and separately unsubscribable.
4. Messages and the people you message
An inbound message is transformed into an event, delivered to your webhook and then dropped by the retention jobs. Nobody at Wapito reads your conversations. While a number is linked, the WhatsApp engine keeps that number's message history in its own database, which the history endpoints read. On the default engine, a daily job deletes that history once WhatsApp unlinks the device; on the optional NOWEB engine it stays until the channel is deleted. Deleting the channel deletes it with everything else. Media files are copied off the engine only so your endpoint has a stable link to fetch, and are deleted when the window below expires.
The people you message are not our customers. You are responsible for having a lawful basis for contacting them, for telling them who is messaging them and why, and for honouring their objections. The Acceptable Use Policy makes that a condition of using the service, not a suggestion.
5. How long we keep it
Automatically, on a schedule, wherever the table gives a period, and the same periods the security page publishes; the few rows without one say so. Deleting a channel unlinks the WhatsApp session and removes its credentials, its message history and its request log; deleting your account removes the account record and every channel on it. From 1 December 2026, a channel that is never linked within 14 days, or stays logged out or banned for 30 days, is deleted automatically after a warning email; the account itself is kept.
| What | Where | Kept for |
|---|---|---|
| WhatsApp session credentialsThey are what keeps your number linked. Deleting the channel deletes them and unlinks the device. A logout removes the device keys and the message keys; the rest of the session (its settings, the number, display name and WhatsApp LID the engine recorded for it, and per-contact tokens) goes with the channel. | Postgres on the Wapito VM | 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)The history endpoints (GET /v1/chats and the GET /v1/messages reads) are served from it. A number that is no longer linked cannot use it, so it is not kept. Nobody at Wapito browses it. | Postgres on the Wapito VM, one engine database per channel | 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 bannedA channel nobody can use should not keep a token, webhooks, a request log or engine data. Deletion removes all of that; your account and your other channels stay. Linking the channel ends the period; opening its QR code, asking for a pairing code or pressing Reconnect starts it again, and a logged-out channel stays logged out until it is linked. On the default engine, a channel whose linked device is gone counts as logged out whatever its status shows. No channel is deleted this way while it is premium, in a trial or locked, while its account has an active, trialing or past-due subscription, or while the engine may still have its device linked. | Firestore and the Wapito VM | 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 tokensThe token itself is shown once, at creation. We store only its hash, so a database copy cannot be used to call the API. | Firestore, SHA-256 hash only | Until you rotate the token or delete the channel |
| Message media (images, audio, documents)Inbound files are copied off the engine so your webhook gets a stable link. After that window the file is deleted. | Disk on the Wapito VM | 24 hours on Sandbox, 7 days on Premium |
| Raw inbound engine eventsA short buffer between the engine and your webhook, kept only until the engine can no longer retry the same event; an event not yet processed stays until it is. Events nothing uses, such as group read receipts, are never stored. It is not a message archive. | Postgres on the Wapito VM | Within 2 hours 10 minutes of processing (connection-status changes: 3 days) |
| Webhook jobs and delivery attemptsSo the Logs tab can show you what was delivered, with the status code and the retry schedule. | Postgres on the Wapito VM | 30 days |
| API request log (method, route, status, duration, IP)Debugging, abuse investigation and rate-limit enforcement. Request and response bodies are not stored. | Postgres on the Wapito VM | 14 days |
| The Logs tab’s webhook delivery list (event type, endpoint URL, status, status code, error, attempts, times)A copy of each webhook job’s outcome that your dashboard can watch live. It never holds the event body or the signing secret. | Firestore | 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 functionsDebugging and incident response. A log line can carry personal data that appears in a request or an error: IP addresses, email addresses, and phone numbers or WhatsApp ids in request paths and engine events. | Google Cloud Logging, and a copy on the Wapito VM | 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)Limits the free WhatsApp number checker on the website to a few checks per IP address per day. | Firestore | 2 days, then deleted within about a day (counts from before 9 November 2026: deleted by that date) |
| Rate-limit countersSliding windows for the per-minute and per-day limits on your plan. | Postgres on the Wapito VM | 2 days |
| Usage counters (sent, received, requests, checks per day; requests per month)The Usage tab, GET /v1/usage and quota enforcement. Counters are numbers, never message content. | Firestore and Postgres on the Wapito VM | 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)Your login, what you are entitled to, and which channels are yours. How you first found Wapito — the UTM source, medium and campaign or the Google Ads click id of the link you arrived by, the address of the site or app that sent you without its path, the page you landed on and your Google Analytics client id — tells us which pages and campaigns bring sign-ups. A record from before 9 November 2026 also held the full referring address, the UTM term and content, the time of the first visit, when that first touch was recorded and a Google Analytics session id; those are removed from the record by that date. The sign-up alert emailed to the Wapito team at the time still shows the full referring address (see the copies of sent emails below). | Firebase Auth and Firestore | Until you delete your account |
| Email send records (one per notice the service sends you)So a retried job never sends the same email twice. A record holds a hash of the email’s id and when it was sent, not the address or the subject; one made before 9 November 2026 also held those two, and they are removed from it by that date. The email itself is kept as a copy in the mailbox, in the next row. | Firestore | 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 WapitoA mailbox keeps a copy of every message it sends, as any email account does. Support reads them to answer a question about a notice you received, and the team reads the alerts to act on a payment or a ban. | Zoho Mail (the sending mailbox) and the Wapito team’s inbox | Until deleted from the mailbox |
| Payment records (amount, date, invoice id)Invoicing and accounting. Card numbers never reach Wapito — Stripe holds them. | Firestore and Stripe | As long as tax law requires, typically seven years |
| Daily snapshots of the whole VM diskRecovery of the machine itself. A snapshot is a copy of everything on the disk when it was taken — the databases, the engine session files and the media files included — so something deleted on the VM can survive in a snapshot until that snapshot is deleted, 14 days after it was taken. | Google Compute Engine, United States | 14 days |
| Nightly backups of the Postgres databases and engine session files on the VMDisaster recovery only. Each copy holds what those databases and files held when it was made, the event buffer, the webhook jobs and the message history the engine keeps for a channel included, so something deleted there can survive in a backup until that copy is gone for good. Google deletes a copy on its own schedule, usually within a day of its 21st day, and it stays restorable for 7 more days after that: about 29 days in all. The last 7 days exist so that a backup deleted by mistake, or by an intruder, can still be restored. | Google Cloud Storage, us-central1 | 21 days, then 7 more days deleted but still restorable: gone for good about 29 days after it was made |
6. Who else processes it
Three processors, each doing one job under contract, and none of them permitted to use your data for their own purposes.
- Google Cloud and Firebase — Authentication, Firestore, Cloud Functions, static hosting and the virtual machine the API and engine run on. (https://firebase.google.com/support/privacy)
- Stripe — Subscriptions, payments and invoices. Card details are entered on Stripe and never reach Wapito. (https://stripe.com/privacy)
- Zoho Mail — Transactional email: connection alerts, trial reminders and billing notices. (https://www.zoho.com/privacy.html)
7. Where the data is
Our servers run in Google Cloud in the United States, Stripe is a United States company, and our email is sent through Zoho Mail's United States data centre. If you are in the European Economic Area, the United Kingdom or Switzerland, your data is therefore transferred outside your region; those transfers rely on the Standard Contractual Clauses or an equivalent mechanism in each processor's data-processing terms.
WhatsApp traffic necessarily also passes through WhatsApp's own infrastructure, which is operated by Meta and governed by Meta's terms rather than ours.
8. How it is protected
Tokens are stored only as SHA-256 hashes, webhook payloads are signed, database access is limited to the service and to the people who operate it, and secrets live in environment configuration rather than in the repository. The engineering detail, including what we deliberately do not claim, is on the security page.
The full technical description is on the security page .
9. Your rights
Depending on where you live, you have some or all of the following rights over the personal data we hold about you as controller: to know what we hold and get a copy of it, to have inaccurate data corrected, to have data erased, to restrict or object to processing, to receive your data in a portable format, and to withdraw a consent you have given.
Exercise any of them by writing to support@wapito.com from the address on the account. We answer within thirty days and we do not charge for it. Where you are asking about data we hold as your processor — the traffic on your channels — we will point you back to your own records, because those instructions are yours to act on.
If you think we have handled your data badly, please tell us first. You also have the right to complain to your local data protection authority.
11. Children
Wapito is a developer tool for adults. It is not directed at children, we do not knowingly collect data from anyone under eighteen, and an account found to belong to a child will be closed.
12. Changes to this policy
When this policy changes, the review date at the top changes with it, and a material change is announced by email or in the dashboard before it takes effect. The retention periods above are generated from the same configuration the retention jobs use, so they change only when the jobs do.
Draft — under legal review. This document was written by the Wapito team and has not yet been reviewed by a qualified lawyer. It describes how we actually operate and we intend to be bound by it, but wording and the governing jurisdiction may change before launch.