Public document · forward freely to your reviewer
Security & data-handling packet
Published July 4, 2026 · Tideover (pilot stage). This is a plain publish date, not an audit date.
This is the one document to forward to whoever reviews tools before you adopt them. It assembles, on a single printable page, what tideover.app/security and tideover.app/privacy already state: exactly what Tideover can and cannot see, how to cut every integration off, who processes your data, how long it is kept, and what we do and do not claim. Every line describes real behavior in the Tideover codebase.
What Tideover can — and cannot — see
How to cut us off — one action per integration rung
| Rung | What it grants Tideover | How you cut us off |
|---|---|---|
| 0 — CSV import | The order/customer fields from a file you upload yourself. | Nothing recurring to revoke — stop uploading, and email us to delete the imported records. |
| 1 — Email forwarding | A copy of the presale mail your forwarding rule sends to a Tideover alias. | Delete the forwarding rule in your mail settings. Mail stops reaching us immediately. |
| 2 — Helpdesk webhook | Presale ticket events your helpdesk fires at our ingest URL (e.g. a Gorgias HTTP integration). | Deactivate or delete the webhook or trigger in your helpdesk. No further events reach us. |
| 3 — Write-back API key | A least-privilege agent-user key so approved replies post back inside your helpdesk. | Reset the API key (invalidates instantly) or delete the Tideover agent user. |
| Optional — Shopify custom app | Read-only order data, if you ever create a custom app with read_orders. | Uninstall the custom app from your Shopify admin. |
Sub-processors (4)
The full set of third parties that process routed data. We name them all, and we update this list before adding another.
Data retention, deletion & export
We keep routed tickets and the order and customer records they depend on for as long as your pilot or account is active. Status-page view logs are append-only evidence records, kept for the same period. When you no longer need a record, or when your account ends, we delete it (see below).
You can ask us to export or delete the data you have routed to us at any time by emailing hello@tideover.app, and we will act on the request within a reasonable period. When your account ends, we delete the data you routed to us. Because you are the controller, you can also cut the flow at the source at any time — the Security page lists the one action that revokes each integration.
Security posture — architecture, not badges
Tideover holds only what a routed presale ticket needs (see above). The one place buyer data leaves the system — a status link you share — is a single narrow function (getPublicStatus in lib/status.ts) that exposes only that order's first name, order reference, region, timeline, and a confidence band. Email, lifetime value, risk score, and every other order are defined out of that function, so the status page cannot leak them even by mistake.
When you scope Tideover to your presale tags, the ingest endpoint verifies the vendor's signature over the exact raw bytes received, then parses, then checks the payload against your tag allow-list, then persists. A non-matching payload is acknowledged with a 200 and discarded before it is ever written to a database or drafted — the only trace is a log line. Untrusted input is never parsed or stored before it is authenticated (app/api/ticket-ingest/route.ts).
The cockpit and dashboards sit behind a signed session cookie. In live mode, middleware on the edge gates every operator page and API: a request without a valid, unexpired, HMAC-SHA256-signed session (keyed with a server-side AUTH_SECRET) is redirected to sign-in or refused. Rotating that secret revokes every active session immediately; changing the operator password stops new sign-ins. Public surfaces — this packet, buyers' status links, and the marketing site — are intentionally never gated.
When a buyer opens a status link, Tideover records the time, a shortened browser user-agent, and only the first two octets of their IP address (e.g. "203.0", never the full address). These are append-only records kept as factual "notified on X, viewed on Y" chargeback evidence — not a behavioral profile.
There is no code path in Tideover that reads card or payment data, your Shopify admin, your full customer list, or any password. Integrations are forwarding aliases, webhooks with a shared secret, and least-privilege API keys only. Each rung is revocable in one action (see the ladder above).
Tideover's copy and product never state a fabricated metric, testimonial, rating, logo count, or hard delivery date; a linter (scripts/proof-lint.mjs) enforces it in CI. This packet is written under the same rule — it describes behavior, and names real sub-processors, rather than pointing at a badge.
What Tideover does not claim
Tideover is a pilot-stage product and we will not dress it up. We do not hold SOC 2. We have not completed a third-party penetration test or security audit. We do not claim “bank-level” or “military-grade” encryption, and we do not claim to be “GDPR compliant” or to carry any certification.
What we can give you is everything on this page: what we store, what we drop, who processes it, and how you cut us off in one action. The safety here is structural — we hold as little as the job needs — rather than a badge we point at. That honesty is the credibility.
For your technical reviewer
The reasoning behind every data-exposure and auth decision above is written down as Architecture Decision Records (docs/adr/) in the Tideover repository — each a short record of the “why” a reviewer can read without archaeology. We share the repository, or any specific record, with your technical reviewer on request. The most relevant to a data-handling review: