We request the narrowest set of Shopify API scopes each app needs, authenticate with OAuth tokens rather than your password, encrypt data in transit and at rest, never write to your inventory without a human approving the change, and delete your store's data when you uninstall. We are a small team, and we would rather tell you exactly what we do than imply a compliance programme we have not been audited for.
1. Our principles
Four rules govern how these apps are built:
- Ask for less. Every additional API scope is additional risk to you. We request the minimum an app needs to function, and we drop scopes when a feature no longer requires them.
- Keep less. Data we do not store cannot leak. Where an app can read from Shopify on demand instead of holding a copy, it does.
- Never write silently. Inventory is money. Changes to it are proposed, shown, and applied only when a person approves them.
- Leave cleanly. Uninstalling means deletion, on a schedule we publish, without you having to ask.
2. What we access
Shopify shows you the exact permission list before you install, and you approve it yourself. Broadly, each app requests:
| App | Reads | Writes |
|---|---|---|
| Stocktake & Inventory Count | Products, variants, SKUs, barcodes, inventory levels and items, locations, collections, vendors | Inventory adjustments you approve; draft purchase orders and transfers you create |
| Sell by Weight & More for POS | Products, variants, prices, tags, inventory levels, POS order line items | Measurement-based line pricing and the corresponding inventory adjustment |
| MiMi Product Rentals | Products, variants, availability, orders relating to bookings, delivery methods | Rental bookings, deposits, fulfilment and return records |
We do not request access to your payouts, your Shopify account credentials, or customer data unrelated to the feature you installed the app for.
The Shopify install screen is the authoritative list. The table above describes what each app uses the access for, in plain language. The exact API scopes are shown to you by Shopify before you approve anything — if the two ever appear to disagree, trust the install screen and tell us, because that is a documentation bug on our side.
3. Authentication
- Apps authenticate to Shopify using the standard OAuth 2.0 flow. We receive a scoped access token; we never receive or store your Shopify password.
- Access tokens are stored encrypted and are never exposed to the browser or written to logs.
- Embedded admin requests are verified using Shopify's session token mechanism, and every incoming webhook is verified against its HMAC signature before it is processed. Unsigned or mismatched requests are rejected.
- Tokens are revoked and deleted on uninstall.
4. Encryption
- In transit — all traffic between your browser, the POS device, our servers and Shopify uses TLS 1.2 or higher. Plain HTTP is redirected, not served.
- At rest — databases and backups are encrypted at rest using the storage-layer encryption provided by our hosting platform.
- Secrets — API credentials and tokens are held in a secrets manager with restricted access, never in source control.
5. Infrastructure
Our applications run on [hosting provider] in [region]. We rely on that provider for physical data-centre security, hardware lifecycle and network isolation; they maintain their own independent certifications, which you can review on their trust pages.
- Databases are not exposed to the public internet and are reachable only from application services.
- Automated backups run on a regular schedule and are encrypted. Restores are tested periodically.
- Application and platform dependencies are patched on a routine cadence, and security advisories are actioned promptly.
6. Internal access control
- Access to production systems is limited to the engineers who need it, and is granted on a least-privilege basis.
- Administrative accounts require multi-factor authentication.
- We access an individual store's data only when it is necessary to investigate a fault or when you have asked us to look at something.
- Access is removed promptly when someone no longer needs it.
7. Approval before writes
This is a design decision rather than a control, but it is the one that matters most to a retailer.
A stock count does not push numbers into Shopify as it goes. It produces a discrepancy report — counted versus expected, line by line — and inventory is only adjusted once someone reviews that report and approves it. A miscount by a member of staff is therefore a line to correct, not a write-off to discover next quarter.
8. GDPR webhooks
Shopify requires every app to implement three mandatory privacy webhooks. We implement all three:
| Webhook | What we do |
|---|---|
customers/data_request | Compile and return any personal data we hold about that customer, so the merchant can fulfil the request. |
customers/redact | Erase that customer's personal data from our systems. |
shop/redact | Delete the store's data. Shopify sends this 48 hours after uninstall. |
Every one is HMAC-verified before it is acted on. Full retention detail is in the Privacy Policy.
9. How we build
- Code is version controlled, reviewed before it reaches production, and deployed through an automated pipeline rather than by hand.
- Dependencies are monitored for known vulnerabilities and updated when advisories are published.
- Input is validated and output encoded to guard against injection and cross-site scripting; database access is parameterised.
- Every app passes Shopify's App Store review before publication, which includes checks on permissions, security requirements and the mandatory webhooks.
10. Incident response
If we identify a security incident affecting merchant data, we will:
- Contain it and stop ongoing exposure.
- Investigate the scope — what was affected, whose data, and over what period.
- Notify affected merchants without undue delay, with what we know, what we have done, and what you should do.
- Notify the relevant supervisory authority where the law requires it, within the applicable deadline.
- Fix the root cause and tell you what changed.
We will not delay notification to make the incident sound better once we understand it.
11. Responsible disclosure
If you believe you have found a vulnerability in one of our apps, we want to hear about it. Email mimiapps11@gmail.com with the subject line SECURITY and include steps to reproduce, the affected app, and any supporting evidence.
Our commitment to you:
- We will acknowledge within two business days.
- We will keep you updated while we investigate and confirm when it is fixed.
- We will not pursue legal action against researchers acting in good faith, who avoid privacy violations and service degradation, who do not access or modify data beyond what is needed to demonstrate the issue, and who give us reasonable time to fix it before publishing.
- We are happy to credit you publicly if you would like that.
Please do not run automated scanners or load tests against our production systems without arranging it with us first.
12. What we don't claim
Security pages tend to imply more than they say, so here is the other half of the picture:
- We are not currently SOC 2 or ISO 27001 certified. If you need a certified vendor for a procurement process, we are not that vendor today, and we would rather tell you now than in month three.
- We have not commissioned an independent third-party penetration test to date. If your organisation requires one before installing, contact us and we will tell you honestly where that stands.
- No system is perfectly secure, and we will not tell you otherwise. What we can commit to is minimal access, honest disclosure and a fast fix.
If any of the above changes, this page changes with it, and the date at the top will show when.
13. Contact
- Security reports: mimiapps11@gmail.com with subject SECURITY
- Data protection and DPA requests: mimiapps11@gmail.com
- Everything else: the Support page