Your data in Greebl
Privacy Policy
Draft updated
Your account and sign-in
Greebl uses Supabase Auth to create and manage accounts. Supabase processes your email address, account identifier, passwords submitted for sign-up or sign-in, and authentication requests.
Access and refresh tokens keep you signed in and authenticate app requests. On iOS and Android, the app stores its session using the device’s secure storage. The app’s browser version uses browser local storage. Passwords are not included in that saved session.
Signing out clears the saved session. Temporary connection failures may keep it so you can retry. Password recovery uses a separate, temporarily stored verification value on your device; the recovery session stays in memory and does not replace your normal sign-in session.
Compromised-password checks
During sign-up and password reset, Greebl checks eligible passwords against Have I Been Pwned (HIBP) Pwned Passwords. The check sends only the first five characters of a SHA-1 password hash and compares the response on your device. It does not send your password, full hash, email, account ID, or session tokens to HIBP.
HIBP receives ordinary connection information, such as your IP address and User-Agent. The check does not save or log password-derived data in the app. HIBP’s own retention practices remain subject to review.
Your collection and catalog searches
When connected to Greebl’s backend, Supabase stores your shelf items, build status, favorites, and collection preference for whether built sets contribute available parts. You can change your preference and update or remove shelf items. Local preview collection data stays in memory.
Catalog queries and filters are sent to Greebl’s Supabase-backed search service. The app does not persist them as a search-history feature; this does not determine what ordinary infrastructure logs may contain.
Shared catalog and inventory reference data is imported from Rebrickable. The implemented catalog search uses Greebl’s catalog rather than sending your search query or account identity directly to Rebrickable.
AI Mix requests, results, and reports
Supabase processes and stores your selected shelf items, category, difficulty, size, optional colors, and request identifiers, together with generation status, timestamps, and successful results. Account-linked plan and daily quota records control generation access. A separate daily capacity count covers the service overall without a user identifier.
To generate an idea, Greebl sends a limited prompt from its server to Groq. It includes category, difficulty, size, selected colors, source-set titles and piece counts, and up to 120 inventory candidates with part numbers, names, colors, and available quantities. The prompt excludes your email, account ID, authentication tokens, collection item IDs, catalog image URLs, and quota counters.
The Groq request asks for the response not to be stored by setting store: false. That request setting does not establish Groq’s contractual retention, logging, or other operational practices; those still require review.
Successful concepts are stored in Supabase. Saving an AI Mix in backend mode creates an account-linked saved relationship to that result. Removing a Saved Mix removes that relationship, rather than deleting the generation record. Local preview saves may exist only in the current app session.
If you use Report Result, Supabase stores your account ID, the generation ID, selected reason, optional note (up to 500 characters), review status, and submission time. Reports may be reviewed for moderation and debugging. The implemented report flow does not send reports to Groq or Rebrickable.
Build Projects and other local data
Build Projects are stored on your device, separately from the account’s server data. They include source identity, title, build status, timestamps, and limited visual information. This storage service does not send those records to a third-party backend.
Local app-data controls can clear Build Projects. Deleting your server account does not clear them. Bundled examples and local preview profile, Ideas, collection, and social data are also separate from account-owned server records.
Sharing an idea
When you choose Share for an AI Mix, its title, source-set titles, and a short description are passed to your device’s share sheet, the browser’s sharing facility, or a clipboard fallback. Your chosen destination may receive that text. Greebl does not implement a sharing backend. Server account deletion does not clear your clipboard or copies held by a destination you selected.
Deleting your account
Use Delete Account in the app to request permanent account deletion. After successful deletion, the Auth account and linked server records are removed, including shelf items (also soft-removed items), collection preferences, AI Mix generations, saved relationships, entitlements, per-user quota records, and result reports. The app clears its saved sign-in session. If deletion fails, the session is kept so you can retry.
Shared catalog data and the service-wide capacity count remain because they are not owned by your account. Device-local Build Projects, local preview data, and shared copies have separate controls. This account-deletion behavior does not establish deletion or retention guarantees for provider logs or backups.
The current account-deletion flow does not make a separate request to delete previously delivered PostHog analytics or Sentry diagnostics, or automatically clear the device-local analytics identifier. Provider-side retention and deletion arrangements still need final review.
This website
Greebl’s website code does not use JavaScript, analytics, advertising, trackers, cookies, or third-party page resources. Hosting services may process ordinary connection information and may operate according to their own infrastructure practices.
Product analytics: PostHog
The native app includes PostHog product analytics to help understand use of Greebl, activation, build coverage, and product failures. Delivery depends on the build’s settings: it is disabled in development and the app’s browser version, and native preview or production builds send events only when PostHog is explicitly enabled with the required configuration and an available client.
Events describe interactions such as opening the app, completing onboarding, searching the catalog, changing collection status, viewing build possibilities, generating or saving an AI Mix, and updating Build Projects. They can include counts, statuses, search-query length, generation settings, quota measurements, and the catalog identifier of an opened candidate.
The primary analytics identifier belongs to the app installation and is stored locally on your device. It remains the same across sign-in and sign-out. Events can also include an opaque account ID when available, session and event identifiers, timestamps, app version/build, platform, locale, sign-in state, and plan. An installation identifier does not mean authenticated events cannot be associated with your account.
The current analytics contract excludes raw search text, AI prompts and generated content, emails, passwords, authentication tokens, report notes, receipts, full collection or inventory lists, missing-parts lists, instruction URLs, and images. The app sends defined interaction fields and aggregate measurements instead. PostHog’s automatic lifecycle capture and session replay are disabled; Greebl explicitly records its own app-opening events.
The PostHog integration is implemented and configuration-gated. This draft does not claim that PostHog delivery has been verified in preview or production, or that PostHog is active in every build.
Technical diagnostics: Sentry
The native app separately includes Sentry to report unexpected technical errors and help diagnose problems. It is disabled in development and the app’s browser version. Native preview or production builds use Sentry only when explicitly enabled with valid configuration; otherwise reporting falls back to a disabled provider.
Diagnostics can include exception types and stack frames, app version, build number, environment, platform, and limited context such as an operation, safe error code, status, or aggregate count. When you are authenticated, the app attaches only your opaque account ID as its user context. That context is cleared when you sign out or become unauthenticated.
The integration disables automatic personal-information collection, removes request metadata, replaces raw error messages with redacted text, and filters and limits diagnostic context. Emails, passwords, tokens, prompts, generated content, report notes, receipts, inventory or collection payloads, and request bodies or headers must not be attached. Only Greebl-defined diagnostic breadcrumbs are retained.
Screenshots, view hierarchy, automatic failed-request capture, tracing, profiling, and session replay are disabled. These safeguards describe the app’s configuration; they do not establish what connection information a provider receives or how long it retains information.
Android Preview diagnostic delivery and JavaScript source-map symbolication (mapping an error back to app source) were verified. Production delivery, iOS delivery and symbolication, and native crash delivery remain unverified.
Retention and details still under review
A final retention schedule has not been established for accounts, removed shelf rows, generation records, aggregate capacity data, PostHog analytics, Sentry diagnostics, or operational logs. Provider data locations, subprocessors, contractual roles, retention, and deletion practices also remain under review. The current file-storage setup is an implementation detail rather than a permanent promise about future releases.
The developer’s legal identity, launch markets, age eligibility, and applicable regional rights and request procedures must be finalized before public release. These decisions will be reflected in the reviewed policy. The draft update date above records this version; it is not a finalized effective date.
Questions about your data
Contact support@greebl.app with privacy questions. Do not send passwords, session tokens, recovery codes, or other credentials.