What wandkit stores, why it stores it, and how long it keeps it. Written against the code, with the gaps named rather than papered over.
wandkit is operated by Flabbergast, a product studio in Zagreb, Croatia. Flabbergast is the controller for this website and for dashboard accounts, and the processor for the end-user data your app sends, on the terms in the data processing addendum. This page describes what the SDK and the dashboard actually do with data today, written against the code, and it is kept in step with the code as the beta moves.
An earlier version of this page said wandkit generates AI suggestions inside your own workspace. That was never true. There is no AI or machine learning processing in wandkit anywhere. No model, ours or a third party's, receives your data, your users' events or their feedback.
Questions, corrections, or a request about data we hold: info@wandkit.app. It is the only address that reaches us.
Everything the SDK sends is scoped to one project. An API key belongs to a single project, and the board and erasure queries are filtered by that project's id, so an action in one project cannot reach another's rows. Account and organization data sits above projects. In the intended arrangement you are the controller of your end users' data and wandkit is the processor acting on your instructions. That relationship is set out in the data processing addendum, which is part of the beta terms.
Your email address, your name and a profile picture URL, taken from the Google account you sign in with. Google Sign-In is the only method the dashboard offers. Alongside it: your organization, your role in it, and the invitations you sent or accepted.
Google is the identity providerThe event name your app calls, the properties your app attaches, when it happened, the SDK platform and version, the install id, and your own user id once you call identify(). wandkit never invents an event. It stores what you send, so the properties are your decision to make.
Plus a per-user, per-event-name counterStar ratings, thumbs, selected options and free text, tied to the user who answered and the form that asked. Free text is whatever your user typed, so treat that column as capable of holding anything at all.
Exportable as NDJSON from the CLIPosts, threaded comments, votes, follows, reports and display names, plus image and video attachments (10 MB per image, 50 MB per video, up to five per post). Each post also carries device context recorded at submit with no separate prompt: platform, OS version, your app's version, device model and locale. Every post created through the SDK is held pending until a team member approves it.
Pre-moderation cannot be turned offThe APNs token, the install id, the device id, the platform, and your user id once identify() has run. logout() detaches that id from the device, so a shared phone stops receiving the previous account's notifications.
Apple Push Notification service onlyIf you connect RevenueCat, opening a user profile sends that user's id to RevenueCat and displays what comes back. Nothing about the subscription is written to our database, so there is no stale copy to leak or to erase.
Read live, never storedA referral link opens a hosted web page, which records device signals from the browser. On first launch your app can send a comparable set, and the backend scores the two against each other to work out which visit became which install. When a campaign pays out, wandkit also stores the reward grant, the state it is in, each retry, and what the entitlement provider returned. Full field list below.
Includes the IP addressA user profile shows sessions, but no session is stored anywhere. They are computed at read time by grouping that user's event timestamps into runs with no gap longer than 30 minutes, over a 90 day window. Close the page and they cease to exist.
Computed, not recordedThis is the part of wandkit that most resembles tracking, so here it is without abbreviation. It runs in two places: on the hosted referral landing page in the browser, and once per install if your app calls the detection method after configure. Its only job is to credit an install to the person who invited it. It is not marketing attribution and it does not follow anyone across other apps or sites.
The landing page record is attached to the referral link that was opened. The install-side record is attached to the install id, and keeps the score and, where one was found, the referral it matched.
Landing page records are deleted seven days after they arrive. Install match attempts are deleted after fourteen. The match is a score, not a certainty, and a wrong match costs an inviter a credit rather than exposing anything.
A worker runs on a fixed interval and deletes by age. These are the horizons in the code, not intentions:
Events, survey responses and board content have no automatic expiry today, and there is no setting that would give them one. Deleting the project is the only thing that removes them in bulk: that cascades across every table, but it does not currently sweep attachment files out of object storage. Both gaps are named again below rather than quietly left out.
The dashboard has a right to erasure action. An organization admin runs it against one project and one of your user ids. It is a single transaction, so it either completes or changes nothing, and it reports back what it touched.
You get back a count for each category, which is what you would attach to a compliance record.
What erasure does not reach, stated plainly, because a compliance record built on the assumption that it does would be wrong. The raw event log and its per-event counters are untouched. So are survey responses and their answers, and so are referral match attempts and reward grant records. Those rows are keyed by an internal user key that contains the id you passed to identify(), so the identifier survives in them. Attachment files the user uploaded also stay in object storage, since the posts holding them survive as anonymized rows. Closing this is the first item in the missing list below. Until it is closed, a full erasure means running the action and then deleting the project, or removing those rows yourself.
There is no equivalent one-user export yet. Today you can export a form's responses as NDJSON from the CLI and filter them yourself.
Which hosting provider and which storage bucket those run on is deployment configuration rather than something the code names, so this page cannot yet list them with the precision a sub-processor list needs. Producing that list is part of the work below.
Naming the gaps is more useful than implying they are handled.
info@wandkit.app reaches us, and it is the only address that does. sales@, support@, hello@ and security@ do not exist. If you are an end user of an app built with wandkit, the fastest route is that app's developer: they hold the account you are asking about and they can run the erasure themselves. We will help them do it.