Privacy Policy

Account holders (couples and the family members they invite)

When you sign up for Anvaya, we collect:

• Your name and email address
• A password (stored only as a one-way hash, never in plain text), or a Google account ID if you sign in with Google
• A profile image, if you set one (or one supplied by Google when you sign in with Google)
• Email-verification one-time codes (delivered by email and discarded after use)
• Session metadata tied to your login: a session token, IP address, and User-Agent string
• An optional invite code you used to sign up
• Anything you fill in during onboarding: couple names, estimated guest count, wedding subdomain, event types, dates, and venue / city (we use Google Places for venue and city autocomplete; see Subprocessors)

Wedding content you create or upload

Once you have an account, the data you (or your invited collaborators) add to your wedding sits inside your wedding workspace. Depending on what you use, this can include:

• Events (name, date, time, location, dress code, ceremony type, Google Place ID for the venue)
• Budget data — categories, line items, estimates, actuals, vendor packages, vendor payments, funding sources, scenarios
• Vendors — name, contact name, email, phone, website, category, location, status, quote, notes, attachments
• Tasks — title, description, due dates, assignees
• Wedding website content — story, wedding party member bios and photos, gallery images, accommodations, registry links, custom design tokens and CSS
• Seating charts — table layouts, fixtures, seat assignments
• Audit log entries — every create/update/delete on most domain entities is recorded with the actor, action, entity, and before/after snapshot
• Comments and chat history — text you enter in comments or in the AI assistant chat

Wedding guests

When you add guests to your wedding, we store information you provide about them. Guests typically have not signed up to Anvaya themselves; you are the source of this data. We may store, per guest:

• First name, last name
• Email address, phone number (optional)
• Mailing address — street, city, state, postal code, country, optional Google Place ID
• Side (bride / groom / mutual), tags, and free-text notes you write
• Group / household assignment
• Per-event RSVP status, dietary notes, and meal selections
• Plus-one allowances and per-attendee RSVP records
• Save-the-date / RSVP tokens (random IDs used in the links you share with guests)
• Intake question responses from any custom questionnaire you build
• Gift records you log against the guest

See Section 7 for how guest data is treated and how a guest can request changes or deletion.

Messages with guests and vendors

If you use Anvaya to message guests or import vendor email threads, we store:

• Guest conversations — message body, channel (SMS / WhatsApp / email), direction, sender, timestamps, and the Twilio message ID and delivery status (PENDING, SENT, DELIVERED, FAILED)
• Broadcast records — the audience filter, body, and per-recipient delivery status
• Vendor email extractions — the from address, name, subject, full forwarded body, and any attachments you forwarded to your vendors-{your-subdomain}@anvaya.love address. After AI extraction, the structured fields (vendor name, contact, quote, etc.) are stored in your account; the raw email body and pending attachments remain on the extraction record for your review until you accept or dismiss it.

OAuth tokens for connected AI assistants

If you connect an external AI assistant (such as Claude, ChatGPT, or a similar MCP client) to your wedding, we store an OAuth record containing the client ID, the user, the wedding, the scopes granted, expiration, and revocation timestamp. The access and refresh tokens themselves are stored as one-way hashes (we cannot read the original token from our database). See Section 6.

Operational logs and analytics

We keep an internal log of AI calls per wedding (model used, token counts, estimated cost) to monitor usage and cost. We use PostHog for product analytics; PostHog is loaded only after you grant analytics consent (or, for users where the law allows opt-out rather than opt-in, until you opt out via the Privacy Preferences link in the footer). When session recording is on, all form inputs are masked. See Section 8.

Cloudflare, our infrastructure provider, sees standard request metadata (IP address, User-Agent, request URL) at the edge for every request to anvaya.love.

Waitlist

If you join the early-access waitlist before signing up, we store the email address you submitted and the dates we invited you and sent that invite.

Sensitive personal information (CCPA/CPRA)

A few of the categories above can qualify as “sensitive personal information” under the California Consumer Privacy Act / California Privacy Rights Act, depending on how the host fills them in:

• Religious or philosophical beliefs — inferable from the ceremony types you choose (mehndi, nikah, Hindu, Sikh, Christian, civil, etc.).
• Precise geolocation — guest mailing addresses and Google Place IDs for venues can resolve to a specific street.
• Health information — guest dietary requirements and meal selections can imply allergies or medical conditions.
• Personal information of minors under 16 — guest records you create about child attendees.

We use this sensitive personal information only to provide the wedding-planning service you signed up for — for example, showing the data back to you, generating seating charts, sending an invitation, or counting meals. We do not use it to infer characteristics about you, to advertise, to train AI models, or for any purpose outside the safe harbor in California Civil Code §1798.121(d) and 11 CCR §7027(m). Because our use stays inside that safe harbor, the “Limit the Use of My Sensitive Personal Information” right does not apply. If you would still prefer we delete a specific sensitive field, write to us at privacy@anvaya.love.

Lawful basis (GDPR Art. 6)

For account holders in the EU, UK, or Switzerland, we rely on the following lawful bases when we act as the controller of your data:

• Contract performance (Art. 6(1)(b)) — to deliver the planning workspace, render your public wedding site, save your work, send transactional email tied to your account, and operate features you trigger (RSVPs, vendor extraction, AI assistant calls).
• Legitimate interests (Art. 6(1)(f)) — to keep the platform secure (rate limiting, webhook signature verification, audit logs), prevent abuse, and run product analytics in jurisdictions where opt-out applies. Where we rely on legitimate interests we balance them against your rights and freedoms; you can object at any time at privacy@anvaya.love.
• Consent (Art. 6(1)(a)) — for non-essential cookies and product analytics in jurisdictions where opt-in applies, and for any optional communications you sign up for. You can withdraw consent any time via the Privacy Preferences link in the footer.
• Legal obligation (Art. 6(1)(c)) — to meet breach notification, tax, and other statutory obligations.

When you enter wedding-guest or vendor data into Anvaya you remain the controller for that data; Anvaya processes it as your processor under the Data Processing Terms in our Terms of Service. You are responsible for choosing and documenting a lawful basis under Art. 6 for the guest and vendor data you enter.

What we use the data for

We use what we collect to:

• Run the platform. Authenticate you, render your dashboard and your public wedding site, save your work, and serve images and files you upload.
• Send transactional email. Sign-in / sign-up verification codes, account notices, and (when you enable it) save-the-dates and invitations are delivered through Resend from noreply@anvaya.love.
• Send and receive guest messages. Outbound SMS and WhatsApp go through Twilio; inbound replies arrive via Twilio webhooks. Email replies that you forward arrive via Cloudflare Email Routing.
• Receive vendor emails you forward. Cloudflare Email Routing delivers messages sent to vendors-{your-subdomain}@anvaya.love to our email worker, which parses the message and posts it back to Anvaya for AI extraction.
• Run AI features you trigger. Vendor-email and document extraction, the Anvaya AI chat, design chat, signal generation, and similar features call AI models on your behalf. See Section 5.
• Show maps and venue suggestions. When you type a venue or city, we call Google's Places and Maps APIs from your browser.
• Resolve sun and weather times. When we display sunrise / sunset on your event days, we call the public Open-Meteo API with the venue's coordinates.
• Improve the product. If you consent to analytics, PostHog tells us which features get used. We do not sell or rent your data, and we do not use your wedding content to train AI models.
• Keep the platform safe. We rate-limit certain endpoints, verify Twilio webhook signatures with HMAC-SHA1, verify the email-worker webhook with HMAC-SHA256, and write an audit-log entry when records are created, updated, or deleted.

Scopes

Two scopes are advertised, and the assistant only gets what you grant:

• wedding:read — read access to your wedding data: events, guests, RSVPs, budget, vendors, tasks, members, dashboard metrics, activity feed, AI signals.
• wedding:write — change access: create, update, and delete the same data, including drafting reminders or messages on your behalf.

What the connected assistant can see

When you authorize an assistant, our server picks the wedding associated with your account and binds the access token to that single wedding and your role within it. The assistant cannot reach weddings you do not belong to. Tool calls run with the same role checks as the dashboard does.

Token lifetimes

• Authorization codes expire after 10 minutes and are single-use.
• Access tokens (JWT, HS256) expire after 24 hours.
• Refresh tokens expire after 180 days and rotate on every use; the previous refresh token is revoked at the same time.
• Access and refresh tokens are hashed at rest in our database — we cannot read the original token from the database.

Audit log

Most write actions performed by the assistant are recorded in your wedding's audit log alongside actions you take in the UI. The audit log shows the actor (the user the assistant authenticated as), the action, the entity, and a snapshot of changes.

Revoking access

You can revoke any connected assistant from your account settings. The same effect can be achieved programmatically via POST /api/oauth/revoke (RFC 7009). Revocation immediately invalidates the refresh token and blocks future refreshes; in-flight access tokens stop working as soon as they expire (within 24 hours) or sooner if a new request relies on a revoked refresh token.

What the assistant's vendor sees

Once data leaves Anvaya as part of an MCP tool response, it is in the hands of the AI assistant's vendor (Anthropic, OpenAI, etc.). Their privacy policy governs how they handle that data. We have no direct relationship with the assistant vendor and do not control whether they retain or process the response further.

EU / UK / Switzerland residents

The rights above mirror what the GDPR, UK Data Protection Act, and Swiss FADP provide: access, rectification, erasure, restriction, portability, objection, and the right to lodge a complaint with your supervisory authority. EU residents can find their authority at edpb.europa.eu/about-edpb/about-edpb/members; UK residents can complain to the ICO.

California residents (CCPA / CPRA)

You have the right to know what personal information we collect, delete it, correct it, request a copy, and opt out of sale or sharing for cross-context behavioral advertising. We do not sell or share personal information for cross-context behavioral advertising; we have not done so in the previous 12 months.

Sensitive personal information. See Section 2 for the list. We use it only to provide the service (the safe harbor in Civil Code §1798.121(d) and 11 CCR §7027(m)), so the “Limit the Use of My Sensitive Personal Information” right does not apply. You can still ask us to delete a specific field.

Global Privacy Control (GPC). If your browser sends a Sec-GPC: 1 header (or sets the navigator.globalPrivacyControl property), we treat it as a request to opt out of any sale or sharing of personal information for cross-context behavioral advertising and as a withdrawal of analytics consent. Because we neither sell nor share, the practical effect today is to disable PostHog product analytics. We do not require you to confirm, authenticate, or repeat the request.

Categories of personal information collected (CCPA §1798.110(a)(1)). The fields enumerated in Section 2 map to these statutory categories:

We do not collect categories C (protected classifications), E (biometric), H (audio / visual / sensory), I (professional or employment), or J (education).

Other US state residents

If you live in Colorado, Connecticut, Virginia, Texas, Utah, Oregon, Montana, Iowa, Indiana, Tennessee, Delaware, New Hampshire, New Jersey, Maryland, Minnesota, Rhode Island, Kentucky, Nebraska, or Florida, your state's comprehensive consumer-privacy law gives you rights very similar to California: access, deletion, correction, portability, and opt-out of sale / share / targeted advertising. Several of these states (notably Colorado, Connecticut, Texas, Oregon, Montana, New Hampshire, New Jersey, Maryland, Minnesota, and Delaware) require us to honor a Universal Opt-Out Mechanism such as Global Privacy Control; we do, as described in the California subsection above.

Several states (Colorado, Connecticut, Texas, Oregon, Montana, New Hampshire, New Jersey, Maryland, Minnesota, Delaware, Virginia) also require opt-in consent before processing sensitive data. By entering ceremony types, dietary information, addresses, or guest data about minors into Anvaya, you consent to their processing for the wedding-planning purposes described in this policy. You can withdraw that consent by deleting the field or, for analytics, via the Privacy Preferences link in the footer.

To exercise any state-law right, write to privacy@anvaya.love. We respond within the timeframe required by your state (typically 45 days, extendable by 45 days for complex requests). You also have the right to appeal a denial; instructions will be in our response.

Transfer mechanisms (EEA, UK, Switzerland → US)

We rely on the following safeguards, in order:

• EU-US Data Privacy Framework — for personal data transferred to subprocessors that are self-certified under the EU-US DPF (Commission Implementing Decision (EU) 2023/1795 of 10 July 2023). Cloudflare, AWS, Google, Twilio, and Resend are active participants; certification status can be verified at dataprivacyframework.gov.
• UK Extension to the EU-US DPF (“UK Data Bridge”) — for transfers from the United Kingdom, effective 12 October 2023 under the Data Protection (Adequacy) (United States of America) Regulations 2023.
• Swiss-US Data Privacy Framework — for transfers from Switzerland.
• Standard Contractual Clauses — for any subprocessor that is not DPF-certified. We rely on Module Two (controller-to-processor) of the European Commission's SCCs (Implementing Decision (EU) 2021/914) and, for UK transfers, the ICO's International Data Transfer Addendum to those Clauses. OpenRouter is currently covered by SCCs rather than DPF.

We monitor the EU-US DPF's status — including the General Court's September 2025 decision in Latombe v. Commission upholding the framework — and will update these disclosures if the legal landscape changes.