Privacy Policy

Citizen Sites (“Citizen Sites,” “we,” “us,” or “our”) is a hosted software platform that helps churches build and run a public website. The platform includes a page editor, a website-builder portal for the church owner, custom domains, a forms tool with optional Planning Center person-push, a read-only Google Calendar surface, a prayer board with magic-link team viewers, sermon and video recording pages, basic analytics, and connections to a small set of external apps.

When a church signs up with Citizen Sites, that church is the “Customer” or “Tenant.” The Customer controls the personal information of its members, prayer-team viewers, form submitters, and visitors (the “End Users”). For that information Citizen Sites acts as a service provider / data processor on the Customer’s behalf. End Users with questions about their personal data should contact their church directly first.

This policy applies to information collected through:

• Our marketing website at buildcitizensites.com.
• The Citizen Sites authoring surfaces — the page editor, owner portal, admin console, and renderer used to build and publish church sites.
• Tenant church websites we host, including custom domains pointed at our infrastructure.
• Forms hosted on tenant church sites, including Planning Center form embeds we serve through the platform.
• The public prayer-team landing page accessed by a tenant’s invited viewers via magic-link tokens.
• Email and other direct communication you send us.

This policy does not cover the Citizen Send mobile app or its public web cards at buildcitizensites.com/citizensend/…. Citizen Send is a separate product on a separate Firebase project with its own privacy policy. This policy also does not cover third-party websites we link to but do not operate.

Church owner account & authentication

Each tenant church has one owner account. When the owner signs up we collect their name, email address, password (stored only as a salted hash by Firebase Authentication), the church name, and the identifiers we need to scope their access to their own tenant. We also issue a signed session cookie so signed-in pages know who you are. Our authoritative authorization signal is a JSON Web Token custom claim (churchId + role) on the owner’s Firebase identity.

Site content & uploaded media

Pages, blocks, design globals (colors, fonts, header / footer layout), images, uploaded fonts, video links, and any other content the church creates in the editor. Uploaded media lives in Firebase Storage and the static-site export bucket on Google Cloud Storage.

Forms & submissions

Anything submitted through forms on a tenant site (contact forms, signup forms, custom forms, our own feature-request, custom-design-request, and contact forms). If a Customer connects Planning Center and enables person-push on a form, the submission is forwarded to their Planning Center People account; the submitting End User’s data is then processed under Planning Center’s own privacy terms.

Prayer board entries

Prayer requests written by the church owner. If the owner invites prayer-team viewers via email, we store the invitee’s name, email address, and a hashed copy of their magic-link token. Magic-link viewers are not Firebase users; they read the prayer board through a per-person token-protected URL.

Calendar data

When a Customer connects Google Calendar, we exchange OAuth tokens and read events from the calendars they grant access to. Google Calendar is the source-of-truth; we display events on the tenant site and in the owner portal but do not write to Google Calendar.

Recordings metadata

When a Customer adds a YouTube recording or watch-page entry, we store the video identifier, title, description, thumbnail URL, and any metadata they choose to attach. We do not host the video file itself.

Subscription billing data

Citizen Sites subscription billing runs through Stripe. Stripe collects the Customer’s card data directly inside Stripe’s PCI-DSS certified environment; we never see or store full card numbers. We store the Stripe customer and subscription identifiers, plan name, billing cadence, and a small audit log of webhook events used to keep the subscription state in sync.

Citizen Sites does not process online giving, donor payments, or any other money flowing to the church. Tenants who want to take donations should link out to their preferred giving provider (for example through a button or embed); that provider handles donor data under its own policy.

Integration tokens

If a Customer connects Google Calendar or Planning Center we store the OAuth refresh token and any synced records the integration is scoped to read (calendar events, Planning Center form metadata). We do not request access beyond the documented scopes.

Logs, telemetry & usage

Web servers and edge caches record IP addresses, user agents, timestamps, and request paths for security, rate limiting, and debugging. Our contact form additionally stores a one-way hashed IP address and the submitting browser’s user agent to deter abuse and spam — we cannot reverse the hash to recover the original IP.

We run Vercel Analytics and Vercel Speed Insightson our own platform surfaces only — the marketing site, signed-in owner portal, page editor, and admin console. These tools collect aggregate performance and page-view metrics with no advertising identifiers. Tenant church sites do not run any third-party analytics by default. A tenant may add their own analytics or pixel in their site settings; if they do, those tools collect data under the tenant’s own privacy policy, not ours.

• To operate the platform — sign-in, page rendering, the static-site export pipeline, scheduled jobs, email delivery, and backups.
• To bill the church owner’s subscription through Stripe.
• To send transactional email (sign-in links, password resets, prayer-team magic-link invitations, form-submission notifications).
• To investigate security incidents, prevent abuse, and rate-limit malicious traffic.
• To improve product reliability through aggregated, non-identifying usage measurement.
• To respond when you contact us.

We do not sell personal information. We do not use End User data to train AI models. We do not use End User data for advertising.

Personal information is shared only as required to run the service or as required by law:

• With your church (the Customer). End User data is visible to the church owner on the Customer church account.
• With service providers (sub-processors). See the next section.
• With integrations the Customer connects. If the Customer enables Planning Center person-push, form submissions flow to their Planning Center account. If they connect Google Calendar, calendar event data flows from Google to our platform.
• For legal reasons. Subpoena, court order, or to protect the rights, property, and safety of Citizen Sites, our customers, and the public.
• In a corporate transaction. If Citizen Sites is acquired or merges, customer relationships and the data tied to them transfer with the business under this same policy or a more protective one.

We rely on a small number of carefully chosen sub-processors to deliver the platform:

• Google Cloud / Firebase — authentication, Firestore database, Cloud Storage, and Cloud Tasks queues.
• Vercel — hosting, edge caching, image optimization, the domains API, and Vercel Blob storage for static-site exports.
• Stripe — platform subscription billing for the church owner’s seat. (Citizen Sites does not operate Stripe Connect or process donor payments.)
• Resend and AWS Simple Email Service — transactional email delivery.
• Google Calendar, Planning Center, and YouTube — only when a Customer chooses to connect their account.

Each sub-processor is bound by their own privacy commitments. We will publish material changes to this list in advance.

We use a small number of first-party cookies and local-storage entries:

• A signed session cookie that proves you’re authenticated to the owner portal, page editor, and admin console.
• Firebase’s authentication cookies for the same purpose.
• Editor-only preferences (most recent viewport, last-open panel) used to restore the editor state.
• Caching headers on tenant site responses for performance, not tracking.

We do not use third-party advertising cookies or cross-site trackers. Tenant churches may add their own analytics or pixels in their site settings; if they do, those tools collect data under the tenant’s own privacy policy.

The prayer board lets the church owner invite trusted viewers (a “prayer team”) to read the church’s prayer requests without creating a Firebase account. Each invited viewer receives an email with a unique magic-link URL.

Server-side we store the invitee’s name, email address, a one-way hashed copy of the token, and a time-to-live so the token expires automatically. Opening the landing page verifies the token and renders the prayer wall server-side — no cookie, no portal access, no ability to write. Owners can revoke a viewer at any time from the owner portal, which invalidates the token immediately.

The platform optionally connects to a small set of external apps. Each integration runs only when the Customer explicitly enables it, and only the documented scopes are requested:

• Google Calendar — read-only access to chosen calendars so events appear on the tenant site and in the owner portal.
• Planning Center — form embeds on the tenant site, plus optional person-push to Planning Center People when a form is submitted.
• YouTube — read-only access to channel video metadata for the watch / recordings page.

You can disconnect any integration at any time from the owner portal. Disconnecting revokes the stored refresh token and stops the data flow; previously synced records that already live in your tenant data remain until you delete them.

We retain personal information for as long as a tenant church’s account is active. When a church cancels, we keep their data for a 30-day grace period in case they want to reactivate, then delete primary records on a rolling schedule. We keep up to 25 publish backups per church so a recent published version can be restored on request.

Short-lived records self-expire via Firestore TTL: pending signup invitations, password-reset tokens, prayer-team magic-link tokens, Stripe webhook event de-duplication records, email- and form-job de-duplication records, static-site export de-duplication records, Planning Center person-push de-duplication records, rate-limit buckets, Quick Setup resumable drafts, and pending deletion requests all expire within minutes to days depending on the record type.

Tenants can request a full export or deletion at any time through our contact form. Individual End Users should contact their church first; if the church will not act on a valid request, reach out to us and we’ll help.

We use Firebase Authentication, Firestore security rules, per-tenant access checks at the API layer (with the owner’s JWT custom claim as the authoritative signal), signed session cookies, content security policy headers, HTTPS everywhere, IP-based rate limiting on every API endpoint, server-side HTML sanitization, and least-privilege service accounts. We log security events and monitor for abnormal access patterns.

No system is perfect. If you discover a security issue, please report it through our contact form. We will not pursue legal action against good-faith researchers who follow standard responsible-disclosure norms.

Depending on where you live, you may have rights to access, correct, export, or delete your personal information, to object to processing, or to lodge a complaint with a supervisory authority. End Users should normally exercise these rights through the church that maintains their record. We will help any Customer fulfill a verified request that they need our help with.

Citizen Sites is operated from the United States. By using the platform from outside the U.S., you understand that your information will be processed in the U.S. and other countries where our service providers operate.

We’ll update the “Last updated” date at the top whenever this policy changes. For material changes (new sub-processors, expanded data uses, new categories of collection) we’ll notify Customers by email at least 30 days before the change takes effect.

For privacy questions, deletion requests, or anything else covered by this policy, write to us. We read every email ourselves.