Can a Shopify inventory app run without accessing your customer data?

Short answer: Yes. Parwise does exactly that. The reorder math, low-stock alerts, and purchase orders all run on order line data only (SKU, quantity, cost, date). Parwise never requests the read_customers scope, so it has no access to customer names, email addresses, phone numbers, or postal addresses. Raw order webhook payloads are purged within seven days. What stays on disk: SKU, quantity, cost, and date. Nothing with a face attached.

This page explains what "customer data" actually means on Shopify, why most inventory apps ask for more than the inventory job strictly requires, and what Parwise's data footprint looks like concretely.

What "customer data" means on Shopify

The phrase gets used loosely. On Shopify, data access is controlled by scopes, and customer data specifically breaks into two different categories:

• read_customers is the scope that unlocks customer profiles: names, email addresses, phone numbers, and shipping/billing addresses. This is what almost every "does this app see my customers?" worry is really about. An app that doesn't request read_customers genuinely cannot read those fields, because Shopify enforces scope restrictions at the API level.
• read_orders gives access to order records: line items, SKUs, quantities, prices, presentment currency, and dates. Order payloads can reference a customer (an order ID links back to a customer object), which is exactly why Shopify governs order data under its Protected Customer Data (PCD) framework and expects apps to request only the minimum and store only what they need. Having read_orders is not the same as having read_customers, but it is not zero either.

That distinction matters when you're evaluating an inventory app. The honest question is not "does this app touch any order data?" (any sales-velocity app will) but rather "which scopes does it request, what does it actually read from each order, what does it store, and how long does it keep it?"

What Parwise reads and what it doesn't

Parwise needs to know, for each order line item: what SKU was sold, how many units, at what cost, and when. That is the complete input to velocity reorder math (average daily sales × lead time + safety stock). Nothing else is required.

So that is all it reads:

• SKU / variant ID: to know which product the sale belongs to.
• Quantity: how many units moved.
• Cost: the unit cost recorded on the variant at the time of sale.
• Date: to compute the trailing daily average.

Here is what it does not read, store, or request access to:

• Customer names, emails, phone numbers, or addresses. The read_customers scope is not requested. There is no path in the app's code that reads a customer profile.
• Payment details. No card numbers, no payment method records.
• Product cost for margin analysis. Cost is read to weight reorder quantities (how much to order depends partly on unit cost and MOQ), not to compute gross margin or markup. The app does not frame itself as a profitability tool and does not expose margin figures.
• Any field not needed for the reorder decision.

Raw order and refund webhook payloads are purged within approximately seven days through the outbox processing pipeline. Once processed, only the extracted line-item fields remain. The stored record for a past order looks like: SKU = "WIDGET-RED-M", qty = 3, cost = 12.00, date = 2026-06-10. No customer identity in any form.

Why does any of this matter?

A few reasons, ranging from practical to regulatory:

A smaller breach surface. Every field an app requests and stores is a field that could be exposed in a breach. An app that stores no customer names or emails cannot leak customer names or emails in a security incident. Narrowing the stored field set is the simplest breach-surface reduction available.

Shopify's Protected Customer Data minimization requirement. Shopify requires apps in its PCD program to declare their data access and to collect only the minimum needed for the stated function. Parwise's entire data declaration is "order data, not customer fields." That is a simpler story to tell an auditor or a privacy-conscious wholesale buyer than a broader declaration that includes customer profiles.

Supplier and B2B merchant DPA considerations. If you sell to other businesses, your buyers may ask what third parties you share their order data with and in what form. "We use an inventory app that sees SKU and quantity, no customer identity" is a short answer. "We use an inventory app that reads full customer profiles" is a longer conversation.

GDPR / CCPA access requests. Customer access requests require you to know which third-party systems hold data about a given person. An inventory app with read_customers may be in scope. One with no customer scope and no customer fields at rest almost certainly is not.

None of this is dramatic. It is just a smaller surface, and smaller surfaces are easier to manage.

Is any order data really "customer data"?

Honestly, yes, at the platform level. An order is associated with a customer. The order ID can be joined to a customer record through Shopify's API. That is why Shopify governs order data under PCD at all. The scope-level protection (read_customers versus read_orders) is real, but the boundary is not perfectly airtight in an abstract sense.

The accurate claim is this: Parwise requests no customer scope, reads no customer fields from orders (it extracts only line-item fields), and stores no customer-identifying data. That is a meaningful reduction in exposure compared with an app that requests both scopes and stores full order records indefinitely. It is not "completely untouched by anything order-adjacent," because no sales-velocity inventory app can honestly say that.

How Parwise's data footprint compares in practice

Most inventory apps request read_orders because they need sales velocity. Some also request read_customers for buyer registration, net terms, or customer-tagged catalog features. Where an app's feature set doesn't genuinely need customer profiles, requesting that scope is collecting more than the job requires.

Parwise's features are: reorder points, low-stock alerts, an on-hand dashboard, purchase orders with a receiving lifecycle, and supplier management. None of those functions require reading who the customer is. So it doesn't.

What the app explicitly does NOT do, directly because of this scoping choice:

• No customer-tagged reorder rules ("reorder differently for VIP buyers").
• No buyer registration or approval workflows.
• No net terms or customer-specific credit.
• No per-customer purchase history view in the Parwise dashboard.

If those are features you need, a broader inventory platform or B2B suite that does request customer access is probably the right tool, and reading those customer fields would be appropriate for it. Parwise is built for the narrower job of "when should I reorder, and what PO should I send," and it stays inside that scope, literally.

Pricing overview

Parwise is flat: Free $0, Pro $39/mo, Scale $79/mo. Annual plans save about two months ($390/yr on Pro, $790/yr on Scale). 14-day trial on Pro and Scale.

• Free: low-stock alerts, on-hand dashboard, velocity reorder points (editable lead time + safety stock), days-of-cover, the "Caught in time" stat, CSV export, first-run backfill. No order cap.
• Pro ($39): everything in Free, plus purchase orders, the receiving lifecycle (draft, send, partial-receive, close), and supplier CRUD (lead time, MOQ, unit cost).
• Scale ($79): everything in Pro, plus automated supplier-feed ingestion, per-location multi-location stock visibility, and priority support.

None of the tiers are metered by revenue, orders, SKUs, or locations. The price is fixed to the features you use, not to how large your store gets.

See Parwise on the Shopify App Store

FAQ

Does Parwise read my customers' names, emails, or addresses? No. Parwise does not request the read_customers scope, so it has no API access to customer profiles. It reads order line items only (SKU, quantity, cost, date).

What does Parwise actually store from my order data? SKU, quantity, unit cost, and date of sale, extracted from order line items. Raw order webhook payloads are purged within approximately seven days. Customer fields are not retained at any stage.

Is order data the same as customer data on Shopify? At the platform level, orders are associated with customers, which is why Shopify governs them under its Protected Customer Data framework. The difference in practice comes down to which scopes an app requests and what it extracts. Parwise requests only read_orders, reads only line-item fields, and stores no customer identity.

Why do some inventory apps request the read_customers scope? Typically because they offer features that genuinely require customer records: buyer registration and approval, net terms, customer-tagged catalogs, or per-customer purchase history. Those are legitimate reasons to request that scope. If an inventory app's feature set doesn't include those things, the scope isn't necessary.

Is Parwise GDPR-friendly? No third-party app can make a blanket GDPR compliance claim on your behalf, but Parwise's data footprint is narrow: no customer identity at rest, a seven-day purge on raw order payloads, and AES-256-GCM encrypted credentials at the infrastructure level. That narrow profile simplifies your own compliance story. Consult your DPA/GDPR counsel for your specific situation.

What inventory jobs does Parwise's data minimization exclude? Features that require knowing who the customer is: customer-tagged reorder rules, buyer registration, net terms, and per-customer purchase history. Those features require read_customers, and Parwise deliberately does not offer them.

How does Parwise's reorder math work? Plain velocity: average daily sales (trailing 30 days) × lead time + safety stock. The formula is shown in the dashboard, not hidden, and you can override lead time and safety stock per SKU or store-wide. It is not machine learning and not seasonal forecasting. It is a trailing average with editable inputs. Going into a known peak, you would raise your reorder point by hand; Parwise won't anticipate the spike on its own.

Does Parwise read my product cost? It reads the unit cost recorded on the variant to factor into purchase order quantities (MOQ and cost per unit are inputs to the order calculation). It does not use cost to compute margin, and it does not surface margin or markup figures in the dashboard. The app is for inventory decisions, not P&L analysis.