Returns Intelligence
Security And Data Protection
This page describes the controls used to protect merchant data in the app.
Last updated June 19, 2026.
Access Control
Dashboard pages and dashboard APIs require authenticated access and tenant workspace authorization. Internal job routes require signed tenant-scoped operation credentials or a fenced legacy compatibility secret.
Human support access is denied by default. Workspace owners and admins must grant scoped, time-limited support access before support can inspect data-quality traces for a case. Grants and revocations are recorded in the tenant audit log.
The settings support form explains the data-quality examples merchants should provide: order IDs, return or RMA IDs, SKU/product, date range, reporting month, expected result, actual result, and redacted screenshots or export snippets when relevant.
Shopify lifecycle webhooks are public endpoints by design, but they verify Shopify HMAC signatures before mutating install state.
Encryption
Public app traffic uses HTTPS/TLS. Railway public networking provides automatic SSL certificates for hosted app domains, and Railway private networking uses encrypted WireGuard tunnels for service-to-service traffic inside a project.
Tenant integration credentials, including Shopify and vendor secrets, are encrypted server-side with AES-256-GCM before being stored. Runtime secret values remain server-side and are not exposed to browser clients.
Production database and backup storage must run on infrastructure with encryption at rest enabled. Launch evidence must record the provider control or managed database configuration before public merchant onboarding.
Data Minimization
The app requests the minimum Shopify data needed for return-rate analytics. Direct customer name, email, phone, and address fields are not part of the v1 dashboard, API, exports, or logs.
Raw integration payloads are treated as sensitive diagnostic evidence and should be limited to replayability, support, and reliability needs. Audit metadata records scope and counts rather than raw support messages, credentials, tokens, or unnecessary customer personal data.
Support cases should not include passwords, access tokens, customer payment details, full customer message bodies, or unnecessary personal data.
Unattributed partial refunds and diagnostic records are tracked separately from the main KPI numerator to avoid overcounting and unsupported conclusions.
Incident And Deletion Handling
Suspected unauthorized access should be reported to app support. Credentials can be revoked, integrations disabled, and scheduler credentials rotated without deleting the merchant workspace.
Deletion and anonymization requests are handled through the retention policy in the Data Processing Addendum.