1. Who we are
For the purposes of the EU General Data Protection Regulation ("GDPR"), the data controller responsible for your personal data is [Legal entity name], [legal form], registered at [registered address], company/ registration number [registration number], tax number [tax number] ("we", "us"). You can reach us about privacy matters at [privacy@codeblockstudio.net].
2. Data we collect
We collect the following categories of personal data:
| Category | Examples | Source |
|---|---|---|
| Account data | Name, email address, hashed password, sign-in method (email/password or Google), profile settings | You, or Google if you use Google sign-in |
| Security data | Two-factor authentication (TOTP) setup, session and login history, IP address at sign-in | Automatically, when you use these features |
| Payment data | Billing name/address, subscription plan and status, truncated card details (e.g. last 4 digits). We do not receive or store your full card number, it is handled directly by Stripe. | You, via Stripe |
| Project content | Projects, code, block configurations, uploaded images/ assets, and (only if you choose to add them) third-party API keys/secrets, Discord bot tokens, or Telegram bot tokens used inside your own projects | You |
| Your published project's visitor/end-user/member/respondent/device data | If you build and publish a Website or Web Application, blocks you choose to add to it (Form, File Upload, Booking, Live Chat, Blog comments, Data Table/Kanban/Calendar/Comments, or a Web Application's own end-user accounts created via its Login/Signup Form blocks) may collect personal data about your own visitors, for example a booking's name/email/time, a chat message, an uploaded file, or an end-user's account email. Any image an end user or visitor uploads is automatically resized, compressed, and converted to a smaller format before storage, purely a technical optimization, we do not look at or analyze the image itself. A Web Application's Account Security block may additionally store, for that same end user, a passkey's device label and usage timestamps (never the passkey itself, only metadata about it), an end user's own API key (stored as a hash, like a password, so we cannot read the original key back), and session/device metadata (a hashed IP address, browser user agent string, and last active time) used to show that end user their own signed in devices and let them sign out of any of them. A Push Notifications block, if that end user turns notifications on, stores the browser generated subscription needed to deliver a notification to that device, and is removed automatically once the browser reports it is no longer valid. A Live Chat block stores the messages sent in a room, and a Presence Indicator or an @mention inside a Comments block stores who is currently viewing a page or was mentioned, each purely to display that feature back to your other end users. If you turn on the Organizations block, an end user creating one or inviting someone else stores the organization's name, who created it, and each member's role, and an invite stores the invited email address and role until it is accepted or expires. If you build and publish an API, its Database Query blocks or a stored collection may hold data submitted by your own callers. If you connect a Discord Bot, its commands, events, and the modules you enable (for example Leveling, Economy, Warnings, Audit Log, Invite Tracker, or the anonymous Confessions board) may store data about your own server's members, such as a Discord user ID, roles, or message content. If you connect a Chat Bot to Telegram, the flows you build may similarly store data about the people who message your bot, such as their Telegram user ID, username, or message content, in the variables or records your flow chooses to set. If you build and publish a Form Builder form, every field a respondent fills in and submits is stored as their response, for you to view or export, for example their name, email address, or any other answer your fields ask for. If you build and publish a Desktop or Mobile Application, blocks like Local Data Table/Local Record Form, Camera, Location, QR Scanner, or its own local Login Form/Signup Form/Change Password Form accounts store data on that installed copy's own device, we never receive or see it, unless you add your own Call API action to send it somewhere. On a Website project, a Resource Download block set to require an email address stores that visitor's email as a lead for you, and a Reviews block stores a visitor's own submitted name, star rating, and review text, held as pending until you approve or reject it, only an approved review is ever shown back to other visitors. We process this data only as your service provider, to run the feature you configured; you, not us, are the controller responsible for it, see Section 3 and our Terms of Service. | Your project's own visitors, callers, server members, Telegram bot users, form respondents, or installed copies, not you |
| Web Application admin & reliability data | If a Web Application project owner uses the "view as user" (impersonation) tool to sign in as one of their app's own end users for troubleshooting, we log who was impersonated, by which project owner, and when, in a dedicated record that owner cannot turn off or delete. If a project owner defines feature flags or turns on maintenance mode, we store the flag keys/values or maintenance message they set. If a published Web Application encounters a client side error, its page automatically reports the error message, a stack trace, and the page it happened on to that project's own error log, so the owner can see and fix it, this never includes anything you typed into a form. A general audit log also records other sensitive in-app actions (for example promoting an end user to admin, or changing a collection record from the admin surface), each entry attributed to either the project owner or the end user who performed it. | Automatically, from a project owner's or end user's own actions inside a Web Application |
| Desktop app crash reports | If you turn on crash reporting for a Desktop Application, an installed copy that crashes sends us the OS platform and app version (never the crash's actual contents) so we can show you a crash count, along with the hashed IP address of the device that sent it, kept only briefly to rate-limit this endpoint. | Your project's own installed copies, not you |
| Marketing preferences | Whether you've opted in to receive product update emails | You, via a signup checkbox or your Profile page |
| AI Assistant usage data | If you use the optional AI Assistant add-on: your prompts/ questions and your project's current structure (for Chat, a summary of its blocks/pages or, for a Discord Bot, REST API, or Chat Bot project, its blocks and how they're connected; for Generate, the full current structure so it can be edited, extended, or replaced according to your request) are sent to our AI provider, Anthropic, to generate a response. For a Discord Bot, REST API, or Chat Bot project, only the one command/event/module/endpoint/flow you currently have open is sent — never the whole project at once. Chat messages (yours and the assistant's replies) are saved so the conversation is still there next time you open the same project (or, for a Discord Bot/REST API/Chat Bot project, the same command/event/module/endpoint/flow) — we also keep a token-usage count and timestamp per request, to enforce the add-on's usage limits, see Section 3. | You, when you use the AI Assistant |
| Usage & technical data | IP address, browser/device type, pages viewed, error logs, timestamps | Automatically, from your device |
| Cookie data | See Section 4 | Automatically, per your cookie choices |
| Support communications | Emails or messages you send us, and our replies | You |
Third-party secrets you add to a project (for example a payment provider's secret key, a Discord bot token, a Telegram bot token, or your own API key for a Discord Bot integration such as Riot Games) are encrypted at rest and used only to run the automations/integrations you configured. Treat them as your own responsibility to keep valid and scoped correctly, see Section 10 of our Terms of Service.
3. How we use it & legal basis
Under the GDPR, we may only process personal data when we have a valid legal basis. Here is how each purpose maps to a basis:
| Purpose | Legal basis |
|---|---|
| Creating and running your account, saving and rendering your projects | Performance of a contract with you |
| Processing subscription payments and billing | Performance of a contract with you; legal obligation (tax/accounting records) |
| Account security (2FA, suspicious-login detection, abuse prevention) | Legitimate interest (keeping accounts and the Service secure) |
| Responding to support requests | Performance of a contract with you; legitimate interest |
| Optional cookies (preferences, analytics, marketing) | Consent, see Section 4 |
| Providing the optional AI Assistant add-on (in-editor chat, structure/workflow generation) | Performance of a contract with you (for add-on subscribers); legitimate interest in enforcing fair-use limits and preventing abuse |
| Sending marketing/product update emails (only if you opt in) | Consent, withdrawable at any time from your Profile page |
| Sending essential service emails (verification, password reset, billing receipts, security alerts) | Performance of a contract with you; legal obligation |
| Product improvement and aggregated statistics | Legitimate interest (kept in a form that does not identify you where possible) |
| Complying with legal obligations (e.g. responding to a lawful request) | Legal obligation |
We do not sell your personal data. If you use the optional AI Assistant add-on, the prompts and project-structure summaries described in Section 2 are sent to Anthropic solely to generate a response to you, on the same request/response basis as any other feature you actively use, not for any advertising purpose, and we do not otherwise use your project content to train any third-party AI model.
If your published project collects data from other people (for example a Website or Web Application's Form, File Upload, Booking, Live Chat, or Blog comment block, or its own end-user accounts and data collections; an API project's Database Query blocks or stored collections, including an OIDC Login block you add to let your API's own visitors sign in with Google or another OpenID Connect provider, which verifies an incoming sign in token and can expose that visitor's email, name, and provider account id to the rest of your endpoint's logic, for example to store a record scoped to that visitor; a Discord Bot project's commands, events, or modules, such as Leveling, Economy, Warnings, moderation notes, Audit Log, Invite Tracker, Event RSVP, ModMail, a custom profile, marriage status, reputation, or Confessions, including the content of a direct message a member sends your bot, if you enable a feature that reads one; a Chat Bot project's flows, including the content of a message a person sends your Telegram bot and any variable or record your flow chooses to store about them; a Form Builder project's published form, every response a person submits to it; or a Desktop Application's crash reporting, if you turn it on), you, as the project's owner, are the data controller for that data under the GDPR, you decide why it's collected and what happens to it. We act only as your processor: we host and run the block or module you configured, and do not otherwise use, share, or act on that data ourselves beyond what running the feature requires (for example, the anti-abuse rate-limiting and spam checks described elsewhere in this Policy). If you use these features, you are responsible for having your own lawful basis and, where required, your own privacy notice for the people affected, and for responding to their own requests to access, correct, or delete their data, see Section 8 of our Terms of Service. A Web Application's Account Security block gives an end user a self service way to do this directly: "Export my data" downloads that end user's own account details, every record they own across every collection in your app, and their session and passkey metadata, as one file; "Delete my account" permanently removes the account after confirming their password, and every record, session, and passkey belonging to that account is removed along with it. Neither of these tools removes data about that end user stored elsewhere in your project by other means (for example a Form submission that references them by name rather than through their account), so you may still need to act on a request yourself in those cases.
Data your Desktop or Mobile Application collects on its own device (for example the Local Data Table/Local Record Form, Camera, Location, or QR Scanner blocks, or its own local Login Form/Signup Form/Change Password Form accounts, hashed and checked entirely on that device) stays on that installed copy's own device. We never receive, host, or process it, so we are not a party to that data at all, unless you add your own Call API action to send it somewhere yourself.
If your published Website uses an Embed or Custom Code block, whatever you put there (a third-party embed URL, or your own HTML/CSS/JS) runs directly in your visitor's browser when they view that page. A Custom Code block runs inside a sandboxed frame with no access to your site's cookies, storage, or other blocks, but any network request the code itself makes still goes wherever you pointed it, we don't see or control that traffic. You are responsible for choosing content you trust and for disclosing it to your visitors if it collects their data.
6. International transfers
Some of the providers listed in Section 5 process data outside the European Economic Area (for example in the United States). Where this happens, we rely on an adequacy decision by the European Commission or, where one does not apply, on Standard Contractual Clauses and additional safeguards required by the GDPR. Our primary hosting regions are [to be confirmed, e.g. Supabase project region / Vercel edge regions].
7. How long we keep data
We keep your account and project data for as long as your account is active. Deleting your account from your Profile page deactivates it immediately, you can no longer sign in, and the email address cannot be used to register a new account in the meantime, and starts a 3-day grace period before your projects and account are permanently deleted. This window exists so a mistaken deletion, or one made by someone who gained unauthorized access to your account, can still be reversed: contact [support@codeblockstudio.net] within those 3 days. After the grace period, deletion is permanent and cannot be undone, except for:
- billing and invoice records, which we keep for as long as required by applicable tax/accounting law (typically several years);
- data we must keep to comply with a legal obligation, resolve a dispute, or enforce our agreements;
- routine backups, which age out on their own retention schedule and are not actively restored except for disaster recovery.
Technical/security logs are kept for a shorter period, typically no more than [90] days, unless needed longer to investigate a specific security incident.
8. Your rights
If the GDPR applies to you, you have the right to:
- Access the personal data we hold about you;
- Rectify inaccurate or incomplete data;
- Erase your data ("right to be forgotten"), subject to the retention needs in Section 7;
- Restrict or object to processing based on our legitimate interest;
- Port your data to another service in a structured, machine-readable format;
- Withdraw consent at any time for anything we process based on consent (e.g. optional cookies), without affecting processing done before the withdrawal;
- Lodge a complaint with a supervisory authority, see Section 12.
Most of the data we hold about you is directly visible and editable from your account settings, including your name, email, connected sign-in methods, and cookie choices. For anything else, contact us at [privacy@codeblockstudio.net], we will respond within one month, as required by the GDPR.
9. Security
We use industry-standard safeguards, including encryption in transit (HTTPS) for all traffic, encryption at rest for third-party secrets you store in a project and for two-factor authentication data, hashed (never plaintext) passwords and end-user API keys, and access controls limiting who can reach production data. A Web Application project owner's use of the "view as user" tool described in Section 2 is always logged in a record that owner cannot turn off or delete, so there is an audit trail if it is ever misused. No method of transmission or storage is 100% secure, but we work to protect your data and to respond quickly if something goes wrong.
10. Children's privacy
The Service is not directed at children under 16, and we do not knowingly collect personal data from them. If you believe a child has provided us with personal data, contact us at [privacy@codeblockstudio.net] and we will delete it.
11. Changes to this policy
We may update this Privacy Policy from time to time. If a change is material, we will notify you (by email and/or in-app) before it takes effect. The "Last updated" date at the top of this page always reflects the current version.
12. Contact us & complaints
Questions or requests about this Policy can be sent to [privacy@codeblockstudio.net], or by post to [registered address]. Our Help Center also answers most common questions about how the Service works.
If you are in the EU/EEA and believe we have not handled your personal data lawfully, you have the right to lodge a complaint with your local data protection authority. In Hungary, this is the National Authority for Data Protection and Freedom of Information (Nemzeti Adatvédelmi és Információszabadság Hatóság, "NAIH"), 1055 Budapest, Falk Miksa utca 9-11, naih.hu.