User keys
The identifier you pass to identify(), a device UUID generated by the SDK, an optional display name (user-set or suggested by your app), first and last seen timestamps, and the last SDK platform and version.
Data processing addendum
wandkit processes end-user personal data on your behalf. This page describes exactly what that data is, how long it is kept, and what erasure actually does. It is a draft, not an executed agreement.
Read this first
This addendum is written from the code and describes exactly what happens to end-user data. It is part of the beta terms from the moment you accept them; a countersigned copy is available on request.
- The processor is Flabbergast, a product studio in Zagreb, Croatia, inside the European Union. Croatian law governs, as in the beta terms.
- The sub-processors below are named, with the job each one does and whether it is in the path for every project or only when you connect it.
- We make no residency claim. Storage endpoint and region are deployment configuration, not a product guarantee. We are not claiming EU-only hosting, and we are not claiming Standard Contractual Clauses are in place, because neither is true today.
Everything else on this page is checked against the code as it stands today. If you need contractual cover before that work is finished, say so at info@wandkit.app and we will tell you honestly whether we can meet it yet.
Roles
You are the controller for your end users' personal data. wandkit is the processor, acting on your instructions: the API calls your app makes, and the settings you choose in the dashboard.
For your own dashboard account, wandkit is the controller. That covers your team members' names, email addresses, avatar URLs, organization membership and invitations. A sign-in record can also carry the IP address and user agent of the request that created it.
Your end users are the data subjects. wandkit has no ongoing relationship with them. Push is the only channel wandkit uses to send them a message outside your app, and only if you enable it: an automatic notice to a post author when their feedback goes live, plus any one-off push your team sends from the dashboard or with a server key.
You choose the identifier
The SDK stores whatever string you pass. If you pass an email address, wandkit stores an email address. If you pass an internal id, that is all we hold.
// A stable internal id keeps personal data out of wandkit. WandKit.identify("user_8f21c3")
Anonymous users are read-only. They can browse the board but cannot post, vote or comment. Until you call identify, a user is keyed by a UUID the SDK generates and keeps in UserDefaults on that device.
What wandkit processes
Device context
Platform, OS version, your app's version, device model identifier and locale, read when the SDK opens a board session and stored on the posts submitted from it. No advertising identifier is ever read.
Event log
Event name, the JSON properties your code attaches, the user key and device id, and occurrence and receipt timestamps. The properties are entirely yours, so what lands here is your decision.
Responses
Star ratings, thumbs, selected option ids and free text, tied to the user key that saw the survey. Free text is whatever the person typed.
Posts and comments
Post titles and bodies, threaded comments, votes, follows and reports, with author identity attached. Every SDK-created post is held pending until one of your team approves it.
Attachments
Images up to 10MB and video up to 50MB, five per post, held in an S3-compatible object store. They arrive through Apple's out-of-process pickers, so the SDK receives only the files the person selected. Screenshot bug reports are opt-in and re-render your own app window.
Device tokens
APNs device tokens with install id and registration timestamps, unlinked from the user on logout so a shared device stops receiving the old account's pushes. Apple is the only push transport. Android tokens can register but nothing is ever sent to them.
Install matching signals
User agent, language list, timezone and offset, platform, screen and viewport size, pixel ratio, client timestamp and IP address, captured on the landing page and again at install. This is browser fingerprinting. We are calling it what it is.
Reward grants
One row per user per reward campaign, holding the user key, the grant state (pending, processing, granted, failed or abandoned), the number of retries, timestamps, and the response returned by your entitlement provider. The reward configuration is copied onto the row when the grant is created, so a later edit to the campaign cannot change what an already-earned grant delivers.
Written only when a campaign pays outEntitlements
Read live from your own RevenueCat account with the key you supply, either when someone on your team opens that user's subscription view or when a reward campaign grants an entitlement to that user. wandkit stores no copy of the subscription state, only the grant record described under Rewards.
What wandkit does not do
- No AI or machine learning of any kind. There is no AI dependency in the SDK, the API or the dashboard, so there is no model to train on your data and no automated inference over it.
- No advertising identifiers. The SDK never reads the IDFA and never triggers a tracking permission prompt.
- No library-wide photo access. Attachments come back from Apple's own picker, which runs outside your process and returns only what the person chose, and the screenshot flow redraws your own window inside it. Neither asks for a photo-library permission.
- No analytics product today. There are no funnels, cohorts, retention curves or cross-project profiles. Behavioral event analytics is coming and is not built, and this page will be updated to describe what it processes before it ships. The only aggregate kept right now is a per-user, per-event-name counter, and it exists solely to fire the Nth-occurrence survey trigger.
- No sale of data, and no sharing beyond the sub-processor categories below.
Retention
Four windows are enforced by a cleanup worker on a schedule. Reward grant rows are not on one of them and fall under the catch-all below. These are the values in the code today.
- Referral landing-page fingerprints: deleted after 7 days.
- Referral install match attempts: deleted after 14 days.
- Push devices not refreshed by an app launch: deleted after 90 days.
- Attachment upload slots never attached to a post: deleted after 24 hours, object first, row second.
Expired authentication tokens are cleaned on the same pass, as are invitations that have reached a terminal state, on a window that defaults to 90 days and is set at deploy time. Everything else is kept for the life of the project. Deleting a project removes its rows by cascade, though stored attachment objects are not swept with them today. There is no configurable retention policy yet, and no automatic expiry on events, responses or board content.
Erasure, and the part it does not cover
An organization admin can erase one end user from the dashboard. It runs in a single transaction, because a half-finished erasure is worse than none.
- Posts and comments have their authorship cleared. The text stays, so threads other people contributed to remain readable.
- Votes, on posts and on comments, and follows are rewritten to one fresh placeholder per erasure call. The counts stay correct and nothing points back to the person.
- That user's reports, ban record, push devices and directory row are deleted outright.
It does not reach every table that holds the identifier. Raw event rows, the per-event-name counters, survey responses, and referral and reward-grant rows all still carry the user key you passed to identify(). If you need those removed, that is a manual operation on our side today. Ask at info@wandkit.app. A self-serve path for it is not built.
We are stating this because a compliance report that overstates what happened is worse than one that admits a gap.
Sub-processors
Every service that can touch end-user data, with the job it does. Processing region is set when the service is deployed; ask and we will tell you the current one.
Infrastructure
A PostgreSQL host for all structured data, Amazon Web Services for the S3 object store that holds attachments, application hosting for the API and dashboard, and a telemetry collector receiving OpenTelemetry traces, metrics and logs.
Endpoint and region are set at deploy timePlatform services
Resend for dashboard email, sent from noreply@wandkit.app. Apple Push Notification service for iOS push. Google sign-in, which is the only way into the dashboard.
No email or SSO alternative is wired upYour outbound integrations
Slack and Discord webhooks for the 16 event types you can toggle. RevenueCat for entitlement lookups and reward grants. App Store Connect and Google Play for the releases board and store reviews.
Configured per project, with your own credentialsNotice and objection
Before a new sub-processor touches end-user data, every beta team gets an email at least 14 days ahead naming it and what it will do. Reply to object. If we cannot resolve the objection, you can end the beta and we erase your project.
Sent to the address on your organizationSecurity measures actually in place
- Three key types with separate scopes: wk_ for the SDK, wks_ for server-to-server calls, wkp_ for personal access tokens, which are scoped, expiring and revocable.
- Third-party credentials you store, such as an APNs signing key or a RevenueCat key, are encrypted at rest with AES-256-GCM under a server master key. Only the last four characters are ever displayed back.
- Every dashboard query is scoped by project id. A user key belonging to another project reads as not found, never as someone else's data.
- Pre-moderation on every SDK-created post is mandatory and cannot be switched off. Nothing an end user writes becomes visible without a team member approving it.
- Erasure, bans and report handling are limited to organization admins.
And what is not
No SOC 2 or ISO certification. No published penetration test. No uptime SLA, and the metrics endpoint is a stub. No admin audit log. No SSO, SAML, SCIM or MFA. If any of these are a hard requirement for you, wandkit does not meet them today.
Still open
- The hosting region as a written guarantee, and a transfer mechanism if data ever leaves the EEA.
- A breach notification window and the contact route for it.
- A security schedule that matches what is implemented, not what is aspired to.
- Deletion or return of data at the end of the agreement, including how backups are handled.
- Which side answers end-user data subject requests, and the tooling gap noted above.
Send comments, or the version your counsel needs, to info@wandkit.app. That is the only monitored address. There is no sales@, support@ or security@ inbox.