Privacy Policy

Restocker is an inventory and demand-forecasting application for Shopify and Squarespace merchants. You connect your store, and Restocker reads your product catalogue, inventory levels and sales history in order to calculate per-SKU demand rates, reorder points and low-stock alerts.

Restocker is operated by FRI Solutions LLC, a limited liability company incorporated in Pennsylvania, United States. This policy covers the Restocker web application at app.restocker.co and the background jobs and forecasting services that synchronise and process data from connected stores.

Privacy contact: write to support@restocker.co for any question or request about this policy or about data we hold. We have not appointed a Data Protection Officer and are not required to: Restocker carries out no large-scale monitoring and handles no special-category data. We have not appointed an EU or UK representative.

For data about your own Restocker account — your email address, your name, your billing details — we decide how that data is used, and we are the controller of it.

For data we read out of your connected store — your catalogue, your inventory and your order records — we act on your instructions as a processor. You remain the controller of your store's data, and of your relationship with your own customers.

This is the question merchants ask first, and the one a generic policy usually fudges, so it comes before the rest.

Restocker stores no personal data about the people who buy from your store. Not their names, not their email addresses, not their phone numbers, not their shipping or billing addresses. Forecasting works from quantities and dates; who bought an item is irrelevant to how fast it sells.

That is a structural fact about the software, not a promise about our intentions, and it holds in three independent places:

• There is nowhere to put it. Our order table has no column for a customer email, name or address. The three that once existed were dropped from the database outright, and the migration that dropped them refuses to run if any of them still holds a value. We also removed the table that stored the raw bodies of incoming webhooks, which is where a shopper's details would otherwise have arrived intact; nothing had ever written to it, and deleting it means no future change can quietly start.
• We do not ask Shopify for it. The GraphQL query we send for orders requests order totals, dates, statuses, refunds and line items. It does not request the email, customer, shippingAddress, billingAddress or phone fields at all. Not fetching data is a stronger guarantee than promising not to keep it.
• A test enforces it. Every column on the order table is classified as customer personal data or reviewed as not, and an automated test compares that classification against the live database. Adding an unclassified column to that table fails the build, and classifying one as customer personal data makes our Shopify redaction handlers fail loudly rather than quietly report success over data they can no longer reach.

We do not request access to your customer list, we hold no Shopify protected customer data access, we never call the Shopify or Squarespace customer APIs, and we do not build customer profiles, segment your buyers, or use any of your data for advertising.

Two honest qualifications, because the sentence above should be exact:

• Squarespace sends more than we ask for. The Squarespace orders API has no way to request fewer fields, so its response reaches our servers containing the customer's email address, phone number, billing address and shipping address. Our code does not read those fields and never writes them anywhere; they exist only in memory for the moment the response is being parsed, and are discarded with it.
• One identifier survives in the compliance audit trail. When Shopify sends us a customer data or redaction request, we record that the request happened. We keep only what that record needs: the shop it concerns, Shopify's own identifier for the request, Shopify's opaque numeric customer id, and thenumber of orders the request named. We do not keep the customer's email address or phone number, and we do not keep the order numbers themselves — a list of one person's orders is still information about that person, and retaining it after a redaction request would defeat the request. The stored copy is built by selecting those few fields, rather than by removing the ones we know about, so anything Shopify adds to these requests in future is left out by default.

This list describes what the application actually writes to its database, not the broadest set of things its permissions would allow.

Products and variants

• Product and variant titles, descriptions, categories and tags
• SKUs and platform product/variant identifiers
• Cost, price, currency, weight and dimensions
• Product image URLs

Inventory and locations

• Stock levels per location — available-to-sell, physical, committed, incoming and reserved quantities
• The names and addresses of your own store, warehouse and fulfilment locations. These are your business locations, not customer addresses.
• Stock movements we derive from sales, recorded against the automated sync rather than against any person

Orders

Orders are the input to demand forecasting: without sales history there is nothing to forecast. For each order we store the order number and platform identifier, the order date, the status — including whether it was cancelled or refunded, which is what stops a cancelled sale inflating your forecast — the subtotal, tax, shipping cost and total, the currency, and the individual line items (SKU, product and variant name, quantity and price).

"Shipping" in that list is an amount of money, not an address. Nothing in an order record identifies the buyer; see section 3.

• Account: your name and email address, whether your email is verified, and — if you sign in with a password — a salted bcrypt hash of that password. We never store your password itself.
• Sign-in: you can sign in with an email and password, with Google, or through Shopify. If you use Google, we receive your email address, name and profile image from Google and store the tokens that keep that link working.
• Workspace and billing: your organisation name, a billing email address, your plan, and the customer, subscription and price identifiers issued by Stripe. Card numbers go to Stripe directly and never reach our servers or our database.
• Connected store: your store's domain and identifier, its name, the store contact email the platform reports, and its country, currency, timezone and plan name.
• Preferences: notification email address, timezone, alert thresholds and quiet hours.
• Team invitations: the email address of anyone you invite to your workspace, until the invitation is accepted or expires.
• Support and feedback: anything you write in the in-app feedback form or send to us by email, together with the page you were on and your browser's user-agent string.
• Technical records: IP address and browser user-agent on sign-in sessions and in audit records of significant account actions, and the error and diagnostic context described under Sentry in section 7.

• To provide the product: computing per-SKU demand rates, reorder points, forecasts and low-stock alerts from your catalogue, inventory and sales history.
• To send the messages you asked for: stock alerts, team invitations, email verification and password resets, and occasional notices about the service.
• To bill you: managing trials, subscriptions and invoices through Stripe.
• To keep the service working and secure: diagnosing errors, preventing abuse, and keeping an audit trail of significant account actions.

We do not sell your data. We do not share it with advertisers. We do not use your store's data to train machine-learning models for anyone other than you, and we do not use it to build a product for your competitors.

We use the following sub-processors. Each one is in use today, and each is limited to the purpose listed.

• Amazon Web Services — the application database (Amazon RDS for PostgreSQL) and container hosting for our forecasting services (AWS App Runner). Our App Runner services run in the US East (N. Virginia) region.
• Vercel — hosting for the web application, plus Vercel Web Analytics and Speed Insights, which collect aggregate page-view and page-performance measurements. These run on every page of the application, including this one.
• Prisma Accelerate — the pooled, encrypted connection layer through which the production application queries the database.
• Stripe — subscription billing and payment processing. Stripe handles card details directly; we hold only its customer, subscription and price identifiers.
• Resend — delivery of transactional email such as alerts, team invitations, verification and password resets. All of our email goes through Resend.
• Sentry — application error and performance monitoring. Error reports can incidentally contain technical context such as a URL, an account identifier or a request parameter. Session Replay is switched off, so Sentry does not record what you see or do on screen.
• GitHub — when you submit feedback through the in-app feedback form, we create a tracking issue containing your message, your account email address, your organisation name, the page you were on and your browser's user-agent string.
• Google — only if you choose to sign in with Google.
• Shopify and Squarespace — the platforms you choose to connect, which is what makes the data flow possible in the first place.

We also disclose data where the law requires it, and we would transfer it as part of a merger or acquisition — in which case we would tell you before your data became subject to a different policy.

Your data is stored and processed in the United States.

• Shopify access tokens are encrypted before they are written to the database, using AES-256-GCM with a 256-bit key derived per record by PBKDF2-HMAC-SHA256 over 100,000 iterations with a random 256-bit salt, a random 128-bit initialisation vector, and an authentication tag that makes tampering detectable.
• Squarespace credentials are encrypted the same way.
• Traffic between your browser, our application and our database is encrypted in transit.
• Each workspace's data is scoped to that workspace, and access to it requires an authenticated session belonging to it. Roles that can act on billing or close an account are re-checked against the database on every request rather than trusted from the browser's session token.
• Passwords are stored only as salted bcrypt hashes, never in a readable form.
• Webhook deliveries from Shopify are verified against the platform's signature before we act on them, and each delivery is recorded so a retry cannot be processed twice.
• When you uninstall the Shopify app, your access token is erased from our database immediately rather than kept until the redaction webhook arrives. A credential we are no longer entitled to use is pure liability.

While your account is open we keep your account and store data, because forecasting depends on sales history: the longer the history, the better the forecast.

Once you leave, we delete your data within 30 days. One number, for both routes out:

• You uninstall the Shopify app. The connection is deactivated, your access token is erased, billing is stopped (see the Terms), and a clock starts. A scheduled job that runs every day deletes the store's data once 30 days have passed. If you reinstall before then, the clock is cleared and nothing is deleted.
• You close your account. Same window, same job — see section 10.
• Shopify sends us a shop redaction request. That deletes immediately, rather than waiting out the window. See section 11.

A workspace can be configured with a shorter retention window than 30 days, and that shorter value is honoured. It cannot be configured with a longer one: the limit is clamped in code, so no setting can hold data beyond the 30 days Shopify allows.

Deletion is all-or-nothing. Each workspace is deleted inside a single database transaction that ends by checking every table for rows left behind; if anything survived, the whole deletion is rolled back and recorded as a failure to be retried, rather than reported as a success that only half happened.

You can close your workspace yourself, from Settings → Profile. It is the workspace owner's decision to make, so only the owner sees the option, and you confirm by typing the workspace name rather than clicking a checkbox.

Closing the account does the following immediately:

• Cancels your Stripe subscription straight away, not at the end of the billing period. If we cannot reach Stripe to cancel it, the account is not closed at all — we will not leave you locked out of a workspace that is still charging you.
• Erases your Shopify access token, disconnecting Restocker from your store.
• Deactivates every store connection on the workspace.

Closing is reversible for 30 days, and deletes nothing until then. Deleting a workspace cannot be undone and support cannot restore it, so the closure stops the account dead but leaves the rows in place. Reopening it within the window brings your products, orders, history and forecasts back exactly as they were. It does not bring back the two things that were destroyed on purpose: you will need to reconnect your store, because the access token was erased and cannot be recovered, and you will need to subscribe again, because the subscription was cancelled at Stripe.

After 30 days the scheduled sweep deletes the workspace permanently and the closure can no longer be reversed.

One thing closing does not do: it does not sign you out of the browser you are already signed in on. We mark your sessions revoked in our database, but sign-in state is carried in a signed token held by your browser, and that token keeps working until it expires. If that matters to you, sign out explicitly.

If you would rather not use the self-serve route, or you want data deleted without closing the workspace, email support@restocker.co from the address on your account.

Depending on where you live, you may have the right to access, correct, export or delete your personal data, to object to or restrict how we use it, and to complain to a data protection authority.

To exercise any of these, email support@restocker.co from the address on your account. We will verify the request and respond within 30 days.

Requests that come through Shopify

Restocker implements the three compliance webhooks Shopify requires. Shopify delivers them automatically, we verify the signature on each one, and we write an audit record of what the handler actually did — the per-table row counts, and anything deliberately not done and why. Here is what each one does, in the terms the code reports:

• customers/data_request — a shopper has asked what data we hold about them. We record the request, and we answer that we hold none, because we do not store end-customer personal data (section 3). The handler still queries the database for the order records Shopify named in the delivery and reports how many of them we hold, so the audit record shows a real lookup rather than a hard-coded zero. Those records are quantities, money and dates; none of them identifies the shopper.
• customers/redact — a request to erase a shopper's data. There is nothing to erase, and the response says so in those words rather than reporting a success over work that did not happen: the count of customer personal data erased is zero, and the reason recorded alongside it is that no customer email, name or address column exists to erase. Because no customer identity is stored, a shopper can no longer be resolved to their orders at all; the only orders either handler can name are the ones Shopify itself names in the delivery.
• shop/redact — sent 48 hours after a shop is closed or the app is uninstalled. This one deletes, immediately. It removes the shop's products, variants, inventory items and levels, locations, webhook records, sync logs, API metrics and sync jobs; and it blanks the shop record itself — access token, refresh token, webhook secret, merchant contact email and shop name. The shop domain is kept so that a redelivery of the same request can still find the shop and so the audit trail can say which shop it was.
  Your catalogue, orders and alerts belong to your workspace rather than to one storefront, so they are deleted too when Shopify is the only storefront that workspace has. If you also have a live Squarespace store, they are left alone — deleting them would destroy data your other storefront depends on — and the skip is recorded on the audit record for a human to act on.

If you are a shopper rather than a merchant, contact the store you bought from. They control their customer data; we hold none of it.

We set no advertising cookies, and we use no cross-site tracking. The cookies below are the ones the application needs in order to work at all.

• Session. A signed session cookie that keeps you signed in, valid for up to 30 days. Your sign-in state is carried in the cookie itself rather than stored in our database. Signing out clears it.
• Sign-in security. Our authentication library also sets a CSRF token cookie and a callback-URL cookie, and — during a Google sign-in only — short-lived state, PKCE and nonce cookies that exist for the duration of the handshake.
• Shopify handshake. Three cookies set during the Shopify sign-in and install flow, each expiring after ten minutes. Two are anti-forgery tokens; the third carries a signed note of which account and which store the handshake belongs to, so the callback lands on the right workspace.

Your theme preference, your current workspace, whether the sidebar is collapsed and when you last looked at your alerts are stored in your browser's local storage rather than in cookies. They stay on your device and are never sent to us.

Vercel Web Analytics and Speed Insights, described in section 7, collect aggregate page-view and page-performance measurements. We do not set analytics cookies of our own, and we show no cookie consent banner: the cookies listed above are strictly necessary for a service you have asked for.

Restocker is a business tool and is not directed at children. We do not knowingly collect personal data from anyone under 16. If you believe a child has provided us with personal data, contact us and we will delete it.

When we change this policy we update the date at the top of the page. If a change materially affects how we handle your data, we will tell you by email or in the app before it takes effect.

For any privacy question or request, including the rights described in section 11, email support@restocker.co. That address is monitored, and it is the right route for data-subject requests as well as for support.

The canonical version of this policy lives at app.restocker.co/privacy.

See also our Terms of Service.