A guest list is personal data, an invitation link is a key and a QR code is a pass. Winglark is designed so that each of them is protected by the architecture itself — scoped to its owner, stored as a secret only we can verify, and checked on our servers every time it is used.
Each boundary is enforced on the server: a guest’s link opens one invitation, inside one event, inside one client, inside one organisation.
Per workspaceEvery lookup is scoped to the organisation that owns the record
Argon2idPassword hashing, with sign-in that never reveals whether an account exists
Keyed digestsInvitation links, sign-in links and door codes are stored only as keyed digests
EU storageWorkspace and guest data are stored in the European Union
Security by design
Security is part of the architecture, not a layer on top.
The safest path through Winglark is the only path. Protection is built into how data is looked up, where code runs and how every integration behaves.
Server-side by construction
Everything that reads or changes your data runs on our servers, never in the browser. Server modules are marked so they cannot reach a visitor’s device, and automated tests hold that boundary.
Ownership in every query
A record is fetched together with the organisation that owns it. There is no separate “found it, now check access” step that could be forgotten — access is part of the lookup itself.
Secure by default
An integration without its credentials refuses rather than opens. Incoming webhooks without a configured key reject every call, and switched-off features cannot be reached through a side door.
Least privilege
Each workspace role carries only the permissions its job needs, and our own staff act through a narrow, audited channel.
Nothing technical on screen
Error pages never expose database messages, stack traces or configuration details. Those stay in our own operational records.
Swipe for more
Organisation & tenant isolation
Your organisation is a boundary, not a filter.
Each workspace belongs to one organisation. Its events, guests, lists and designs are reachable only from inside it — and inside an agency workspace, every client can be kept apart as well.
Tenant isolation
Every lookup is made against the workspace that owns the record. A record belonging to another organisation behaves exactly as if it did not exist, so it can never be read, changed or even confirmed.
Agencies and their clients
Records carry the client they belong to. Lists, designs and events are filtered by client on the server, and a member’s access to a client can only narrow what their role already allows.
Proven by tests
Cross-organisation and cross-client attempts are part of the automated test suite, so the boundary is verified with every release rather than assumed.
Recorded changes
Administrative actions and sensitive changes are written to an audit log, giving a clear record of who changed what.
Swipe for more
A request can only find records inside the workspace — and, for agencies, the client — it belongs to.
Data protection
Personal data, handled with care at every step.
Guest data is encrypted on the way in, stored in the European Union, shown only to the people who need it and exported only with a reason.
Encrypted in transit
All traffic to Winglark uses HTTPS, plain HTTP is redirected, and browsers are told to use nothing else (HSTS). Connections between our application and its database are encrypted.
Encrypted at rest
Stored data is encrypted at rest by our hosting and database platforms. On top of that, secrets such as links, codes and sessions are stored only as keyed digests.
Stored in the EU
Workspace and guest data are stored in the European Union: the application runs in Frankfurt and the production database is hosted in the EU.
Need-to-know visibility
Guest email addresses and phone numbers are masked for team members who are not allowed to see them. Sensitive answers, such as dietary or accessibility needs, are visible only to the roles that need them.
Accountable exports
Guest lists can be exported as CSV or Excel on every plan. Exports that contain personal data ask for a reason, mask what the exporter may not see, and are recorded.
One standard, every country
The EU’s GDPR is the baseline, and the same controls serve organisers and guests under other data protection laws, such as the UK GDPR, Türkiye’s KVKK, Switzerland’s FADP and California’s CCPA.
Swipe for more
Identity & access control
Who you are, and exactly what you may do.
Sign-in is protected against guessing and enumeration, sessions live on the server, and every role in a workspace carries a precise set of permissions.
Sign in with Google
Google sign-in uses the standard OAuth 2.0 authorisation-code flow with PKCE, state and nonce checks, and links an account only to an address Google has verified.
Strong password protection
Passwords are hashed with Argon2id and a unique salt. They are never stored, logged or recoverable, and sign-in and password reset give the same answer whether or not an address has an account.
Single-use account links
Password-reset, email-confirmation and activation links work once, for one purpose and one person, and expire. A password reset signs the account out everywhere.
Server-side sessions
Sessions use secure, HTTP-only cookies. The session token is stored on the server as a keyed digest and can be revoked there at any time.
Role-based permissions
Owners, managers, marketing and guest managers, reporters and door staff each hold a defined set of permissions. Door staff see the door screen only; reporters can read but not change.
Rate limiting
Sign-in, sign-up, password reset, invitation lookups, replies and public forms are rate-limited to slow down guessing and abuse.
Controlled staff access
Access to Winglark’s internal console is limited to named staff and can be revoked at once. Every change our staff make to a customer account requires a stated reason and is written to an audit log.
Swipe for more
What each workspace role may do (simplified).
Workspace settings
Guest list
Contact details
Send invitations
Sensitive answers
Reports
Owner
Allowed
Allowed
Allowed
Allowed
Allowed
Allowed
Manager
Allowed
Allowed
Allowed
Allowed
·Not allowed
Allowed
Guest manager
·Not allowed
Allowed
Allowed
Allowed
Allowed
Allowed
Marketing manager
·Not allowed
·Not allowed
·Not allowed
Allowed
·Not allowed
Allowed
Reporter
·Not allowed
·Not allowed
·Not allowed
·Not allowed
·Not allowed
Allowed
Door staff
·Not allowed
·Not allowed
·Not allowed
·Not allowed
·Not allowed
·Not allowed
What each workspace role may do (simplified).
Secure invitation architecture
Every invitation is a key only its guest holds.
Invitations and replies are designed so that a guest reaches their own invitation and nothing else, and every answer they give is recorded faithfully.
Unguessable links
Each guest’s link carries 256 bits of unguessable value and no personal information. Only a keyed digest of it is stored, so even a copy of our database could not be turned into working links.
Protected lookups
Invitation lookups are rate-limited, and resending an invitation replaces the previous link.
One faithful reply
Each guest has one answer they can change until replies close. Every change is kept as a revision, and simultaneous submissions can never create a second reply.
Guests see only their own
A guest can open only their own invitation — never another guest’s details or answers.
Safe imports
ListGuard reads uploaded spreadsheets as data only: formulas are neutralised, files are size-limited, and lists are checked for errors and duplicates before anyone is invited.
Swipe for more
GatePass QR security
A door pass that cannot be guessed, copied into use or reused.
GatePass turns any phone into a secure scanner. Every pass is checked on our servers, admits once, and stays safe even when the door loses its signal.
Opaque, signed passes
A QR pass carries an opaque code and nothing about the guest. It is generated with a server-side secret key, so it cannot be guessed or forged, and only a keyed digest of it is stored.
Verified on the server
A scanned code is checked on our servers. Each pass admits once, a second scan is flagged, and codes from another event, revoked passes and withdrawn devices are refused.
Revocable devices
A lost door phone can be switched off centrally; a revoked device can neither scan nor sync.
Safe offline mode
The list a door phone keeps for moments without signal holds no contact details and no usable pass values, and it expires after 12 hours.
Reconciled on reconnect
Every admission made offline is checked again by the server when the phone reconnects. The first arrival counts, duplicates are raised, and nothing is overwritten.
Key rotation
Rotating the server key invalidates every outstanding pass at once.
Swipe for more
Door check-in is included in the plans that offer it, or can be added to a single event.
01LinkUnguessable, stored as a keyed digest
02ReplyOne answer per guest, every change kept
03PassSigned with a server key, nothing personal
04ScanChecked on the server, admits once
05OfflineNo contacts, expires, re-checked on reconnect
The guest’s path, and the protection at each step.
Live participation
Guests take part. Nobody takes over the room.
During an event, guests answer polls, ask questions and react from their own phones through Companion and LivePulse. Each link opens one event, taking part needs no account, and nothing a guest writes reaches the room until the organisers approve it.
Links scoped to one event
Every guest link opens a single event. Links are derived from a server-side secret and only a keyed digest of each is stored, so they cannot be guessed or listed.
No pass on the open link
The open link from a QR code in the room is anonymous and never shows an entry pass. A guest’s GatePass pass appears only on their personal page, and only while door check-in is active.
Replaced in one action
The organisers can replace every guest link at once, and the room-screen link separately. The old links stop working immediately; a screen showing the old link goes dark at its next refresh.
One phone, one voice, no account
A phone is recognised by a signed key for that event alone, held in a cookie scripts cannot read. Answers and votes are stored against a keyed digest of it, never a name, and each phone answers a poll once.
Moderated before it is shown
Questions wait for approval by the organising team before they reach the room’s list or the screen; rejected questions never appear.
Limits against floods
Votes, questions, upvotes and reactions are rate-limited per phone, and questions across a shared network too.
Networking only by choice
In MeetFlow, a guest appears to others only after writing a profile and choosing to be visible, only to guests of the same event, and only on their own invitation link. Nothing is taken from the guest list, and hiding or leaving takes one tap.
Notes between two people
Requests and notes between guests are visible to those two guests only. Organisers see counts — how many take part, how many requests — never what was written. A blocked guest and the blocker no longer see each other.
Messages stay with the hosts
Voice, video and written messages left through VoiceBook reach the organising team only. One is shown anywhere else only when the guest allowed it and the organisers approved it; a guest can take a message back from their own phone, and the recording is deleted. Recordings are not sent to any AI service; transcripts are typed by the organising team.
Photos private until approved
MomentFlow keeps every photo and video guests send visible to the organising team only until it is approved for the screen or the gallery. Each guest answers two separate questions — keep it for this event, and, unticked by default, use it in promotion — and can take any moment back from their own private link. Files are stored in the EU.
A visit is a scan, nothing more
Event Passport counts a place only when its printed code is scanned — no location, no background tracking. Each place counts once per guest, and organisers see totals by place, never one person’s route.
Swipe for more
Audience consent
Your audience is yours. Their choice is theirs.
With AudiencePass, a venue keeps a permanent QR code that visitors scan to hear about its future events. The people who join are the organisation’s contacts, and the decision to leave belongs to each of them — Winglark enforces it.
Not Winglark’s audience
Contacts collected through AudiencePass are processed to run the organisation’s list and send what it chooses to send. Winglark does not use them for its own marketing and does not show them to any other customer.
A decision the organisation cannot lift
Leaving records a suppression on Winglark’s side. No setting, role, selection or import removes it; only the person can rejoin, from their own link.
One rule on every send path
AudiencePass mail, ReachLab campaigns and first invitations through MailFlow all ask the same question before they write to somebody.
Kept apart, even from itself
The same address in two organisations is two unrelated records. A suppression is stored as a keyed digest that differs per organisation, so the two cannot be joined.
Confirmed by default
A person counts only after pressing the link sent to their inbox. The consent history keeps the sentence they agreed to, when and in which language — no IP address, no device fingerprint.
Codes that cannot be guessed
Each QR carries a random, keyed token that names nothing. A code can be replaced in one action; the old one stops at once.
Follow-ups ask the same question
After an event, AfterFlow sends only what an organiser approved, through MailFlow, and checks every recipient at the moment of sending against the same rule: suppressions, unsubscribes, audience leaves and refused consent. Every follow-up carries a one-click way out, and opens and clicks are not tracked.
Sponsors receive only a yes
With SponsorFlow, a sponsor or exhibitor receives a participant’s details only after that person agrees on their own phone to share with that one sponsor; each yes is recorded with the wording’s version and language. A scanned code is never a lead, booth staff see only their own sponsor, and stopping removes the details at once.
Swipe for more
Webhook verification
Only signed messages change what Winglark knows.
Delivery reports from our email provider update invitation status. Winglark accepts them only when it can prove where they came from.
Signature verification
Every delivery webhook must carry a valid signature from the provider, checked with a constant-time comparison before anything is processed.
Replay protection
Signed messages are accepted only within a short time window, so an old message cannot be replayed later.
Counted once
Each delivery event is recorded exactly once, however many times the provider retries it.
Closed without a key
A webhook endpoint without its verification key configured refuses every request.
Your API keys
A workspace API key is shown once, when it is created, and stored only as a keyed hash. Each key is limited to the scopes chosen for it, can be revoked at any moment, and stops working when the member who created it loses access.
Webhooks we send
Messages Winglark sends to your systems are signed with a timestamped HMAC, go only to public HTTPS addresses checked again at every send, are retried on a fixed schedule and are logged for you to inspect.
Swipe for more
Secure communications
Mail sent carefully, from senders you can trust.
MailFlow sends invitations through an established email delivery provider and follows every message from queued to delivered.
Verified senders
Invitations leave only from a sender address whose domain has been verified with the email provider.
Automatic suppression
Addresses that bounce permanently or complain are kept out of future sends automatically. A complaint can never be released, and every send path honours the suppression list.
Consent-based marketing
Our early-access list is double opt-in, and every message carries a one-click unsubscribe that needs no account.
Controlled channels
Text and WhatsApp messaging stay switched off on production, so guest phone numbers are never messaged.
Swipe for more
01Verified senderOnly a confirmed domain can send
02ProviderDelivered by an established email service
03Signed reportUnsigned or stale reports are refused
04SuppressionBounces and complaints are kept out
How an invitation leaves, and how we know what happened to it.
Infrastructure security
Established platforms, clearly divided responsibilities.
Winglark runs on Vercel and Neon in the European Union. The providers secure their platforms; Winglark secures how they are used.
Secret management
Credentials are kept in the hosting platform’s secret store, never in code. Each kind of credential — sessions, invitation links, door codes, the internal console — has its own key.
Browser protections
Every page is sent with security headers that block framing and content sniffing, limit referrer data and restrict powerful browser features.
Continuous backups
Our database provider keeps a continuous history of the production database, and Winglark maintains a documented procedure for restoring from it.
Health monitoring
A health check reports the state of the service, including database reachability and schema readiness, and operational failures are raised in a staff exception queue.
Swipe for more
Who is responsible for what.
Area
Provider
Winglark
Hosting and network
Vercel runs and secures the platform and its network.
Configuration, security headers, which branch may deploy.
Database
Neon runs the database, encrypts storage and keeps point-in-time history.
Schema, organisation scoping in every query, the restore procedure.
Email
Resend delivers mail and signs its delivery reports.
Verified senders, signature checks, suppression.
Sign-in with Google
Google authenticates the person.
The OAuth flow checks and which accounts are linked.
AI Studio
OpenAI generates text and images.
What is sent, fact checks, where results are stored.
Who is responsible for what.
Production & staging separation
Live data lives in its own world.
Production is fully separated from staging and development, so building and testing Winglark never touches customer data.
Separate environments
Production and staging use separate database projects and separate deployment scopes. Development and testing run against staging and disposable test databases, never production.
Controlled releases
Only Winglark’s release branch can deploy Winglark, and every release is checked on the live site after it ships, with the previous deployment kept ready as a rollback point.
Safe database changes
Database changes are additive and backwards-compatible, applied before the release that needs them. The service reports itself unhealthy if its database schema is behind.
Swipe for more
Automated security testing
Security rules are tested, not remembered.
More than 3,500 automated tests run before release. The security-critical ones check the boundaries described on this page directly.
Isolation
Tests attempt to reach another organisation’s events, guests and clients, and confirm that every attempt is refused.
Tokens and links
Tests confirm that links work once, expire, cannot be reused for another purpose and are stored only as digests.
The door
Tests cover single admission, simultaneous scans, revoked devices, foreign passes and offline reconciliation.
Webhooks and permissions
Tests confirm that unsigned or stale webhooks are refused and that every staff action checks its permission and requires a reason.
Swipe for more
Secure development practices
Security is part of how Winglark is built.
Every change follows the same disciplined routine, from the first line of code to the check on the live site.
Security hardening
Winglark went through a dedicated security hardening pass before launch.
Evidence-based claims
Every statement on this page is traced to the code, configuration or tests that implement it, in an internal evidence record maintained alongside the product.
Guarded boundaries
The line between server and browser, the scoping of every query and the handling of secrets are enforced by code structure and tests, not by convention.
Isolated development
Winglark is developed and released on its own branch and project, separate from anything else in its repository.
Swipe for more
AI & data processing
AI Studio sees your event, never your guest list.
AI Studio runs only when you use it, on the plans that include it. Its provider is OpenAI.
Minimal data
Only the event details (title, dates and times, venue, reply deadline), your style settings and brand kit, and your own instructions are sent — plus an image you choose to edit. No guest names, addresses or answers.
Results stay with you
Generated designs are copied into your own workspace, behind the same organisation isolation as everything else.
Facts protected
Generated text is checked against the event’s date, time and venue before you see it, and those facts stay editable in the event itself.
Model training
OpenAI’s API terms state that data sent through its API is not used to train its models by default.
Swipe for more
Privacy & data governance
Your data serves your events — and nothing else.
The organiser decides what goes into Winglark; Winglark stores and processes it to run the organiser’s events. The Privacy Policy is the governing document.
No selling, no sharing
Winglark does not sell data, does not share guest lists between organisers and does not market to guests.
Analytics after consent
Website analytics and advertising measurement run only after a visitor agrees, and session recording is switched off.
Transparent subprocessors
The services that process data on our behalf are listed with their purpose and location on the subprocessors page.
Event pages show what you choose
An event’s own page under EventSite is unlisted by default and asks search engines not to list it; it can be limited to invited guests or made public by the organiser. People who register become guests in that organisation’s workspace and nowhere else, and the event pages load no third-party trackers.
Swipe for more
For your assessment
Security documentation requests.
If your team is evaluating Winglark, we will answer your security questionnaire and walk you through the architecture described here.
Security questionnairesWe complete standard questionnaires with the same level of candour as this page.
Architecture walkthroughA call with the people who built the system, covering isolation, tokens, the door and our providers.
Privacy and subprocessorsThe Privacy Policy, Terms and the current subprocessor list.
If you believe you have found a vulnerability in Winglark, report it privately. The disclosure page explains what to include and how to test responsibly.
No. Every lookup is made against the workspace that owns the record, so a record from another organisation behaves as if it does not exist. Agencies can also keep each client’s data apart, enforced on the server, and these boundaries are verified by automated tests before release.
How are our guests’ personal details protected?
Guest data is encrypted in transit and at rest and stored in the EU. Contact details are masked for team members without permission to see them, sensitive answers are limited to the roles that need them, and exports with personal data require a reason and are recorded. Invitation links and door codes carry no personal information.
Which sign-in options are available?
Sign in with Google (OAuth 2.0 with PKCE) or with an email address and a password hashed with Argon2id. Multi-factor authentication and enterprise single sign-on such as SAML are not offered at this time.
How is access controlled inside our workspace?
Each member has a role with a defined set of permissions — from owner to reporter and door staff. Contact details and sensitive answers follow those permissions, and door staff only ever see the door screen.
How secure are invitation links and QR passes?
Invitation links carry 256 bits of unguessable value and QR passes are generated with a server-side secret key. Both are stored only as keyed digests, checked on our servers, and a pass admits its guest once.
Where is our data stored?
In the European Union: the application runs in Frankfurt and the production database is hosted in the EU. Some subprocessors, such as email delivery and AI Studio’s provider, may process data outside the EU; the subprocessors page lists each one.
Do you follow GDPR, KVKK and other data protection laws?
Winglark is built to the EU’s General Data Protection Regulation as its baseline, and the same protections apply to people wherever they live, including under the UK GDPR, Türkiye’s KVKK, Switzerland’s FADP and California’s CCPA: data stored in the EU, access limited by role, export on every plan, and deletion of an event, its guest list or a whole account. The organiser decides why guest data is collected, and Winglark processes it on their behalf. The Privacy Policy is the governing document; questions about a specific law can be sent through the contact page.
Is guest data sent to AI?
No. AI Studio sends only event details and your own instructions to its provider, and only when you use it.
How do you handle a security incident?
The people who built Winglark investigate directly: contain the issue, restore service and inform affected customers using the contact details on their workspace. We do not publish contractual response or recovery times.
Do you have backups?
Yes. Our database provider keeps a continuous history of the production database, and Winglark maintains a documented procedure for restoring from it.
Do you hold SOC 2 or ISO 27001 certification?
Not at this time, and no independent penetration test has been commissioned yet. Our security controls are documented control by control against the code and tests that implement them, and we walk security teams through them during an assessment.
Can we receive security documentation for our assessment?
Yes. We answer security questionnaires and offer an architecture walkthrough with the people who built the system. Use the contact page and mention your assessment.
See it on your own event.
Winglark is in early access. Request access, a person reviews it, and an invitation to your workspace follows.