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.

Last updated: 21 May 2026

Controller and lawful bases

Hubbaly explains who controls data and the Lawful bases for using it

Privacy notice basics

  • Chicken House Labs Ltd, trading as Hubbaly, is the data controller for platform account, security, payment, support, safety, transactional communication, and product-operation processing.
  • Organisers and community admins may act as separate data controllers for event and community data they decide to collect or require. Hubbaly may act as processor for that organiser-controlled data under documented instructions and a Data Processing Addendum.
  • Contact privacy@hubbaly.com for privacy, data protection, DPA, or individual-rights requests. If we appoint a separate statutory data protection officer, we will publish that contact here.
  • Most data comes directly from you when you use Hubbaly. We may also receive data from organisers, community admins, event staff, guests, payment providers, sign-in providers, browser/device providers, email delivery systems, and operational logs.
  • If you do not provide data needed for an account, ticket, payment, required form, or security check, the relevant workflow may not be available.

Your rights

  • You can ask us to access, correct, delete, restrict, or export personal data, subject to legal limits and the role Hubbaly has for that data.
  • You can object to processing based on legitimate interests and ask for data portability where that right applies.
  • You can withdraw consent where we rely on consent, without affecting earlier processing that was already lawful.
  • You can complain to the Information Commissioner's Office at ico.org.uk, but we ask that you contact privacy@hubbaly.com first so we can investigate.
  • Hubbaly does not use solely automated decision-making that produces legal or similarly significant effects in ordinary account use. Safety, abuse, and payment-risk signals may inform human review or product enforcement.

Contract

We use account, community, event, ticket, checkout, support, and transactional-message data where it is necessary to provide Hubbaly or take steps you request before using it.

Legal obligation

We use and retain records where needed for tax, accounting, company, payment, consumer, regulatory, law-enforcement, or court-process obligations.

Legitimate interests

We use data for security, fraud prevention, abuse investigation, moderation, platform integrity, service improvement, operational logging, support quality, and limited audience measurement where those interests are not overridden by individual rights.

Consent

We rely on consent where the law requires it, such as optional non-essential storage or analytics choices. You can withdraw consent through the relevant product control or by contacting privacy@hubbaly.com.

Vital interests

In rare emergencies, we may use data where necessary to protect someone's life or immediate safety.

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.

Account and profile data

Email, username, display name, bio, avatar, location, website, timezone, profile visibility settings, memberships, and linked public-profile state.

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.

Reusable hub-scoped details

Where a Pro+ hub uses Details to collect, Hubbaly can store answers such as full name, phone number, organisation or group, and other operational details required for interest, joining, invite acceptance, or ticket checkout. These answers stay with that hub, are not shared with other hubs, are encrypted at rest, and are visible only to authorised Hub Admin roles chosen by that hub.

Content moderation and support

Chat messages, reactions, mentions, photo uploads, tags, reports, takedown requests, incident records, trust-safety restriction records, moderation history, and admin audit records.

Forms and verification

Document signatures can store signer name, rendered content snapshot, form-field 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, decide whether an account can still use the product, and preserve restricted evidence when safety or legal review requires it.
  • Project account admission status from active platform restrictions so bans and suspensions are enforced consistently across authenticated requests.
  • 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.
  • Reusable hub details stay scoped to the hub that collected them. They are not a global Hubbaly profile, not shared with other hubs, and can be reviewed from Account -> Shared details and the relevant hub's own Shared details page where the user still has access.
  • 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, public album, and guest-ticket pages to understand visits, downloads, broken journeys, and which public sharing links are working. This page gives you a simple way to disable visitor analytics if you object.

These visitor analytics stay first-party and service-improvement only. Daily unique counts use a server-side daily hash derived from request details, then the raw details are discarded before the visitor row is stored. Hubbaly does not create a visitor cookie, localStorage visitor ID, guest-ticket session marker, or persistent public-hub variant label 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.

Browser push services

Push notifications are delivered through the browser platform's web-push service, such as Apple Push Notification service, Firebase Cloud Messaging, or Mozilla Autopush, depending on the browser and device.

Hosting and storage

The service uses hosting, database, object storage, content delivery, deployment, and operational infrastructure providers. Public notices use categories here; named infrastructure providers and locations are maintained in Hubbaly's processor and subprocessor schedule.

Sentry

Environment-configured error monitoring and release/source-map support in deployed API and web environments where Sentry is enabled.

International transfers

  • Hubbaly uses UK, EEA, and international service providers for hosting, payments, email, database, storage, delivery, support, monitoring, and sign-in workflows.
  • Where personal data is transferred outside the UK, we rely on UK adequacy regulations or appropriate safeguards such as the UK International Data Transfer Agreement or the UK Addendum to the EU standard contractual clauses.
  • Named providers, expected processing locations, and transfer mechanisms are maintained in Hubbaly's processor and subprocessor schedule, available for DPA and customer due-diligence requests.

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, platform safety issues, or active trust-safety restrictions.

Banned-account enforcement records

If an account is platform-banned, we may retain limited identity and enforcement metadata for up to 24 months after the account's last activity so the ban can be enforced, reviewed, and audited. We may keep those records longer if an active case, legal hold, or statutory requirement requires it.

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.