Account and profile data
Email, username, display name, bio, avatar, location, website, timezone, profile visibility settings, memberships, and linked public-profile state.
Privacy
Clear about what we collect, how we use it, and what happens when you delete it.
Hubbaly is built around communities, events, attendance, and durable records. This page explains the data the product uses to run those workflows, the privacy controls built into the platform, the third parties that support the service, and the narrower retention exceptions that still apply after account deletion.
What Hubbaly collects
The product stores the data it needs to run communities, events, trust, and support workflows.
That data is not one single bucket. Different parts of the codebase store different classes of records for identity, event operations, moderation, payments, and delivery.
Authentication and security data
Password hashes, session records, refresh-token hashes, hashed session IPs, user-agent summaries, password reset and email-link tokens, Google SSO identities, passkeys, MFA factors, and backup codes.
Communities, events, and tickets
Community roles, share links, invites, membership requests, events, ticket orders, ticket transfers, guest attendee names/emails, purchases, refund workflows, and calendar subscriptions.
Content, moderation, and support
Chat messages, reactions, mentions, photo uploads, tags, reports, takedown requests, incident records, moderation history, and admin audit records.
Forms and verification
Document signatures can store signer name, rendered content snapshot, structured answers, IP address, and user agent. Optional member verification can store legal name and a private verification photo.
Payments, notifications, and analytics
Order and payout records, Stripe reference IDs, email delivery and suppression state, push subscription/device identifiers, notification preferences, and first-party product analytics events.
Use and visibility
Hubbaly uses data to run the product, secure it, and enforce privacy inside the product itself.
How we use data
- Run accounts, communities, events, tickets, guest flows, chat, photos, and support workflows.
- Authenticate users and protect accounts with sessions, SSO, passkeys, MFA, audit trails, and abuse-prevention controls.
- Process payments, organiser payouts, refunds, disputes, resale flows, and finance reporting.
- Deliver in-app alerts, transactional emails, push notifications, secure ticket links, and password or sign-in recovery links.
- Moderate content, review reports and incidents, enforce platform or community policies, and preserve restricted evidence when safety or legal review requires it.
- Measure product usage and troubleshoot issues through first-party analytics, delivery telemetry, and operational logging.
How visibility works in-product
- Profile pages, uploaded avatars, memberships, and profile photos follow the user's visibility settings plus relationship context such as shared communities or accepted connections.
- Hub and event discovery follows community visibility, join policy, event visibility, ticket access, and role-based access gates.
- Attendee surfaces, tagged photos, albums, verification details, and moderation tools each have their own role and visibility checks.
- For privacy-sensitive resources, Hubbaly often returns Not found instead of confirming existence with Forbidden.
Cookies, browser storage, and analytics
Auth lives in cookies. Product state and first-party analytics also use browser storage where appropriate.
Storage and analytics details
- Auth uses HTTP-only access and refresh cookies. Optional Google SSO uses a signed state cookie, and passkey login uses a short-lived challenge cookie.
- The web proxy also uses short-lived beta and admin verification cookies to avoid repeating access checks on every navigation.
- The web app uses browser storage such as localStorage and sessionStorage for non-auth state including theme choice, active-hub selection, join-request drafts, scanner device ID, help return state, chat UI/cache state, and a visitor analytics preference when you choose to disable that measurement.
- Hubbaly uses aggregate audience-measurement analytics on public hub and guest-ticket pages for first-party service improvement, and this page provides a simple way to disable visitor analytics. Those visitor analytics do not create separate consent-state storage, persistent public-hub variant labels, or guest-ticket session markers in your browser.
- Authenticated product telemetry such as help, chat, and account-photo analytics is a separate internal analytics surface and can still create short-lived first-party session identifiers where the product needs them for troubleshooting or UX integrity.
- Payment card entry is handled by Stripe Checkout and Stripe Connect onboarding surfaces. Hubbaly stores the resulting order, refund, dispute, payout, and Stripe reference records rather than raw card details.
Visitor analytics preference
Hubbaly uses aggregate audience-measurement analytics on public hub and guest-ticket pages to understand visits, spot broken journeys, and improve those flows. This page gives you a simple way to disable visitor analytics if you object.
These visitor analytics stay first-party and service-improvement only. They do not create separate consent-state storage, guest-ticket session markers, or persistent public-hub variant labels in your browser.
Current setting: Loading saved setting….
External processors and infrastructure
Some workflows rely on specialist processors and hosting providers.
The current codebase is explicitly wired to the following categories of services.
Stripe
Checkout, organiser connected-account onboarding, payouts, refunds, disputes, and related payment references.
Google services
Optional Google SSO for sign-in and optional Google Places lookups for event-location search when configured.
OpenStreetMap Nominatim
Fallback location lookup when Google Places is not configured or returns no match.
Postmark
Transactional email delivery, webhook telemetry, suppression handling, and delivery status correlation.
OneSignal
Push notification delivery using synced subscription IDs and user alias targeting.
Hosting and storage
Vercel for the web app, Hetzner for API hosting and S3-compatible object storage, and Neon for PostgreSQL data storage.
Sentry
Environment-configured error monitoring and release/source-map support in deployed API and web environments where Sentry is enabled.
Account deletion
Account deletion removes profile and sign-in data from active systems.
Deleting your account signs you out everywhere and removes your profile and sign-in data from active systems.
That includes the live account identity people use to reach you in the product: email sign-in, profile details, live memberships, and active account access.
Chat media you sent is removed from normal chat immediately when you delete your account.
Payments and compliance
We may keep records needed for payment, refund, dispute, tax, and accounting obligations when deleting a live account would leave those obligations unsupported.
Security and abuse prevention
We may keep limited security records where we still need them to investigate fraud, abuse, policy violations, or platform safety issues.
Restricted abuse evidence
If someone reports removed media or a manually deleted message, we may keep a short-lived restricted evidence copy so moderators can review the report, resolve the case, and meet legal or safety obligations.
Backups
Deleted data is removed from active systems first. Backup copies may persist until the backup set naturally expires and are not kept as a live account workspace.
Chat history and evidence
Text messages may remain in conversation history with your sender anonymised so the thread still makes sense to the people who were already part of it.
If someone who previously had access to removed media later reports it, or if a message was manually deleted before it was reported, that evidence can move into a restricted moderator-only review path and then a short follow-up retention window before purge.
Where moderation or legal review requires it, that restricted evidence can preserve sender identity and previous usernames tied to the account history.
Identity after deletion
Current and previous usernames stay reserved permanently so someone else cannot later inherit the same public identity.
Your old email address can be used to create a fresh account later, but that fresh account does not restore the deleted account history.
If we retain any records after deletion, they are kept only for payment, refund, dispute, tax, security, and backup reasons, not as a restorable live profile.
Questions
Need help with deletion or privacy questions?
Use the Help Center for product-specific workflows, and contact us directly if you need support on a deletion, privacy, moderation, or data-handling question tied to your account.