Privacy

Your calendars, merged. No advertising profile.

calfeed does not sell personal information, does not build advertising profiles, and cannot write to your calendars. Access is read-only by construction: we request read-only permissions from Google and Microsoft, and there is no code that creates, edits or deletes an event.

Last updated: September 16, 2026.

What we store

For each calendar someone connects, we store only the event fields that person chose to share — busy/free only, or a chosen subset of title, location, description, attendee count, attendee names and the meeting link. Start and end times are always stored, because merging is impossible without them. Everything else in the event is discarded at sync time and never written anywhere.

Two extra details ride along with each event: your own answer to it — organizer, accepted, tentative, declined, or not answered yet — which is a fact about you rather than about the meeting, so it is not part of the sharing choice (views can hide events you declined); and, when the meeting link is shared, the conferencing vendor plus the join URL if Google or Microsoft gives us one.

We keep only the upcoming events your views actually serve. If your only view shows the next 7 days, we store 7 days of events (plus one day of slack) — not your year, not your past. Yesterday is the oldest thing we ever hold, and 60 days ahead is the hard ceiling regardless of views.

Narrow what a calendar shares and the extra stored fields are deleted immediately. Remove a calendar, or revoke calfeed's access at Google or Microsoft, and its stored events are gone within minutes.

Calendars you upload yourself

For a calendar we cannot reach, you can push instead of connecting a provider: calfeed gives that source a private upload URL (/v1/push/<token>) and you send it a dump of events whenever you like. What we keep from an upload follows the same sharing choice as any other source; cancelled events are never stored, and events outside the retention window — yesterday to 60 days ahead for an upload — are dropped as they arrive rather than kept. The upload URL's token is stored hashed for lookup and, separately, encrypted (AES-256-GCM) so you can be shown the URL again; you can also restrict uploads to chosen IP ranges or require a secret header. Each upload attempt is logged — time, outcome and how many events were stored or dropped — newest 50 per source, with no event content in the log. Uploaded dumps never carry a meeting join link.

Sign-in and tokens

You sign in with Google or Microsoft. calfeed never sees a password. The OAuth tokens the providers give us are stored encrypted (AES-256-GCM) and used for exactly one thing: reading the calendars you connected. Sign-in state is one HttpOnly session cookie; there are no tracking cookies.

Feed URLs

A feed URL is an unguessable secret. Anyone holding it sees exactly what that view shares — nothing more. You can rotate a URL (the old one dies instantly), disable it, restrict it to chosen IP addresses, or require a secret header. Feeds carry noindex headers and are listed nowhere.

Feed JSON spells each event's date and time out as wall-clock text in the view's timezone, so a display with no timezone support never does date maths. That is the times we already store, formatted — nothing extra is collected to do it.

Third parties

calfeed runs on Cloudflare (Workers and D1); stored data lives on Cloudflare's infrastructure. We call the Google Calendar and Microsoft Graph APIs to read the calendars you granted, and fetch any public ICS URLs you add. That is the whole list. There are no analytics scripts, no ad networks, and no data brokers.

What we do not collect

Questions

Write to apps@calfeed.io. Short questions get short, honest answers.