Salestino is a Shopify app and a public website at salestino.com. The operator is established in Poland. Legal name, postal address and NIP (and KRS / CEIDG number if a registered entrepreneur): OWNER: imię i nazwisko or firma, ulica, kod, miasto, NIP.
Contact for privacy requests: hello@salestino.com. We have not appointed a Data Protection Officer. Polish law would require us to notify PUODO within 14 days if we did.
Lead supervisory authority: Prezes Urzędu Ochrony Danych Osobowych (PUODO / UODO), ul. Stawki 2, 00-193 Warszawa, uodo.gov.pl.
Three layers, and they are not interchangeable:
customers/redact is processed the same way as a Polish one.ePrivacy Art. 5(3) (device storage) applies to the widget on every storefront in the Union, because it is Union law about the device, not about our seat. The EU AI Act Art. 50(1) disclosure is in the widget because the system talks to a person, wherever that person is, and we list in PL and DE.
The same product sits in two legal roles. Mixing them up is how privacy pages become false.
We do not sell personal data. We do not use store customer data to train a model of our own, to build a cross-merchant profile, or to advertise. Catalog text, policy text and a buyer’s message are sent to a model host only to produce a reply or a draft for that store, with the host instructed not to retain the prompt for training.
The form on salestino.com asks for an email address and, optionally, a Shopify store name. We use that to send an install link and a small number of emails about early access. Legal basis: consent (you tick the box; it is not pre-ticked; the server refuses the row without it).
We do not record your country, IP or browser as part of the signup. Cloudflare, which serves the page, sees the request the way any HTTPS host does.
You can withdraw consent by writing to hello@salestino.com. We delete the row. A waitlist row is not kept longer than 12 months after signup; until a scheduled sweep exists, that erasure is done by hand from the same address.
When a merchant installs the app, Shopify tells us the shop domain, shop name, and the shop’s contact email. Staff who open the app are identified by Shopify’s staff id. Invited agents sign in with a magic link to the address the owner typed.
We use this to run the account: seats, billing through Shopify, transactional mail (invites, overage notices, delivery failures), and to send a customer-data export to the shop owner when Shopify asks us to. Legal basis: performing the contract to provide the app, and legitimate interests in securing the account.
A sign-in creates a session row that records the IP address and browser user-agent it was created from. That is there to make a stolen session visible, nothing else: it is never used to profile a person, and the row is deleted once the session expires. Magic-link records and invitations that were never accepted are deleted the same way.
Billing itself is Shopify’s. We do not collect card numbers. We store the Shopify subscription id, the plan tier, and usage counters (visits, email replies, LLM spend).
A buyer who chats on a store, emails the store’s support address, or asks us to look up an order is the merchant’s customer. The merchant is the controller. We process:
Purpose: provide the merchant with the helpdesk and, on paid plans, the AI agent they installed. We do not use this data for our own marketing.
The buyer’s rights are exercised against the merchant. Shopify forwards access and erasure requests to us as mandatory webhooks; we collect or delete what we hold and mail the export to the shop owner so they can answer the customer. A buyer who writes to us directly is pointed at the store, and we still honour an erasure Shopify sends.
Through the Admin API, with the scopes the merchant granted:
We request write scopes only when the merchant turns on the matching action in Settings. We do not request read_all_orders.
This marketing site sets no cookie of our own. The font files are served from our domain.
On a merchant’s storefront the chat widget:
localStorage only after the visitor opens chat — that token is how their conversation continues. It is strictly necessary for a service they asked for.We are established in Poland, so a transfer of personal data to a processor outside the EEA is a Chapter V transfer. Several subprocessors below are in the United States. OWNER + legal: put the actual mechanism here before production holds EU customer data — standard contractual clauses, Data Privacy Framework certification, or an adequacy decision. Do not claim any of those until the signed papers exist.
| Who | For | What they see | Where |
|---|---|---|---|
| Cloudflare, Inc. | This website, DNS, D1 waitlist, R2 attachments | Waitlist email; email-attachment bytes | Global anycast; R2 region OWNER |
| Postmark (ActiveCampaign) | Transactional mail and the helpdesk | Addresses and message bodies we send or receive | United States |
| OpenRouter, Inc. | Model routing for chat and drafts, and the embedding of catalog and policy text (default configuration) | Masked message text, retrieved catalog/policy chunks, order city and country. Configured with data_collection: deny so the prompt is not retained for training. Direct connection to a model host is the production preference. | United States |
| Anthropic PBC | The model itself, when the app is configured to call it directly instead of through a router | The same prompt as above. Anthropic’s API does not train on it. | United States |
| OpenAI, L.L.C. | Standby model, used only when the primary times out or errors; embeddings if configured | The same prompt as above. Not used to train models on API traffic. | United States |
| Voyage AI (MongoDB) | Embeddings, if configured instead of the two above | Catalog and policy text, and the visitor’s message as the search query it is turned into. Same masking as above. | United States |
| Upstash, Inc. (QStash) | The job queue: delayed refunds, syncs, sweeps | Identifiers only — a merchant id, an action id, a thread id. No message text, no addresses. | US company; queue region eu-central-1 (Frankfurt) by configuration |
| Functional Software, Inc. (Sentry) | Error reporting | Error events and identifiers. Buyer email is not sent. Request bodies, query strings, cookies and headers are switched off in the SDK, so a report carries the method and the path and nothing from the request itself. | United States |
| Railway (planned production — not live) | App hosting and PostgreSQL | Merchant and customer data the app holds | OWNER: region |
| Shopify Inc. | The platform the app runs on | Whatever the merchant already stores there; we send actions back through their Admin API | Shopify’s regions |
The Shopify app is not generally available as of this date. Waitlist rows live in Cloudflare D1. Merchant and customer data today live on the development database used to build the product, not on a public production host. This page will be updated before the production cutover with the live region and the signed transfer terms.
Waitlist: section 3. Merchant account: for as long as the app is installed, then 30 days after uninstall (or immediately on Shopify’s shop/redact webhook). Reinstalling inside that window keeps the store’s history. Sign-in sessions, magic links and unaccepted invitations go when they expire (invitations, 30 days after). Store customer data, while the merchant stays installed:
| Record | Kept for | Why |
|---|---|---|
| Orders | not stored | Read live from Shopify when needed. We do not keep a copy. |
| Order-verification attempts | 90 days | The address the visitor typed to prove an order |
| Conversations, helpdesk threads, action records, attribution | 24 months | The merchant’s support history; money-moving actions are their financial record |
| Visit beacons | 90 days | Plan metering |
| Staff access log (ids only, never the data) | 24 months | Audit of who opened a customer’s thread |
| Images attached in a chat | 14 days | A photo in the widget, the team room or a reply. The message keeps the filename and says the file expired. Files a customer emailed are different — those live with the thread |
| Team chat between the store’s own staff | 12 months | Their coordination, not the customer’s data. If an address is quoted there, an erasure request scrubs the message |
| A data-request export file | 30 days | The copy we build for the store to forward; deleted after, or immediately if that person then asks for erasure |
| Spam threads and their attachments | 30 days | Then deleted, files included |
These periods are the ones running in code. They become a sentence the owner is standing behind; changing them is a product decision, not an engineering one.
There are none, and the product is not built to have them. The assistant can work out whether a refund, a return, an address change or a discount is possible, what Shopify would actually do and what it would cost — and then it stops. Every one of those is carried out by a person on the store’s team, from a queue in the app, with one button. Nothing the assistant proposes reaches the store’s Shopify data until somebody presses it.
So no decision here produces legal or similarly significant effects for a buyer by automated means alone, and GDPR Art. 22 has nothing to bite on. It is still true that a buyer can ask for a person on any turn of the chat, and that the widget tells them they are talking to an AI before it says anything else.
What the software does do is check, and re-check: identity verified for that order, the store’s plan and permissions, the live state of the order in Shopify, the store’s return window and excluded collections. The whole check runs again at the moment the person approves, and once more before any money moves — so a request that sat in the queue for a week cannot go through on a stale answer. Refund amounts come from Shopify’s own refund calculation, never from the model — and the person approving sees that figure in an editable box and may change it before it is sent, within the maximum Shopify itself allows. An approved refund is sent after a 30-minute pause, which is the store’s own undo.
Under GDPR you have the right to access, correct, erase, restrict, object, receive a copy, and withdraw consent. For waitlist and merchant-account data, write to hello@salestino.com. For store-customer data, ask the store — they are the controller; Shopify will also send us the request and we will honour it, and the store can act on a request made to them directly, including for someone who only ever used the chat and has no Shopify account. An access request comes back as a complete file, never a summary or an extract, and it answers Art. 15(1)(a)–(h) — purposes, categories, recipients, retention, source, rights, and whether anything was decided about that person automatically — as well as holding the data. An erasure request also deletes any such file we had already made.
You may complain to PUODO (lead authority, because we are established in Poland) or to the supervisory authority of your own Member State. UK and other non-EU authorities remain available where their law applies to you as a data subject.
Access tokens are encrypted at rest. Traffic is TLS. Each merchant’s rows are isolated by database row-level security. Attachments sit in a private bucket and are read through short-lived presigned URLs. Seats are owner or agent; only the owner can change plan, action limits, sending domain or the storefront look. Staff reads of a customer’s thread are written to an access log by reference, not by copying the data.
When we are the controller (waitlist, merchant accounts) and a breach is likely to result in a risk to people, GDPR Art. 33 requires us to notify PUODO within 72 hours of becoming aware of it. When we are the processor (store customers), we notify the merchant without undue delay so they can meet their own Art. 33 clock. OWNER: write the actual playbook (who picks up Sentry, who emails PUODO, evidence) before a data-protection review. The 72-hour rule is not optional.
If this page changes in a way that affects what we collect or why, we will update the date above. Material changes to processing we do as a processor are also a DPA matter and go to the merchant.
hello@salestino.com · DPA · Terms · Imprint