Privacy Policy

1. Introduction

Emporiqa, operated by Rosel Group LTD., a limited liability company registered in Sofia, Bulgaria (UIC/EIK 206801487) ("we," "our," or "us"), is committed to protecting your privacy. This Privacy Policy explains how we collect, use, disclose, and safeguard personal information when you use our e-commerce online-salesperson platform (also described in marketing materials as a chat assistant for e-commerce) and related services (the "Service"). Our full registered address and contact details are in Section 15.

Controller vs. processor roles. For personal data relating to merchant accounts and dashboard users (for example your account email, team member details, billing data), we act as the controller. For personal data processed through the chat widget on behalf of a merchant (for example customer chat messages sent to a merchant's store), we act as a processor and the merchant is the controller; the merchant is responsible for providing an appropriate privacy notice to their end customers.

Data protection contact. We have not appointed a formal Data Protection Officer (we are not required to under GDPR Art. 37). Because we are established inside the European Union, we are not required to designate an EU representative under Art. 27. For any data-protection matter, including rights requests, you may contact us at [email protected].

Please read this Privacy Policy carefully. If you do not agree with it, please do not access the Service.

At a Glance: What We Collect, Why, Where It Goes and for How Long

This table summarizes the personal data the Service handles. The sections below give the details. Where a period runs from a conversation's last activity, a job that runs once a day deletes the data, so it is gone from our live systems within a day after the period ends, and from our encrypted backups within about six weeks.

2. Information We Collect

2.1 Information You Provide or Your Store Transmits

We receive information in two ways: information you enter directly into our platform, and information your store sends to our webhook endpoints on your instruction. Specifically:

• Account registration information (name, email address, business details)
• Payment information (processed securely by our payment processor, Stripe; we do not store full card numbers)
• Profile information and preferences
• Support communications and correspondence
• Store content transmitted via webhooks: product data, page/policy content, and inventory metadata that your store actively pushes to our webhook endpoints. We do not pull or scrape data from your store.
• Webhook signing secrets: a secret shared with your store. We use it to verify HMAC-SHA256 signatures on webhook requests from your store and on the signed customer token your plugin issues, to sign our requests to your plugin and verify its signed answers, and, through a separate key derived from it, to sign the requests store rules send to Zapier or Make. Stored encrypted at rest using symmetric (Fernet) encryption.
• Team member information: Names, email addresses, and access levels (Owner or Team Member)
• Pictures you upload (optional): a picture for your chat, and, if a team member chooses to add one, their own photo shown to shoppers beside their replies in that store. Both are optional and both are uploaded by the person they belong to. Uploaded images are re-encoded on our side, which removes camera metadata such as GPS coordinates. They are served from a public URL, so a shopper viewing the chat can see them.
• Order tracking configuration (optional): if you enable order tracking, you provide an HTTPS endpoint on your store that we call with an HMAC-signed request when a customer asks about an order. We use the answer to write the chat reply. When it includes order details, they are shown to the customer as an order card, which is stored with the conversation (see Section 2.3).

2.2 Information Collected Automatically

When the chat widget is loaded on your store, or when you use our dashboard, we automatically collect:

• Customer chat data: All customer conversations (kept until 90 days after the conversation's last activity, then automatically deleted)
• Page the customer is viewing: where the store has page awareness switched on, the address and title of the store page a customer is on when they send a message are saved with that message, with query parameters removed except those that identify the product, so the store's team can see which product was being discussed; they are deleted with the conversation after 90 days.
• Customer satisfaction ratings: Thumbs up/down feedback submitted by customers after chat sessions
• Cart interaction data: Products added, removed, or updated via in-chat cart operations
• Conversion tracking data: Cart events and purchase attribution linking chat sessions to completed orders. If you enable conversion tracking, your store sends us an order.completed webhook containing the order identifier, order total, and an identifier linking the order to a chat session. We do not receive or store the customer's name, address, or payment details through this webhook.
• Widget engagement data: Chat widget loads, opens, unique visitors, and engagement rates
• Anonymous visitor fingerprint (server-side): for unique-visitor counts the widget does NOT store any identifier in the shopper's browser. Instead, the server derives a one-way SHA-256 hash of the visitor's IP address, browser User-Agent string, a server-side salt that rotates every 24 hours, and the store ID. Because the salt rotates daily, the same visitor on two different days produces unrelated fingerprints, and the data cannot be linked across days. Under GDPR Recital 26 this is anonymous data, not personal data, and does not require consent.
• Signed customer identifier (optional): if you pass a user_id parameter when embedding the widget, we verify its HMAC signature and associate chat sessions with that identifier. We use it to link a chat to your customer record and, where your plugin supports it, to look up that customer's account, orders and customer-specific prices in your shop. Where a store rule allows it, the identifier is also included in the requests the rule sends to your shop or to your Zapier or Make webhook (see Section 2.6). We do not use it for any other purpose.
• Proactive trigger data: Which chat triggers fired based on visitor behavior (time on page, pages viewed, checkout page visits), whether each message was clicked, closed or left to disappear, the page's language code, and customer responses. No visitor identifier; when the customer writes after clicking, the record is linked to that conversation. Kept 90 days
• Platform usage: How you use the dashboard, manage products, and access features
• Team activity: What Owner and Team Member users do in the system
• Store connection data: How well your store stays connected and synced with our platform
• Billing and usage data: Invoice creation, subscription management, and usage tracking
• Device information and browser details
• IP addresses (used for rate limiting and abuse prevention; kept in rate-limit counters for up to 24 hours and in our web server's access log for less than a day)
• Country of the shopper: our edge network derives a country code from the IP address. It is stored with the conversation so the store owner can see where an enquiry came from, and it lets a store owner limit their chat to the countries they sell to. Only the country is recorded, never the city, the region or coordinates. The country code alone is kept in the shopper's browser so it does not have to be looked up on every page; it identifies nobody and is cleared with their site data.
• Session information (authentication cookies, CSRF tokens)
• Usage data for billing (conversation counts, webhook event counts)
• Store management activities: When stores are paused/activated, settings changes, and operational activities

2.3 Customer Data

When a customer uses the chat widget on your store, we process customer data on your behalf, including customer questions, product searches, order tracking inquiries, cart operations (products added or removed via chat), satisfaction ratings, and chat history. All customer conversations are kept until 90 days after the conversation's last activity and then automatically deleted. We process this information to generate assistant responses via our LLM subprocessors (see Section 5). When order tracking is enabled, we send the details a customer gives for it (for example an order number and email address) to your store's endpoint. Your store's answer, which can include order contents and delivery details, is processed by our LLM subprocessors to write the reply, and is kept only as part of the conversation. Where the answer is shown as an order card, the card is stored with the conversation and can include the items, totals, the customer's name, the shipping and billing addresses, the payment method and tracking details. It is deleted with the conversation.

Chat messages and voice recordings are not used to train AI models. Our large language model subprocessor's published API data usage policy states that data submitted via the API is not used to train or improve its models by default. We do not opt in to any model-improvement programs that would change this, and we do not feed chat content into our own training pipelines. The subprocessor keeps API requests for up to 30 days to check for abuse, then deletes them. We have asked OpenAI for zero data retention; until OpenAI grants it, the 30 days apply. The current named subprocessor is listed on our Subprocessors page.

Human handoff: if a customer's question is escalated to a human (via our handoff feature), the customer's chat messages become visible to your authorized team members in your platform dashboard so they can respond. Contact details the customer types into the chat for this, such as a name, email address or phone number, are attached to the request, shown to your team and can be included in handoff emails, marked as not verified. Handoff availability and behavior are controlled by you.

Voice mode: if you switch voice mode on, a customer may choose to speak instead of typing. The first time a customer uses voice in a browser, the widget tells them that they will talk to an AI with an AI voice and asks them to confirm, and the browser asks for microphone permission. Voice mode is hands-free: after each reply the microphone turns on again by itself and records anything loud enough to count as speech, which can include other people nearby, until the customer ends voice mode or stays silent for about 10 to 15 seconds. Each spoken message is recorded in the customer's browser and sent to our large language model subprocessor to be transcribed. We do not store the recording; the subprocessor may keep the request, including the audio, for up to 30 days for abuse monitoring, as described below. Each transcript is shown briefly and sent unless the customer cancels it; a transcript the customer sends is stored as a chat message, like typed text, and one they cancel is not. The text of the reply is sent to the same subprocessor to be turned into speech, and the generated audio is held in memory for up to 5 minutes so the browser can play it, then discarded. Recordings are used only to turn speech into text. Neither we nor our subprocessor create voiceprints or use recordings to recognise or identify a speaker, or to infer emotion, age or other personal characteristics.

2.4 Chat Assistant Data

Our systems process and store:

• Product and page information for search and recommendations
• Conversation history and context for customer service (90-day retention period)
• Language detection and processing data (so the chat answers in the language the customer writes in)
• Aggregate conversation volumes and token counts (used for billing, capacity planning, and abuse detection; we do not use the content of customer chats to improve responses or train AI models)

2.5 Platform Management Data

Our business management features collect and store:

• Store dashboard data: Product and page status, connection monitoring
• Conversion tracking dashboard: Revenue attribution, conversion funnel metrics (sessions, cart adds, checkouts, purchases), chat-attributed revenue
• CSAT dashboard data: Aggregate satisfaction scores and individual low-rated conversation review
• Proactive trigger configuration: Trigger rules, templates, and performance data per store
• Team management data: User access levels (Owner/Team Member), permissions, activity tracking
• Store connection data: Setup configurations, connection status tracking, security logs
• Billing management data: Invoice history, usage tracking, subscription management
• Activity records: Complete records of all platform activities organized by user access level
• Business analytics data: Detailed statistics on usage, performance, and customer interactions
• Chat widget data: Customization settings, positioning, brand colors, and website security rules

2.6 Store Rules

A merchant can set up rules that tell the chat what to do when a customer asks about a particular thing, for example the status of an order or a return. The merchant decides which details a rule asks the customer for, such as an order number, email address, phone number, name, a reason, or other fields the merchant defines, and where the rule sends them. The chat asks only for the details the rule declares, and the rule sends only those details and the extras described below. Depending on how the merchant has set up the rule, the chat:

• Answers with the merchant's own text. This sends nothing outside the conversation by itself.
• Checks the merchant's shop: it sends a signed request to an address on the shop's own domain, which the merchant has shown they control, and uses the shop's answer to write the reply.
• Emails the merchant's team: it sends the details, the customer's message (with an English translation when it is in another language) and a link to the conversation to the team members the merchant picks for the rule, from our no-reply address through our email delivery provider. The email marks the details the customer typed as not verified, and marks each detail taken from the customer's account as taken from it. Where the details include a valid email address, typed by the customer or taken from their account, a reply to that email goes to the customer.
• Sends the details to Zapier or Make: it posts them, signed, to a webhook address in the merchant's own Zapier or Make account. The merchant chooses and contracts with these services. They receive the data as the merchant's recipients, not as our subprocessors.

When a rule calls the shop or sends to Zapier or Make, the merchant can also choose to include the address of the page the customer is on, the product they are viewing, the products in their cart (product id, SKU and quantity) and the customer's message as typed. Each of these is off unless the merchant turns it on. The request also carries the rule's name, a request identifier, the language of the conversation, the channel the chat runs in, the customer's currency where it is known, whether the customer is signed in, and whether it is a test. Where the store's plugin supports it and the merchant allows it, a customer who is signed in to the store is identified by their customer id, taken from a signed token the plugin issues, instead of being asked for the details that prove an order is theirs; the request then also carries that customer id. A request to Zapier or Make also lists which details were taken from the customer's account.

The merchant can set a rule to take the customer's email address, name or newest order number from their account in the shop instead of asking for it. For a signed-in customer, we then ask the store's plugin for the name and email address on their store account and up to 10 of their most recent orders (order number, date, status, total and currency), plus any fields the merchant adds to that answer in their own shop. This answer is held in a cache for up to 30 minutes. A value a rule takes from it is handled like a detail the customer typed: it is sent where the rule sends its details (the team email, the Zapier or Make request, or the shop for an order status lookup) and kept with the conversation until the conversation is deleted.

The details a customer gives also pass through our large language model subprocessor (Section 5.1), which reads the conversation to pick them out and to write the reply. For data collected through rules, the merchant is the controller: they decide what is collected, for what purpose, and where it goes, and we process it on their instructions (Section 4). Once the data reaches the merchant's shop, team inbox, or Zapier or Make account, it is handled under the merchant's own privacy notice and the terms of the services they use.

So that the merchant can see what each rule did, we keep a record of it with the conversation: the names of the fields it used (not their values), the outcome, and a short excerpt of the customer's words that led to it, with email addresses and long numbers masked. When a rule emails the team or offers the customer a person, the details, including any taken from the customer's account, are also attached to a request in the merchant's dashboard. Both are deleted with the conversation, 90 days after its last activity. A history of the changes a merchant makes to their rules is kept for the life of the store and for 1 year after the store is deleted; it holds no customer data.

To deliver and retry rule requests, we hold short-lived copies on our cache servers in the EU. A team email or Zapier or Make request (the details, the customer's message and the request body) is held for up to 2 days so it can be retried, and removed once it is delivered. The English translation of a customer's message for a team email is kept for 7 days, so a re-sent email is not translated again. The answers that decide which rule applies and which details a message contains are kept for 10 minutes.

3. How We Use Your Information

We use the information we collect to:

• Provide, operate, and maintain our e-commerce chat assistant services
• Process transactions and manage your account and subscription plans
• Improve platform reliability and performance (operational metrics only; we do not use customer chat content to improve the Service)
• Provide customer support and respond to inquiries
• Send service notifications and important updates
• Conduct aggregate analytics to understand platform-wide usage patterns
• Detect and prevent fraud, abuse, and security threats
• Comply with legal obligations and enforce our terms
• Generate vector embeddings of your product and page content for semantic search
• Track conversion attribution from chat sessions to purchases
• Process and aggregate customer satisfaction (CSAT) ratings
• Deliver proactive chat triggers based on visitor behavior
• Process in-chat cart operations (add, remove, update, checkout)
• Manage team members and role-based access controls
• Process billing information and generate invoices
• Maintain chat history and conversation records (90-day retention)
• Track platform usage and generate analytics reports
• Monitor store status and manage suspension/activation
• Create activity logs and audit trails
• Enable profile management and user updates

4. Legal Basis for Processing (GDPR)

Where GDPR applies, the legal basis under Art. 6(1) for each category of processing we carry out as a controller is:

• Contract performance (Art. 6(1)(b)): account registration and authentication, provisioning the Service, team-member management, subscription management, billing, sending service-related notifications, and responding to support requests.
• Legitimate interests (Art. 6(1)(f)): platform security and abuse prevention (including rate limiting, signature verification, audit logs, and an occasional check asking a store visitor to confirm they are human before the chat continues), aggregate usage analytics for capacity planning, and product improvement from operational metrics. We have balanced these interests against your rights and concluded they do not override them. You may object under Section 9.
• Consent (Art. 6(1)(a)): optional marketing communications and any non-essential cookies or analytics that require consent under ePrivacy rules. You may withdraw consent at any time without affecting processing carried out beforehand.
• Legal obligation (Art. 6(1)(c)): retention of invoices and tax records, responses to lawful requests from competent authorities, and compliance with GDPR itself (breach notification, subject-rights responses, record-keeping).

For personal data processed on behalf of a merchant via the chat widget (for example, customer chat messages), we act as a processor under Art. 28 and process only on the merchant's documented instructions. The merchant is responsible for establishing the legal basis for that processing under their own privacy notice.

Automated decision-making (Art. 22). The Service generates AI-assisted responses to customer chat messages, but it does not make decisions producing legal effects concerning a data subject or similarly significantly affecting them. In particular, we do not use automated processing to deny service, set pricing per individual, or make employment, credit, or similar decisions about any person.

5. Subprocessors and Information Sharing

5.1 Subprocessors

We engage the following categories of third-party subprocessors to deliver the Service. Each is contractually bound to process data only on our documented instructions, to maintain appropriate security, and not to use customer data for training AI models.

• Large language model provider: generates chat responses from customer messages and processes product/page content during catalog sync (summaries and embeddings); where voice mode is on, it also transcribes customers' spoken messages and generates the spoken replies. The provider keeps API requests for up to 30 days to check for abuse, then deletes them. We have asked OpenAI for zero data retention; until OpenAI grants it, the 30 days apply.
• Search ranking provider: OpenRouter (United States) passes the shopper's search query, with product and page text, to Cohere, the provider of the ranking model. OpenRouter does not keep it; Cohere keeps it under its own terms.
• Payment processor: handles subscription billing and stores payment-method data. We do not store full card numbers.
• Cloud hosting and infrastructure provider: runs our application servers, PostgreSQL databases, Redis cache, vector database, and file storage, on servers in Germany (Hetzner).
• CDN and edge network provider: fronts our HTTP traffic and the chat widget embed script. Processes IP addresses, request/response metadata, and proxied traffic for caching, DDoS protection, and abuse prevention.
• Error-tracking and observability provider: receives application error reports and performance traces so we can diagnose issues. Payloads may include request metadata, user identifiers for the logged-in platform user, and stack traces. Customer chat message bodies are scrubbed before submission.
• Email delivery provider: delivers the emails we send from our no-reply address, including sign-in links, account notices, handoff alerts to a store's team, and store-rule emails. These can contain the contact details and messages a customer gave in the chat and the details a store rule collected.

The current authoritative list of named subprocessors (including jurisdictions and purposes) is published at our Subprocessors page. We will notify registered account holders at least 30 days before engaging a new subprocessor that processes customer personal data.

5.2 Other Disclosures

• Store order tracking API (optional): when you enable order tracking, the details a customer gives for it are sent to the endpoint you configure on your own store, using HMAC-signed requests. Your store's answer is used to write the reply in the chat.
• Store rules (optional): where a merchant sets up rules, the details a rule collects go where the merchant directs: an address on the merchant's own shop, the store's team by email, or a Zapier or Make webhook in the merchant's own account (see Section 2.6). These are recipients the merchant chooses, not our subprocessors.
• Official platform extensions: if you install one of our extensions (Drupal Commerce, WooCommerce, Sylius, PrestaShop, Shopware, Magento 2 / Adobe Commerce), it runs inside your own store and transmits data to our webhook endpoints. The extension is first-party code we publish, not a third-party recipient.
• Legal Requirements: When required by law or to protect rights and safety
• Business Transfers: In connection with mergers, acquisitions, or asset sales

We do not sell, rent, or trade your personal information to third parties for their marketing purposes.

6. Cookies and Tracking Technologies

6.1 Dashboard Cookies (for platform users)

When you access our platform dashboard, we use essential cookies necessary for the operation of the dashboard:

• Session cookies for authentication and security
• CSRF protection tokens
• User preference storage (language, theme, selected store)

6.2 Chat Widget Storage (on end-customer browsers)

When a customer loads the chat widget on your store, the widget writes a small amount of state to the shopper's browser. Every entry is single-purpose and either first-party to your store's own domain or held in the chat window's own storage. The entries the chat needs are exempt from the ePrivacy Directive Art. 5(3) consent requirement under the "strictly necessary for the service explicitly requested by the user" criterion. The returning-visitor flag, the proactive message state, the daily usage marker and the recently viewed products serve features beyond that, and none of them is written where your store loads the chat on click (see the last entries below):

• Conversation thread identifier (localStorage): so a customer's chat continues across page navigation within your store. Cleared when the chat session ends.
• Chat window state (localStorage and sessionStorage): open or closed, unread badge, coordination between open tabs, how often to check for new messages, and whether the satisfaction question was already asked. No identifier; sessionStorage entries end when the tab closes, localStorage entries are overwritten as the chat is used.
• Returning-visitor flag (localStorage on your store's domain): the value 1, set on the first visit, so proactive messages can treat new and returning visitors differently. No identifier; it stays until the customer clears their site data.
• Proactive message state (localStorage and sessionStorage): pages viewed in this visit, whether it is the first visit, which proactive messages were shown or closed, when the last one appeared, and when a tab last had the chat open, shared by the store's open tabs so a message is not repeated in another tab or shown during a conversation. No identifier; a new visit starts after 30 minutes without a page view.
• Country (localStorage, only where your store limits the chat by country): the visitor's country code as our server determined it, kept 30 days when the chat is allowed there and 1 hour when it is not, so the check is not repeated on every page.
• Daily usage marker (localStorage): the date and the chat events (such as loads and opens) this browser already counted today, so daily counts are not inflated. No identifier.
• emporiqa_sid first-party cookie: carries the chat thread identifier on your store's domain so your integration plugin can read it server-side when a customer completes an order, and emit the order.completed webhook with the corresponding chat session. Single-purpose (conversion attribution), 1-hour sliding TTL, SameSite=Lax, not combined with any cross-site tracking. Strictly necessary for the conversion-attribution service your store has explicitly enabled. Not set where your store switches off linking orders to chats; with that switch in our Shopware plugin, no orders are sent to us either.
• Voice mode (only where the store has switched it on): held in the chat window's own storage on our domain, which the browser keeps separate for your store's site: a localStorage entry recording that the customer confirmed the voice notice, so it is not shown again, kept until the customer clears their site data, and a sessionStorage entry holding whether spoken replies are muted, cleared when the browser tab closes.
• Recently viewed products (localStorage on your store's domain, only where page awareness is on): up to 25 product pages the customer opened (address, name, SKU, image). Up to 8 are sent with a chat message as context for that answer and are not stored by us; the entry stays until the customer clears their site data.
• Attention pulse (sessionStorage on your store's domain): that the chat button's short attention animation was already shown, so it plays once per browser session. Cleared when the tab closes.
• Loading on click (where your store uses it): your store's page draws the chat button itself. Until the customer clicks it, their browser makes no request to us and nothing is written; the button reads only the entry that follows. After the click, the returning-visitor flag, the proactive message state, the daily usage marker, the recently viewed products and the attention pulse are not written.
• Chat opened (localStorage on your store's domain, loading on click only): when the customer last opened the chat, so later pages load it at once and a conversation carries on. Used for 30 days after the last open; it stays until the customer clears their site data.
• No visitor tracking ID: unique-visitor counts are derived server-side from a daily-rotated anonymous fingerprint (see section above), nothing trackable is stored in the shopper's browser.

The chat widget does not set third-party advertising cookies, cross-site tracking cookies, or persistent device identifiers. Every entry listed above is first-party to your store's domain or held in the chat window's own storage, and is used only for the purpose stated next to it.

6.3 Managing Cookies and Storage

You can manage your cookie and localStorage preferences through your browser settings. Disabling dashboard cookies will prevent you from logging into the platform. Clearing widget localStorage on an end-customer's browser will end their current chat session but does not otherwise affect their experience of your store.

7. Data Security

We implement appropriate technical and organizational security measures to protect your personal information, including:

• TLS 1.2+ encryption for all data in transit
• Symmetric (Fernet) encryption at rest for webhook signing secrets
• HMAC-SHA256 signature verification on all webhook traffic from your store
• Encrypted database backups
• Access controls and least-privilege permissions for our operations team
• A review of these measures whenever the service changes, and at least once a year
• Incident response procedures and breach notification in line with GDPR Art. 33
• Multi-tenant data isolation between stores at the application and database layer
• Data residency: primary application infrastructure and data stores are on servers in Germany (Hetzner). Customer chat messages (and, where voice mode is on, voice recordings and the reply text to be spoken) are transmitted to our LLM subprocessor (see Section 5), which may process them outside the EU under GDPR transfer safeguards (Section 10).

8. Data Retention

We retain your personal information for as long as necessary to provide our services and fulfill the purposes outlined in this Privacy Policy. Specific retention periods include:

• Your sign-in account and profile: kept until you ask us to delete it (see Section 9). Store data (catalog, pages, settings, team access and conversations): deleted 30 days after you close the store; you can cancel the closure within those 30 days
• Transaction records: Retained for 7 years for legal and tax purposes
• Chat logs and customer conversations, including order cards and the details store rules collected: retained until 90 days after the conversation's last activity, then deleted by a daily job, so within a day after that, and from our encrypted backups within about six weeks. They are deleted earlier when the store is deleted
• Orders your store's plugin sends to link orders to chats (order number, total, currency and items, no customer details): 90 days; an order linked to a conversation is deleted with it
• Voice recordings: not stored by us; each recording is transcribed and then discarded, and a transcript the customer sends is kept as part of the chat log. Our large language model subprocessor may keep the request, including the audio, for up to 30 days for abuse monitoring (see Section 5.1). Spoken replies: held in memory for up to 5 minutes, then discarded
• Platform analytics and usage data: Retained for 2 years unless longer retention is required
• Vector embeddings: retained for the lifetime of the underlying product or page. Deleted when you issue a product.deleted or page.deleted webhook, when you delete a page you created in the dashboard, or when your store is deleted. When a reconciling sync.complete marks an item as no longer present, it is removed from search and kept in an archive for up to 30 days, so a later sync can restore it, then deleted.
• Uploaded pictures: retained until you replace or remove them, or until the store or membership they belong to is deleted, whichever comes first. Removing a picture deletes the file.
• Store rule records (field names, outcomes and masked excerpts) and the details a rule attaches to a request for the team: deleted with the conversation, 90 days after its last activity. Short-lived copies: account information read from the shop, up to 30 minutes; rule requests waiting for delivery, up to 2 days; English translations for team emails, 7 days; rule matching and details read from a message, 10 minutes; prices for a signed-in customer, 5 minutes. History of changes to a store's rules: retained for the life of the store and 1 year after it is deleted
• Marketing data: Retained until you withdraw consent
• Team member data: Retained while account is active and for 1 year after member removal
• Activity logs: Retained for 2 years for audit and security purposes
• Billing dashboard data: Invoice history retained for 7 years, usage statistics for 2 years
• Store management data: Product/page data retained while store is active, deleted upon store termination

Important: Chat conversations are automatically deleted after 90 days to protect customer privacy. If you need a copy of particular conversations for business purposes, ask us before the 90-day limit and we will export them for you.

9. Your Rights

If GDPR applies to the processing of your personal data, you have the following rights in respect of the personal data we hold about you as a controller:

• Access (Art. 15): obtain confirmation of whether we process your personal data and receive a copy.
• Rectification (Art. 16): have inaccurate or incomplete data corrected.
• Erasure (Art. 17): have your personal data deleted where the grounds in Art. 17(1) apply.
• Restriction (Art. 18): request limitation of processing in the circumstances set out in Art. 18(1).
• Portability (Art. 20): receive the personal data you provided to us in a structured, commonly used and machine-readable format, and have it transmitted to another controller where technically feasible.
• Objection (Art. 21): object to processing based on our legitimate interests, including to profiling. We will stop processing unless we demonstrate compelling legitimate grounds that override your interests.
• Withdraw consent (Art. 7(3)): withdraw any consent you have given, at any time, without affecting the lawfulness of processing carried out beforehand.
• Right not to be subject to solely automated decision-making (Art. 22): see Section 4 for our position on automated decision-making.
• Lodge a complaint with a supervisory authority (Art. 77): in particular in the EU Member State of your habitual residence, place of work, or the place of the alleged infringement. Our lead supervisory authority is the Commission for Personal Data Protection of the Republic of Bulgaria (cpdp.bg).

To exercise these rights, contact us at [email protected]. We will respond without undue delay and at the latest within one month of receiving your request, extendable by a further two months where necessary under Art. 12(3). We may need to verify your identity before acting on a request.

If your request concerns chat messages or customer data processed on behalf of a merchant, the merchant is the controller of that data. We will forward such requests to the merchant and assist them in responding, in line with our processor obligations under Art. 28.

10. International Data Transfers

Our primary application infrastructure and PostgreSQL, Redis, vector database, and file storage are on servers in Germany (Hetzner). Some personal data is transferred outside the European Economic Area (EEA) in the course of delivering the Service, specifically:

• United States: our large language model subprocessor, our search-ranking subprocessor, our payment processor, our error-tracking subprocessor, and our CDN / edge-network subprocessor are based in the United States. Chat message content, search queries, voice recordings where voice mode is on, technical error context, and HTTP request metadata may be transmitted to their US systems for processing. Each transfer is governed by Standard Contractual Clauses (SCCs) approved by the European Commission under Decision 2021/914, supplemented by the additional safeguards each provider makes available (including Data Privacy Framework certification, where applicable).

Before relying on any new transfer mechanism, we assess whether the destination country's law ensures an essentially equivalent level of protection, following the approach set out by the European Court of Justice in Schrems II. Where necessary we apply additional technical measures (for example, TLS 1.2+ in transit, no training on the data, and short provider retention windows) to protect transferred data. You may request a copy of the relevant SCCs by contacting us at [email protected].

11. Compliance and Breach Notification

We comply with applicable data protection laws, including the General Data Protection Regulation (Regulation (EU) 2016/679), the Bulgarian Personal Data Protection Act, and the California Consumer Privacy Act (CCPA) where applicable.

Breach notification. For data we control, we notify the competent supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a breach that is likely to result in a risk to the rights and freedoms of individuals (Art. 33), and the affected people where the risk is high (Art. 34). For data we process on behalf of a merchant, we notify the merchant of every breach affecting it without undue delay and within 48 hours (Art. 33(2) and our Data Processing Addendum); the merchant, as controller, decides on notifying the authority and its customers.

Data Processing Addendum. If you are a merchant processing personal data of EU residents through the Service, you are the controller and we are the processor. Our Data Processing Addendum (Article 28 GDPR), with the Standard Contractual Clauses for transfers outside the EEA, is published and applies automatically; no signature is needed.

12. California Privacy Rights (CCPA)

If you are a California resident, the California Consumer Privacy Act (CCPA) grants you additional rights regarding your personal information:

• Right to Know: You can request disclosure of the categories and specific pieces of personal information we have collected about you
• Right to Delete: You can request deletion of your personal information, subject to certain exceptions
• Right to Opt-Out of Sale: We do not sell your personal information to third parties. If this changes, we will provide a "Do Not Sell My Personal Information" option
• Right to Non-Discrimination: We will not discriminate against you for exercising your CCPA rights

Categories of personal information collected: Identifiers (name, email), commercial information (subscription and billing data), internet activity (usage logs, chat data), audio information (voice messages a customer chooses to speak, transcribed and not retained by us), and professional information (business details). See Section 2 for complete details.

To exercise your California privacy rights, contact us at [email protected]. We will respond to verifiable requests within 45 days.

13. Children's Privacy

Our Service is not intended for children under 16 years of age. We do not knowingly collect personal information from children under 16. If you become aware that a child has provided us with personal information, please contact us.

14. Changes to This Privacy Policy

We may update this Privacy Policy from time to time. We will notify you of any changes by posting the new Privacy Policy on this page and updating the "Last updated" date. You are advised to review this Privacy Policy periodically for any changes.

15. Contact Information

If you have any questions about this Privacy Policy or you wish to exercise your data-protection rights, please contact us:

16. Governing Language

This Privacy Policy is published in English. Translations into other languages are provided for convenience only. In case of any discrepancy or inconsistency between the English version and any translation, the English version shall prevail.