Security and data handling.
A short, plainspoken summary of what we touch, what we don't, and how we keep it safe. Written for restaurant operators and their IT teams.
DineRoute is built on the principle that your restaurant's customer data should never leave your control. We are a thin attribution layer — your Meta Pixel, your Google Ads tag, your GA4 property, your TikTok Pixel fire your conversions to your ad accounts, not ours.
That principle drives almost every architecture decision below. We hold the minimum amount of data needed to route a click to the right restaurant and forward a server-side event back to the platforms you already use. Then we get out of the way.
Three things we get right before we worry about anything else.
These are the controls that matter most for a service holding attribution data and ad-platform credentials.
Encryption at rest and in transit
All data is stored in Supabase Postgres on AWS us-east-1 with disk-level AES-256 encryption. Meta CAPI tokens and other secrets are additionally encrypted column-level with pgcrypto so a database snapshot alone cannot leak them. TLS 1.2+ on every connection.
Least-privilege access
Production database access is restricted to two engineers via SSO + hardware key. No customer support reps, contractors, or AI tools touch raw event data. Row-level security on every table enforces tenant isolation — a restaurant operator's read queries can only ever see their own location.
Audit logging
Every admin action, integration credential change, and tenant-scoped data export is logged with actor, timestamp, IP, and diff. Logs are immutable, retained 12 months, and available to enterprise customers on request. We monitor for anomalies daily.
Data handling, in detail
What we collect
- Page visits on your DineRoute smart-link page (timestamp, page URL, referrer)
- Platform clicks (which platform tile a visitor tapped — DoorDash, Uber Eats, etc.)
- Click IDs from inbound ad traffic: fbclid (Meta), gclid / gbraid / wbraid (Google), ttclid (TikTok)
- UTMs and other querystring parameters present on the inbound URL
- The visitor's device User-Agent and IP address (used for fraud scoring and CAPI Match Quality)
- A first-party visitor ID cookie (dr_vid) we generate so we can dedupe events across a single session
What we don't collect
- No order content. We never see the diner's cart, items, or order totals — they place orders on DoorDash, Uber Eats, or your site, not on us.
- No payment information. Ever. There is no payment surface on a DineRoute smart-link page.
- No PII from end diners beyond the IP and User-Agent that any web server would log. No name, email, phone number, or address is collected on a smart-link page.
- No cross-site tracking. The dr_attrib and dr_vid cookies are first-party to your restaurant's smart-link page and are not shared across customers.
Where it lives
All event and configuration data lives in a single Supabase Postgres database in AWS us-east-1, encrypted at rest with AES-256. We use pgcrypto for column-level encryption on the values we treat as secrets: Meta Conversions API tokens, TikTok Events API tokens, and admin session material. Those columns cannot be read without a key held in our application config, not the database itself.
How long we keep it
- Raw events: 90 days from collection. After that they are aggregated and deleted.
- Aggregates: retained indefinitely so your historical dashboards stay accurate. Aggregates are click counts, conversion counts, and Match Quality scores — never individual click IDs or device fingerprints.
- Exports: on request, any time, via the admin dashboard or by emailing privacy@dineroute.com.
- On cancellation: raw events purged within 30 days. Aggregates and billing records kept 7 years for tax and accounting compliance, then deleted.
Subprocessors
We use a small, deliberately short list of vendors. Each is bound by a data processing agreement that mirrors the obligations we have to you.
- Netlify — marketing site hosting and edge functions for the smart-link redirect layer.
- Supabase — managed Postgres database, authentication, and storage. Hosted on AWS us-east-1.
- Resend — transactional email delivery (account verification, billing receipts, security alerts).
- Cloudflare — DNS, edge proxy, and WAF in front of customer-facing routes.
- Stripe — payment processing for subscriptions. Stripe receives billing data only; never event data.
Subject to change — current list updated 2026-05-21. We notify customers at least 30 days before adding a new subprocessor that touches event data.
Vulnerability reporting
If you believe you have found a security issue in DineRoute, please email security@dineroute.com. PGP key available on request. We acknowledge reports within one business day and aim to provide a remediation plan within seven days for confirmed issues. We do not yet run a bug bounty program, but we credit researchers in our changelog with permission.
What restaurant IT teams ask before they sign.
Are you SOC 2 compliant?
Not yet. SOC 2 Type I is in scope for 2027, after we hit the customer count where it becomes the right tradeoff. In the meantime we run on AWS us-east-1 inside Supabase, which is itself SOC 2 Type II. Our application-layer controls (RLS, least-privilege access, audit logs, encrypted secrets) are designed against the SOC 2 trust criteria.
Do you run penetration tests?
We commission an external penetration test annually, with the next one scheduled for Q4 2026. We also run automated dependency and SAST scans on every pull request. Summary reports are available under NDA to enterprise customers.
What encryption do you use?
AES-256 at rest on Supabase-managed Postgres, TLS 1.2 or higher on every connection (HSTS enforced, modern ciphers only), and pgcrypto column-level encryption on the secrets we hold for you — Meta CAPI tokens, TikTok Events API tokens, and admin session material.
Where does the data physically live?
AWS us-east-1 (Northern Virginia) inside our Supabase project. We do not currently offer EU residency. If that is a hard requirement for you, contact us — we are evaluating a Supabase EU project for a 2027 launch.
Will you sign a GDPR data processing agreement?
Yes. We act as a processor for restaurant operators and a sub-processor where agencies resell DineRoute. We provide a standard DPA on request — email privacy@dineroute.com and we will get a signed version back within two business days.
Do you comply with CCPA?
Yes. Restaurant operators are the business and DineRoute is the service provider under CCPA. We do not sell personal information and we do not share it across customers. End diners on smart-link pages can submit CCPA deletion or access requests through privacy@dineroute.com and we route them to the relevant restaurant operator.
Can I export all of my data?
Any time. From the admin dashboard you can export raw events, aggregates, and integration configs as CSV or JSON. The export covers your full retention window. Enterprise customers get a scheduled S3 delivery option.
What happens if I delete my account?
Raw event data tied to your tenant is purged within 30 days of cancellation. Aggregates and billing records are retained for 7 years for tax and accounting compliance, in line with US bookkeeping requirements. You can request earlier purge of aggregates by emailing privacy@dineroute.com.
We answer the boring questions in plain language.
Send us your IT security questionnaire. We have answered it before. We will fill it out, send it back, and not make you wait.
Response SLA: one business day. Most questionnaires returned within three.