Privacy Policy
Overview
HeadQrtr is a time-tracking and client relationship management (CRM) tool built by HeadQrtr LLC. This policy explains what data we collect, why, and how you can control it. We are committed to protecting your privacy and only collect data necessary to provide the service.
This policy covers the application at app.headqrtr.com, the HeadQrtr Time Tracker browser extension, and the marketing site at headqrtr.com. These surfaces collect and store different categories of data, noted where relevant below.
Data we collect
We collect and process the following categories of personal data:
- Account data — email address and hashed password for authentication
- Contact/client data — names, email addresses, phone numbers, company names, addresses, and notes you enter about your clients
- Financial data — invoices, expenses, billing rates, and payment records you create
- Time tracking data — time entries, descriptions, clients, projects, project tags/categories, billable status, timestamps, and duration. The browser extension does not read browsing history, active-tab URLs, or page content
- Content — pages, boards, proposals, and email templates you create
- Lead form submissions — responses submitted through your published forms, including respondent IP address, browser info, and referral source
- Booking data — details guests submit through your public booking page, including the guest's name, email address, phone number, notes, appointment date and time, and time zone
- Social media data — posts, profiles, and publishing data from separately connected social accounts (LinkedIn, Meta, TikTok, and, when enabled, YouTube) that you explicitly authorize
- Usage data — audit logs of security-relevant actions (login, logout, password changes) including IP address and timestamp
- Pilot signup data — email address, browser info, referrer, and timestamp collected when you submit the pilot signup form on headqrtr.com
How we use your data
- Service delivery — to provide time tracking, invoicing, CRM, and project management features
- Authentication and security — to verify your identity, manage sessions, and protect against unauthorized access
- Payment processing — to create checkout sessions and verify payments via Stripe (we never store card numbers)
- Client portals — to share deliverables, documents, and reports with your clients when you choose to
- Pilot communications — to contact you about the pilot program and product updates (marketing site)
Lawful basis for processing
We process your data under the following legal bases (GDPR Article 6):
- Contract performance — processing necessary to provide the service you signed up for
- Legitimate interest — security logging, fraud prevention, and service improvement
- Consent — optional integrations (including Google Calendar, LinkedIn, Meta, and TikTok) that you explicitly authorize via OAuth; analytics cookies that require opt-in
Third-party services
We use the following third-party services that may process your data:
| Service | Purpose | Data shared |
|---|---|---|
| Supabase | Database and authentication | All app data (encrypted in transit and at rest) |
| Stripe | Payment processing | Invoice amount, client email (card data handled entirely by Stripe) |
| Netlify | Hosting and serverless functions | Server logs, IP addresses |
| Google APIs | Google Calendar (optional, user-authorized) | Calendar-list metadata, selected calendar identifiers, event records, free/busy ranges, and OAuth authorization data described below |
| LinkedIn API | Social publishing (optional, user-authorized) | Profile info and posts you create, accessed on your behalf via OAuth |
| Meta (Facebook/Instagram) API | Social publishing (optional, user-authorized) | Pages, profiles, and posts you create, accessed on your behalf via OAuth |
| TikTok API | Social publishing (optional, user-authorized) | Profile and posts you create, accessed on your behalf via OAuth |
| Google reCAPTCHA v3 | Spam prevention on public forms and bookings | Browser interaction signals (no personal data sent) |
| Cloudflare Turnstile | Spam prevention on pilot signup (marketing site) | Browser interaction signals (no personal data sent) |
| Dropbox | File uploads (optional, for client portals) | Files you choose to upload |
| Anthropic | AI command assistant (optional) | Command text and context you provide |
| Sentry | Error monitoring | Error details, browser info, and stack traces (no personal content) |
| PostHog | Product analytics on app.headqrtr.com (consent-based) | Anonymous usage events and feature interactions |
| Google Analytics 4 | Marketing site traffic on headqrtr.com only (consent-based) | Anonymized page views, referrer, browser info; anonymize_ip enabled; not loaded until consent |
| Resend | Transactional email delivery | Recipient email address, message content, and delivery metadata needed to send app emails |
| MailerSend | Fallback transactional email delivery when configured | Recipient email address, message content, and delivery metadata needed to send app emails |
| MailerLite | Limited mailing-list or admin notification workflows | Subscriber/contact details and message content when those workflows are used |
Separate social media integrations (LinkedIn, Meta, TikTok, and, when enabled, YouTube) are entirely optional. We only access these accounts when you explicitly connect them via OAuth, and we only act on your behalf — publishing content you create, reading profile data you authorize, and managing posts you initiate. We don't access your social accounts without your authorization, and you can disconnect any integration at any time from Settings.
These social media integrations are separate from the Google Calendar OAuth connection described below. The Google OAuth connection covered by this policy section and the current Calendar review does not request Gmail or YouTube permissions.
We don't sell your data to any third party. We don't use advertising trackers inside the app.
Google API Services and Limited Use disclosure
HeadQrtr's use and transfer to any other app of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements. The use and transfer of raw or derived user data received from Google Workspace APIs will adhere to that policy.
The use of raw or derived user data received from Workspace APIs will adhere to the Google User Data Policy, including the Limited Use requirements.
When you connect your Google Calendar, HeadQrtr requests access only to Calendar-list metadata, Calendar event data, and free/busy data. We use that data solely for the user-facing Calendar, planning, booking, and scheduling features described below. In line with the Limited Use requirements:
- We do not transfer Google user data to third parties except as necessary to provide these features with your consent, for security purposes, to comply with applicable law, or as part of a merger, acquisition, or sale of assets after obtaining your explicit prior consent
- We do not use Google user data for advertising, and we do not sell it
- We do not use Google user data to train generalized AI or machine-learning models
- No humans read this data unless you give explicit permission, it is required for security or legal reasons, or it has been aggregated and anonymized
- Our employees, agents, contractors, and successors are required to comply with these Google user-data commitments
- You can disconnect Google Calendar at any time from Settings. A completed disconnect deletes HeadQrtr's stored Calendar refresh token and clears the browser-held access token; you can also revoke access directly from your Google Account
Current Google OAuth connection
Google Calendar is the only Google OAuth integration covered by this connection and the permissions described in this section. Connecting Google Calendar does not grant HeadQrtr access to Gmail, YouTube, Google Drive, or other Google services.
The connection requests https://www.googleapis.com/auth/calendar.events, https://www.googleapis.com/auth/calendar.events.freebusy, and https://www.googleapis.com/auth/calendar.calendarlist.readonly. These permissions authorize event and availability access for calendars the user can access and read-only access to the connected account's Calendar list. HeadQrtr uses the list permission to let you choose which available calendars to display, which calendars to check for booking conflicts, and which writable calendar receives new events.
Google Calendar data we access
Depending on the Calendar features you use and the permissions you grant, HeadQrtr may access:
- Calendar-list metadata — calendar identifiers, display names, whether a calendar is primary, access roles, time zones, and hidden status used to present and validate your calendar choices. A calendar identifier may be an email address
- Calendar event data — for the readable calendars you select for display, HeadQrtr requests the source calendar identifier, event identifier, title, start and end dates and times, all-day status, event status, location, and Calendar link. HeadQrtr holds those display details temporarily in application memory. When you direct HeadQrtr to create or update an event, HeadQrtr sends the title, description, start and end time, time zone, and location; for a booking, it may also send the guest attendee email address and a Google Meet conference-creation request. HeadQrtr receives the created event identifier and any generated Meet link needed for the booking linkage described below
- Availability data — free/busy time ranges for the calendars you select for booking-conflict checks. Free/busy responses used by HeadQrtr identify occupied start and end times and do not provide the event title, description, attendee list, or location
- Authorization data — Google OAuth access and refresh tokens needed to maintain the connection and make the Calendar requests you authorize
- Derived and stored Calendar data — normalized event details displayed temporarily in HeadQrtr; your selected display, conflict-check, and write calendar identifiers stored as a user preference; and Google event identifiers and destination calendar identifiers, plus any Google Meet links, stored with the related HeadQrtr booking so that the linked event can be removed from the correct calendar if the booking is cancelled
HeadQrtr does not create or maintain aggregated or anonymized datasets derived from Google Calendar data for analytics, advertising, profiling, or model training.
How we use Google Calendar data
- Display upcoming events from the readable calendars you select in HeadQrtr's Calendar and planning views
- Check the free/busy time ranges of the calendars you select for conflict checking to prevent conflicting or double-booked appointment times
- Create Calendar events in the writable calendar you select when you add a HeadQrtr time block to Calendar or when a guest makes a booking
- Delete the linked Google event from the calendar where HeadQrtr created it when a HeadQrtr booking is cancelled and ask Google Calendar to send the corresponding attendee cancellation update
- Create a Google Meet link when you select Google Meet for a booking and include an attendee when you direct HeadQrtr to send a Calendar invitation
When HeadQrtr creates a Calendar event in your selected writable calendar at your direction, it may send Google the event title, description, start and end time, time zone, location, and booking information needed for the event, which can include the guest's name, email address, phone number, notes, and attendee email address.
Storage, transfers, and security
- Google processes Calendar requests and event data as the API provider
- Supabase stores the server-side refresh token, your selected calendar identifiers in a user-preference record, and related booking metadata in access-controlled database tables protected by row-level security; selected identifiers may also be cached in user-scoped browser storage; Netlify serverless functions process booking availability and Calendar event operations
- Short-lived Google access tokens issued to the browser are kept in memory rather than localStorage or other persistent browser storage; server-side access tokens are obtained as needed and are not written to the database
- Google Calendar data and tokens are transmitted over HTTPS/TLS, and access to server-side credentials is limited to authorized service functions
- When a booking has a Google-generated Meet link, HeadQrtr includes that link and the booking details needed for the message in transactional emails delivered to the intended guest and account owner. Resend, or MailerSend when used as the configured fallback, processes those messages solely to deliver them
- HeadQrtr does not include raw or derived Google Calendar data in analytics-event properties. Calendar-rendering surfaces and Calendar-related network requests are excluded from PostHog session replay
- HeadQrtr does not automatically include Google Calendar data in prompts sent to Anthropic or another AI provider. If you manually paste Calendar information into an AI command, that user-provided command is processed under the AI disclosures in this policy and our Terms
Google Calendar retention and deletion
- Access tokens — browser-issued tokens remain only in memory until they expire, are cleared, or the browser session ends; server-issued access tokens are used transiently for the requested operation and are not persistently stored
- Refresh tokens — retained in server-side storage while Google Calendar remains connected and deleted when a completed disconnect, invalid-token cleanup, or completed account deletion removes the connection
- Calendar-list metadata — fetched to present and validate your available calendar choices and held temporarily in application memory; HeadQrtr does not maintain a persistent copy of the connected account's full Calendar list
- Selected calendar identifiers — your display, conflict-check, and write selections are retained in a server-side user preference and user-scoped browser storage while Calendar remains connected. The server-side preference is deleted when a completed disconnect or completed account deletion removes the connection, and the browser cache is cleared by a completed in-app disconnect; if account deletion is completed while a device is offline, its local cache remains on that device until HeadQrtr site data is cleared
- Event details — fetched from the calendars you select for display and held temporarily in application memory; HeadQrtr does not maintain a separate persistent copy of the user's Google Calendar event collections
- Free/busy time ranges — fetched from the calendars you select for conflict checking, used to calculate booking availability, and not stored as a persistent Google Calendar dataset
- Google event identifiers, destination calendar identifiers, and Meet links — retained with the associated HeadQrtr booking for as long as that booking record is retained, subject to the account deletion and legal-hold rules below
Approved account-deletion requests are processed manually. Stored Google OAuth tokens and selected-calendar preferences are included in the deletion checklist and their removal must be verified before the request is marked complete, unless retention is required by law or a documented security requirement. For Google user data, any transfer associated with a merger, acquisition, or sale of assets will follow the notice and consent requirements of the Google API Services User Data Policy and applicable law. We do not use Google user data to determine creditworthiness or for lending purposes.
Data storage and security
- Data is stored in Supabase (PostgreSQL) with row-level security policies
- Passwords are hashed using scrypt with random salts
- Session tokens are stored as SHA-256 hashes
- All data in transit is encrypted via HTTPS/TLS
- Optional AES-256-GCM encryption is available for local data
- Multi-factor authentication (TOTP) is available
- All security-relevant actions are logged with IP address and timestamp
Data retention
- Account data — retained while your account is active
- Business records — retained while your account is active unless a verified deletion request, legal hold, or security requirement changes that schedule
- Deletion requests — submitted through Settings or support are manually reviewed and targeted for completion within 30 days, unless applicable law requires a different period. A recovery window may apply to ordinary item deletion, but we do not delay a valid verified erasure request solely for recovery
- Audit logs — retained for 90 days for security investigation purposes
- Session data — expires after 72 hours of inactivity and is purged on a scheduled cleanup cycle
- Active timer state — retained locally in the app or Chrome and in your private HeadQrtr account while a timer is active so the app and extension can stay in sync. The live account record is removed when the timer is saved or discarded; local copies remain until then, or until the relevant browser storage is cleared. Saved entries follow the business-record retention rules above
- Privacy-request records — a minimal confidential receipt may be retained for 24 months after completion to document how the request was handled; it does not contain the deleted content
- Pilot signup data — retained while the pilot program is active. You can request deletion at any time by emailing us
Your rights
You have the following rights under CCPA, GDPR, and other applicable privacy laws:
- Right to access — export all your data as a JSON file from Settings in the app
- Right to deletion — submit a verified deletion request from Settings or by contacting support (CCPA Section 1798.105). Requests are manually reviewed before irreversible deletion
- Right to portability — your data export is in machine-readable JSON format
- Right to rectification — edit any of your data directly in the app
- Right to restrict processing — contact us to request processing restrictions
- Right to opt out — we do not sell data; client portal activity tracking can be disabled in portal settings
To exercise these rights, use the Data Privacy controls in your account Settings, or contact us at the address below.
Cookies and local storage
On app.headqrtr.com (the application) we use the following cookies and browser storage:
- tt_session (cookie) — authentication session token (strictly necessary, HttpOnly)
- tt_device (cookie) — companion session verification token (strictly necessary, HttpOnly)
- tt_csrf (cookie) — CSRF protection token (strictly necessary)
- localStorage — app preferences, offline data cache, and theme settings (functional)
- PostHog cookies — product analytics, only set when you consent via the cookie banner (analytics)
On headqrtr.com (the marketing site) we use:
- headqrtr_cookie_consent (localStorage) — records your analytics consent choice (strictly necessary)
- Google Analytics cookies (
_ga,_ga_*) — only set when you accept analytics in the cookie banner. The Google Analytics script is not loaded at all until you consent.anonymize_ipis enabled. No advertising or remarketing features are used.
The HeadQrtr timer extension uses chrome.storage.local to keep each signed-in user's timer description, selected client, project, and category IDs, billable and timing state, and last connected HeadQrtr user ID. The same active state is stored in that user's private HeadQrtr account while the timer runs so the app and extension can stay in sync; it is not exposed as team live-timer data. The active account record is removed when the timer is saved or discarded. Local state remains until then, or until the extension is removed or its storage is cleared. A short-lived Chrome identity window uses browser-managed tt_session and tt_device cookies to verify your existing HeadQrtr sign-in, then returns a five-minute, extension-specific authorization assertion. The extension does not read or store cookie values, does not request Chrome's cookie-reading permission, and does not persist the authorization assertion.
We do not use advertising cookies on any HeadQrtr surface. Analytics cookies (PostHog on the app, Google Analytics on the marketing site) are only set with your explicit consent and can be revoked at any time using the cookie settings link in the relevant footer. The browser extension does not include analytics or advertising trackers.
Children's privacy
HeadQrtr is not directed at children under 16. We do not knowingly collect data from children.
Changes to this policy
We may update this privacy policy from time to time. The "Last updated" date at the top of this page reflects the most recent revision. Continued use of the service after changes constitutes acceptance.
Contact
For privacy inquiries or to exercise your data rights, contact:
HeadQrtr LLC
support@headqrtr.com