Havara: Subprocessors
Effective October 30, 2026
Last updated November 12, 2026
Earlier versions of this document are available on request at [email protected].
This is the complete list of vendors that touch member data, plus the one that measures visitors to our marketing site, what each one receives, and whether it is actually running today. Two vendors, PostHog and TypeSafe, are wired in but switched OFF and receive no member data; we say what would have to change before either turns on. Two vendors that carried that label have since been switched on, Resend on 2026-08-05 and Sentry on 2026-08-26. In those two cases the vendor began processing before this list was updated, which broke the commitment in our Privacy Policy to update this list before switching a Conditional vendor on. This page and the DPA were not yet published, so their 30 days' notice bound no one then. Both flips are recorded in their rows rather than smoothed over.
This page lists the third-party service providers ("subprocessors") that Havara LLC, a Georgia limited liability company, uses to operate Havara, the HOA / residents' community app. A subprocessor is a vendor that processes personal data on our behalf to deliver part of the service.
Every entry carries a Status:
- Live: the vendor processes data for Havara today. For every Live vendor but one, that can be member data. The exception is Cloudflare Web Analytics, which processes data about visitors to the havara.app marketing site, collected by Havara as controller for its own purposes, and receives no member data. Correspondence can also come from people without a Havara account.
- Conditional: the integration is built, but it is switched off and receives no data unless a configuration key is set. We list these because enabling them requires no code change; if we enable one, we will update this page at least 30 days first (see "Changes to this list", which also records the two vendors switched on before this list was updated). We have not always updated it first. Resend (2026-08-05) and Sentry (2026-08-26, the first build carrying the configuration key committed on 2026-08-21) were each switched on before this list was updated, which broke the Privacy Policy's commitment to update it first, and the list was corrected afterwards. PostHog and TypeSafe are the Conditional vendors today. TypeSafe has an additional source-controlled approval marker, currently false, so an environment-variable change alone cannot activate it.
The Workspace mailbox also processed correspondence before being listed. Its row records that late disclosure separately, alongside the corrected Cloudflare routing scope. Whether a Customer had accepted the DPA while that mailbox processing occurred has not been established; the earlier Resend and Sentry finding does not apply to it.
Current subprocessors
| Name | Status | Purpose | Data processed | Data-use commitment | Region |
|---|---|---|---|---|---|
| Supabase | Live | Primary backend: Postgres database, Auth (email + password sign-in, with email magic-link and PKCE password reset as secondary flows, and, in the phone app from version 2.3, Sign in with Apple and Google sign-in, whose signed tokens it checks against each provider's published keys), file Storage (documents, avatars, chat attachments, community media, request/violation/ARC photos), Edge Functions, and push-notification orchestration. Separately, the web console at app.havara.app offers Apple and Google sign-in through Supabase OAuth. The browser keeps the Havara session in this origin's local storage, with provider access and refresh tokens removed before storage. When Havara's sales email to businesses is activated, Supabase also answers whether a business email address is on the opt-out list Havara keeps for its other commercial email, and keeps no copy of the address. This purpose is currently off. | All account data, community memberships, all user-generated content, documents and embeddings, AI Ask history, push tokens, notification preferences, audit/moderation records, and marketing-site waitlist entries. Also Supabase's own request and sign-in logs: for each request the app or console makes, the IP address, the user agent and the approximate location derived from the IP address (city, region, postal code, country and time zone), with the account's user id when the member is signed in and the email address on sign-in events, kept 7 days. For sales email: a business email address, sent only for that check and not kept. | Acts as a processor on our instructions; encrypts data at rest (AES-256) and in transit (TLS) per its published security page (read 2026-07-12). Supabase's published Data Processing Addendum (Version 1, August 1, 2026) supplements and forms part of the Supabase Terms of Service, so it applies to our account without a separate signature. It carries purpose limitation (clause 3.2) and the CCPA prohibitions on selling, sharing and out-of-purpose use (clause 3.3), and it has no clause about AI training (read 2026-09-16). Supabase's Terms of Service, section 8(b), say that to the extent Supabase uses artificial intelligence to provide features to the customer through its services, and in providing its AI Tools (the chatbots and other AI tools it offers for support and similar interactions), it will not use, or allow any third party to use, Customer Data, the customer's AI Input or any AI Output to train, fine-tune or otherwise improve any artificial intelligence or machine learning model without the customer's prior written consent (read 2026-10-02). The commitment is limited to that scope as written; those Terms define Customer Data to exclude aggregated data. Supabase's own subprocessor list (June 1, 2026) names OpenAI, LLC for natural language processing and does not say which data categories reach it. | Single hosted project (ref atpkrqchznroqzbmoyap) in the United States, region us-east-2 (US East / Ohio). |
| OpenAI | Live | AI text embeddings (text-embedding-3-small) for Ask document search, and moderation screening (omni-moderation-latest), which every Ask question is sent to before it is answered; a flagged question is refused and kept in a moderation log the community's moderators can read, while a moderation call that times out or errors lets the question through. Called server-side by our Ask and document-processing services. OpenAI does NOT perform OCR; scanned PDFs go to AWS Textract (see the AWS row). OpenAI does not generate Ask answers and does not title Ask threads. Thread titles are derived on the device from the first question, with no AI call. When Community Agent is activated, also screens the member's raw draft/change request and the proposed rewrite. Those checks fail closed. This new purpose is currently off. | Document text/excerpts (during indexing) and the member's Ask question text. No account identifiers are sent in the request body. Community Agent input requests and proposed posts, which may include details the member typed; no account id or roster is supplied. | OpenAI's Data Processing Addendum (updated December 1, 2025, effective January 1, 2026) supplements and is incorporated into the OpenAI Services Agreement (same dates), which applies it whenever the services are used to process personal data (section 5.3), so it applies to our account without a separate signature. Under that agreement OpenAI uses customer content only to provide the services, comply with the law, enforce its policies and prevent abuse, and does not use it to develop or improve its services unless the customer explicitly agrees (section 4.2). Both read 2026-10-02. Per OpenAI's published API data policy (read 2026-07-12): API data is not used to train OpenAI models unless the customer opts in; abuse-monitoring logs are retained up to 30 days. | OpenAI API (US-based service via api.openai.com). |
| Amazon Web Services | Live | Optical character recognition of scanned / image-only PDFs, via Amazon Textract's asynchronous plain-text detection (StartDocumentTextDetection). The PDF is copied to a private, encrypted, public-access-blocked S3 bucket for the duration of the scan and deleted after the scan, with a 1-day lifecycle rule as backstop. Documents that already contain selectable text are never sent. Called server-side by our document-processing service. | The bytes of scanned PDFs with no text layer, and the text recognized from them. No account or community identifiers are sent; the staged object's key carries the document's internal id. | The AWS Service Terms (last updated October 1, 2026; read 2026-10-02) incorporate the AWS Data Processing Addendum whenever AWS services process customer data as that addendum defines it (section 1.14.1), so it applies to our account without a separate signature. Per AWS's Textract FAQ (fetched 2026-09-22, re-read 2026-09-23): Textract may store and use document inputs to provide and maintain the service. Unless an AWS Organizations AI services opt-out policy applies, it may also use them to improve Textract and other Amazon AI services and keep some content in another AWS region. That opt-out applies: since September 23, 2026, an AWS Organizations policy has opted the AWS account that runs these scans out of every AI service the policy covers, Textract included. The staged S3 copy is deleted after the scan. | AWS (US-based service, us-east-1). |
| Anthropic | Live | Generates the cited, documents-only Ask answer (claude-haiku-4-5) from retrieved document excerpts. Called server-side by our Ask service. When Community Agent is activated, also rewrites member-requested community posts after server-known names and unit/location details are removed. This new purpose is currently off. When Havara's sales email to businesses is activated, also suggests drafts of those emails and of replies, sorts the replies, and helps judge whether a business fits, from the public business information and the replies the Privacy Policy describes under business contacts. This purpose is also currently off. | The member's question, earlier turns retained after current citation-access checks, and the retrieved document excerpts. No account identifiers are sent in the request body. The sanitized member request or change instruction and a previous checked draft for a requested revision; no account id or community roster is supplied. For sales email: a business's name, website and published email address, notes from its public web pages, and the emails and replies; no individual's name or personal contact details are looked up, and no Havara account data is sent. | Anthropic's Commercial Terms (effective June 17, 2025; read 2026-10-02) say Anthropic may not train models on customer content from its services (Section B), and incorporate Anthropic's Data Processing Addendum by reference (Section C). Anthropic's published retention terms for API customers (updated July 1, 2026; read 2026-10-02) say it deletes API inputs and outputs within 30 days of receipt or generation, with exceptions those terms list, including content its automated trust and safety systems flag as violating its Usage Policy (inputs and outputs kept for up to 2 years, classification scores for up to 7 years) and retention the law requires. | Anthropic API (US-based service via api.anthropic.com). |
| TypeSafe | Conditional: currently OFF, receives no member data | Would evaluate how well each of up to six permission-filtered Ask passages supports the question. The result is a test measurement only and cannot reorder passages, filter passages, change citations, or change an answer. Activation requires both a server setting and a reviewed code setting, and both are currently off. | If activated: the current question, at most one earlier question (the most recent one that still passes the current access checks, which can be older than your last question), or none, and up to six retrieved excerpts with their document titles and section headings. No name, email, account id, user id, community id, or document id is added to the request, but the question and excerpt text may contain the names of people mentioned in them. Separately, in November 2026 Havara used TypeSafe's Jev model in its own research, outside the app, to sort public records about Georgia community associations. TypeSafe received organization names, cities, counties and short sentences Havara's code wrote from those records, and, in error, about 400 names of people and some mailing addresses from county property records. Havara changed its code to stop each kind of error it found, and on November 11, 2026 deleted those association records and the county and IRS working files, but cannot take back what TypeSafe received. None of it was member data. | TypeSafe's current model documentation says its model is not trained on customer requests or responses (read 2026-09-19). Its customer agreement (last updated 2026-09-19) lets it keep, use and share the data it receives (the questions and excerpts) in perpetuity to derive telemetry, to monitor for fraud and abuse of its services, and as necessary to comply with law, and lets it use that derived telemetry (technical logs, hashes, summary statistics, classifications, metrics and learnings) without restriction, including to improve its products. Its privacy policy says it will not train models on that data and states no fixed retention period (both read 2026-09-22). Zero data retention is an enterprise option, not the default. Before this row changes to Live, Havara will record here the data processing terms it accepted, TypeSafe's retention window for our data, the account tier, and whether zero data retention applies, and will give at least 30 days' notice (see "Changes to this list"). | TypeSafe API (api.typesafe.ai); hosting region to be confirmed before activation. |
| Expo (Expo Application Services) | Live | Delivers push notifications via Expo's push service (exp.host) for new messages, notices, join decisions, and emergency alerts, and, where a community runs a security desk, parcel and guest arrival notices; EAS is also the build / distribution pipeline. From app version 2.2 (build 35), EAS Update also answers the app's update check (u.expo.dev), made by expo-updates at every app start without waiting for it; publishing an update is a deliberate step Havara takes, and none had been published as of 2026-09-23. | Device Expo push tokens and the notification title/body/route payload, which may include message previews unless the member turns previews off (previews default to on). A security desk notice carries a parcel's carrier or a guest's name unless previews are off. Each update check, read from expo-updates 57.0.23 (FileDownloader on iOS and Android): platform, runtime version (the app version, 2.2), channel (production), the running, embedded and recently failed update ids, any headers Expo's server asked to have sent back, EAS-Client-ID (a random UUID the library generates once and keeps in the app's own storage: UserDefaults on iOS, SharedPreferences on Android), the device's IP address as with any request, and, only after a fatal error, Expo-Fatal-Error, a text description of it cut to 1,024 characters (on iOS a fatal error of the app's code or of the update system; on Android only the update system). No account id, name, email, phone number or push token. | Expo offers no separate data processing addendum. Its Terms of Service (last updated May 29, 2025, effective June 30, 2025; read 2026-10-02), section 3.2, make Expo a processor of the personal data in the content customers send through its services where the GDPR applies, bound by module two of the EU standard contractual clauses, and a controller only when it uses that data in aggregated or de-identified form to improve its products or as its privacy policy describes. Per Expo's published policies (read 2026-07-12): push receipts are cleared after 24 hours; Expo states GDPR/CCPA/Data Privacy Framework compliance. Payload-content retention is not documented, so we keep payloads minimal and let members disable previews. The EAS Update pages read on 2026-09-23 state no retention period for update checks; Expo counts each installation that downloads an update as a monthly active user for billing, and one that downloads none is not counted (EAS Update FAQ). | Expo / EAS cloud (US-based service). u.expo.dev answers through Cloudflare's network, so a check is received at the edge nearest the device (response headers, 2026-09-23). |
| Apple | Live | iOS app distribution (App Store / TestFlight) and Apple Push Notification service (APNs) for iOS push delivery; and Sign in with Apple in the iPhone app from version 2.3 (tester-only; public from version 2.4, available on both stores since October 20, 2026), for members who choose it, including ending Havara's access when the member deletes their account. Separately, Apple sign-in on the web console at app.havara.app confirms identity and tells Apple that the member uses Havara. For web-only Apple sign-in deletion completes with an undeliverable record and no Apple revocation request. Remove Havara at account.apple.com under Sign-In and Security, Sign in with Apple. The browser stores the Havara session with provider access and refresh tokens removed. | App distribution metadata and APNs push payloads relayed to iOS devices. For Sign in with Apple: the member's sign-in on their iPhone, after which Apple gives Havara an identifier for the member's Apple ID, an email address (or a private relay address) and, the first time only, the name the member shares, and learns that the member uses Havara; the one-time code Havara's server exchanges with Apple for a refresh token, and that token, or a fresh code, sent back to Apple at account deletion to end Havara's access; and email Havara sends to a private relay address, which Apple forwards. | Apple offers no data processing addendum for these services. They run under Apple's Developer Program License Agreement (last updated August 18, 2026; read 2026-10-02). For push, Apple will not access or disclose the content of a push notification unless it believes in good faith that doing so is reasonably necessary to comply with legal process, enforce the agreement, address security, fraud or technical issues, or protect the rights, property or safety of Apple, its developers, its customers or the public, and it may collect technical and diagnostic information about our use of the service (Attachment 1, section 5.6). For distribution, Apple handles App Store users' information as its own Privacy Policy describes. | Apple (US-based service). |
| Live | Android push delivery through Firebase Cloud Messaging, configured in the app's production build, and Android distribution through Google Play; and Google sign-in in the phone app from version 2.3 (tester-only; public from version 2.4, available on both stores since October 20, 2026), on iPhone and Android, for members who choose it. The iPhone sign-in library separately declares App Functionality and Analytics, described in the Privacy Policy Section 3. Separately, Google sign-in on the web console at app.havara.app confirms identity, shares the identifier, name, email and profile photo link with Supabase, and tells Google that the member uses Havara. The browser stores the Havara session with provider access and refresh tokens removed; the native Google library and its sign-out cleanup are not used by the console. | Android push payloads (the same title and body Expo receives, which may include message previews unless the member turns previews off) and app distribution metadata. For Google sign-in: the member's sign-in, after which Google gives the app a signed token with the member's Google account identifier, name, email address and profile photo link, and learns that the member uses Havara. Havara requests no other Google data. Havara's servers keep no Google token; Google's sign-in library keeps the member's Google sign-in in the app on the phone until the member signs out of Havara there (on iPhone, including a refresh token that is never sent to Havara). A session that ends another way, such as after a deletion from the web console, does not clear it: it stays until someone signs in and out on that phone again or the app is removed, and on iPhone, where removal may not delete it, until the reinstalled app first starts a Google sign-in or a sign-out. Havara does not ask Google to end its access; the member can remove Havara in their Google Account settings. Separately, the iPhone library declares Name, Email Address, Phone Number and Coarse Location for App Functionality; User ID and Other Data Types for App Functionality and Analytics; Device ID and Other Usage Data for Analytics. All eight are declared linked, not tracking. The app also invokes the library to clear any Google sign-in whenever anyone signs out of the Havara phone app, even if they used another sign-in method. Collection/transmission timing (including before choosing Google), exact Other Data Types fields and retention are unverified. Android library declaration parity was not assessed by this iPhone check. The local-token lifecycle above does not set a deletion deadline for Google's separate library records. | Firebase Cloud Messaging runs under the Google APIs Terms of Service and Google's Firebase Data Processing and Security Terms (last modified August 21, 2024), which the terms for that service incorporate (Firebase's terms page, last modified September 24, 2026), so they apply to the Firebase project our Android app uses. Google Play distribution runs under the Google Play Developer Distribution Agreement (effective September 15, 2025), under which Google handles the data it collects under its own Privacy Policy and the Google Controller-Controller Data Protection Terms apply (section 9). All read 2026-10-02. Google's own Privacy Policy describes its sign-in-library practices and controls; no fixed SDK retention period or erasure guarantee is established here. | Google (global infrastructure). | |
| Resend | ACTIVE as of 2026-08-05. Was Conditional-OFF until then | Sends transactional emails: community invitations, vendor quote-request relays, announcement email mirroring, and operator alerts to the operator's own address, and delivers the sign-in emails Supabase Auth sends (confirming an address, sign-in links, password resets and a change of address). If activated, the vendor digest would also use this delivery path for an operator-triggered commercial email to one community's board listing the vendors who bought paid placement there. Its sending key and sender address are now configured, so these no longer fail closed. This row said "receives no data" and that its keys were not configured until 2026-08-05; both statements were false from the moment the keys were set. Our Privacy Policy was corrected on 2026-08-05 in the same change as this note. Since then our push notification service has also emailed a copy of compliance notices, join-request and claim decisions and tenant access notices to members the push did not reach; since member email was switched on on September 30, 2026, only when member email does not send them (below). It never sends, before or after that switch-on, a denial to someone already a member of the community other than the denial of their unit claim, nor the denial of a unit claim to someone no longer a member, unless it cannot read the membership at that moment (below). Our operator alert service emails every waitlist submission to the operator's address. | Lifecycle v1 additionally sends the community creator a board setup welcome with [email protected] as reply-to, and eligible staff a join-request reminder with waiting count and oldest wait in hours, never requester details. Recipient email addresses, community name and invite code, and a link carrying that code (invites; and, for a welcome a board member sends by hand to an address they give, which no screen offers, the community's name and the name they give); for sign-in emails, which Supabase Auth sends through Resend's mail server to the account's email address: that address and a single-use link or code to confirm it, sign in or reset the password, and, for a change of that address, which no screen in the app or console offers, the new address, sent to both the old and the new one (our authentication settings, read on 2026-09-30, name Resend's mail server); for a vendor quote relay: the vendor's contact email and name, the community's name, the request text, how the resident would like to be contacted, and the requesting resident's own phone number and email address, which the message carries so the business can reply to that neighbor directly, plus a single-use link the vendor opens to answer (added 2026-09-05; the service that sends it is live in production and relayed its first request by email on 2026-09-19); for a request a board writes to a vendor itself: the vendor's contact email and name, the community's name, the board's words and how the board would like to be contacted; for a vendor listing invitation: the vendor's contact email and name and the community's name, plus a single-use link to confirm its details, which is commercial email and carries the same postal address the digest does (added 2026-09-05; none sent as of 2026-09-22); announcement subject/body, the community's name and member email addresses (each member's confirmed sign-in email address; mirroring); and, to the operator's own address only, the name and email of whoever creates a community, with the community's name, our reference number for it and how people join it, and the name, email and account identifier of the first person to create an account in each five-minute period, when, how they signed up (Apple, Google or email) and whether their email address is confirmed (the signup alert, added 2026-08-13; at most one email in each five-minute period, so anyone else who creates an account in that period is not named, only counted in the number of accounts the next alert shows), and each access request submitted on the havara.app form (name, email, community name and address, role, homes count, how the visitor heard about us, their note, which of our sites it was sent from, when, and our reference number for it); and reports a member files on a declared interest, at most one email every five minutes, each carrying one report (the declaration's words and when it was made or withdrawn, the name of the person who made it, the community and the business, the report's reason and any words sent with it, the reporter's account identifier, not their name, and our reference numbers for the report, the declaration and the community; added 2026-09-25); and the first payment Havara receives (the community, the amount, when it was paid and the payment processor's reference for it), and notices that member email has stopped sending, which carry counts only; each of these alerts can also carry running totals, such as how many accounts or communities there are; and email copies from our push notification service, sent to the member's confirmed sign-in email address, only when the push did not reach them: a compliance notice (the community, the rule cited, the board's full notice text and the due date), the answer to a request to join or a claim to a home (the community, and whether it was approved), and a change to a tenant's access (the community, and the end date, or that it no longer has one, or that access has ended), sent before member email was switched on and since then only when member email does not send them (below); and, for a board member, admin or declarant owed a reminder of a compliance calendar deadline, their confirmed sign-in email address, the community name, whether it is due soon or overdue, the due date, never the deadline's title, and a link to the calendar, sent only when the push does not reach them (live in production). And, for an accommodation request, the confirmed sign-in email address of a community administrator (board, admin or declarant) or of the member who filed it, the community name, that a member filed one or that the board asked for more information, recorded a decision or replied, and a link to the console, never the request's title or details, a message, a question, a decision or a file name, sent only when the push does not reach them. And, for a parcel a community's security desk logs for a home or reminds the home about, the confirmed sign-in email address of each member seated on the home when the parcel was logged whom the push did not reach, the community name, that a delivery arrived or is still waiting, and a link to Havara, never the name on the label, the carrier, the tracking digits, the shelf or the desk's note. The signup alert widens this row from a handful of community creators to any user of the product, which is why it is called out rather than folded into the sentence above. Vendor digest (added 2026-08-20, nothing sent yet): the email addresses of one community's board members, together with that community's paid vendor placements, and an unsubscribe link that carries the board member's email address. Unlike everything else in this row, the digest is commercial email, not transactional, because its purpose is to promote businesses that paid for placement. Open tracking and click tracking are off for the havara.app sending domain (read from the Resend account 2026-08-20), so Resend returns us no open or click data. No digest has been sent to any address, so Resend has received nothing under this heading. Bounce and complaint feedback (receiver source added, not yet activated): when configured, Resend returns event type and time, recipient addresses and provider metadata such as sender, message identifier, subject and bounce diagnostics. The receiver records only an address, its generated match key, the bounce or complaint source and Havara recording time. Other event content is discarded rather than stored or logged by the receiver. A best-effort operator email carries only source and new-entry count through Resend, never an address or domain. No feedback is sent to the optional operator webhook. Member email (added 2026-09-28, switched on as of September 30, 2026): our member email service sends each member email about their own account, home and requests and about their community (Privacy Policy section 4.3): the member's confirmed sign-in email address, the community's name, and what each email shows: in the welcome, the member's name, the names of the community's current board members and links to the apps; the answer to a request to join (that it was not approved); for a tenant, the date their access is set to end, or that it no longer has an end date, or that it has ended; for a charge or payment on the member's own home, its kind (dues, a fine, a fee or interest), the amount, the board's short description and the date; for a compliance notice addressed to them, the rule and the deadline; that the board decided their appeal on a rule, naming the rule but not the outcome; the board's decision on their architectural request, approved or denied, the title of the meeting it put their reconsideration on, and that it kept its decision after reconsidering, each with the request's title; that their request was resolved or their records request answered, with its title; an emergency alert's kind and place; for a meeting, its title, time and place, and whether it was scheduled, moved or cancelled or its minutes posted, and, for a meeting scheduled or moved, its full join link (which can hold a meeting access code) and phone dial-in, unless it is held only in executive session, and whether its agenda includes a special assessment, a change to the rules on how homes may be used or an executive session, never an agenda item's title or details; for a poll, its question and closing time; for an event they said they are going to, its title, time and place and that they said they are going; and in the monthly summary, upcoming meetings and events with their times, open polls with their closing times and whether the member voted, the titles of new documents they can open, decisions logged with their dates, how many of their own requests are open and how many of their architectural requests are in review, their own home's balance, and how many members and new members the community has; and in the daily chat catch-up, how many new chat messages the member has in that community and how many of them mention them, and which of two reasons they get it (Havara cannot send notifications to their phone, or they chose to get it anyway), never a message, its author or a chat's name. Every time is shown in the member's time zone and names it. Every member email also carries a link to the member's notification settings and Havara's postal address, and each kind the member can switch off carries a link with a code that identifies the member's account and the kind of email, in its unsubscribe link and in a header mail apps read, so the unsubscribe works without signing in. A member email never carries a message, a notice's text, an alert's note or a request's text. Since the switch-on the push notification service sends its email copies of join and claim decisions, compliance notices and tenant access notices above only when member email does not send them, including whenever member email is switched off, and always for the answer, approved or denied, to a unit claim (a member's claim to a home) and the approval of any other request from someone who is already a member of the community, which member email does not send. Before and after the switch-on, the denial of any other request from someone already a member is sent by neither: the push notification service reads the membership and sends no push and no email for it, and it sends nothing either for the denial of a unit claim to someone who is no longer a member, whose words ("This does not change your membership") would be false. If that membership read fails, the service sends the usual denial, by push and, when the push does not reach them, by email, and logs the error. Member email and announcement email also carry a code that stops the same email being sent twice, which identifies no one. Nothing queued before the switch-on is ever sent. For a report on other content (Privacy Policy section 5), an alert to Havara carries only the report identifier and the total number of open reports of that kind, at most one email in each five-minute period. It includes no source kind, content, reason, community or people. | Resend's Data Processing Addendum (last updated December 31, 2025; read 2026-10-02) becomes binding when a customer accepts Resend's Terms of Service, so it applies to our account without a separate signature. Under it Resend is a processor acting on our documented instructions, deletes customer data within 90 days of account termination, and carries out its primary processing in the United States. | Resend email API (US-based service via api.resend.com), and Resend's SMTP mail server (smtp.resend.com) for the sign-in emails Supabase Auth sends. |
| PostHog | Conditional: OFF; planned activation date not set, at least 30 days after customer-admin notice | Optional product analytics for phone and console, individual opt-in, default off; keyless builds send nothing; demo excluded | Allowlisted event names, enums, booleans, counts, random installation id and timestamp. No account, community, conversation or content identifiers. Connection IP reaches PostHog, configured to discard it with GeoIP disabled at project level | PostHog's privacy addendum describes service-provider processing to supply the service. Its public DPA is a template, not an executed Havara agreement; review and execution are required before activation (read October 20, 2026). Retention unknown until US project creation; verify and publish actual setting before activation. Unlinked historical events cannot be found by account for deletion | US Cloud (us.i.posthog.com) |
| Sentry | ACTIVE. Its configuration key was added on 2026-08-21, the first build carrying it was cut 2026-08-26, and the first real events arrived 2026-08-27. Was Conditional-OFF until then | Crash / error reporting, switched on in every production build of the app; native crash reporting joins it from the first store build carrying that change. This row said "currently OFF, receives no data" until 2026-08-26; that became false the moment the key was set, and the key was set without this list being updated first, which is the step the privacy policy commits to. | Handled and uncaught JavaScript errors: the error type and message, plus the stack where the call site passed a real Error. More than forty places in the app report handled errors they catch; a global error handler adds uncaught ones. The app also sends short diagnostic messages written by our developers. Every event also carries the level, the environment and the release; a grouping label derived from the caller-supplied scope string; extra details holding that scope plus occasional record ids, such as a poll's or a vendor's id; and the account's user id while someone is signed in. Every event reaches Sentry from the device's IP address, and Sentry works out an approximate location from it (city, region and country) and keeps that with the event. From the build after app 2.2 build 36, the app asks Sentry not to store the address, so Sentry does not write it into the event; it still works out the location from the connection's address. From the first store build carrying native crash reporting, reports also include native crash stacks; device details (manufacturer, brand, model, processor and chipset, screen size and density, orientation, and whether it is an emulator); operating-system details, including whether the device appears rooted or jailbroken; memory, storage capacity and free space; battery level, charging state and temperature, and thermal state on iPhone; the device's language setting (locale) and time zone; its network connection type and whether it is online; when the device last started up; an installation identifier; on iPhone, a device-and-app hash derived from Apple's identifier for vendor, device model and app bundle id, sent whether signed in or not; on Android, which permissions the app requests and whether each is granted; whether the app was in the foreground and when it started; app memory and build type; app version and build metadata, including the over-the-air update id, runtime version and launch duration; diagnostic correlation metadata such as trace and span identifiers; and automatic app-lifecycle and device-state breadcrumbs, Android network-change breadcrumbs (network type, signal strength, upload and download bandwidth, and whether a VPN is active), and iPhone system-event breadcrumbs (keyboard shown or hidden, screenshot taken, time zone changes with the previous offset, and significant time changes such as midnight or daylight saving). iPhone native screen-view and touch breadcrumbs are disabled. Android also retains activity-lifecycle breadcrumbs and interaction breadcrumbs containing the view class and id, not its text. Android app-not-responding reports include the stacks of each app thread: on Android 11 and later when the system flags the app as frozen, and on Android 10 and earlier when the app's main thread has been blocked for five seconds. Available fields vary by platform and report. Performance tracing, profiling, replay, session tracking, console logs and HTTP breadcrumbs are disabled. While someone is signed in, the report's user field is the account id; Android reports also carry the installation identifier and iPhone reports the device-and-app hash, signed in or not. A report sent while no one is signed in, or before the app restores sign-in, can carry the installation identifier as its user id instead. The app asks Sentry not to infer or store an IP address for JavaScript and iPhone reports; Android native crash reports carry no IP address supplied by the app. Each connection still carries an address and Sentry can retain approximate geography. That approximate location can include city, region and country. Never message bodies, email, phone or push tokens. From the console update that adds browser error reporting, Sentry also receives console error types and scrubbed messages, stack traces, the account user id, build environment and release, and navigation paths with query strings and fragments removed. Email-shaped text is replaced, strings are bounded, and request cookies, headers and bodies are excluded. The browser reporter asks Sentry not to infer or store an IP address in the event. Sentry still receives the connection address and can derive approximate location; this has not been verified against a stored console event. The browser SDK collects navigation breadcrumbs only, with no performance tracing, replay, DOM interactions, console logs or network breadcrumbs. | Sentry is bound by its Data Processing Addendum (version 5.1.0, May 29, 2024), and Havara's Sentry organization accepted it on October 4, 2026 (its Legal & Compliance settings, read October 4, 2026). Sentry's Terms of Service (version 3.0.0, which that organization has also accepted; read 2026-10-02) apply alongside it: Sentry may use the error data only as needed to provide, maintain and improve its service, may use elements that by their nature cannot identify anyone for its other business purposes, and may use other elements for them only where the organization's settings allow; it protects the data with reasonable technical and organizational measures described in its security policy; and it stores the data in the region the organization chose. Error events retained 30 days (free tier) / 90 days (paid); backups deleted after 90 days (published docs, read 2026-07-12). US or EU region, fixed at organization creation. | Sentry ingest endpoint (o4511541325004800.ingest.us.sentry.io, US region). |
| Stripe | Live | Bills the community subscription. Hosted Stripe Checkout is opened from the web console's billing card; our server-side billing services (live in production, verified 2026-08-04) create the session and receive subscription lifecycle events. Individual members are never charged. | The billing administrator's payment details, entered directly on Stripe's hosted pages and never received or stored by Havara, plus the billing contact email and community identifier. Havara keeps only Stripe's customer and subscription identifiers, the subscription's status, the trial end date, the paid-until date and the date of any failed payment on the community record (confirmed against the production database 2026-08-04). | Stripe's Data Processing Agreement (last updated 18 November 2025) applies to our account automatically: section 4.1 of the Stripe Services Agreement General Terms (last modified 18 November 2025) incorporates it by reference, so no separate signature is needed. The DPA includes Stripe's Data Transfers Addendum, which carries the 2021 EU Standard Contractual Clauses, the Swiss adaptation and the UK International Data Transfer Addendum. Stripe acts as our processor when it provides the service on our instructions, and as its own controller for its stated purposes, which include fraud prevention, choice of banks and payment providers, legal and anti-money-laundering compliance, and product development (DPA section 2). Stripe must notify us of a personal data incident without undue delay, and no later than 48 hours where EU or UK GDPR applies (DPA section 3.1(f)). Stripe appoints subprocessors under a general authorisation and emails 30 days' advance notice of additions only to users who subscribe on its Sub-processors List page (DPA section 3.2). Read from both primary sources on 2026-09-16. | Stripe (US-based service via api.stripe.com). Havara's Stripe account is a United States account that bills in US dollars. |
| Workspace by Google (support mailbox) | Live: already stores correspondence | Stores inbound support, privacy and legal correspondence forwarded by Cloudflare to a mailbox in the Workspace tenant on fstrhub.com, a domain belonging to the Havara owner's other company. DPA 7.3 classification: addition to this list of a previously unlisted subprocessor already processing mail, correcting an existing omission. It is not a new activation or purpose. Notice is still required and held. No advance notice of this correction has been sent; it cannot be given retroactively. The addendum was not accepted before October 22, 2026, so support mail held in this Workspace until then had no accepted addendum. Google's EU Data Protection Law indicator and HIPAA Business Associate Amendment are not accepted for this Workspace. When Havara's sales email to businesses starts, this mailbox also sends that email from [email protected] and holds the replies; that is Havara's own business correspondence, not member or Customer data, and the Privacy Policy's business contacts section governs it. This purpose has not started. | Sender address, name, message content and attachments, including any original Havara email content quoted in a reply. Support correspondence follows a manual three-year policy measured from the last message in the thread, then yearly purge; the purge label and filter are not yet set up. Account deletion does not reach it. Earlier-deletion requests go to [email protected]. For sales email: the business email addresses Havara writes to, the emails it sends and the replies, kept under the Privacy Policy's 12-month manual policy for business contacts. | Google's Cloud Data Processing Addendum was accepted for this Workspace on October 22, 2026, by the owner's other company that holds fstrhub.com, not by Havara LLC; Havara remains responsible to the Customer for this processing. | No storage region is selected. |
| Cloudflare | Live | DNS for havara.app, TLS termination, CDN, and Pages hosting for both the marketing site and the app.havara.app web console. Also uses Cloudflare Email Routing to forward inbound mail to published contact addresses, [email protected], [email protected], [email protected], [email protected] and [email protected], to the Google Workspace mailbox. DPA 7.3 classification: correction of existing processing, not a new vendor or new purpose. Notice is still required and held. No advance notice of this correction has been sent; it cannot be given retroactively. | All web traffic to both sites transits Cloudflare, including IP addresses, request metadata, and TLS-terminated request contents. For inbound email, Email Routing processes the message envelope (sender and recipient addresses), headers and body in transit, including the content of privacy and support requests, before forwarding it to Havara's destination mailbox. This is separate from website hosting and Web Analytics. | Havara uses Cloudflare's Free plan, under Cloudflare's Self-Serve Subscription Agreement (last updated September 12, 2025; read 2026-10-02). That agreement incorporates Cloudflare's Data Processing Addendum, with Cloudflare acting as processor or subprocessor, where the content includes personal data of EU or UK data subjects or personal information under the CCPA; it does not incorporate it for other data. | Cloudflare global edge network. Traffic is served from the point of presence nearest the visitor, so processing is not US-only. |
| Cloudflare Web Analytics | Live: Cloudflare Web Analytics is on, since the site deploy of September 23, 2026 at 01:17 UTC (the evening of September 22 in US Eastern time). This list was not published then, so no 30-day notice ran before it began processing; the Privacy Policy has disclosed it since that deploy. A Conditional row for it was drafted on 2026-09-15 and never published. It processes data about visitors to the havara.app marketing site, collected by Havara as controller for its own purposes; it receives no member data | Measures page views and page-load performance on havara.app through a beacon script the site build embeds in every page except those whose address can carry an invite code or a single-use token (the invite page, the vendor reply and listing pages, and the not-found page), which also send no referrer. A separate integration from the Cloudflare row above, which is our hosting and DNS provider rather than this product. | The page path and the referrer, not the query string; timing and Core Web Vitals metrics read from the visitor's browser Performance API, including the slowest or shifting page element; country, browser, operating system and device type derived from the request, which carries the visitor's IP address. | Per Cloudflare's published Web Analytics documentation (read 2026-09-22): it does not log query strings, uses no client-side state such as cookies or local storage, does not collect or use visitors' personal data, states for its Core Web Vitals reporting (Vitals Explorer) that it does not fingerprint individuals via their IP address, user agent string or any other data, and does not track individual end users across the sites that use it. Raw beacon data is kept 7 days and aggregated to about 10 percent of its volume after that; six months are visible to us. | Cloudflare's global edge network; the beacon loads from Cloudflare's own script host and reports to Cloudflare's own collection domain, not to a domain we control. The beacon loads without Subresource Integrity because Cloudflare updates the script in place and publishes no hash, and the site's security policy limits the addresses scripts on the page may connect to and where forms may submit. That policy caps two routes out and not a third: it does not stop a compromised script from sending data by navigating the page away, carrying what it collected in the destination it navigates to. |
How the AI Ask subprocessors fit together
Two AI vendors currently see a slice of an Ask request (OpenAI to search, Anthropic to answer). A third, TypeSafe, is declared but switched off. None is told who asked.
When a member uses the AI "Ask" tab, the request is handled server-side and touches two live subprocessors in sequence. The declared TypeSafe test evaluation remains off:
- OpenAI first receives the question at its moderation service (a moderation call that times out or errors lets the question through rather than blocking it), then embeds the question text so the right passages of the community's governing documents can be retrieved, and (separately, at document-upload time) embeds document text for Ask search. AWS Textract performs OCR on scanned PDFs that have no text layer.
- Anthropic composes the final cited answer from the member's question, earlier turns retained after current citation-access checks, and the retrieved document excerpts.
- TypeSafe (currently off) would evaluate how well each retrieved excerpt supports the question. Its result would be logged without raw question or excerpt text and would not affect the answer.
In both cases the document content and the question text go to the provider, but no account identifiers are included in the request body. Ask conversation thread titles are not generated by any AI vendor. The app derives the title from the first question locally. Boards can toggle a document out of Ask, which deletes its text chunks and embeddings from retrieval.
Ask checks current access to each recorded cited document before reusing an earlier turn or cached answer. Invalid citation data or a failed check prevents reuse; fixed replies with no document content, such as the reply that nothing relevant was found or the reply about who the assistant is, can be reused without citations. Stored citations may omit retrieved sources, so these checks cannot establish access to every source previously used. Your own saved history remains available to you. OpenAI's follow-up embedding prefix uses at most one earlier question (the most recent one that still passes the current access checks, which can be older than your last question), or none.
Services that are not subprocessors (but you should know about)
One infrastructure service sees our servers' traffic but not your account data, and the services we would use to find businesses see only what we search for. (Google Fonts was listed here until the web console and havara.app began serving their own fonts; neither sends a font request to Google now.)
- esm.sh (server-side dependency CDN). Our server-side Edge Functions load their code dependencies from the
esm.shCDN. These are server-to-server requests for JavaScript modules; no member personal data is sent. The CDN never appears in the data path of any request that carries member content.
- Web search and map services (finding businesses to email). If Havara starts emailing businesses about Havara, its sales tool would send web search services, such as Serper, and public servers that serve OpenStreetMap data only the kind of business and the place it is looking in, never a person's name, and would read the public results. None of them would receive member data or any business contact record. On November 2, 2026, one test search sent its query to two public servers that serve OpenStreetMap data. Both failed, and it recorded no business.
What we DON'T do
- No advertising SDKs, no ad networks, no data brokers. Member data is never sold or shared for advertising.
- No payment processor for dues. The community subscription is billed through Stripe (see its row); Havara never receives card, bank, or ACH data. Dues standing is board-entered, read-only information.
- No SMS provider. The SMS announcement channel is unwired and sends nothing.
- No AI vendor receives account identifiers in request bodies, and no AI vendor generates Ask thread titles.
Changes to this list
We may add or replace subprocessors as the service evolves. When we make a material change to this list (including switching a Conditional vendor to Live), we will provide notice at least 30 days before the new or newly enabled subprocessor begins processing personal data, giving affected communities a reasonable opportunity to review and object per the DPA §7.
Two Conditional vendors were switched to Live before this list was updated: Resend on 2026-08-05 and Sentry on 2026-08-26. Our Privacy Policy commits us to update this list before switching a Conditional vendor on, and in both cases the list was corrected after processing began rather than before. Advance notice cannot be given retroactively.
Cloudflare Web Analytics has been on since the site deploy of September 23, 2026 (01:17 UTC; the evening of September 22 in US Eastern time). This list was not published then, so no 30-day notice ran before it began; the Privacy Policy has disclosed it since that deploy, and it appears on this list for the first time as Live. It processes data about visitors to the havara.app marketing site, collected by Havara as controller for its own purposes, and receives no member data.
Havara determined on 2026-08-28 that no community had accepted a DPA and none was in force. The original DPA took effect on first publication at havara.app/dpa, so no Customer existed then to receive the §7.3 notice or to exercise the §7.4 right to object, and nothing is owed retroactively to any counterparty. What was broken is the Privacy Policy's public commitment, not this page's or the DPA's (neither had been published) and not a contract.
This native-crash revision is in effect from October 30, 2026; the prior list was in effect from October 6, 2026 to October 29, 2026. Havara treats its first publication as the DPA §7.3 notice for every subprocessor on it: a community bound by the DPA from October 6, 2026 may object to any of them under §7.4 until November 5, 2026. That earlier window does not cover the newly listed Workspace mailbox or the corrected Cloudflare routing scope; their separate notice remains unsent.
The Google Workspace support-mailbox entry and the named Cloudflare forwarding addresses correct processing that already happens. Both corrections will be included in the customer admin notice under DPA Section 7.3, with the Section 7.4 objection period of 30 days. That notice remains unsent. It does not make the existing processing newly activated or turn a late disclosure into advance notice. These corrections take effect 30 days after the notice date. The earlier native-crash revision retains its October 30, 2026 effective date. PostHog remains Conditional and OFF.
To be notified of changes, watch this page or email [email protected] with the subject "subscribe: subprocessors".
The support-correspondence amendment takes effect 30 days after the notice date. Earlier amendments retain their stated effective dates. No notice for this amendment has been sent.
This list reflects the subprocessors in use as of its effective date above. It makes no claim to any security certification or audit (such as SOC 2, ISO 27001, HIPAA, or PCI); see the Security Overview for the measures actually in place. The Data Processing Addendum that covers these subprocessors is the DPA between Havara LLC and each community; how long data is kept (on our side and each vendor's) is in the Data Retention Schedule.
Optional product analytics
Havara's optional PostHog product analytics is currently switched off in the phone app and console. Nothing is sent. Activation is planned for a date at least 30 days after the customer-admin notice is sent; that date has not been set. Publication, the notice, a recorded Privacy Policy Section 17 materiality decision and any required acceptance, verified project privacy settings and retention, and the full notice period must precede key placement. The Subprocessor List remains Conditional until a separate update after the first verified event.
Once activated, it is off unless you turn it on in Profile or Your account. It sends only the event names and scalar properties in the permitted event list below, a random installation identifier and a timestamp. It is not linked to your account: no account, community, conversation or content identifier, names, contact details, message text, page queries or fragments are sent. There is no identification call, person profile, autocapture or replay. PostHog receives the connection IP address; before activation its project must be set to discard client IP data and disable GeoIP enrichment. It must not infer a location from these events. This does not change Sentry, Cloudflare or Google's separate processing.
The phone keeps the installation identifier with a local account marker in device storage. The console uses session storage, with a tab-memory fallback. The account marker never leaves the device. The identifier is removed on sign-out, account change, consent withdrawal and confirmed account deletion, then recreated on the next permitted send. A session restore for the same account keeps it. Demo and mock activity is never sent. Previously sent events cannot be located by account for export or deletion, because there is no account linkage or PostHog deletion integration. They expire under the project's retention setting, which is unknown until project creation and must be verified and published before activation.
Permitted events and properties (all other events and properties are dropped):
| Event | Properties |
|---|---|
| app_open | none |
| message_sent | is_reply, has_mention (booleans); kind (general, group, direct, board) |
| announcement_posted, announcement_edited | is_official, requires_ack (booleans) |
| bulletin_posted, bulletin_acknowledged, poll_voted, document_opened, question_asked, notifications_opened | none |
| poll_created | option_count (non-negative integer) |
| event_created, notifications_cleared | count (non-negative integer) |
| event_rsvp | state (going, maybe, not_going, none) |
| push_previews_set | enabled (boolean) |
| console_page_view | route (one of the console's fixed route patterns, or unmatched; no query or fragment) |