Privacy, thoughtfully handled.

Information we use

For hosts, the service needs account email, authentication and session information, event content, optional structured post-event hosting feedback, purchase and entitlement records, and support correspondence. Before sign-in, an invitation draft stays in the host’s browser or app storage; the wizard restores it for seven days after the last edit and deletes an expired copy when it next opens. It is not sent to WarmInvite until the host signs in and saves it. Unsynced edits to an existing event are also kept on the host’s browser or device for recovery. For guests, an inviting host may provide a name and email. Guests may add their RSVP, household count, names of additional guests when the host requires them, and optional answers. Device and security data supports reliable access and abuse prevention.

Where it comes from

Hosts supply their own account and event details and may give us an invitee’s name and email before that person visits WarmInvite. Guests provide their own reply, optional answers, verification details, and any required names of people joining them. Browsers and apps provide necessary session and security signals. When purchases are enabled, Apple or Stripe supplies transaction status for its purchase channel; WarmInvite does not ask guests for payment details to RSVP. If a host requests AI design help, the resulting suggestion comes from the approved model route and remains a proposal until the host accepts it.

Why we use it

We use these details to create and display invitations, authenticate hosts, deliver event messages, manage guest responses and access, process purchases, protect the service, and answer requests. Marketing requires a separate choice; an RSVP alone does not sign a guest up for promotions.

Legal bases under review

For the intended service, account and paid-service records may be needed for a host contract; required financial records may be kept for a legal duty; proportionate security controls may rely on a documented legitimate interest or legal duty; and marketing needs its own applicable permission. Guest invitations and event messages need a basis assessed for the actual host and guest relationship. Optional dietary or accessibility answers need a separate sensitive-data assessment and an appropriate condition. The purpose-by-purpose basis and any organisation-host roles will be finalised before launch. The GDPR page explains the proposed approach and your rights.

Private event information

Hosts choose whether an invitation is open by link, limited to verified invitees, or subject to approval. Guest lists are private by default. A restricted address must be checked on the server before it is shown to an authorised guest. People who receive information can still copy or share it outside the service.

AI design assistance

When a host explicitly requests writing or design help, WarmInvite sends a minimised brief to OpenRouter and an approved model route. For an optional generated background, it sends a fixed abstract-art preset without event or guest details. WarmInvite does not add guest lists, contact information, access links, or optional dietary or accessibility answers to text-AI requests. Private invitations omit their saved title and venue from text-AI requests. Public titles and venues are screened for common contact and access details before inclusion. Hosts are asked to keep those details out of their own brief; the server rejects common contact, access-link, and access-code patterns, but cannot identify every name or private fact in free text. Generated text and images require host review before use, and the host chooses whether an approved image appears on the invitation. Short-lived health diagnostics record model identifiers, usage, latency, and fixed failure codes without prompts, generated content, or guest details.

To recover an interrupted generated-background request, your browser or app keeps an account- and event-scoped request reference, the public image direction and a timestamp. These records contain no invitation text, guest details or image description. They remain after sign-out so the same account can recover its request. A finished record is replaced when you explicitly start another preview. Account deletion attempts to clear that account’s local records; you can also remove them by clearing browser or app data.

For an interrupted text or collection request, we keep the original brief, model choice, request reference, input fingerprint and timestamp on your device, scoped to your account and event. On the web, this stays in the current tab’s session storage. The brief is kept for up to seven days from the request and is removed when recovery next reads an expired record. Deleting the brief removes its retry copy; the request reference can still recover an existing result. Signing out or deleting your account attempts to clear these local text records. Clearing browser or app data also removes them. Checking an original request does not send the brief to an AI provider or use another AI action.

Automated processing

Capacity and waitlist rules can automatically confirm, hold, or waitlist a reply according to the host’s event settings and available seats. A host can review replies when approval is enabled and can manage the guest list. Optional AI tools suggest wording, design, or a collection to the host; they do not score guests or decide who may attend. WarmInvite does not use a guest’s optional answers to make an AI admission decision.

Providers and transfers

Cloudflare provides application hosting, database, storage, and email services. OpenRouter and its approved inference route support optional design actions. Apple handles in-app purchases when enabled. The planned web checkout uses a Stripe-hosted payment page; that channel remains disabled until its operational and legal review is complete. Each provider’s actual location, terms, data-protection role, and transfer safeguards must be recorded before launch. See the provider list.

Retention and your choices

The current service clears optional sensitive guest answers and private notes seven days after the event, then removes guest contact and ordinary response data after 30 days, subject to lawful exceptions. A host’s design archive may last up to 12 months. Optional hosting feedback supports staff aggregate counts about the service, stays with that event, is included in the host’s account data export, and can be changed or removed. Event or account deletion removes the answer. If an event or account is deleted, a minimal account-and-day AI spend total remains through that UTC day to enforce the daily spending limit; scheduled cleanup removes prior days. It contains no prompts or generated content. Financial records may need longer statutory retention. We will disclose the implemented schedule and backup delay before launch. Visit the privacy choices centre for request methods.

Apple Wallet passes are not currently available. The proposed Wallet service would use a device notification token and an opaque pass identifier to send updates through Apple. After withdrawal or deletion, its proposed removal-notification window is up to 24 hours, subject to review before activation. Those notifications would contain no invitation or guest details. An updated inactive pass would remove those details and its arrival code; a device that is offline may still display its older pass, but that pass cannot grant entry after withdrawal.

Rights and complaints

The privacy choices centre explains current self-service actions and the planned verified request route for access, correction, deletion, and other applicable rights. People in the EU or EEA can also complain to a data protection authority. For Sweden, the Swedish Authority for Privacy Protection (IMY) explains how to file a complaint.

Optional usage analytics

Optional first-party step reports are prepared but disabled by default. They require a separate choice on each browser or iPhone installation. Reports exclude invitation URLs, event and account IDs, guest answers and private content. Aggregate counts last 35 UTC dates; daily keyed hashes of network addresses and random report IDs limit abuse and duplicates and are removed by scheduled cleanup after the UTC day. The local choice lasts up to 180 days. See cookies and storage controls or the iPhone Profile controls. Turning off stops future reports. Browser GPC and Do Not Track signals keep collection off. This is separate from marketing email.

Regional information

Read our GDPR information and California data matrix. The legal basis and applicability analysis will be completed for the live product and the operating countries before launch.