Last updated 16 October 2026
Security
1. What this page is
Vuelly is a reporting dashboard. Agency users sign in with Google. The application runs on Vercel. Account data and reports sit in Supabase (Postgres and Auth). Meta and Klaviyo tokens are handled on the server.
The browser receives the Supabase URL, the publishable key, and the user's session. It does not receive the database service credential, the token encryption key, the Meta or Klaviyo app secrets, or a plaintext platform token.
2. What we protect
The sensitive material is the agency user's name and email, the client list, encrypted Meta and Klaviyo credentials, and the aggregated performance rows those credentials are used to fetch. We do not store Klaviyo email addresses, phone numbers, or subscriber profiles. Order history is stored as totals. Share links expose one client's report to anyone holding the link.
3. Controls in the product
- Transport. The site is served over HTTPS. Production responses include HSTS. Security headers include nosniff, a restrictive referrer policy, DENY framing, and a permissions policy that turns off camera, microphone, and geolocation.
- Tokens at rest. Meta and Klaviyo credentials are encrypted with AES-256-GCM before they are written to the database. Each ciphertext is bound to the agency, the provider, and the connection. Keys can be rotated. Authenticated database roles cannot read the ciphertext columns.
- Row-level security. Postgres row-level security limits an agency's signed-in queries to that agency's rows. A server-only service credential is used for provisioning, sync, share-link lookup, and the Meta deletion callback.
- Sign-in. Production sign-in is Google, through Supabase Auth. Session cookies are HttpOnly and SameSite=Lax, and Secure in production. Vuelly does not publish its own multi-factor enrolment screen. Google account security is the sign-in control.
- OAuth. Klaviyo uses PKCE. Meta uses PKCE unless the app is explicitly configured to skip it. Connect attempts use a one-time nonce bound to the signed-in user and agency. Redirects after sign-in are limited to relative paths and an allowlist of hosts.
- Disconnect. Disconnecting Meta calls Meta to revoke the permission, then deletes the ciphertext. Disconnecting Klaviyo OAuth revokes the refresh token, then deletes the ciphertext. A private Klaviyo API key has no revoke URL. We delete the ciphertext. A dead token is also cleared when the provider reports that it is no longer valid.
- Meta deletion callback. A signed request from Meta, verified with the app secret, deletes matched Meta connections and their reporting rows. The status page is public. Details are on the data deletion page.
- Rate limits. Sign-in, OAuth, sign-out, and share resolution are rate limited. Limits are counted in the server process, or in Upstash when that store is configured. If Upstash is configured and cannot be reached, those routes fail closed.
- Audit log. Sign-in, sign-out, connect, disconnect, revoke, share create, rotate, revoke, and access, and client offboard, are written to an append-only log. Share views store a hash of the IP address and user agent. The log strips fields whose names look like tokens or passwords.
- Sync limits. Each agency is limited in how many syncs it can start and run in an hour.
5. What we do not claim
We have not commissioned a SOC 2 report, an ISO/IEC 27001 certificate, or a published penetration test. We do not offer an uptime SLA. We do not offer customers an on-site audit. Disconnecting a platform deletes the token immediately. It does not, by itself, delete historical reporting rows. That deletion path is described in the Privacy Policy and the data deletion instructions.
Founder access to Vercel, Supabase, Google, Meta, and Klaviyo is an operational matter outside this repository. A customer should not read this page as a statement that every console has been certified.
6. Report a concern
Email hello@vuelly.com if you believe you have found a security weakness or an unauthorised disclosure. Please describe the issue and give us a reasonable chance to investigate before you publish it. We do not run a paid bug-bounty program. This request is not a promise of safe harbour.