Last updated
This policy explains what Ballast collects when it is installed on a Shopify store, why, and what happens to it. It is written to be read rather than to be survived.
Ballast is an inventory planning tool. It needs to know that two units of a SKU sold on a Tuesday at a particular shop. It does not need to know who bought them, and it does not store that. No shopper personal data is held by this app — not names, not email addresses, not shipping addresses, not payment details, not IP addresses.
The personal data it does hold is limited to the people who run the store and the business contacts entered for suppliers. Both are listed in full below.
| Data controller | WILLIAM JORDAN ISAAC ELVY |
| Registered address | 16/71 Jijaws St, Sumner, QLD, 4074, Australia |
| Privacy contact | support@ballastcloud.com |
For merchants in the EU and UK we act as a data processor for the store data we handle on your behalf; you are the controller of it. For your own account and billing relationship with us, we are the controller.
Shopify shows you this list when you install the app, in its own words. Here is what each permission is actually for. The app can see nothing outside this list, whatever it or we might claim: Shopify enforces it.
| Permission | What it is for |
|---|---|
| read_products | Reads your products and variants — the names, SKUs, barcodes and prices that appear on every list, report and label in the app. |
| write_products | Writes back one product field on your instruction: a barcode, for stock that has none, so it can be scanned and labelled like the rest. |
| read_inventory | Reads how much of each variant is on hand at each of your locations. This is the number every forecast, count and transfer starts from. |
| write_inventory | Applies the stock movements you approve — receiving a delivery, finishing a count, sending a transfer, writing off damage — back to Shopify, and records the unit cost you agreed with a supplier against the item it belongs to. |
| read_locations | Reads your locations, so stock can be planned, counted and moved per shop rather than as one undifferentiated pile. |
| read_orders | Reads which variants sold, when, in what quantity and at which location. This is what demand forecasting is computed from. |
| read_all_orders | Extends the above beyond Shopify's standard 60-day window. Seasonal buying needs more than two months of history; this is the permission that provides it. |
| read_fulfillments | Reads whether an order was fulfilled and from where, so a sale is counted against the location it actually left. |
| read_merchant_managed_fulfillment_orders | Reads the fulfilment orders your own locations handle, so stock you ship yourself is attributed correctly rather than being counted twice or not at all. |
There is no customer permission in that list, and there is no request pending for one. That is the mechanism behind the next section rather than a policy we could quietly change our minds about: Shopify would refuse to return customer data to this app.
The following are never requested, never received and never stored:
Three mechanisms enforce this rather than merely stating it:
This is why the customers/data_request and customers/redact compliance webhooks, which Shopify requires every app to handle, are handled here as deliberate no-ops: the request is verified and recorded, and there is nothing to return and nothing to erase.
A complete list. Nothing is held that is not named here.
| Data | Why |
|---|---|
| Store domain, store name, contact email, country, currency and Shopify plan name | Identifies your store to the app; the plan name sets how fast it may read from Shopify |
| The first name, last name, email address and user ID of a staff member, where Shopify supplies them with a session | Supplied by Shopify as part of signing in; used to attribute an action to the person who took it |
| A Shopify API access token for your store | Required to read your catalogue and inventory, and to write back the changes you approve |
Sessions are encrypted at rest. A session is a credential with write access to your inventory, so it is encrypted before it is stored rather than relying on database access control alone.
| Data | Why |
|---|---|
| Supplier name, contact name, email address, phone number and address | So a purchase order can be addressed to them |
| Location addresses | Synced from Shopify; used for receiving stock and for transfers between shops |
Supplier contact details are business contact data that you enter and control. They are used only to produce your own purchase orders. They are never used for our marketing, and the app never transmits them anywhere — see section 4.4.
| Data | Why | Kept for |
|---|---|---|
| Products, variants, inventory levels and locations | The core function of the app | Until uninstall, plus 48 hours |
| Quantities and revenue sold, per variant, per day, per location | Demand forecasting | Until uninstall, plus 48 hours |
| Purchase orders, receipts, stocktakes, transfers, write-offs and consignment records | The core function of the app | Until uninstall, plus 48 hours |
| Webhook delivery records and background job history | So the same update is never applied twice, and so a fault can be diagnosed | Until uninstall, plus 48 hours |
| Application logs | Diagnosing faults | 30 days |
Logs record store domains, screen names, timings and error detail. They deliberately do not record request or response bodies, because those bodies contain access tokens while an app is being installed and your supplier costs everywhere else.
This app sends no email, and makes no outbound request to a supplier. It has no mail server, no mail provider, and no code that opens a connection to one.
A purchase order leaves the app only when you make it leave: the app renders it as a document you print or save as a PDF, and exports it as a CSV file you download. Both happen in your browser. What happens next — attaching it to your own email, handing it across a counter — is yours, under your own provider's terms, not ours.
The document a supplier receives is deliberately narrower than the screen it was printed from. It carries the quantities ordered and the unit costs agreed with that supplier; it withholds your landed cost, what you have received so far, and your internal notes.
| Provider | What for | Where |
|---|---|---|
| Shopify Inc. | The source of your store data, and our billing relationship with you | Per Shopify's own terms |
| Fly.io | Hosting the application and its database | Ashburn, Virginia, United States |
That is the complete list. In particular there is no email provider, because the app sends no email; and no analytics, error-reporting or customer-messaging provider of any kind. We will give notice in the app before adding anyone who handles personal data.
We do not rely on consent for any processing described here, and the app performs none that would require it.
The application and its database run in Ashburn, Virginia, United States. Where personal data is transferred out of the UK or the EEA, it is transferred under the UK International Data Transfer Agreement or the EU Standard Contractual Clauses, as applicable.
| Event | What happens |
|---|---|
| You uninstall the app | Access tokens and sessions are deleted immediately. Your records are kept for 48 hours. |
| 48 hours after uninstall | Shopify sends shop/redact. Everything belonging to your store is deleted. |
| You ask us to delete sooner | We delete on request — see section 10. |
The 48-hour window is deliberate, and it favours you. A store that uninstalls to test something, whose card declines for a day, or that reinstalls after trying an alternative comes back to its purchase orders, suppliers, costs and sales history intact. That history takes months to accumulate and cannot be rebuilt from Shopify beyond its 60-day order window. After the window elapses, deletion is total.
Application logs and database backups are retained for 30 days and are then discarded. Nothing about your store survives in either beyond that.
Depending on where you live, you may have the right to access, correct, export, delete or restrict processing of your personal data, to object to processing, and to complain to a supervisory authority.
To exercise any of them, write to support@ballastcloud.com. We will respond within 30 days.
Two of them you can exercise yourself, immediately, without asking us:
If you are a supplier whose contact details are held in a merchant's account, that merchant controls those details. Contact them first; we will help them respond, and will act on a direct request where the law requires us to.
No system is perfectly secure. If you believe you have found a vulnerability, please report it to support@ballastcloud.com rather than disclosing it publicly. We will acknowledge it within three business days.
The app is a business tool, sold to businesses. It is not directed at children, and we do not knowingly collect personal data from anyone under 16.
Material changes are notified in the app, and by email to your store's contact address, at least 14 days before they take effect. The date at the top of this page always reflects the current version.
WILLIAM JORDAN ISAAC ELVY, 16/71 Jijaws St, Sumner, QLD, 4074, Australia. Privacy enquiries: support@ballastcloud.com.
For a question about using the app rather than about your data, /support is the faster route.
This page is served by the app itself, so it says what this build of it actually does.