Privacy Policy — Restoc

Last updated: 29 October 2026

Restoc (the "App") is a Shopify application operated by Vincent Danneker, a sole proprietor based in Lisbon, Portugal (the "Operator", "we"). The App lets Shopify merchants notify their customers by email when an out-of-stock product becomes available again.

Contact: support@restoc.app

Data we process

Merchant and store data

When a merchant installs the App, we access, through Shopify's APIs and with read-only scopes: the shop domain and store contact email, product and inventory data (needed to detect restocks), and order data (used only for the weekly recovered-sales report sent to the merchant). We do not modify inventory or orders, and we modify a product only in the one way the next paragraph describes, at the merchant's own request. We also read inventory quantities per location to show the merchant transfer suggestions between their own locations; a suggestion is information only — the App never moves stock — and it is computed from product and inventory data alone, with no subscriber data involved.

When a merchant attaches a deposit to a product they have marked as preorder, we create and maintain a selling plan group for that product in the merchant's Shopify, and we store, on the product's preorder record: the deposit configuration the merchant set (a percentage or a fixed amount), Shopify's identifiers for that plan, whether the product is associated with it, and the state and moment of its last synchronization, including the last failure in reduced form. The deposit and the remaining balance are charged by Shopify, never by the App: we do not receive, process or store card or payment data, and a customer who pays a deposit places a Shopify order — nothing about that customer is stored by the App for the deposit. Deleting the preorder record deletes this data with it, under the same erasure rules as everything else in this policy.

Subscriber data

When a shopper submits the "Notify me" form on a merchant's storefront, we store the email address provided and the product (and variant, where applicable) the shopper subscribed to, together with the subscription date. On a product the merchant has marked as preorder, the same form records a preorder request instead of a restock subscription; on a product marked as coming soon, it records a launch request; on a product marked as discontinued, it records a bring it back vote. The data stored is the same. Apart from the optional form details described in the next sentences, we store nothing else about the shopper: no address, no payment data, no browsing history. When a merchant turns on the optional form details, the form may also ask for the shopper's name, how many of the product they want, and a short note for the shop. Each detail is optional — the form never requires one — and what the shopper writes is stored on the same subscription record, shown to the merchant on the waitlist and in its export, and deleted with the record under the same erasure rules as everything else on it. When a merchant offers it, a shopper who received an alert can also ask the merchant to set the item aside; that request — the fact that it was made, the merchant's answer, and its deadline — is recorded on the same subscription record. No additional data about the shopper is collected for it. When a merchant uses VIP early access, we also read, at the moment an alert is planned, the tags on the merchant's own Shopify customer record for the subscribed address, solely to decide the order the alerts are sent in. We store no copy of those tags, we never add, remove or change a tag, and no shopper is told of the order. When a merchant turns on alert discount codes, we create a one-time discount code in the merchant's own Shopify for that subscription's alert and store the code on the subscription record until it expires or the record is deleted; the code is a random string and carries no shopper data, and it is deleted with the record under the same erasure rules as everything else on it. We also record, on the same subscription record, the moment the App first detects that the product is available again and, in the App's send journal, the moment the alert email is sent, so the merchant can see how quickly alerts go out. These are timestamps about the alert itself, not new data about the shopper, and they are deleted with the record under the same erasure rules. A shopper can also follow a merchant's drop calendar: we then store the same email address once for that shop, with no product attached, together with a journal of the announced products we emailed about under that follow. The follow appears on the shopper's personal page described in the next sentences and can be stopped there; it is deleted under the same erasure rules as everything else in this section. When a merchant enables text alerts and a shopper ticks the separate text consent box on the same form, we also store, on that subscription record, the phone number the shopper provided, the consent itself, and the moment it was given. The number is used only to send that subscription's restock alert as a text message, in addition to the email; a separate journal of those texts records that a text was sent, when, and through which provider, and never the number itself. Replying STOP to a text strikes the text consent from the record on the spot, and the number with it unless a WhatsApp consent on the same record still stands, and the record's deletion, under the same erasure rules as everything else in this section, deletes the number and its text journal with it. When a merchant enables WhatsApp alerts and a shopper ticks the separate WhatsApp consent box on the same form, the same number also serves that subscription's restock alert as a WhatsApp message, in addition to the email, through a message template approved in advance and filled with the shop's name, the product and its link; no free-form WhatsApp message is ever sent. The WhatsApp consent and its moment are stored on the same record, beside the text consent and independently of it; a separate journal of those messages records that a message was sent, when, and through which provider, and never the number either. Replying STOP on WhatsApp strikes the WhatsApp consent from the record on the spot, and the number itself is struck whenever no alert channel's consent remains on the record. When a merchant enables web push alerts and a shopper ticks the separate web push consent box on the same form, and their browser grants notification permission, we also store, on a separate subscription record linked to that subscription, the browser push endpoint the browser's push service minted and the two encryption keys the browser minted with it, together with the web push consent and its moment on the subscription record itself. The endpoint and keys are used only to send that subscription's restock alert as a browser notification, in addition to the email; a separate journal of those notifications records that one was sent, when, and through which provider, and never the endpoint or the keys. A shopper can revoke the subscription at any time in their browser's site settings; when the push service later reports the subscription gone, the stored endpoint, keys and consent are struck from the record, and the record's deletion, under the same erasure rules as everything else in this section, deletes the subscription and its notification journal with it. When a merchant runs an A/B test of the notify button, the block keeps the version the shopper is shown — a single letter, A or B — in the shopper's own browser, so the presentation is stable from visit to visit; the App creates no visitor identifier for this and keeps no record of individual visitors. The letter travels with a signup and is recorded on that signup record, like the other facts of the signup described above, so the merchant can read each version's results in aggregate; the merchant's counts themselves (button views and signups per version) are shop-level totals that name no shopper. Each alert and reminder email also carries a signed link to the shopper's own page at that shop, where the shopper can see the subscriptions held for their address at that shop and delete any of them. The link is valid for 30 days from the email that carries it and shows only that shopper's own records at that one shop; the page itself stores nothing new — viewing it and deleting through it act on the same records described above, and a deletion there has exactly the effects described for a merchant deletion. When a merchant turns on double opt-in, a storefront signup first receives a confirmation email carrying a signed link of the same kind; the signup is only confirmed — and only then joins the records described above — when the shopper opens the confirmation page and confirms. The link is valid for 7 days and binds that signup record and that shopper's address; an unconfirmed signup is held in that waiting state and is deleted under the same erasure rules. A storefront signup that joins at once also receives a signup confirmation email restating the alert it just created, carrying the same signed link to the shopper's own page; it is sent once, at signup, and never to an address the provider has stopped delivering to.

Why we process it

• To send the restock alert email the shopper asked for when the product returns to stock.
• To send the preorder availability email the shopper asked for when a product they joined the preorder list for becomes available.
• To send the launch email the shopper asked for when a product they joined the launch list for launches.
• To send the return email the shopper asked for if a product they voted to bring back ever returns to stock. A vote is never a promise of a return: no email is sent unless the product actually comes back.
• To send the signup confirmation email that restates the alert a storefront signup just created, when the signup joins at once.
• To send the drop calendar email the shopper asked for when a product on a merchant's announced launch or preorder calendar they follow becomes available. Following a calendar is not a subscription to any product and is never a promise of stock.
• To send the restock alert as a text message as well as an email, when the shopper ticked the text consent box and left a number for that subscription. The text is the same alert, never a marketing message, and it always carries the words to stop further texts.
• To send the restock alert as a WhatsApp message as well as an email, when the shopper ticked the separate WhatsApp consent box for that subscription. The message is the same alert, carried by a pre-approved template, never a marketing message, and it always carries the words to stop further WhatsApp messages.
• To send the restock alert as a browser notification as well as an email, when the shopper ticked the separate web push consent box for that subscription and their browser granted notification permission. The notification is the same alert, never a marketing message; the shopper stops further notifications in their browser's site settings or by deleting the subscription from their personal page.
• To operate the merchant's waitlist (including lists the merchant imports from another notify-me tool at their own initiative).
• To relay a shopper's hold request to the merchant and to email the shopper the merchant's answer (confirmed, declined, or expired unanswered), when the shopper asks from their alert.
• To email the customers a merchant has tagged in Shopify ahead of the merchant's other waiting subscribers, when the merchant uses VIP early access. Early access changes only the order of the alerts; it reserves no stock and guarantees no purchase.
• To include the merchant's one-time discount code in the alert the shopper asked for, when the merchant turns that feature on. The code is created in the merchant's own Shopify at the moment the alert is sent, works once, and is never mentioned in an alert unless it was actually created.
• To produce the merchant's weekly recovered-sales report.
• To bill the merchant's subscription through Shopify.

We never use subscriber email addresses for advertising, we never contact subscribers about anything other than the alert they subscribed to (a restock, the availability of a preordered product, the launch of a coming soon product, or the return of a discontinued product they voted for) and the answer to a hold request the shopper themselves sent from that alert, and we never sell or rent personal data.

Legal bases (GDPR)

For merchant data, processing is necessary to perform the contract with the merchant. For subscriber data, processing is based on the shopper's own request: submitting an email address in the notify-me form is a request to receive one alert email about that product.

Retention and deletion

• A subscriber record is kept until the alert has been sent, until the merchant deletes it, or until the merchant uninstalls the App.
• When a merchant uninstalls the App, we delete the shop's data in accordance with Shopify's mandatory shop/redact webhook requirements.
• We honour Shopify's mandatory customers/data_request and customers/redact webhooks within the required deadlines: data about a customer is provided to the merchant on request and erased on a redact request.
• A shopper can be removed from a waitlist at any time by deleting the record themselves from the personal page linked in their alert and reminder emails, or from the alerts section of their Shopify customer account at that shop, by asking the merchant, or by writing to us at the contact address above; we will delete the record and confirm.

Who data passes through

The App runs on Fly.io (hosting, European region) and sends alert emails through Brevo, an email delivery provider acting as a processor. Shopify processes data as the platform the App is installed on. These providers process data only to provide their service. No other third party receives personal data from the App.

Cookies and tracking

The storefront notify-me form sets no tracking cookies and runs no analytics or advertising scripts. The form also runs an invisible anti-bot check: the browser solves a short-lived signed proof in the background and a hidden field must stay empty. The proof and the field's value are checked when the form is submitted and are not stored on the signup; no third-party anti-bot service receives them. The embedded merchant admin uses the session mechanisms provided by Shopify.

Your rights

If you are in the European Economic Area, you have the right to access, rectify, erase and restrict the processing of your personal data, and to complain to your local data protection authority. For waitlist data, contact the merchant whose store you subscribed on, or write to us directly and we will act on it.

Changes

If this policy changes in a way that affects how personal data is handled, the updated version will be published at this address with a new "last updated" date before it takes effect.