What Tideover can see — and what it can’t.
This page is for you and whoever reviews tools before you adopt them. It describes how Tideover actually handles data, in plain terms. We hold as little as the job needs, we drop what isn't presale before it lands in a database, and every integration has a single action that cuts us off. That is the design, not a policy we promise to follow later.
Everything on this page plus our sub-processors and data-handling, on one printable page to forward to a security or procurement reviewer.
What Tideover can see
Only the data a routed presale ticket actually needs.
- The presale tickets you route to usThe subject and body text of the support messages you forward or webhook to Tideover, the customer's email address, an order reference if the message carries one, and when it was sent. That is the message you chose to send us — nothing more from your inbox.
- The order and customer details needed to match a ticket to a real timelineFor the orders and customers you route or import: first name, email, order value, region, production stage, and the delivery estimate disclosed at purchase. We use these to compute the timeline and risk you see, and the reassurance the buyer sees. Not your whole store — only what a routed ticket needs.
- Status-page view metadata, for dispute evidenceWhen a buyer opens a status link you shared, we log 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). It is a factual "notified on X, viewed on Y" record, kept as chargeback evidence.
What Tideover never sees
No code path in Tideover reaches any of this.
- Card or payment dataTideover never touches checkout or a payment processor. Card numbers, bank details, and payment credentials live with Shopify, Kickstarter, and your processor. There is no code path in Tideover that reads them.
- Your Shopify adminRunning the pilot needs no app install, no admin password, and no OAuth into your store. The forwarding and webhook rungs move tickets to us without granting any access to your Shopify admin.
- Your full customer listWe only receive the customers attached to the tickets you route, plus any export you deliberately choose to import. Tideover never performs a bulk pull of your store's customer database.
- PasswordsNo integration rung asks for a login. Forwarding aliases, webhooks with a shared secret, and least-privilege API keys are the only mechanisms — never your password.
- Anything outside the tickets you send usMessages you don't route never reach us. Where you scope us to presale tags, anything that isn't presale is discarded at the edge before it is ever stored (see below).
The one place buyer data leaves Tideover: the status page
A status link you share with a buyer exposes only that one order's own low-sensitivity fields: the buyer's first name, order reference, region, the timeline, and a confidence band (never a hard delivery date). Email, lifetime value, risk score, and any other order are defined out of that function on purpose. It is a single, audited boundary in the code (getPublicStatus in lib/status.ts), so the status page cannot leak those excluded fields even if we wanted it to.
One action cuts Tideover off, per rung.
You grant access in rungs, lowest-trust first, and you take it back the same way. Here is the exact one action that severs each rung. We would rather tell you how to fire us than pretend you can't.
| 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. |
Non-presale data is discarded before it touches a database.
Helpdesk webhooks are not tag-aware on the way out, so they can send us tickets that have nothing to do with presale. We handle that at the edge, before anything is stored.
When you scope Tideover to your presale tags, every incoming payload is checked against that allow-list. A payload whose tags don't match is acknowledged with a 200 and then dropped — it is never written to the database and never drafted. The only trace is a log line recording that a non-matching event was discarded.
Order of operations is deliberate: we verify the vendor's signature over the exact raw bytes received, then parse the message, then apply the tag filter, then persist. We never parse or store untrusted input before it is authenticated. So the promise "we drop what isn't presale before it touches a database" is a real code path (app/api/ticket-ingest/route.ts), not a line of copy.
How your operators log in.
The dashboard and cockpit — where drafts are reviewed and approved — sit behind a signed session cookie. In production, every operator page and operator API is gated by middleware: a request without a valid, unexpired, correctly-signed session is redirected to sign-in or refused.
The session is an HMAC-signed token minted from a server-side secret. Rotating that secret revokes every active session immediately; changing the operator password stops new sign-ins. The public pages — this one, your buyers' status links, and the marketing site — are intentionally not gated, so nothing a buyer needs is ever behind a login.
What we don’t claim
Tideover is a pilot-stage product, and we won't dress it up as more. We do not hold SOC 2. We have not completed a third-party penetration test or security audit. We don't claim "bank-level" or "military-grade" encryption, and we don't claim to be "GDPR compliant" or to carry any certification.
What we can tell you is everything above: what we store, what we drop, 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.