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 your helpdesk webhook routes 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 CSV and webhook rungs move your data 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. CSV files you export yourself and helpdesk webhooks with a shared secret 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).
With AI drafting off (the default), buyer data leaves Tideover in one place: 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. Turn on AI drafting and there is exactly one more exit, covered next.
If you turn on AI drafting: one subprocessor
AI drafting is optional and off by default. When it is on, the ticket's subject and text — plus the buyer's first name, order stage, and timing band — are sent to DeepSeek (Hangzhou DeepSeek Artificial Intelligence Co., Ltd., servers in the People's Republic of China) to draft the reply; DeepSeek's own privacy policy governs its handling of that text. Email addresses, lifetime value, and payment data are never in the prompt. Every AI draft passes the same hard-date gate as a template draft, and a person approves it before anything sends. Leave the feature off and no ticket text leaves Tideover.
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 — Helpdesk webhook | Presale ticket events your helpdesk fires at our ingest URL (e.g. a Gorgias HTTP integration or Zendesk trigger), authenticated with a shared secret. | Deactivate or delete the webhook or trigger in your helpdesk. No further events reach us. |
| Future — Write-back API key | Nothing today: approved replies are sent by you, from your own helpdesk. If a direct write-back integration ships, it would use a least-privilege agent-user key you create. | Nothing to revoke until it exists. If you ever create such a key, resetting it (invalidates instantly) or deleting the agent user cuts it off. |
| 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 per-user accounts. In production, sign-in runs through Auth0, and every operator page and operator API is gated by middleware: a request without a valid session is redirected to sign-in or refused. If the auth configuration is ever incomplete, the gate fails closed with an explicit error — it never silently opens.
Each workspace is isolated to the account that created it and the seats that owner invites; removing a member revokes their access. A legacy single-password mode remains only as an env-gated fallback for deployments without Auth0 configured. 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.