Havara: Data Retention Schedule
Effective October 30, 2026
Last updated October 19, 2026
Your data lives in one US database while your account is active. When you delete your account, your personal records are erased and anything you posted into shared community spaces is anonymized so other members' conversations stay intact. The handful of hard time limits that exist in the product and in our vendors' terms are listed below. Where a period is a policy default rather than something the product enforces, we say so.
This schedule states how long Havara (the invitation-gated HOA / residents' community app operated by Havara LLC, a Georgia limited liability company) keeps each category of personal data, and what happens to it when you delete your account or a community leaves the platform. It is the companion to the Privacy Policy, the DPA §10, and the Subprocessor List. Every period below is either enforced by the product, stated in a vendor's published terms (with the date we read them), or an honest policy default that is not yet automated. Each row says which.
1. The retention model
Lifecycle-based (kept while you're a member, removed or anonymized when you leave) with a short list of fixed windows on top.
Havara does not warehouse data on fixed multi-year schedules. The default rule for everything you or your community put into the service is:
Retained while your account and community membership are active; erased or anonymized when you delete your account.
On top of that default sit the fixed windows in §3 (enforced in code or by a vendor's published terms) and the policy defaults in §6 (adopted by Havara, not yet enforced by an automated job; flagged honestly).
All data lives in a single hosted Supabase project in the United States, region us-east-2 (US East / Ohio). Nothing in this schedule moves data out of that region.
2. Retention by category
One table, one row per data category, with the exact deletion behavior.
"Erased" means the row (and you) are gone. "Anonymized" means the content survives for the community but the author reference is removed; it displays as "Member" and can no longer be linked to you.
| # | Category | Kept for | On account deletion |
|---|---|---|---|
| 1 | Account & profile (name, email, phone, avatar, bio) | Life of the account | Erased: the auth record is deleted and every per-user row cascades with it; the avatar image is removed from storage in the same flow |
| 2 | Community memberships, roles, unit/tenancy links, join requests; your member list choice for each community | Life of the membership. Your member list choice outlives the membership: it is kept after you leave a community and applies again if you rejoin (you cannot change that community's choice until then), until you change it, delete your account, or the community is deleted | Erased (cascade from the profile row) |
| 3 | Chat messages & DMs (text) | Life of the community, until you delete a message. Deleting a message removes its text for everyone at once. Apart from a request someone made from the message (end of this row), a copy is kept only for your community's moderators, and only when a report on the message is open when you delete it: then until 90 days after the report is closed. That copy is a moderation record, not part of your self-serve data export, where a deleted message has no text. A message a moderator removed is kept for the moderators until they restore it, and once its author deletes it, until 90 days after its report closed. A message the chat filter holds for review is kept like any other message. When a report on a message is filed, the moderators keep the text it had then with that report, on the same rule: until 90 days after the last report on it is closed, and gone at once if you delete the message while no report on it is open, unless a moderator had removed it. A deleted message's photos and files can no longer be opened in chat by anyone, moderators included, though a link someone already loaded keeps working for up to an hour; the stored file itself is not yet erased (not built). A request someone made from the message before it was deleted keeps the message's text and a copy of its photo, and both follow the request (row 16), not this row. A board pin lasts until a board member unpins it, or the message is edited, has a file added, is deleted (a new event's line is deleted when its event is removed, row 7) or is removed; restoring or releasing the message does not bring the pin back. | Anonymized (messages remain in the thread, author removed); a copy kept for an open report follows the same 90-day rule. A pinned message stays pinned when its author leaves. The pin's record of who set it is cleared when that board member deletes their account, and the pin stays |
| 4 | Chat participation, reactions, read receipts | Life of the account | Erased (cascade) |
| 5 | Chat/DM photo, video & file attachments | Life of the community (they belong to the thread) | Remain with the anonymized message |
| 6 | Announcements, comments, acknowledgements, and the earlier versions of an edited announcement (each kept when the board changes a notice's title, text, audience or flags; read by the community's administrators; no erase path) | Life of the community. A withdrawn announcement is kept, with its withdrawal date | Announcements/comments anonymized; your acknowledgements erased (cascade); on an earlier version you edited, your account identifier is cleared and the wording stays |
| 7 | Events & RSVPs | Life of the community / account. A new community-wide event's line in the community's main chat ("New event:" and its title, under the posting board member's name) is a chat message and follows row 3; it keeps the title as first posted, and is removed when the event is removed (or when its author deletes it, or a moderator hides it) | RSVPs erased (cascade); the event and its chat line stay, the line's author anonymized as in row 3 |
| 8 | Amenity bookings | Life of the account | Erased (cascade) |
| 9 | Governing documents (board-uploaded PDFs) | Your board can set how long each kind of document is kept. While that period applies to a document, nobody can remove it in the app, except in its first 7 days after upload, or after a board administrator shortens or clears the period, which the activity log records. Havara can remove a document on a valid legal request. Documents stay with the community until removed, including earlier versions, and are deleted with the community. A version the board marks replaced by a newer one is kept, readable to members under the newer version's earlier versions, until it is removed under the same rules. A deleted document's file is removed by the daily sweep, normally within two days (see §3). Before this sweep included documents, a file could remain in storage after its document was deleted. | Unaffected (community property, board-controlled) |
| 10 | Document text chunks & AI embeddings | Only while the document exists, is AI-enabled and has not been replaced | Deleted immediately when the board removes the document, toggles it out of Ask, or marks it replaced by a newer version |
| 11 | AI "Ask" questions, answers & threads, and the thumbs up or down you give an answer (kept on the answer) | Life of the account | Answers anonymized; thread linkage to you removed |
| 12 | Poll & survey votes (stored per account even for anonymous-display polls) | Life of the account | Erased (cascade) |
| 13 | Violation cases in which you are the named subject, incl. the case photo, and the hearing notices, written decisions and fine committee votes on them | Life of the account | Erased (the case rows cascade away with your profile). The case photo is then deleted from the private violation-photos bucket by the orphaned-photo sweep, normally within two days; until then it is unreadable through the app, because the case row is gone (see §3) |
| 14 | Violation/ARC/request actions you took as a board member (opened, decided, assigned, sent a hearing notice, recorded a written decision or a committee vote, posted an entry on a home's balance as a community administrator or someone who handles compliance (a charge such as dues, an assessment, a fine, a fee or interest; a credit, refund or write-off; a recorded payment; or a reversal of any of them), created an assessment (what your community charges each home), acknowledged consideration before an architectural denial, listed a record withheld from a records request or took one off that list, saved the copy-cost schedule, named a director and set the meeting on a meet and confer request, or, as that director, proposed or confirmed its written resolution) | Life of the community | Anonymized (actor references set null); the withheld item, the schedule and the assessment stay. On a meet and confer request you were the director of, the link to your account is cleared and your name and seat stay in its thread lines as they were recorded, as on signed minutes (row 33), until that request is erased with its requester's account; completion-inspection notes, results and photos instead stay only while their parent request exists, with the event actor cleared on inspector deletion |
| 15 | ARC (architectural review) requests you submitted, incl. photos and your optional installation category, and any request to reconsider them (erased with the request) | Life of the account | Requests and their installation category erased (cascade), and with them a request to reconsider a denial and the meeting and outcome the board recorded on it, which are stored on the request and its trail. The photos are then deleted from the private arc-photos bucket by the orphaned-photo sweep, normally within two days; until then they are unreadable through the app, because the request row is gone (see §3). Photos you uploaded to an ARC request you never submitted are deleted the same way when your account is deleted (see §6 item 6) |
| 16 | General resident requests you opened, incl. the photo (a request made with the phone's "Make this a request" starts with the chat message's text and holds a copy of its photo: both follow this row, not the chat message's, so deleting or hiding the chat message does not remove them); this includes records requests and the response date your board set on one, and on a records request your delivery choice, the board's estimate and invoice, and the board's list of records it withheld from you (an item the board took off that list is kept, marked with who removed it and when, until the request itself is erased); and on a meet and confer request the director and meeting your board set and the written resolution, proposed or confirmed by both of you | Life of the account | Erased (cascade, the withheld list with its request, and a meet and confer request with its confirmed resolution and its thread lines). A copy your board downloaded with the community record is the association's and is outside Havara's erasure; comments by others on the thread are anonymized, not erased. The photo is then deleted from the private request-photos bucket by the orphaned-photo sweep, normally within two days; until then a community admin can still read it by path although no screen shows it (see §3) |
| 17 | Emergency alerts & responses | Life of the community | Alerts you raised anonymized; your responses erased (cascade) |
| 18 | Budget, reserve & per-unit dues standing (board-entered, read-only; no payment data exists) | Life of the community | Unit records are community data; the membership link to you is erased. A dues or assessment charge you posted on a home's balance as a community administrator stays, with your name cleared from it (row 14) |
| 19 | Moderation records (content reports, including the reports the chat filter files with no reporter, hides, case notes, blocks) | Life of the community | Your blocks/reports cascade with your account; moderation records about content survive with the content |
| 20 | Audit log of board/governance actions | Life of the community: no automatic purge exists in code and no retention window is defined yet (see §6) | Anonymized (actor reference set null) |
| 21 | Invitations (code + recipient email) | Redeemed invites live with the resulting membership; unredeemed: 90-day policy default, not yet code-enforced (§6) | Invites you sent are anonymized (your name is removed as the sender) |
| 22 | Invite-redemption rate-limit ledger | 1 hour (self-sweeping) | Already gone |
| 23 | Expo push token & notification preferences, including your notification level for each chat (All messages, Mentions only, Daily digest or Off, and when a timed Off ends), the record of when a daily chat digest was sent to you, and your daily chat catch-up email setting | Life of the device registration (token); a chat's level until you change it, or the chat is deleted (leaving a community does not remove it, and it applies again if you rejoin); digest records 30 days, except the latest one | Erased (cascade with profile); tokens are also nulled automatically when a device reports itself de-registered |
| 24 | Consent records (Terms/Privacy acceptance ledger) | Life of the account: append-only while it exists (no client update/delete) | Erased (cascade) |
| 25 | Marketing-site waitlist entries (name, email, community, role, note) | Undefined: no purge exists; see §6 | Independent of any app account (submitted pre-signup); deleted on request to [email protected] |
| 26 | Vendor digest send records (community, the covered placement ids, the subject line, the recipient count, the suppressed count, the operator, the send time) | Undefined: no purge exists, and no row exists, because no digest has ever been sent | Unaffected. The record holds no recipient addresses, only a count, so there is no personal data in it to erase when a recipient deletes their account |
| 27 | Vendor digest opt-out list (an email address, a normalised match key, how the opt-out arrived, and when) | Deliberately indefinite. Deleting the record would quietly undo the opt-out and let the same address be emailed again, which is the failure mode the list exists to prevent | Survives account deletion by design. The list is keyed to the address, not to a profile, and is global to Havara rather than per community, because someone who unsubscribed must not become emailable again by deleting an account or by joining a different community |
| 28 | Declared interests you made in a vendor (your statement, the vendor, when you declared it and when you withdrew it) | Life of the account, withdrawn or not: withdrawing marks one withdrawn and keeps it, and nobody can edit or delete one in the app. If Havara removes its words under the community guidelines, they are replaced at once and kept nowhere but database backups, which age out; the declaration, its dates and the author's name stay for the life of the account | Erased (cascade from the profile row), and erased if the vendor row itself is deleted, which no screen does; removing a vendor from the directory keeps it |
| 29 | Havara's record of removing a declaration's words (who at Havara, when, why, and the report that prompted it; never the words) | As long as the declaration exists | Erased with the declaration (cascade), so when its author deletes their account. A report on an erased declaration keeps its row with its pointer cleared (row 19) |
| 30 | Board seats (the seat title, its optional owner-elected or declarant-appointed category, the holder, the term dates your board entered) | For the life of the seat: the board can edit or remove it at any time, and it goes with the community | On account deletion, and when the holder leaves or is removed, the holder is cleared and the seat, its title, recorded category and dates stay on the community's roster. Paused access leaves the holder on the row; members see the seat as vacant |
| 31 | Compliance calendar (the deadlines your board enters: title, kind, due date, how often it repeats, how far ahead to remind, source note and notes; the owner; who added, marked done, undid or removed each one; any note added when marking one done; the record of which reminders were queued) | For the life of the community. A deadline the board removes is hidden, not erased: it leaves every screen and the community record download, and its row and completions stay. There is no restore and no purge | When the owner leaves or is removed, the owner is cleared and the deadline stays, unassigned. On account deletion, your account identifier is cleared from the deadlines you added or removed and the completions you recorded or undid; the dates and notes stay with the board's record. The reminder record holds no person, only the deadline, its due date and the state |
| 32 | Member email queue (which email was due to you, about what, and whether it was sent; titles, dates and amounts, never an email's text; for a daily chat catch-up, only the period it counts, the counts being worked out when it is sent) and your email switches (in place; member email was switched on on September 30, 2026) | Queue rows: up to 90 days from when they were queued, once sent, skipped or failed, then deleted by a daily job; a row past its shelf life (6 hours to 14 days by kind) is marked skipped first. The switches: life of the account | Erased with the account (cascade), queue and switches alike |
| 33 | The board's meeting record: motions with the mover's and seconder's names, each director's vote with their name, seat and any recusal, consents to actions taken without a meeting, action items, the signature on signed minutes (approval date, signer's name and seat), and every saved version of the minutes, the text as signed and each correction | For the life of the community. Signed minutes and their corrections cannot be edited, withdrawn or removed, by the board or by Havara's app, and neither can any saved version of the minutes; only a reviewed change to the database itself could alter them, and no way to remove them is built. A motion or action item the board removes is hidden, not erased. Deleted with the community | The names stay: a director's name recorded on a motion, a vote, a consent or a signature stays in the association's record. Your account identifier is cleared from every one of these rows |
| 34 | Registers: the insurance policies, service contracts and bids, reserve components, building inspections and maintenance tasks your board records, with the other party's name (an insurer, contractor, bidder, engineer or vendor), the amounts, dates, notes and document links, an inspection's report-received date, the date the board says it delivered the summary to owners and the repair status, and the operating balance your board types for its fidelity coverage check | For the life of the community. An entry the board removes is hidden, not erased: it leaves every member's view and the community record download, and the board can restore it. There is no purge. Deleted with the community | On account deletion, your account identifier is cleared from the entries you added or removed and from the operating balance if you set it last; the entries and figures stay with the association's record. The reminders an entry made (renewals, cancel-by dates, inspection due dates, summary deliveries and recurring maintenance) are compliance deadlines and follow row 31 |
| 35 | Meeting agenda items, executive session minutes and meeting notice rules: the items on a meeting's agenda (titles and details, the executive session topic and notice tags), the minutes of each executive session, and your board's three notice periods | For the life of the community. An agenda item the board removes is deleted (it is added again by typing it). Executive session minutes are never replaced or erased by a save: each save is kept as a new version, the latest is shown, and every version stays in the community record download. There is no purge and no delete for them. Deleted with the community | On account deletion, your account identifier is cleared from the items you added, the minutes versions you saved and the rules if you set them last; the text stays with the association's record, including a name written into executive minutes or an agenda item |
| 36 | Official notice consent, date/source and signed form date; primary and secondary delivery methods, postal/email destinations, representative name/address/email and preferred language; recorder and revision | Until the owner clears the details or the account/community is deleted. Leaving ends administrator access but keeps the private row. The self export includes it; the community export excludes both postal addresses and all eight additional fields. A board print is a current instruction sheet, not a historical delivery snapshot | Erased with the profile or community through the existing cascade. Deleting the recorder clears their id. The existing ids-only audit record follows row 20; clearing contact details does not erase that audit |
| 37 | Requests to speak, board packet items and meeting recording links: who asked to speak at a meeting, on which agenda item or in the owner comment period, when, and whether the board recorded that they spoke; which documents your board shared with a meeting and whether each was kept confidential; the address of a meeting's recording | For the life of the meeting, which is kept for the life of the community. A packet item also ends when the board removes it from the packet or the document is deleted from Documents, and a recording link when the board removes it. Havara keeps the link, not the recording, so how long the recording itself is kept, and whether it stays unedited, is up to wherever your board hosts it. Deleted with the community | On account deletion, your requests to speak are erased. If the board recorded that you spoke, the draft minutes Havara prepares list your name and the item, every member reads them once the board publishes the minutes, and that text stays with the association's record. A packet item you attached stays with the association's record with your account identifier cleared |
| 38 | Accommodation requests you filed: what you asked for and why (which may include information about a disability), the documents you attached and their names, your replies, your community administrators' questions and decisions, and whether you withdrew it | While your account exists, also after you leave the community; deleted with the community. A document you remove leaves the request at once, and its file is deleted from the private accommodation-documents bucket within about two days | Erased (cascade): the requests, their threads (the administrators' questions and decisions included) and the document records go at once, and the orphaned-photo sweep deletes the files, normally within two days; no administrator can open them in the meantime. Havara keeps no copy. If you are an administrator who answered someone else's request, your lines and decisions stay with that request, with your account identifier cleared |
| 39 | Feedback you sent Havara from Report a problem (phone app) or Send feedback (web console): what you wrote, the kind of problem, the community you had open and your role there, where it came from, the platform and the app version | 24 months, then deleted by a daily job at 06:30 UTC. Havara operators can mark it read or closed; neither shortens or extends it | Erased (cascade) |
| 40 | Sign in with Apple or Google (phone app from version 2.3): the identifier the provider issued and what it shared with Havara, and for Apple a refresh token kept only to end Havara's access at account deletion | Life of the account. A later Apple sign-in replaces the token. The record that Havara asked Apple to end its access, kept after the account is gone: no window defined yet (§6). On the phone, not on Havara's servers: the Apple name until it is saved or, if it is still unsaved after 30 days, until the app is next used signed in on that phone, and Google's sign-in record until sign-out of Havara on that phone, neither of which a deletion from the web console reaches (Privacy Policy §3) | Erased (cascade), after one step: the Apple token, or on iPhone a fresh code (exchanged for a token kept in the request), is copied into a request to Apple and cleared from it when Apple answers; if Apple cannot be reached or does not answer, the request is retried for up to 24 hours and then cleared, so the token and the Apple identifier outlast the account by at most 24 hours, plus 15 minutes if an attempt is interrupted, plus an hour, and an hour or so longer only if a cleanup run finds the record busy. What remains is the record that Havara asked, holding the deleted account's identifier, whether it worked and when. A request made ready for a deletion that did not go ahead is deleted after one hour (§3) |
| 41 | Security desk guest passes (only where the board turns the desk on): your guest's name, the days and hours they may come, an optional plate and desk note, and the pass code | 90 days after the last valid day or after cancellation, then deleted by a daily job at 06:50 UTC. Leaving your home cancels the passes you made for it | Cancelled when your seat ends, kept with the home without the link to you, and deleted on the same 90-day clock |
| 42 | Vehicles registered to a home (plate, state or region, make, model, colour) | Until someone seated on the home who can see it removes it (someone seated after it was registered sees it only if they also staff the desk), the seat of the person who registered it ends, or the home is deleted; no time limit otherwise. Someone who staffs the desk can remove one only for a home they are seated on | Deleted at once: deleting your account ends your seat, which deletes the vehicles you registered |
| 43 | Security desk entry log (each guest admitted or turned away for a home: name, optional plate, outcome, note, who recorded it, when) | 12 months, then deleted by the daily job | Kept for the community; your account identifier is cleared from entries you recorded |
| 44 | Parcels the desk logs for a home (the name on the label, carrier, last 4 of the tracking number, size, where it is kept, note, who logged and handed it over, the typed name of whoever collected it) and the desk's reminders about them | 12 months after it is collected or returned, or 12 months after it was logged if neither happened; reminders go with their parcel | Kept for the community; your account identifier is cleared from parcels you logged or handed over. A typed name stays until the parcel's own deletion |
| 45 | The security desk's shift log (notes, handovers, incidents) | 24 months, then deleted by the daily job | Kept for the community; your account identifier is cleared from notes you wrote or acknowledged |
| 46 | Devices and spaces assigned to a home (fobs, remotes, gate cards, keys, parking spaces, storage lockers, equipment) | While assigned; an ended one 24 months after its end date, then deleted by the daily job. The audit log entry made when one is assigned or ended (its name and who did it, not the home) is kept for the life of the community, as row 20, and your community's administrators can read it even while the desk is off | Kept with the home; your account identifier is cleared from ones you assigned, and from the audit log entries you made (row 20) |
Your own copy, any time. Before deleting anything you can export your data in-app: Profile ▸ Privacy & data ▸ Download my data produces a versioned JSON bundle of your records. Community administrators can also make filtered CSV or browser PDF copies of existing violations, architectural requests, resident requests and register entries not removed, including drafts. The source records keep their existing lifetimes; Havara stores no report file or saved filter. A verified file snapshot is one-use for at most60seconds in page memory and clears on context/filter changes or focus departure; a later server-only role change cannot recall bytes already returned. The preparation audit records only administrator, community, kind and time, follows row20 and does not prove a file was saved. Account deletion anonymizes that actor. Downloaded/printed copies are controlled by the association and cannot be erased or recalled by Havara.
Private board discussion. The console has a separate text thread for current approved community administrators, including management administrators assigned to the community and declarants with that role. Other members cannot read it. Havara keeps each message, its author account link, its community and its posting time. Posting and removal add activity records with the actor, community, message identifier and time, without the message text. The thread does not send notifications or feed community chat or search. You can remove your own message while you hold an administrator role. Removal erases its text and keeps a dated placeholder and activity record. Losing that role ends thread access and self-service removal. Deleting your account clears your author account link but retains the text, which may still identify you. Community deletion removes the thread. Your personal download includes messages you wrote, even after leaving; a current administrator's community download includes the thread. Removed text is absent from both downloads. Havara cannot recall copies someone already received. Backups follow the existing backup schedule. For a privacy request after losing access, contact [email protected]. Formal decisions belong in Meetings.
Completion inspections on architectural requests. The date, result, note, links to the approval and earlier inspections, and photos stay with their parent request, including earlier corrected records. Leaving membership keeps earlier own-request access but stops new inspections. Deleting the requester's account or the community removes the request and its inspection records. Inspector deletion clears the inspector account link while another requester's retained notes and photos remain; images, prose, file metadata and returned copies may still identify someone. Personal and community JSON copies include the relevant inspection fields, with photo bytes separate. Havara cannot recall copies you already downloaded or photos already loaded on your device. Actual inspection references retain attached completion photos; unreferenced completion uploads are candidates after 24 hours or uploader deletion through daily file cleanup, at most 200 files per run across the covered storage areas. Candidate eligibility is not an exact deletion deadline. Older ARC draft photos remain until the uploader deletes their account.
Committee records. Committee metadata, appointment history, messages and file records last for the community. Appointment history retains an account identifier after departure; account deletion clears relational account and membership links, not titles, unremoved text or PDF content. Former member is a display label, not anonymization. Storage uploader metadata stays with a stored PDF. Current appointment loss ends content access and own removal; any current administrator may remove content without reading it, including read-only. Removal erases text or filename, path and byte-count fields and retains a dated tombstone and metadata-only audit record. An active referenced PDF remains stored after its uploader deletes their account. Unreferenced PDFs become eligible for the existing bounded orphan sweep after 24 hours, or once their uploader account is gone. New attachment is limited to the first hour after upload. Cleanup remains pending until a successful sweep and can be delayed by failures or backlog. Community deletion cascades committee rows and leaves file objects for that sweep. Personal downloads retain your authored records and appointments after leaving. Community downloads include private content only for committees the exporting administrator is currently appointed to; neither download contains PDF bytes. Queued committee email expires after three days; its private first-send timestamp follows existing outbox purge and provider retention. An unfinished send holds capacity until that update expires plus 24 hours. Retries stop 23 hours after the first attempt; a failed or conflicting retry may still have been delivered. Copies already received and backups follow the existing schedules and cannot be recalled.
3. The hard numbers
Every fixed time window that actually exists today, in one list.
| Window | What it applies to | Source |
|---|---|---|
| Immediate | Document embeddings/chunks when a document is removed or AI-disabled | Enforced by the product |
| Immediate (in the deletion flow) | Avatar image removal on account deletion | Enforced by the product |
| 1 hour | Invite-redemption rate-limit entries | Enforced by the product |
| 1 hour | An Apple sign-in revocation request made ready for an account deletion that did not go ahead, and the Apple token store's rate-limit entries (§2 row 40), which are also erased at once when the account is deleted; and, after 24 hours of retries, the Apple token or code and the Apple identifier in a revocation request Apple has not answered | Enforced by the product (an hourly scheduled job, and on each new request) |
| 24 hours | Push-delivery receipts held by Expo | Expo's published docs (read 2026-07-12) |
| 7 days | Daily database backups at Supabase. Each daily backup is kept for 7 days, so data removed from the live database as this schedule describes stays only in the backups taken before its removal, until they expire about a week later. Point-in-time recovery is not enabled (§4) | Supabase project backup settings (read 2026-10-02) |
| 7 days | Request and sign-in logs at Supabase (platform logs, not written by app code): for each request the app or console makes, the IP address, the user agent, the approximate location Cloudflare derives from the IP address (city, region, postal code, country, time zone) and, when the member is signed in, the account's user id; sign-in events also record the email address. Account deletion does not reach them; they expire | Supabase's published log retention for the Pro plan (pricing page, read 2026-09-25), the plan the Management API reports for the organization; not yet read from the project's dashboard |
| Up to 30 days | Ask questions, the earlier turns of the thread and the document excerpts sent to Anthropic to compose an answer. Anthropic deletes API inputs and outputs within 30 days, with exceptions its 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's Commercial Terms say it may not train models on customer content from its services | Anthropic's Commercial Terms (effective June 17, 2025) and its published API retention terms (updated July 1, 2026), both read 2026-10-02 |
| Up to 30 days | OpenAI abuse-monitoring logs for Ask embedding calls (OpenAI does not train on our API data absent opt-in) | OpenAI's published API data policy (read 2026-07-12) |
| Duration of the scan | Havara's copy of a scanned PDF staged in AWS S3 for Amazon Textract. Havara deletes it after the scan; a 1-day bucket lifecycle rule is the backstop if that delete does not run. This window covers Havara's staged copy only. AWS's service terms allow it to store what Textract processes to provide and maintain the service, under AWS's own retention, and would also let it use that content to improve Textract and other Amazon AI services, and keep some of it in another AWS region, unless an AWS AI services opt-out is in place; Havara has had that opt-out in place since September 23, 2026, covering Textract and every other AI service the policy covers | Enforced by the product, with a storage lifecycle rule as backstop; AWS Textract FAQ (fetched 2026-09-22, re-read 2026-09-23); AWS Organizations AI services opt-out policy (verified 2026-09-23) |
| At account deletion, and daily | Photos in violation-photos, arc-photos and request-photos that no case or request references (the row was erased with an account or a community, or the upload was never attached), files in accommodation-documents that no accommodation request's document record attaches (the requester's account was deleted, the member removed the document, or a filing that uploaded it was refused), and files in documents that no document references (the document was deleted, its community was deleted, or the upload never became a document). The sweep runs when an account is deleted and daily at 06:40 UTC, and deletes through the Storage API, at most 200 objects per run, taking photos whose uploader's account is gone first. In violation-photos and request-photos an unreferenced photo is taken once it is 24 hours old, or at once if the account that uploaded it is gone. For ordinary request photos in arc-photos it is taken only once the account that uploaded it is gone, whatever its age: the app uploads an ARC photo the moment the resident picks it and writes the request only at Submit, so a draft can hold unreferenced photos for days. accommodation-documents follows the request-photos rule: once 24 hours old, or at once if the uploader's account is gone, so a removed document's file goes within about two days. In documents an unreferenced file is taken once it is 24 hours old, never earlier because the account that uploaded it is gone. A deleted member's photos and accommodation documents, and a deleted document's file, are therefore normally gone within two days. Unreferenced completion uploads in arc-photos are eligible once 24 hours old or when their uploader is gone; actual inspection references keep them. | Enforced by the product (a daily scheduled job) |
| Within a day of no document referencing it | Text extracted from a scanned PDF, stored keyed by the file's SHA-256 so the same file is never scanned twice. Removed by a daily job at 06:50 UTC, once no document refers to that file. Before that job was scheduled, nothing ran the purge, so text could remain after the last document that used it was deleted | Enforced by the product (a daily scheduled job) |
| 30 days | Records of when a daily chat digest was sent to a member, except each member's latest, deleted by the hourly digest job | Enforced by the product (an hourly scheduled job) |
| 24 months | Feedback you sent Havara (§2 row 39), deleted by a daily job at 06:30 UTC once it is 24 months old; erased at once if you delete your account | Enforced by the product (a daily scheduled job) |
| 90 days after the last valid day or cancellation | Security desk guest passes (§2 row 41), deleted by a daily job at 06:50 UTC | Enforced by the product (a daily scheduled job) |
| 12 months | The security desk's entry log (§2 row 43); parcels and their reminders, 12 months after a parcel is collected or returned, or 12 months after it was logged if neither happened (§2 row 44); the same daily job | Enforced by the product (a daily scheduled job) |
| 24 months | The security desk's shift log (§2 row 45), and a device or space 24 months after its end date (§2 row 46); the same daily job | Enforced by the product (a daily scheduled job) |
| 90 days after the report is closed | The moderators' copy of a chat message its author deleted while a report on it was open, and the text a chat message had when each report on it was filed. Checked daily at 07:20 UTC; kept while any report on the message is open | Enforced by the product (a daily scheduled job) |
| 90 days after account termination | Customer data at Resend (LIVE since 2026-08-05, receives data. In short, the email address of each person we email and what each email says: invitations; sign-in emails (a single-use link or code to confirm your address, sign in, reset your password or confirm a change of address; a change of address is confirmed at both the old and the new address); member email (§2 row 32), switched on as of September 30, 2026, which carries your name in the welcome and what each email is about, such as titles, dates, times, places, amounts on your own home and the answers to your own requests, and, in each email you can switch off, a link with a code that identifies your account; the copies of compliance notices (with the board's full notice text), join and claim decisions and tenant access notices that our push notification service emails when the push did not reach you and member email does not send them; compliance calendar reminders to board members; quote requests relayed to vendors, which carry the requesting resident's phone number and email address; listing invitations; announcement copies and members' email addresses (announcement email mirroring); and alerts to our own address about new accounts, new communities, access requests and reports on a declared interest. The vendor digest will add board-member addresses here; it has sent nothing yet. This is a summary: the Subprocessor List's Resend row is the full list of what Resend receives) | Resend's published DPA (read 2026-07-12) |
| 30/90 days (events), 90 days (backups) | Error events at Sentry (LIVE since 2026-08-26, receives data: the error type and message, for both uncaught errors and the errors the app catches and reports itself; the stack trace when a real Error is passed; the call-site scope and context the app attaches; and the signed-in account's user id, plus build environment and release; the approximate location (city, region and country) Sentry works out from the IP address each event arrives from, kept with every event; and events from app versions that do not ask Sentry not to (2.2 build 36 and older; later builds ask) can carry that IP address itself, which Sentry writes in only while its project setting against storing IP addresses is off, a setting nobody has checked against a stored event. 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. First real events 2026-08-27) | Sentry's published retention docs (read 2026-07-12) |
| No window yet | Audit log: kept for the life of the community, with no purge in code and no retention window defined (§6) | Havara policy default |
| 90 days | Unredeemed invitations: policy default, not code-enforced (§6) | Havara policy default |
4. Backups
Backups exist so the service can recover from failure; deleted data ages out of them rather than being individually scrubbed.
Supabase, the underlying platform, takes a daily backup of the database and keeps each one for 7 days. Point-in-time recovery is not enabled. Data you delete is removed from the live systems as described above, and stays only in the backups taken before its removal, until they expire about a week later. Backups are not individually edited on request (DPA §10.3).
5. Subprocessor-side retention
What leaves our systems is small, and each vendor's own clock is listed on the subprocessor page.
The Subprocessor List carries a data-use-and-retention commitment per vendor. Supabase stores everything (it is the database) in us-east-2; OpenAI and Anthropic receive question text and document excerpts with no account identifiers in the request body; Expo relays push payloads and clears receipts after 24 hours; Apple relays APNs payloads; Apple and Google also run Sign in with Apple and Google sign-in for members who choose them, and each keeps its own record that the member uses Havara. Google's built-in iPhone library separately declares data whose retention period is not verified; any such records follow Google's terms, distinct from Havara's local-token cleanup. See the Google library disclosure in Privacy Policy Section 3; Resend is LIVE and receives data (since 2026-08-05: the email address of each person we email and what each email says, including invitations; sign-in emails (a single-use link or code to confirm an address, sign in, reset a password or confirm a change of address, sent to the old and the new address); member email, switched on as of September 30, 2026, which in each email you can switch off carries a link with a code that identifies your account; our push notification service's copies of compliance notices (with the notice's text), join and claim decisions and tenant access notices; compliance calendar reminders; security desk parcel notices (the community name and a link only); quote requests relayed to vendors (with the requesting resident's phone number and email address); listing invitations; announcement copies and members' email addresses (announcement email mirroring); and operator alerts to our own address, which from the signup alert onward include the name and email of every account. The vendor digest will add one community's board-member addresses, and has sent nothing to date. The Subprocessor List's Resend row is the full list); PostHog is switched off and receives nothing, because no analytics key is set in the app's production build and the per-member opt-in defaults to off and fails closed; TypeSafe is switched off and receives nothing (Conditional: it would receive the Ask question, at most the preceding one, and up to six excerpts with their document titles and section headings; its customer agreement lets it keep, use and share that data in perpetuity to derive telemetry, to monitor for fraud and abuse and to comply with law, and use the derived telemetry without restriction; it publishes no retention period, its privacy policy says it does not train models on that data, and zero data retention is an enterprise option only); Sentry is LIVE and receives data (since 2026-08-26, the first build carrying its configuration key, which was added on 2026-08-21: uncaught and handled JavaScript error types and messages, stack traces, the call-site scope the app attaches, and the signed-in account's user id, plus build environment and release, with the approximate location and, from older app versions, possibly the IP address described in §3; first real events 2026-08-27). PostHog's window above, and TypeSafe's terms, apply only if that vendor is ever enabled, which triggers 30 days' advance notice under DPA §7. Sentry's window applies today, and that 30-day notice was not given: the key was set and the Subprocessor List was corrected after the fact, so the notice came late and cannot be turned into advance notice retroactively. The same is true of Resend, which went live on 2026-08-05 without notice. Havara determined on 2026-08-28 that no community had accepted a DPA, so nothing is owed retroactively to a counterparty. The corrected Subprocessor List is in effect from October 6, 2026. Havara treats its first publication as the DPA §7.3 notice for every vendor on it, so a community bound by the DPA may object to any of them under §7.4 until November 5, 2026.
6. Policy defaults not yet enforced in code (honest gaps)
These retention promises are currently policy, not software. We list them rather than imply automation that doesn't exist.
- Audit log: no automatic purge exists; rows persist for the life of the community with the actor anonymized on account deletion. No maximum retention period or automated purge is defined yet.
- Unredeemed invitations: the 90-day policy default has no implementing job; unredeemed invite rows (including recipient email addresses) currently persist until the sender's account deletion anonymizes them. The purge is not built.
- Waitlist entries: the marketing-site waitlist table has no retention period or purge. Deletion is honored manually on request to [email protected]. No retention period for these entries is defined or automated yet.
- Orphaned chat attachments: deleting an account anonymizes messages but does not sweep the member's uploaded attachment objects, which remain part of the (anonymized) thread. This is disclosed behavior, not a bug; if policy should instead strip a deleting member's attachments, that is a product change to log.
- Vendor digest send records (§2 row 26): no retention period is defined and no purge exists. This is the mildest gap on this list, because the record deliberately stores a recipient count and never the addresses, so an undefined window keeps a commercial fact rather than a mailing list. No window has been picked yet. Nothing is at stake yet: no digest has been sent and the table holds no rows. The opt-out list in §2 row 27 is not one of these gaps: its indefinite retention is the decision, not a missing one.
- Ordinary ARC request photos of a member who still has an account: photos on erased cases and requests are now deleted by the orphaned-photo sweep (§2 rows 13, 15 and 16, §3). For ordinary request photos in
arc-photos, the sweep takes a photo only once the account that uploaded it is gone, because the mobile ARC form uploads each photo when it is picked and writes the request only at Submit, and an age rule would delete the photos of a draft left open. So a photo from an ARC draft that was never submitted, or any other ordinary ARC request photo whose request is gone while its uploader keeps their account, stays in storage until that account is deleted. Removal before then is manual, on request to [email protected]. The fix, not built: upload ARC photos at Submit, as the resident-request form does, then givearc-photosthe 24-hour rule the other two buckets have. - Apple sign-in revocation records (§2 row 40): the record that Havara asked Apple to end its access for a deleted account, holding that account's identifier, whether it worked and when, has no retention period and no purge. It holds no Apple credential once it has an outcome: the code or token is cleared when Apple answers, or after the 24 hours of retries in §3.
Until these are automated, Havara honors each period manually on request to [email protected].
7. What we DON'T keep
- No payment data. No card, bank, or ACH details exist anywhere in the system; dues standing is board-entered, read-only text.
- No GPS coordinates from a device location API. The app requests no location permission and calls no geolocation API. Approximate locations worked out from an IP address are kept against an account all the same: Supabase's request logs hold the city, region, postal code and country of each request for 7 days, and Sentry holds the city, region and country of each crash report (next bullet, and §3). Google's library also declares Coarse Location for App Functionality; the Privacy Policy explains that declaration and its limits. The quiet-hours time zone the phone reports is kept with the notification preferences (§2 row 23).
- No Havara product-analytics archives in PostHog. PostHog is off and has received nothing; there is no PostHog analytics history to retain. Google's iPhone sign-in library separately declares data for App Functionality and Analytics, described in Privacy Policy Section 3. Those are Google's declarations, not observed transmission or a Havara analytics archive. Its retention period is unverified, and signing out, deleting a Havara account or clearing its local sign-in record does not guarantee deletion of Google-held library records. This is separate from the local-token retention already described above. The thumbs up or down a member gives an Ask answer, which the app keeps to make Ask better, is stored on the answer itself and follows it (§2 row 11), not in an analytics archive. Crash reports are a different matter: Sentry went live on 2026-08-26 (§3, and the Subprocessor List), and error events have been arriving since 2026-08-27. Each event carries the error message, the stack trace, the environment and release, the account's user id when the member is signed in, and the approximate location (city, region and country) Sentry works out from the IP address the event arrives from; events from 2.2 build 36 and older can also carry that IP address, depending on the Sentry project setting described in §3. 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. These events are held by Sentry rather than by Havara and age out on Sentry's clock (events 30 days free tier / 90 days paid, backups 90 days).
- No ad-tech or data-broker copies. Member data is never sold or shared for advertising, so there are no third-party retention tails to disclose. Havara does sell paid vendor placement (in the directory, and in the vendor digest), but no member data leaves Havara to target it and no ad network is involved, so this row is unchanged by it.
- No shadow profiles. The only pre-signup personal data Havara holds is the waitlist row a person submits themselves (§2 row 25) and the invitation email a board enters (§2 row 21). Names typed at a community's security desk for guests, walk-in visitors and whoever collects a parcel (§2 rows 41, 43 and 44) are text on those records, never made into a profile, and are deleted with them.
Requests to join without an invitation code
The home address and optional unit supplied for a join request remain while the request is pending. They are erased in the same transaction as approval or decline, or when the requester withdraws. Account and community deletion cascade through the request and its private submission ledger. The request id, account/community links, status and creation/decision times otherwise remain until account or community deletion. An approved membership's registered home follows the existing membership lifecycle; deleting the registered home clears its assignment reference.
The successful-submission ledger holds account/community links and times for spam limits. Entries older than seven days are removed on a later new submission; this is cleanup on use, not a promise of deletion on the seventh day. Account or community deletion removes them sooner. The board-entered community ZIP remains until changed, cleared or community deletion. Existing lookup-meter and audit retention apply; audit targets do not contain the submitted address or unit. The requester's personal-data export includes their own still-held fields and ledger timestamps.
This processing is prospective for the unreleased request flow. Public disclosure and the October 30 effective boundary precede address collection.