Privacy policy

Vientic is a guest-list tool for people who run curated events. It is operated as a sole proprietorship based in Seattle, Washington (“we”, “us”), at 2801 Alaskan Way, Seattle, WA 98121. Two kinds of people appear in the product:

• Hosts create an account, connect their Luma calendar or upload guest lists, and use Vientic to review registrations, remember past guests and build event reports.
• Guests are the people on a host’s guest lists. Guests never sign up for Vientic and never interact with it directly. Their data reaches us because a host brought it here.

Who is responsible for what. For your account data as a host, we decide how and why it is processed: in data-protection terms we are the controller. For your guests’ data, you decide which guests to bring in, what to ask of them, how to score them and when to delete them, and we process that data on your behalf and on your instructions: you are the controller and we are your processor. The one place we act on our own account is the profile cache described under LinkedIn profile look-ups, which we keep so the same public profile is not bought twice.

A third group, people who open a shared report link, are not identified at all. A view is counted without any visitor identifier, and no account or cookie is attached to it.

When you create and use an account we hold:

• Your email address, a password (stored only as a hash by our authentication provider, never readable by us) or magic-link sign-in, and the name you give us.
• The name of your workspace and its settings.
• If you connect Luma: your Luma API key, stored encrypted in a secrets vault; we display only its last six characters. The calendar it belongs to, and a webhook token and secret if you turn webhooks on.
• If you add a calendar feed: the feed URL and what it returns about your events (names, times, locations, Luma links).
• What you write and decide inside the product: events, scoring criteria, admit and decline decisions, notes about guests, edits to report narratives, and whether a report is shared.
• Usage counts that enforce your plan’s limits, such as guests imported this month or scoring runs used.
• Error reports, with personal details withheld (see Security). We do not run product analytics today.

For each guest on a host’s list we may hold the following, depending on what the source carried:

From the registration itself

• Name, email address, LinkedIn profile URL.
• Company and job title.
• Answers to the host’s registration questions, as the guest typed them (truncated past a length limit).
• Ticket name, amount paid and currency, registration status (approved, pending, declined, waitlisted and similar), the times the registration was created, approved or cancelled, how many seats it covers, and whether and when the guest checked in.
• Luma’s identifiers for the guest and the registration, where the data came from Luma.
• The raw registration record as the source sent it, kept verbatim so an import can be re-read if a field was mapped wrongly.

Derived by Vientic

• A single person record per host that links the same guest across that host’s events, matched on email address and LinkedIn URL, and a history of how many of that host’s events the guest applied to, was admitted to, attended, missed or cancelled late. A guest’s history is never shared between hosts.
• For a host who runs scoring: a fit score, a bucket, and the reasons behind it, per registration.
• For a guest with a LinkedIn profile, when the host’s plan includes look-ups: a professional profile from a data vendor (see LinkedIn profile look-ups) and an AI-written two-line summary of it.
• Notes the host writes about the guest.

What we do not do

We never contact guests, and Vientic itself sends no email to guests. A host who pushes decisions back to Luma causes Luma to update the guest’s status, and Luma may email the guest about that under Luma’s own terms. We do not sell personal data, and we do not share it with advertisers.

• Luma API sync. With the host’s API key we read the guest list of the host’s own Luma events.
• Luma webhooks. If the host turns them on, Luma sends us a registration as it happens. We keep each delivery, including its signature headers, so a host can see what arrived.
• Luma calendar feeds (iCal). These carry events, not guests. A host who follows a partner’s calendar gets the events and can upload that event’s guest list as a CSV.
• CSV uploads. Guest-list exports from Luma or another tool, dropped onto an event. The file is stored in a private bucket; its columns are mapped to the fields above, and a column we cannot map is kept as a registration answer.

• Showing a host their guest list and letting them decide on it.
• Recognizing a returning guest across one host’s events and showing that history.
• Scoring registrations against the host’s own criteria, and explaining the score.
• Looking up a guest’s public professional profile, when the host’s plan allows it and the guest gave a LinkedIn URL.
• Building an event report, including a short narrative, which the host may share.
• Pushing a host’s decisions back to Luma when the host asks.
• Running the service: authentication, enforcing plan limits and detecting errors.
• Improving the quality of scoring and summaries by keeping a record of what the model was asked and what it answered (see AI processing).

Where European or UK data-protection law applies, our legal basis for a host’s account data is the contract we have with the host, and our basis for guest data is the host’s instructions, since we process it as the host’s processor.

Four features call a large language model. For each, here is what the model is sent:

• Scoring. A compact fact sheet per guest: name, headline, current title and company, location, a short career trajectory (titles, companies, dates) if a profile was looked up, the guest’s registration answers with email addresses and phone numbers removed and contact-detail questions dropped, and the counts of the guest’s past events with this host. Plus the host’s criteria. Never the raw vendor profile, never the guest’s email.
• Profile summary. The looked-up profile’s headline, roles, education and skills. The guest’s name is not sent.
• CSV column mapping. Column header text only, never a value from any row.
• Report narrative. Aggregate numbers about the event (how many registered, attended, returned). The model is instructed never to name a guest, and no guest name is in its input.

Model providers. We send these requests to paid model APIs under business terms that do not allow the provider to train on them. If the primary provider fails, the same request is retried down a fixed chain of fallbacks on the same terms; the chain, and the model vendors each route can reach, are in the table under Our service providers.

Our record of each call. We store every model request and response in full, with the account and the guest or registration it was about, so we can measure and improve the quality of scoring and summaries. When a guest is erased, their entries in this record are redacted to a marker, and the cost and timing fields are kept.

Decisions stay with the host. A score is a suggestion shown with its reasons. Vientic never admits or declines a guest on its own; a host chooses each decision and chooses when to send decisions to Luma.

When a host’s plan includes look-ups, the host has turned them on, and a guest supplied a LinkedIn URL, we send that URL (and nothing else about the guest) to a profile-data vendor and store what it returns: name, headline, occupation, summary, location, work history, education, skills, industry, follower and connection counts, and the vendor’s full response kept verbatim. The vendors are listed under Our service providers; which one answers first is an operator setting.

The cache. A fetched profile is keyed by the LinkedIn slug and used for 90 days; after that it counts as stale and is fetched again if still needed. A look-up that found no profile is also remembered for 90 days so the same empty answer is not bought again. The cache is shared across hosts: a profile fetched for one host is served to another host who asks about the same public profile, so it is not bought twice. It holds only what the vendor returned about a public profile, never a host’s notes, scores, decisions or guest lists. A stale copy is not deleted on a schedule today; a profile is deleted when the guest is erased.

These are the companies that process data for us (our “subprocessors”), what each one does, and what it receives. All of them operate from the United States. We will update this table before adding a provider that handles guest data, and we tell hosts in advance, as our data processing agreement describes. That agreement shows the same table, read from the same place, so the two cannot disagree.

Fonts are bundled with the site at build time, so your browser does not contact a font service when you visit.

• Sign-in session. Our authentication provider sets a cookie named sb-<project>-auth-token (sometimes split into numbered parts) that keeps you signed in. It is strictly necessary and is removed when you sign out.

That is the only cookie. There are no analytics, advertising or third-party tracking cookies, which is why the site shows no cookie banner. Public report pages set no cookies at all. If we add product analytics later we will update this section first.

• Host account and guest data: for as long as the account exists. See Deletion for what happens when you delete it.
• Uploaded CSV files: kept in a private bucket while the account exists, so an import can be re-read. Deleted when the account is purged, and when a guest in that file is erased (the whole file is removed, since it cannot be partially rewritten).
• Looked-up profiles: used for 90 days from the fetch, then treated as stale. The stored copy is kept until the guest is erased, when it is deleted immediately.
• AI call records: kept while the account exists; redacted per guest on erasure, and deleted with the account.
• Webhook deliveries and sync logs: kept with the account.
• Operator audit log: records of erasures and operator actions, holding counts and identifiers but no guest name or email.
• Database backups: daily, kept 7 days by our database provider; a deleted record can persist in a backup for that long.
• Error reports: kept by Sentry for 30 days.

Deleting your account

Under Settings → Account you can delete your workspace. It is scheduled for permanent deletion 30 days later and you are signed out. During those 30 days you can ask us to cancel. After the window we permanently delete the account and everything in it: events, guests, registrations, notes, reports and uploaded files. The purge is run by a person, not a scheduled job, so it may happen some time after day 30. Looked-up profiles in the shared cache describe a public profile rather than your account: they stay in the cache with the link to your account removed, and are deleted when that guest is erased.

Erasing one guest

A guest, or a host on a guest’s behalf, can ask us to erase that guest. Write to support@vientic.com with the email address or LinkedIn URL the guest registered with. Because the host is responsible for their guest list, we tell the host about a request that comes from a guest, and we carry out the erasure within 30 days. We then:

• delete the guest’s person record, notes about them, their looked-up profile and its cache entry, and any CSV file that carried them;
• scrub their registrations of name, email, LinkedIn URL, company, title, answers, score reasons and Luma identifiers, while keeping the anonymous fact that a seat existed, so the event’s counts do not silently change;
• redact their entries in the AI call record;
• keep a short suppression entry (Luma identifiers and a salted hash of the email, per event) so a later sync, webhook or re-import of the same event does not bring them back. A registration for a new event is a new relationship and comes in normally.

Because the same person can appear on several hosts’ lists, an erasure is applied per host, and we tell the requester which hosts it was applied to.

• Every table is protected by row-level security, so a host’s queries can only reach that host’s rows; service credentials never reach the browser.
• Uploaded files and generated PDFs live in private buckets and are served only through short-lived signed links.
• Luma API keys and webhook secrets are stored in an encrypted vault.
• Personal details are kept out of logs and error reports by design, and errors are scrubbed of email addresses, phone numbers and LinkedIn slugs before they leave.
• Connections to the site and to every provider use TLS.
• A small number of operators have an administrative view across accounts, used to run the service, answer support requests and carry out erasures. Every administrative action is written to an audit log.

Depending on where you live you may have the right to access, correct, export, restrict or erase personal data about you, to object to some processing, and to complain to your data-protection authority. To exercise any of them write to support@vientic.com. We may ask you to confirm the request from the email address we hold for you, and we answer within 30 days.

• Hosts can see and edit their account under Settings, export any event’s guest list as a CSV from the registrants page, and delete the account as described above.
• Guests can write to us or to the host who invited them. We will tell you which hosts hold data about you and act on erasure as described above.

For residents of California and other US states with privacy laws: we do not sell personal data, do not share it for cross-context advertising, and do not use it for profiling that produces legal or similarly significant effects on you. The categories we collect and the purposes are the ones listed on this page.

Our database, authentication and file storage are in Supabase’s us-west-1 region in the United States, and our other providers operate from the United States. If you or your guests are outside the United States, data about you is transferred there. Our data processing agreement incorporates the Standard Contractual Clauses for hosts in the European Economic Area, the United Kingdom and Switzerland.

Vientic is for people who run events and is not directed at children. You must be at least 18 to create an account. We do not knowingly process data about guests under 18 beyond what a host’s registration carries, and we delete it when we learn of it.

When this policy changes we will update the effective date at the top and, for a material change, email hosts before it takes effect.

support@vientic.com
Vientic, a sole proprietorship based in Seattle, Washington
2801 Alaskan Way, Seattle, WA 98121

See also our terms of service and data processing agreement.