Trust Center

hora Calendar talks to Google Calendar directly from your Mac, iPhone or iPad. Your events, your contacts and your OAuth tokens stay on the device. This page explains in concrete terms what the app does locally, the narrow jobs our servers do, and what those servers cannot see even if we wanted them to.

The short version

• Your calendar data is stored on your Mac, iPhone or iPad with SwiftData. It never passes through a hora Calendar sync server.
• OAuth tokens live in the Keychain (the macOS Keychain on Mac, the iOS Keychain on iPhone and iPad), protected by your system login or device passcode, and never leave the device.
• hora Calendar requests the minimum practical scopes for the features you actually enable.
• We do not operate a general-purpose backend that stores your calendar or meeting content. The only account data we keep is described under Direct accounts below.
• All communication with the Google, Zoom and Microsoft APIs is encrypted in transit with HTTPS.

Direct sync, not a middleman

Many third-party calendar clients sync through the vendor's own servers: your account is connected on their infrastructure, your events are mirrored there, and the app talks to that copy. hora Calendar does not work that way. The app holds its own credentials and calls the Google Calendar API itself. The optional Zoom and Microsoft Teams integrations work the same way — those calls are made by the app on your device, with tokens that never reach us.

Locally cached data stays inside the app sandbox on macOS and iOS/iPadOS. Signing out in hora Calendar Settings removes the stored tokens and the cached data, and uninstalling the app removes its data from your device.

What our servers actually do

The website has exactly five responsibilities for the Direct build of hora Calendar. Each one is deliberately narrow, and none of them involves your calendar content.

Resolving your billing identity

For Direct purchases made before Direct accounts were introduced, the app sends one fresh Google ID token when a purchase needs to know who you are. Our server verifies its signature against Google's public keys, checks the issuer, audience, expiry and subject, and then derives a stable, opaque identifier from it using HMAC-SHA256. What comes out looks like this:

usr_direct_v1_ followed by an opaque digest.

That identifier is all our payment provider ever sees. Your Google subject, your email address and the raw token are never returned to the app, never sent onward, and never written to a log.

Registering your device for entitlement push

When your Direct access status changes, your Mac needs to hear about it. The app sends its Apple Push Notification service device token together with the same short-lived Google ID token. The server derives the opaque identifier itself — the request rejects any user identifier supplied by the client — and forwards a register or unregister command to a private endpoint over HTTPS using a dedicated secret. The device token is handled as opaque bytes.

Resolving the download

A Direct download link does not point straight at a file. The resolver fetches the signed release manifest and validates the exact host, the immutable release path, the version, the build, the file name and the SHA-256 checksum. Only then does it issue a redirect. The download proxy does not record your IP address or user agent. The Direct build is notarized by Apple and updates through the Direct release channel.

Waking your device when your calendar changes

hora Calendar does not poll Google on a timer. It subscribes to Google Calendar push notifications, and Google's notification is deliberately empty: the webhook gets no body, only a header saying that something on a given resource changed. Our worker reads that header, wakes your device over APNs, and the app fetches the actual data directly from Google. No event, title, attendee or description ever passes through our infrastructure.

This is where we keep something durable about your devices, and we will not pretend otherwise. For each registered device the worker stores a keyed hash of your Google account identifier (prefixed u1_; not your email address and not the raw identifier), the APNs device token, the app's bundle identifier, your calendar IDs as encrypted values, and an expiry date. Registrations of devices inactive for more than 30 days are deleted. That is what it takes to know which device to wake, and it is all it is used for. The worker's logs contain no email addresses, calendar IDs or push tokens. Signing out in hora Calendar Settings unregisters the device, so the worker no longer has a device to wake.

Direct accounts

If you buy hora Calendar directly from horacal.app, we create an account for the email you buy with. It lives in a Supabase database in the EU (Ireland, eu-west-1) and holds your email address and a record of your devices: a random device ID, an optional label and the date it was last active, with a limit of 5 devices. The tables have no columns for IP address, user agent, device name or country, and your email address is never sent to analytics or to the push worker.

The Direct app signs you in through your system browser (OAuth with PKCE) and receives an opaque token and a random installation ID; it sends no device name. Paddle is the merchant of record, and RevenueCat holds your entitlement under an opaque account identifier rather than your email address.

What the entitlement push path cannot do

• It cannot read your calendar. No event, guest or meeting data is ever sent to it.
• It cannot read your Google account. The only Google credential this path ever handles is a short-lived ID token, used once to confirm who you are and then discarded.
• It cannot work backwards to your identity. The identifier it stores is a keyed hash, so there is no lookup from it to your email address or Google account.
• It cannot be pointed at someone else's device. A registration can only ever attach to the verified account that made the request.

Payments

Direct checkout and licence management are handled by RevenueCat and Paddle. Paddle is the merchant of record for Direct purchases, and we never see or store your card details. App Store purchases (Mac, iPhone and iPad) are handled by Apple, with RevenueCat managing entitlements, and Setapp purchases are handled by Setapp, under their own terms. What you are entitled to get back, and when, is set out in Refunds & Cancellations.

The website is not the app

This website sets no cookies and uses no advertising trackers, pixels, or session recordings. PostHog counts pageviews and a few actions anonymously, in memory only, without profiles, and discards your IP address. Starting with the next app update, the hora Calendar app sends anonymous counts and crash reports only if you turn them on in Settings; both are off by default, and crash reports (through Sentry, EU region) carry no user identifier, email address or device name. Support requests, from the form or by email, are delivered through Resend and handled in Linear. The full breakdown, including exactly what a support request contains and how long it is kept, is in the Privacy Policy.

Questions

If something here is unclear, or you want evidence for a specific claim, write to support@horacal.app.