Privacy Policy

Data we store

When you install LabelCraft, we store:

Store information. Your shop’s .myshopify.com domain, subscription plan, monthly label usage count, and app settings (default quantities, GS1 prefix, your declared printer brand and model, and any printer calibration offsets). Since 4 September 2026 we also keep the store owner’s email address, which Shopify uses to contact the owner, read from Shopify when we refresh your store name (about once a month). We write to it, as the owner’s address, for three things: one welcome message the day you install; the Tuesday news, once that welcome has announced it, at the address the welcome went to; and, if you have left no address in the app, the help email described under Where data lives. Every message carries a one-click unsubscribe, and the address goes with everything else when you uninstall, unless you asked us to stop writing to it: that address then stays on our opt-out list so we can honour it, as the retention section says. Removing the address you left in the app is narrower than unsubscribing: it leaves the owner’s address untouched, and the help email then goes there, and the Tuesday news to the address your welcome went to, if that welcome announced it. The unsubscribe page each of these emails links to can stop all three at the address it reached.

Printer connection and station settings. If you connect a printer through PrintNode, we store the PrintNode API key you paste, the printer you pick, and its name, so the app can send jobs to it. That key is used server-side only to talk to PrintNode and is never sent back to your browser. If you set up per-location print stations, we also store, for each Shopify location, the label template and the copies rule that station last used. Both live in the same app settings record as your store information above.

Product data snapshots. Label templates you create and your print job history, which includes the product details printed on labels (titles, variants, SKUs, prices, barcodes). Product data is read from Shopify’s API only to render your labels.

Staff account details. The app reaches your store with an access key Shopify issues to the store, not to a person. Shopify’s sign-in gives us no staff member’s name and no email address (the address listed under “Store information” is read separately, through Shopify’s API). Each screen of the app does carry the Shopify user ID of the staff member using it. That ID is a number with no name or email address, and we use it only for the admin language described in the next paragraph.

Your chosen admin language. Shopify tells us which language your admin is set to only on the first screen you open, so to keep the app in that language as you move around it we store the language together with the Shopify user ID of the staff member it belongs to. That ID, which Shopify puts in the login session, is a number with no name or email address. We keep only one at a time per store, never a list of who works there.

Feedback you write to us. The notes you type into the app’s feedback box are kept with your store, read by us, published nowhere, and deleted with everything else when you uninstall. Under that box you can add an address for us to reply to and tick a box beside it. If you do, two things happen: we keep that address on that one note, and we also send that note and that address to ourselves by email, through Resend, so we can answer you. That email then sits in our support mailbox like any message we receive, and uninstalling deletes your note from the app but does not erase an email we have already been sent. The address receives nothing but our answer, it joins no mailing list, and it is never used to contact you about anything else. When we write back inside the app, our reply is kept with your note and deleted with it, and the first time you open your feedback page after that we record that the reply was shown to you, so we know it arrived and can stop flagging it.

Data we do NOT collect

LabelCraft never reads, processes, or stores your customers’ personal data. No customer names, emails, addresses, orders, or payment information - the app only works with your product catalog.

Order and return access

Two features - printing labels straight from an order, and relabeling a return - need Shopify’s read_orders and read_returns permissions. These are optional: the base install asks only for your products and inventory. You grant order or return access in-context, only when you open those pages, and you can revoke each permission from the page that uses it: order access on “Order labels”, return access on “Returns to label”. Relabeling a return needs BOTH, because in Shopify a return belongs to an order, so “Returns to label” asks for both and “Order labels” is where the order permission is turned off again.

When granted, we read only the label fields. From each order or return line we read the product and variant details needed to print a label - title, variant, SKU, barcode, price, compare-at price, vendor, and weight - plus the quantity (and, for a return, the restocked quantity and the return's status) and the order or return number and date.

We never read customer identity. No customer name, email, phone number, or shipping or billing address is ever requested, read, or stored. Shopify’s install screen names a broad order data category, but LabelCraft selects only the product lines inside an order - never the shopper. See Data we do NOT collect above.

Read live, not stockpiled. Order and return data is read at the moment you print. Nothing from it is kept except the product details and the order or return number saved in your print-job history, so you can reprint the same label (see Data we store).

Hosted in the EU, erased on uninstall. These reads run on our EU servers (see Where data lives) and, like all of your data, are purged when you uninstall (see Data retention and deletion).

How we use data

Solely to provide the service: rendering label PDFs, remembering your templates and settings, enforcing plan quotas, and responding to support requests. We do not sell data, share it with third parties for marketing, or use it for advertising.

Usage measurement inside the app

Some stores install LabelCraft and never print a label. From outside the app we cannot tell whether they could not find a button, could not connect a printer, or opened it once and closed the tab. So the app records which of its own screens you open, inside the Shopify admin only. That is the whole of it.

What is sent. What we put in them: the name of the screen you opened, your plan, and a pseudonym for your store. Nothing else. No product titles, no SKUs, no prices, no barcodes, no label content, no order or customer data, and no staff name or email address. PostHog’s own script adds a technical description of your browser to both, described below.

Your domain does not leave. The pseudonym is the same stable one-way hash of your .myshopify.com domain that the churn record described below uses. It is a pseudonym rather than anonymisation, and this says so instead of pretending otherwise.

How that stays true. The tool we use, PostHog, can be configured to capture every click and every string on a page by itself, and to record the session as video. Both are switched off. Two events leave: the screen view we named by hand, and the one PostHog sends when the app tells it which pseudonym that screen view belongs to, which carries that pseudonym and your plan. On both, PostHog’s script stamps its own technical properties, which we do not remove: the browser and its version, the operating system, the device type, the size of your screen and of the window, your time zone, and the version of PostHog’s own library. The address of the page is cut out of them before they leave, but the connection itself still shows PostHog’s servers the internet address your browser comes from, and we do not switch off the country lookup PostHog derives from it. Text that happens to be on your screen is never read, and your screen is never filmed.

PostHog processes these events on servers in the European Union, the same region as ours. We use them to find where setup breaks. They are not used for advertising and are not shared with anyone.

The legal basis is our legitimate interest in making the app usable by the people who install it. Because these events are stored under the pseudonym and not under your domain, the automatic purge described below does not reach them. Email support@labelcraft.tech and we will delete them, or keep your store out of this measurement entirely.

This is not Google Analytics. Google Analytics still never runs inside the Shopify admin or during login, exactly as described under The labelcraft.tech website. One measures the public site, the other measures the app, and neither loads where the other runs.

Where data lives

Our servers and database are hosted on Fly.io in Paris, France (European Union). All traffic between your browser, Shopify, and LabelCraft is encrypted with TLS.

Seven outbound exceptions, one of them only if you set it up. If you connect a printer through PrintNode, the finished label is sent to PrintNode’s service so it can reach your printer. That means the label’s own content - whatever your template prints, such as titles, SKUs, prices, and barcodes - leaves our EU servers for PrintNode, outside the EU, for as long as it takes them to deliver the job. Nothing is sent there unless you have saved a PrintNode key and chosen a printer, and disconnecting PrintNode in Settings stops it.

Email goes out through Resend. Five kinds of email go through Resend, our email provider (its servers, not ours): the welcome message the app sends on install day; the help email we may send, for one of four reasons (warnings on your prints, a trial about to end, printing on one day only, or no print for a while), to the address you leave in the app or, if there is none, to the store owner’s address; the other messages to the address you leave in the app, each of them named by the box you tick beside it (setting up, labels that stop coming out, a weekly note on barcode problems found in your catalogue when there are any, the Tuesday news, and one question about what you think of the app); the few messages we send to a contact address a store publishes; and, when you tick the reply box under the feedback form, the copy of your note that we send to ourselves so we can answer you. Resend receives the address and the message, keeps its delivery log, and holds the addresses that unsubscribe, bounce or complain so that we never write to them again; that list is checked, together with our own, before every message to you. The feedback copy is the one that goes the other way, to our own support mailbox, so no opt-out list applies to it. When Resend is unavailable, all of these messages except the welcome and the feedback copy may go out instead through the mail server of our own mailbox, Namecheap Private Email; those are then checked against our own list only.

The Tuesday news, and how to stop it. A short email on Tuesdays tells you what changed in LabelCraft, and only in weeks when something did. It goes to the address you leave in the app when you tick the box that names it, or to the store owner's address Shopify gives us once your welcome email has announced it, with a link that stops it before the first one. It goes out the same way as the messages above and is checked against the same lists. Its own link stops that email alone; everything else we send you stays as it is. A store whose welcome did not announce it, and that has not ticked that box, never receives it.

Error reports go to Sentry. When a screen of the app breaks, the app sends the error to Sentry, our error-tracking provider (its servers, not ours), so that we learn about the fault instead of waiting for you to report it. Sentry receives the error message, the technical trace of where the code stopped, and the address of the screen with everything after the question mark cut off. What else is attached as a label depends on where the fault happened. In your browser: your .myshopify.com domain, your plan, and the two headers a browser attaches by itself, which are the browser and system you run and the address of the page you came from, that one cut at the question mark as well. That report goes from your browser straight to Sentry’s servers, so the connection itself shows them the internet address your browser comes from. On our servers: the address of the screen, and on some of them a reference number that ties the report to our own server log. Since 15 September 2026 no report carries the Shopify user ID of the staff member who hit the fault, the cookies, any other request header, or the content of whatever was being sent when it broke: all of that is cut before the report leaves. No product title, SKU, price, barcode or label content is attached. Sentry keeps these reports in its European region, on servers in Frankfurt, Germany, and we accepted its data processing terms on 15 September 2026.

The live chat goes through Crisp. When the app shows a chat button, the chat window inside the Shopify admin is run by Crisp, our chat provider (its servers, not ours). The chat bubble on the pages of labelcraft.tech is Crisp’s too, and what it sees there is described under The labelcraft.tech website. In the admin, Crisp’s script loads on the app’s screens, so the connection shows Crisp the internet address your browser comes from, and the script can read, like any script on a page, the browser and system you run and the address of the screen you are on. Before it loads, the app cuts from that address the sign-in details Shopify puts in it, the Shopify user ID of the staff member included. The rest of that address stays as it is, so it can hold what you asked to see on that screen, such as the words you typed in one of the app’s search boxes (a product title or a SKU, for example) or a barcode. As soon as the app loads, it hands Crisp your store’s name and your .myshopify.com domain, so the person on duty can see which store is visiting. When you open the chat, the app adds, when it knows them, the code of the last warning one of your prints raised and the name of the template you last printed on. It may also add, next to your store’s domain, a short key signed by our server, so that we can tell a conversation opened from your store’s admin from one that someone else has labelled with your domain. If you answer the two questions the chat asks first, your printer brand and your label size go too. When the app shows you a message from our team in the chat, it notes in Crisp which message it was and its language and, for a message offering help, its reason (warnings on your prints, a trial about to end, printing on one day only, or no print for a while). Crisp then receives what you write, and the address you type if you leave one. To find that conversation again from one screen to the next, its script keeps an identifier for it in your browser. That address serves to answer that conversation and nothing else: it never signs you up for our emails, which only the separate box in the app does, and that box is never ticked in advance. Beyond that address, the app itself sends Crisp no product title, SKU, price, barcode or label content. When one of us marks your support problem as solved, our server reads your conversation in Crisp, its messages included, and your store’s other conversations there, their messages included. Of all that, it uses only your conversation’s channel, whether an email address is attached to it, the signed key, who wrote each message and when, and whether one of our own messages already holds the link to our App Store reviews. It may then write one message into your conversation asking for a review on the Shopify App Store. We keep only the date and the outcome, never what the conversation says. When the app has a message from our team for you (a welcome, a follow-up, a note after your first print, or an offer of help), your browser sends our server the identifier of your Crisp conversation; our server checks that the conversation names your store and, when it carries the signed key, that the key is valid, then writes the message into it, so it stays in your history and we can see it. To check, it reads your conversation’s details in Crisp and, before the note after your first print, its latest messages, yours included. Of all that, it uses only the store your conversation names, the signed key, the conversation’s channel, whether an email address is attached to it, and whether one of our own messages already holds the link to our App Store reviews. It never writes the message when an email address is attached to the conversation, or when the check fails or Crisp refuses the message; the app then shows the message only on your screen, as before. We keep only which message it was, the date and the outcome. When a member of our team opens your conversation in Crisp, our server shows the state of your store (installation, plan, prints, warnings, messages from our team already shown, our team’s contacts) directly in their browser, without sending it to Crisp. For that, when the chat loads in the app, your browser sends our server the identifier of your Crisp conversation, which our server links to your store; that identifier is kept with your store’s data and deleted with it. Each time a message leaves our side of your conversation in Crisp (a reply from one of us, an automatic message or a note between us), Crisp sends it to our server, its text included; to find your store, our server uses that identifier or, failing it, reads your conversation’s details in Crisp. Of all that, it keeps only, for a reply from one of us and as one of our team’s contacts with your store, the date, which of us replied and the channel, never what a message says.

Store events reach our phone through Telegram. Moments in the life of your store send us a one-line message the day they happen: an install, a plan change, an uninstall, a thumbs-down on the satisfaction question, a data request, and a note left in the feedback box. That list names the common ones rather than all of them: anything that needs our attention the same day can send a line. Those lines go out through Telegram (its servers, not ours). They carry your store’s name and, depending on the event, its plan, how many labels it has printed, or how many orders a data request covers. What never travels is the text you typed: a note sends the fact that one arrived and your store’s name, while the note itself stays in the app and reaches us by email. No product, customer or label content is ever in one.

A backup copy of the database goes to GitHub every night. Once a night our whole database is copied onto a machine GitHub runs, checked there, encrypted there, and stored with GitHub, where it stays 90 days and is then deleted. That copy holds everything: the templates, print history and settings of every store, yours included. So the database passes through GitHub’s hardware unencrypted for as long as the check and the encryption take, and the key that opens the encrypted file is kept as a secret inside the same GitHub account that stores the file, which means GitHub holds the file and the key both. Two other copies reach GitHub outside that backup. One is a page of our internal customer dashboard, with a row per store, which we build by hand when we need it and which GitHub deletes after 30 days. The other is a job that runs every morning and commits its results to a branch of our code as a batch of files. Those files are a census of every store we have, flagged or not: a row per store with its domain, how many print jobs and labels it ran, how many of them hit a warning, when it installed, how far it got in setup, and when it last printed, plus a row for each store that left, with the reason it chose and the day. Two of those files identify a store by a shortened hash of its domain rather than the domain itself, and the note written inside them calls that hash correlatable rather than anonymous. A branch keeps what is written to it until we take it out. The repository belongs to our organisation on GitHub’s Team plan, and we have signed GitHub’s Customer Agreement. A backup is what puts the app back on its feet after a failure, so a copy taken before you uninstall keeps your data until its 90 days run out, and the deletion described below does not reach it.

Data retention and deletion

When you uninstall LabelCraft, Shopify sends us a deletion request and we purge all of your store’s data - templates, print history, settings (including any PrintNode key you saved), and login sessions. We run that purge once Shopify confirms the uninstall to us, which Shopify’s data protection terms put at 48 hours; the confirmation is Shopify’s to send, so it can occasionally reach us later than that.

Four narrow records outlive that purge. So does what has already left for the providers named above: the nightly backup for its 90 days, the dashboard page for its 30, the branch until we take it out (it keeps the date we sent a store our one question about what it thinks of the app, so that a store that reinstalls is not asked again, by email or in the chat), the error reports, the one-line store events and the chat conversations for as long as those providers keep them, the delivery log of a message at our email provider, an email you have already sent us, and the usage events under your pseudonym until you ask us to delete them. Nothing else of your store’s outlives that purge. Two are markers, each one line: if your store started a Pro free trial we keep your .myshopify.com domain with the date the trial was used, and if your store uninstalled while we still had it recorded as installed we keep the domain with the date the install was first announced. They exist to stop one store taking an endless run of free trials by reinstalling, and to stop a returning store being announced as brand new. The third is a churn record, written once when a store uninstalls: how long the install lasted, which setup steps it reached, how many templates, saved lists, print jobs and labels there were, and which warning codes came up - and, for each of those codes, how many print jobs hit it on each day, so we can tell whether a fix we shipped actually stopped the problem for the stores it had been failing. It also records which plan the store was on when it left, whether that plan was paid, billed monthly or yearly, and whether the store was still inside its free trial - we keep it to tell a trial that ended from a subscription that was cancelled. And it carries, when you gave them, the two short answers you chose from our own lists: why you were leaving, if you told us while cancelling, and why you had not printed yet, if you answered that question in the app. Only the option you picked travels, never anything you typed in the box beside it - that text stays on your store's record and is deleted with it. It is stored under a shortened one-way hash of your domain rather than the domain itself - a pseudonym, not full anonymisation - and it holds no product, order, customer or staff data and no label content. We keep it to understand why stores leave. The fourth is an opt-out list: if anyone asks us to stop emailing an address, we keep that address so we can honour it. It outlives your store on purpose, because a request to be left alone that we forget is a request we did not honour.

Three counters on our side are not about your store at all, so none of the above reaches them. One is a daily tally of how many people clicked from the public labelcraft.tech pages towards our App Store listing: a date, which button, which campaign, and a number. Another is a daily copy of what our own advertising on the App Store cost us and how many installs it brought, which is Shopify's figure about our spending, not about you. The third measures how fast the app itself loads: for each day we count, in speed ranges, the standard web performance readings (largest paint, input delay and the like) that Shopify's own admin toolkit reports - a date, a metric name, a screen name, a speed range, and a count. None of the three holds a store, a person or a device, so a deletion request finds nothing in any of them to erase. The first is described in full under The labelcraft.tech website.

You can also request deletion or a copy of your data at any time by emailing support@labelcraft.tech.

The labelcraft.tech website

This section is about the public site you are reading, not about the app. Browsing labelcraft.tech installs nothing and creates no account, and the site itself never ties your visit to a Shopify store. The one way a conversation may come to be tied to one is the chat, described at the end of this section.

We run Google Analytics 4 on the public pages to count visits and see which pages lead to an install. It never loads inside the Shopify admin or during login. What it stores on your device depends on where you are, and there are three cases.

In the United States, Canada outside Quebec, Australia and New Zealand it sets one first-party cookie, _ga, holding a random number so that several page views count as one visit. No advertising cookie is set in those four countries, ever, and you are not asked anything.

In Quebec, it stores nothing and nothing is asked: the tag runs without a cookie and Google publishes none of it.

Everywhere else, the European Economic Area, the United Kingdom and Switzerland included, a bar asks before Google writes anything. Refuse it, or ignore it, and Google sets no cookie. Accept and two things start together: the _ga cookie above, and Google’s advertising storage, which lets us see which ads bring installs and can be used to show you our ads on other sites.

Google receives your IP address to work out an approximate country, and does not store it. We never send your name, your email, or anything else that identifies you. To opt out, block or delete the _ga cookie in your browser settings, or install Google’s opt-out add-on. Your answer to the bar is kept in your own browser under lc-consent-v1. To change your answer, use the Cookies button at the bottom of any page: the bar comes back and your new choice replaces the old one. Clearing this site’s data works too. Every page keeps working whatever you choose.

Separately from Google, we count the clicks that leave for our App Store listing. When you click an Install button, your browser sends our own server three things: today’s date, which button you clicked, and which campaign the link carried. Nothing is written to your device and nothing is read from it, no identifier is created, and the message is byte for byte the same whether you accepted the bar, refused it, or never saw it, because nothing in it could tell you apart from the next visitor. All we ever keep is a running total per day and per button. We added it because Google Analytics reports to us in the four countries above and nowhere else, so before it we had no way to know whether our own ads brought anyone at all.

The chat bubble is Crisp’s, and it loads for every visitor. A chat bubble sits in the corner of every page of this site except the unsubscribe and sign-in pages, so that you can write to us from here. It is run by Crisp, the chat provider described under Where data lives. Its script loads as soon as a page opens, for every visitor, before you answer the cookie bar and whatever you answer, because it is how you reach us. The connection shows Crisp the internet address your browser comes from, and the script can read, like any script on a page, the browser and system you run and the address of the page you are on. It sets Crisp’s own cookies on this site, whose names begin with crisp-client, and they keep an identifier of your conversation for about six months, so that a conversation you start finds you again on your next visit. If you write, Crisp receives what you write, and the address you type if you leave one; that address serves to answer you and never signs you up for our emails. The site itself sends Crisp nothing about you: no name, no email address, no store. A conversation started here is tied to no store, but if you then open LabelCraft in your Shopify admin in the same browser, the app may find that same conversation and add your store’s name and domain to it, as described under Where data lives. The reverse holds too: a conversation you started in the app may be picked up here, with your store’s name and domain. To remove these cookies, clear this site’s data in your browser.

GDPR

LabelCraft implements Shopify’s mandatory privacy webhooks. We store no customer identity - no name, email, phone number or address ever reaches us - but if you use Order labels or Returns to label, the order or return number stays in your print-job history (see Order and return access).

A customer data request is answered from that history. When a shopper asks a store you run for the data we hold about them, Shopify tells us which orders the request covers. We record the request, look those orders up in your print-job history, and undertake to provide you, the store owner, with what we hold about them - the order or return number, the date, and how many labels were printed - or to tell you there are none, within the 30 days Shopify allows. We keep one record of each request we receive, holding the order numbers it named and the dates it arrived and was answered, so that it can be shown to have been answered. No shopper name, email address or phone number is stored: the request carries them, and we drop them. The record is erased with the rest of your store’s data (see Data retention and deletion).

A customer erasure request removes those numbers. The order numbers named in the request are erased from your print-job history, and from our record of any earlier request about the same orders. Shop data erasure is honored automatically as described above. If you are in the EU/EEA you may also contact us to exercise your rights of access, rectification, erasure, and portability.

Changes

If this policy changes materially we will update this page and note the new date at the top. Continued use of the app after a change constitutes acceptance.

Contact

Privacy questions: support@labelcraft.tech