Retrics

TRUST — SECURITY

Security & trust.

Retrics reads your store's history to help you keep your customers. We treat that access as a responsibility, not a convenience. Here is exactly how we protect it — the connection, the data at rest, and the limits we hold ourselves to.

LAST UPDATED · 11 AUG 2026

01Bounded Shopify access

The base analytics connection requests read_customers, read_orders, and read_products. Approved stores may separately grant read_all_orders for history beyond Shopify's standard window. These scopes cannot edit orders, themes, checkout, or customer records.

Only when a merchant explicitly enables Shopify loyalty reward issuance does a separate OAuth step request write_discounts, used solely to create the requested discount codes. Retrics does not request checkout, payment, fulfillment, order-write, or theme-write scopes.

02Verified connections

The Shopify install runs through OAuth with a signed, single-use state parameter, so the authorization callback can't be forged or replayed (CSRF protection).

Every incoming Shopify webhook is verified with a timing-safe HMAC comparison against the shared secret. Requests that fail verification are rejected before any handler runs.

03Encryption in transit and at rest

All traffic to and from Retrics is served over TLS. There is no unencrypted path to the application or its APIs.

Shopify access tokens are encrypted at rest with AES-GCM (authenticated encryption) and are never written to logs. They are decrypted only in memory, at the moment a request to Shopify is made.

04Contact data minimized

Customer email, name, phone, and coarse location may be stored for merchant-facing profiles and search, approved sends, and exports. Core retention and lifecycle computations relate orders through internal customer and order IDs, not raw contact fields.

Retrics also stores an irreversible SHA-256 email hash for suppression, audience, and cross-channel matching. Raw contact data is sent to a delivery provider only when a merchant approves an action on that channel.

05Least privilege, by default

Production access is restricted to one operator and scoped to support and debugging. Secrets are held in a managed secret store, not in source control.

Service providers receive only the data needed for their function, and merchant-connected platforms receive data only for the action the merchant chose. We isolate each workspace's store data and publish the supported provider categories on our service-provider page.

06Shopify data rules, honored

Retrics complies with Shopify's Protected Customer Data requirements: we collect the minimum, use it only to provide the service, and don't retain it beyond what the product needs.

We implement Shopify's mandatory compliance webhooks. Verified customers/redact requests run the automated erasure path; shop/redact purges the exact disconnected installation. A customers/data_request delivery creates a count-only receipt and an encrypted case. An authorized owner/admin can compile a current no-store report on demand; Retrics never sends that report automatically.

07Billing you can trust

Paid plans are billed through Shopify's billing system. Card and payment details are handled by Shopify — Retrics never sees, stores, or processes your card data.

08We never sell your data

We do not sell your data, your customers' data, or any audience derived from it — to anyone, ever. Your store's data is used to run your workspace and nothing else.

Model inputs and outputs from your store are not used to train models for other customers.

09Protecting against data loss

Every Retrics database is managed Postgres with automated daily backups retained for seven days. Backups are encrypted at rest, the same as the live data. Restoring is a supported operation we can run without depending on any one person's machine.

Products are separated at the database level rather than by convention — Retrics, Geo and Chat each hold their own database, so a fault or a bad migration in one cannot reach another's data. Development runs against a local database, never against production.

The larger risk to a merchant's data is not hardware, it is our own code deleting the wrong thing, so the destructive paths are written to fail safe. A catalog sync that errors part-way never prunes, and a sync that returns nothing never prunes either, because “the store has no products” and “something went wrong quietly” look identical and only one of them should empty a catalog. Scheduled cleanups delete strictly what has passed its stated retention window. The audit log is append-only, enforced by the database rather than by trust: updates and deletes against it raise an error.

10If something goes wrong

We treat a security incident as any unauthorized access to merchant or shopper data, any loss of that data, or any failure of the controls described on this page. Suspected incidents are handled as real ones until shown otherwise.

The order is containment, then assessment, then notification. We revoke or rotate whatever credentials are implicated, close the path, and preserve the evidence before changing anything else — an incident investigated after the traces are cleaned up cannot be understood, and the audit log is append-only for this reason.

Affected merchants are notified without undue delay once we are aware, which is a contractual commitment and not a courtesy — it is written into the data processing addendum. The notice says what happened, which categories of data were involved and roughly how much, what the likely consequences are, and what we have done about it. Where we do not yet know something, we say so rather than delaying the notice until we do, and we follow up as we learn more. We will also give you what you reasonably need to meet your own notification obligations.

Afterwards we write down the cause and what changed because of it. A fix that is not reflected in a control is not a fix. Report anything you think we should know to security@retrics.ai.

11Formal audits (roadmap)

We are honest about what is in place today versus what is on the way. The items in this section and the next are commitments in progress, not claims of things already achieved.

SOC 2 Type II is on our roadmap. We are building the control documentation and evidence collection toward a formal audit; we will publish the report here when it is complete, and we won't claim certifications we don't yet hold.

12Ongoing hardening (roadmap)

We are expanding automated dependency and secret scanning, and tightening access reviews. Security is maintained continuously, not treated as a one-time checkbox.

13Report a vulnerability

If you believe you've found a security issue in Retrics, please tell us before disclosing it publicly. Email security@retrics.ai with the details and steps to reproduce. We investigate every credible report, act in good faith, and will keep you updated as we resolve it.

Read the privacy policy