Security at Vertex
Vertex reads sensitive commercial data — orders, costs, ad spend, customer contacts. This page describes the concrete controls that protect it, the architecture it flows through, and how to report a problem if you find one. It’s written to be sent to a security reviewer as-is.
Platform OAuth/access tokens are encrypted with AES-256-GCM before they touch the database. Customer phone numbers and emails are SHA-256 hashed — shoppers are shown anonymously and raw PII is never stored.
Every request — browser to app, app to database, app to platform APIs — travels over TLS 1.2+. There is no unencrypted path for your data.
A daily logical backup is written to independent object storage (Cloudflare R2), separate from the primary database, plus point-in-time recovery. A written disaster-recovery runbook covers restore, rollback, and key rotation.
Privileged actions — cost changes, connections, impersonation, erasure — are recorded in a fleet-wide, filterable audit log. We can always answer “who changed what, and when.”
Data is isolated per organization. Role-based access control and plan entitlements are enforced on the server, not just hidden in the UI — a lower role cannot reach data it shouldn’t.
Email-and-password and passwordless magic-link sign-in, with optional email verification. Sensitive auth endpoints (sign-in, reset, magic-link) are rate-limited to blunt brute-force and bombing attacks.
Credential-bearing endpoints and webhooks enforce per-IP throttling and payload bounds, so a single bad actor can’t hammer the system or smuggle oversized payloads.
We run on Vercel, Neon Postgres, and Cloudflare — managed, audited platforms — so there are no unpatched servers of our own. A public /api/health endpoint and automated ops alerts watch availability.
Architecture
People trust what they can understand. Here’s the path your data takes — from your store to the number on your dashboard. Tokens are encrypted before storage; customer PII is hashed; nothing leaves over an unencrypted channel.
A separate first-party Cloudflare Worker captures ad-click events at the edge and writes to the same encrypted database, so attribution never depends on third-party cookies.
Report a vulnerability
We welcome reports from security researchers. If you believe you’ve found a vulnerability, email us — please don’t disclose it publicly until we’ve had a chance to fix it.
security@tryvertex.io- • We acknowledge good-faith reports and aim to respond within 2 business days.
- • We won’t pursue legal action against researchers who follow responsible disclosure and avoid privacy violations or service disruption.
- • Please include steps to reproduce, affected URLs, and the impact you observed.
Sub-processors
| Provider | Purpose |
|---|---|
| Vercel | Application & API hosting, cron |
| Neon | Serverless Postgres database |
| Cloudflare | Edge pixel worker + encrypted backup storage (R2) |
| Upstash | Distributed rate limiting |
| Email provider | Transactional email (invites, resets, alerts) |
| Salla / Zid | Store data — only on merchant connect |
| Meta / TikTok / Snapchat / Google | Ad data — only on merchant connect |
For data-handling specifics see the Privacy Policy, and for the broader picture visit the Trust Center.