Privacy Policy

When you sign in, Bloop stores your account profile, session, connected account links, focus themes, goals, and app-owned mappings between events, tasks, themes, and goals. The mobile app stores your weekly check-ins and a small set of account-scoped preferences on that device. It also keeps an account-scoped offline snapshot so a slow or disconnected launch can show the last saved week instead of an empty screen. That snapshot can include your profile, calendar names, synced event titles, descriptions, locations and times, tasks, goals, themes, and Google sync status. It is stored in the app's native cache on iPhone, or in browser local storage when the mobile interface is run on the web.

A fresh mobile snapshot replaces the previous one. A snapshot older than 14 days is not displayed and is deleted the next time Bloop reads the cache. The operating system, browser storage controls, or uninstalling the app may remove it sooner. Signing out or deleting the Bloop account also clears this offline snapshot from the device or browser.

If you use Sign in with Apple, Bloop stores Apple's stable identifier for your account and, when Apple provides them, your name and email address. The email may be an Apple private relay address. Bloop verifies Apple's signed identity token and exchanges the one-time authorization code with Apple, then stores the refresh token and signed identity token securely on Bloop's server as client evidence so the correct Apple authorization can be revoked when you delete your account. On iOS, the stable Apple identifier is also stored in SecureStore, tied to the current Bloop session, so the app can sign you out if Apple reports that credential as revoked or no longer available.

If you connect Google, Bloop stores discovered calendar-list metadata—calendar names, time zones, primary status, and access roles—so Settings can show the source selector. It syncs event details only from calendars you enable, plus selected Google Tasks lists and tasks. A Google write occurs when you submit a direct app action or explicitly confirm the exact preview proposed by Bloop Chat or, when available, Voice.

To prevent a retried or interrupted direct create from making a duplicate Google event or task, Bloop keeps an account-linked retry record containing one-way digests, its state, and an opaque local result identifier. This record does not contain the raw retry key, title, guests, request body, or Google provider identifier. It remains for safe replay for the lifetime of the Bloop account and is removed with account deletion.

When you open a calendar event editor, Bloop can fetch attendee names, email addresses, and response status from Google only for that event. Those attendee details are not stored in Bloop's synced event data or shared mobile snapshot, and are not included in Bloop Chat or any available Voice context, reflections, or telemetry.

Typed chat requests, and—when Live Voice is available—transcribed voice requests, AI categorization, and generated weekly summaries may send relevant event titles, task titles, goal names, theme names, dates, and schedule context to OpenAI so the feature can answer or classify your request. Theme descriptions, keywords, and a limited set of previously categorized event titles can be included when they help categorize a new event. If you deliberately state a guest email address in Chat or an available Voice feature, that address is also part of the request sent to OpenAI.

For chat, Bloop selects the smallest relevant data area for the request and caps item lists before sending context. Unrelated conversation does not load private app context. Chat and event categorization use request-local aliases in place of Bloop's persistent internal event, task, and goal identifiers. Those aliases are resolved inside Bloop and are not Google or Apple identifiers.

If Live Voice is available and you deliberately hold its Voice control, live microphone audio is sent from your device to OpenAI's Realtime service for transcription and spoken output. The resulting request text is sent to Bloop's server so it can answer using your connected data, and Bloop's reply text is sent back to Realtime when speech is requested. Bloop does not intentionally store raw microphone audio in its application database or application telemetry.

For Realtime safety and abuse prevention, Bloop sends OpenAI a stable one-way value derived from your Bloop user identifier. It is not your raw Bloop identifier, email address, Google or Apple identifier, or OAuth token, but it lets Realtime recognize requests from the same Bloop account for safety purposes.

OpenAI states that data sent through its API is not used to train or improve its models unless the API customer explicitly opts in. Under OpenAI's default Realtime data controls, customer content can be included in abuse-monitoring logs retained for up to 30 days, unless a longer period is required by law or needed to protect the service or others. OpenAI lists no separate application-state retention for the Realtime endpoint. Bloop has not enabled an opt-in that allows OpenAI to train on Bloop API data and does not rely on OpenAI to store a Voice conversation for the product.

Bloop does not intentionally send Google OAuth tokens to OpenAI. OpenAI-powered features are disabled if the server is not configured with an OpenAI API key.

When OpenAI returns a weekly-summary generation, Bloop keeps an account-linked observability record containing a cryptographic digest derived from that summary input, the model name, generation time and duration, and any prompt, completion, and total token counts the provider reports. The record does not store the raw summary prompt, event or task text, or generated recap. It remains for the lifetime of the Bloop account and is removed with account deletion.

When Bloop proposes a calendar or task change, the exact proposed action is stored temporarily on Bloop's server behind a random confirmation reference. This can include a guest email address that you deliberately supplied. It expires after 15 minutes, cannot be used after confirmation or cancellation, and is removed after use or by scheduled cleanup.

Bloop uses Apple as the sign-in service provider for Sign in with Apple. Apple provides the signed identity token and processes the one-time authorization code used to verify the account and issue the server-side revocation credential described above. Apple sign-in establishes your Bloop identity; it does not give Bloop access to Google Calendar or Google Tasks.

Bloop does not send your Apple sign-in tokens to OpenAI. If you later connect Google, Google's permissions and data handling are separate and are described below.

Bloop requests only the Google permissions its features use: reading the list of your calendars, reading and writing your calendar events, and reading and writing your tasks. Read access keeps the app synced. Write access enables add, edit, move, complete, reopen, and delete actions. Bloop does not request permission to create, delete, or share whole calendars, and it does not read your Google account settings.

Bloop always includes the connected account's primary calendar and lets you choose which discovered non-primary calendars to include. Turning one off removes that calendar's synced event copies and event-linked Bloop mappings from the live application database, and stops future sync until you enable it again. This does not delete or change the original Google Calendar. A previously saved mobile offline snapshot is replaced on its next successful refresh and otherwise expires as described in Retention.

Bloop's use and transfer of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements. Bloop does not sell your Google data, does not share it with data brokers, and never uses it for advertising, retargeting, or interest-based profiling. Service providers that host, store, secure, and operate Bloop may process data on Bloop's behalf. OpenAI receives only the limited context described above, solely to provide the user-facing AI features you actively use.

Calendar guest invitations are available only for events organized by the connected account. Bloop shows a final confirmation and explains that Google will email the named guests before it sends an invitation. An invited person can set their own response to Going, Maybe, or Decline. After Google confirms a declined response and Bloop refreshes, that invitation is excluded from Bloop's local calendar views; the organizer's Google event is not deleted.

Existing attendee names, email addresses, and response status are fetched from Google only when you open that event's editor and are not added to Bloop's synced event records, shared snapshot, AI context, reflections, or telemetry. This differs from a guest address you deliberately enter: a directly entered address passes through Bloop to Google, while an address stated in Chat or an available Voice feature is also processed as described in AI Features and can remain in the confirmation proposal for up to 15 minutes. After confirmation, Google stores the attendee on the event and sends the invitation.

Guest invitations and RSVP changes use the same Google Calendar access Bloop already requests; they do not add another Google permission scope.

You can revoke Google access from your Google Account at any time. If scopes are missing or expired, Bloop will ask you to reconnect before write actions continue.

Bloop's website and API run on Vercel, and active application records are stored in a Supabase-hosted PostgreSQL database. These providers process application data and technical request information needed to host, secure, troubleshoot, and deliver Bloop. Their systems can create operational logs, caches, and backups.

Bloop uses OpenAI for the AI and Voice processing described above, Google for account, Calendar, Tasks, and invitation services, and Apple for Sign in with Apple. These providers process only the data needed for the feature you use under their applicable service terms and Bloop's configuration.

The iPhone app is built and distributed using Expo Application Services. Expo can process release source and configuration, build artifacts, signing or submission information supplied by the release operator, and device-registration information for internal test builds. Expo is build and distribution infrastructure; it is not Bloop's Calendar or Tasks synchronization service.

Email sent to support@hibloop.xyz is forwarded by Porkbun Email Forwarding to an operator-managed Gmail inbox. Porkbun and Google therefore process the addresses, message headers, subject, body, and any attachments you choose to include. Replies may display the operator's Gmail address. Support correspondence is stored separately from your Bloop account and is not automatically removed by the in-app account-deletion control.

Bloop keeps live account records, connected-account records, synced copies, goals, themes, mappings, weekly reviews, daily AI usage counts, direct-create retry records, and weekly-summary generation metadata while the Bloop account remains active. Account deletion removes those live application-database records and expires account-specific weekly-summary cache entries.

Assistant proposals expire after 15 minutes. The offline mobile snapshot is not shown after 14 days and is deleted the next time Bloop reads it. Device-only weekly check-in history is limited to the 32 most recent records. Completed device retry keys are removed after a successful create; unresolved retry protection remains until the operation is resolved or the account's local data is cleared.

Hosting logs, security records, provider caches, database backups, AI-provider records, and support correspondence can follow separate provider or operator retention schedules and may not disappear immediately when live account data is deleted. Contact Bloop Support to request deletion of separately held support correspondence. Bloop retains such records only for service operation, security, support, legal compliance, and recovery—not for advertising or cross-service tracking.

The Settings page includes account deletion. If your account uses Sign in with Apple, Bloop first attempts to revoke the Apple authorization using the server-side refresh token. The deletion then removes active Bloop-owned records associated with your user from the application database, including goals, themes, mappings, synced copies, sessions, linked account records, direct-create retry records, weekly-summary observability records, and the stored Apple revocation credential. Bloop also expires account-specific weekly-summary cache entries. The mobile app removes that account's weekly check-ins and local preferences from the device, and sign-out clears the offline snapshot containing the last saved Calendar, Tasks, goals, and sync data.

If automatic Apple revocation cannot be completed—for example, because an older account has no usable revocation credential or Apple is unavailable—Bloop still deletes your Bloop data and tells you to remove bloop. under Sign in with Apple in your Apple Account settings. This manual step removes the remaining Apple authorization.

Deleting your Bloop account does not delete the original events or tasks in Google unless you explicitly delete those Google items through Bloop before deleting the account. Provider backups, security logs, and separately held support correspondence follow the Retention section above.

Visit Bloop Support for troubleshooting and the public contact method configured by the service operator. Include what you were doing, what you expected, and the app version shown in Settings. Do not include passwords, OAuth tokens, or private data you do not want in a support message.