Parties
Controller: The Customer (the business that has accepted Klirry's Terms of Service).
Processor: Per Philip Alexander Hjelmberg, a sole proprietorship (enskild firma), Drottninggatan 12, 352 29 Växjö, Sweden, Swedish VAT number SE850529273301 ("Klirry"), operated by its founder.
Together referred to as "the Parties".
When this DPA applies. This DPA is accepted together with the Terms of Service and is binding before any processing on the Customer's behalf takes place: it applies from the moment the Customer connects a store or uploads data, including during the 21-day Trial and on test accounts.
Scope note: This DPA governs Klirry's processing of Order Data only — the activity where Klirry acts as a processor on the Customer's documented instructions. Account Data (the Customer's own staff logging into Klirry) is processed by Klirry as an independent controller, determining its own purposes and means, and is governed by the Terms of Service and Privacy Policy, not this DPA — see the "Our two roles" section of the Privacy Policy. Where this DPA's operational sections (e.g. Section 7, deletion) describe a pipeline that deletes both Order Data and Account Data together, that describes the technical mechanism only; it does not extend Article 28 processor obligations to Account Data.
Definitions
| Term | Meaning |
|---|---|
| GDPR | Regulation (EU) 2016/679 of the European Parliament and of the Council |
| Personal Data | Any information relating to an identified or identifiable natural person (GDPR Art. 4(1)) |
| Processing | Any operation performed on Personal Data (GDPR Art. 4(2)) |
| Controller | The Customer — the entity that determines the purposes and means of Processing |
| Processor | Klirry — processes Personal Data on behalf of the Controller |
| Sub-processor | Any third party engaged by Klirry to Process Personal Data of the Controller |
| Data Subject | The natural person whose Personal Data is Processed |
| Order Data | The order-level data, payment and shipping cost records and advertising data imported or uploaded for the Customer, as listed in Annex 1. No end-consumer name, email, address or phone number is imported, but the external order ID and the other order fields are pseudonymised personal data that the Customer can re-link to a person in its own systems. |
| Services | The Klirry profitability and decision software-as-a-service described in the Terms of Service, §3. |
Document structure
This DPA consists of the main body and four annexes:
- Annex 1 — Data Subjects and Personal-Data Categories
- Annex 2 — Technical and Organisational Measures (TOMs)
- Annex 3 — Sub-processors (generated from the vendor register)
- Annex 4 — Connected platforms: the Customer's own platforms that Klirry reads from or sends to on the Customer's instruction (generated from the same register; not sub-processors)
1. Subject matter, duration, nature and purpose
1.1 Subject matter
Klirry processes Personal Data on behalf of the Controller to provide the Services: computing true profit for the Controller's e-commerce business by combining order data, payment-fee and shipping-cost records, ad spend, VAT rates and the Controller's cost settings, and turning it into decisions on advertising, products, countries and markets, payment methods and shipping. Google Analytics 4 data, when connected, is a directional signal only and is never included in the profit figure.
1.2 Nature of processing
- Collection: Order Data and ad-spend data are collected through the Controller's integrations with its e-commerce platform and advertising accounts (read-only queries; see Terms §3 for the only objects Klirry creates on a platform) and from files the Controller uploads (for example payment-provider settlement files and carrier invoices).
- Storage: Data is stored in the EU on Klirry's infrastructure (see Annex 2).
- Aggregation: Order Data is aggregated per date, country, product, payment method, shipping method and campaign to compute profit and decisions.
- No processing for own purposes: Klirry does not use Order Data for its own marketing, resale, benchmarking or analytics purposes, and does not use it to train AI models.
1.3 Purpose of processing
The sole purpose of Processing under this DPA is to deliver the Services as described in the Terms of Service, §3 ("What the service does").
1.4 Duration
Processing starts when the Customer connects a data source or uploads data, and continues until the agreement ends and the retrieval period in Section 7 has ended.
2. Processor obligations
2.1 Documented instructions
Klirry processes Personal Data only on the documented instructions of the Controller. The Services as configured by the Customer constitute the complete set of instructions. If Klirry considers that an instruction infringes data protection law, it informs the Controller without undue delay.
2.2 Confidentiality and support access
Klirry ensures that all persons authorised to process Personal Data are subject to a confidentiality obligation. Access to production Personal Data is limited to the founder and any person with a documented operational need (least privilege). For support, the founder can open an account as the Customer (impersonation); each start and stop is recorded in the audit log with the acting founder and the account, and the impersonated session is shown as such inside the application. Impersonation is used only to answer a support request or investigate a fault.
2.3 No processing for own purposes
Klirry does not process Order Data for any purpose other than performing the Services.
2.4 International transfers
Klirry does not transfer Personal Data of the Controller to a country outside the EU/EEA, or to an international organisation, except on the Controller's documented instructions or where required by EU or Member State law (in which case Klirry informs the Controller beforehand unless the law forbids it). A permitted transfer is made only under a mechanism valid under GDPR Chapter V (an adequacy decision or Standard Contractual Clauses with supplementary measures where needed). Order Data is hosted in the EU; Annex 3 states the region of every sub-processor, including any transfer outside the EU/EEA.
2.5 Security and assistance (Articles 32–36)
Klirry implements the measures in Annex 2 (Article 32) and, taking into account the nature of the processing and the information available to it, assists the Controller in ensuring compliance with Articles 32 to 36: personal data breach notification (Section 5), data protection impact assessments and prior consultation, by supplying the information about the processing described in this DPA on written request within 30 calendar days.
3. Sub-processor authorization
3.1 General authorization
The Controller grants Klirry general written authorization to engage Sub-processors for the purposes of providing the Services, subject to this Section.
3.2 Current Sub-processors
The Sub-processors are listed in Annex 3, generated from the same register as the public page /legal/subprocessors, so the two cannot differ. Annex 3 is part of this DPA. A vendor marked "Not yet engaged" is added only after the notice in Section 3.3. Tools that Klirry uses as controller for its own purposes (billing, newsletter, website analytics) are not Sub-processors of the Controller's data; they appear on the public page for transparency only.
3.2a Flow-down and responsibility
Klirry imposes on every Sub-processor, by written contract, data protection obligations no less protective than those in this DPA (Article 28(4)), and remains fully liable to the Controller for the performance of its Sub-processors' obligations.
3.3 Changes to Sub-processors
Klirry informs the Controller of any intended addition or replacement of a Sub-processor at least 30 days in advance by email to the Controller's account email address.
3.4 Objection right
The Controller may object to a change by written notice to privacy@klirry.com within 14 days of the notice. If the Parties cannot resolve the objection within 30 days, the Controller may terminate the Services with a pro rata refund of prepaid fees for the unused period.
4. Data subject rights assistance
4.1 Scope of assistance
Klirry assists the Controller in answering requests under GDPR Art. 15–22 by:
- providing a data export of all Order Data and Account Data held for the Customer's tenant, in JSON or CSV, through the self-service export (Settings → Export your data; format documented at
/legal/export-format); - providing hard deletion under Section 7;
- answering written requests for technical assistance within 30 calendar days.
4.2 Limitation on end-consumer requests
Klirry does not store end-consumer names, emails, phone numbers or addresses, so an end consumer who contacts Klirry directly cannot be matched to a record. Such requests are handled by the Controller, who can identify the order in its own store and give Klirry the order identifier so that Klirry can assist. Order records remain pseudonymised personal data that the Controller can re-link (Annex 1, A1.2); this section narrows how a request can reach Klirry, not what the data is.
5. Personal data breach notification
5.1 Klirry's obligations
In the event of a Personal Data breach affecting the Controller's data, Klirry:
1. notifies the Controller without undue delay and at the latest within 24 hours of becoming aware of the breach. Notice may be given in stages: a first notice with what is known, followed by the rest as it becomes known; 2. provides the information required by GDPR Art. 33(3): the nature of the breach and the approximate number of Data Subjects and records, a contact point, the likely consequences, and the measures taken or proposed; 3. cooperates with the Controller in meeting its own duties towards supervisory authorities and Data Subjects; 4. does not inform third parties about the breach on the Controller's behalf, except where the law requires.
5.2 Internal procedure
Klirry keeps an incident procedure and an incident register that tracks the shortest clock that applies: 24 hours (Controller, Shopify), 48 hours (Stripe), 72 hours (supervisory authority, IMY, where Klirry is itself controller).
6. Technical and organisational measures (Annex 2)
The measures are set out in Annex 2. Klirry may update them provided the level of security is not reduced.
7. Deletion and return on termination
7.1 Retrieval period
After the agreement ends (cancellation by the Controller, a trial that is never paid, or a pause for non-payment), the Controller has a retrieval period in which it can download all Order Data and Account Data in JSON or CSV: at least 30 calendar days after cancellation; 30 calendar days from the end of the Trial for a Trial account that never becomes a paying account (deletion on day 51 after the account was opened); 60 calendar days from the pause for an account paused for non-payment. For a Shopify store, the data is deleted within 30 days of the redact request Shopify sends after uninstall.
7.2 What is deleted, and what is kept
After the retrieval period Klirry permanently deletes all Personal Data relating to the Customer's tenant: Order Data (orders, order lines, attribution results, decisions), ad-spend data, payment-fee and shipping-cost records, cost configuration, connections and their credentials, users, sessions and tokens, and the operational records generated by the Customer's use of the product (feedback, notification preferences, cost-review status, classification history, decision receipts, to-do items, the transactional email delivery log). Deletion is executed in batched transactions by the automated purge pipeline.
The only data that is kept is listed exhaustively below, each with its retention and legal basis. This is the one retention table used in the Privacy Policy, this DPA, the records of processing, the data inventory and the data-deletion page. Order Data is never in this table: it is deleted.
| Data | Retention | Legal basis |
|---|---|---|
| Customer data while the account exists (orders, order lines, ad spend, costs, connections, users, settings, reports) | For as long as the account exists | Contract; for Order Data the Customer's instruction as controller (GDPR Art. 28) |
| Customer data after cancellation, after a trial that is never paid, or after a pause for non-payment | Retrieval period with full JSON/CSV export, then hard deletion confirmed by email: after cancellation at least 30 days; after a trial that is never paid 30 days from the trial end (day 51 after the account was opened); after a pause for non-payment 60 days from the pause (day 7 after the first failed payment) | EU Data Act Art. 25(2); GDPR Art. 28(3)(g) |
| Shopify store data after the app is uninstalled (shop/redact) | Deleted within 30 days of the redact request | Shopify API Terms 6.2.3 |
| Own invoices, credit notes and accounting records, including the VIES result and the location evidence behind each invoice | 7 years after the end of the financial year | Bokföringslagen (1999:1078) 7 kap. 2 §; GDPR Art. 6(1)(c) and 17(3)(b) |
| VAT records for the One-Stop Shop (OSS) scheme | 10 years after the end of the transaction year | Mervärdesskattelagen (2023:200); GDPR Art. 6(1)(c) |
| Acceptance evidence: terms version, time, account, accepting user, acceptance method | 10 years from the acceptance (the general limitation period), pseudonymised once the account is deleted | GDPR Art. 6(1)(f) and 5(2): proof of the agreement in a legal claim |
| Audit log of security-relevant actions | While the account exists; after deletion 6 months, pseudonymised, then deleted | GDPR Art. 6(1)(f): security, fraud prevention, legal claims |
| Keyed HMAC identifier used to detect trial abuse (not reversible without the key; pseudonymised, not anonymous). It blocks a second trial only when the earlier trial was never paid | 12 months from the first trial start | GDPR Art. 6(1)(f): preventing repeated free trials |
| Support correspondence (emails between a customer and Klirry support) | 12 months after the last message in the conversation | GDPR Art. 6(1)(f): answering follow-up questions and defending a claim; deleted after that |
| Email suppression list (an address that bounced, complained or unsubscribed; the address only, with no link to an account) | No fixed end: kept so the address is never mailed again, until the owner asks for removal | GDPR Art. 6(1)(f); ePrivacy and Marknadsföringslagen (2008:486) 19 § |
| Deletion certificates (date and row counts, with a hash in place of the account) | 3 years | GDPR Art. 5(2) and 17: proof that deletion took place |
| Meta data deletion requests (random confirmation code, a keyed hash of Meta's user id, status and dates; no name or email) | 3 years | GDPR Art. 5(2) and 17: proof that the deletion Meta forwarded took place |
| Queued transactional mail jobs in the job queue (recipient address and the values filled into the message) | A sent mail: 1 hour, and the values are cleared the moment it is sent. A mail that failed for good: the values are cleared at the last attempt and the job is kept at most 7 days | GDPR Art. 6(1)(b) and (f): delivering the message and diagnosing a failed delivery |
| Keyed HMAC of a carrier tracking number on an order | 180 days after the order date | Processor: Customer's instruction (carrier invoice matching) |
| Newsletter subscriptions | Until unsubscribe; an unsubscribed address stays on the suppression list; an unconfirmed subscription is deleted after 30 days | GDPR Art. 6(1)(a) consent; Marknadsföringslagen 19 § |
| Website analytics (only after the visitor's consent) | 13 months | GDPR Art. 6(1)(a) consent; ePrivacy |
| Error reports (Sentry) | At most 30 days | GDPR Art. 6(1)(f): keeping the service working |
| Encrypted database backups | Pre-release dumps: 14 days. A nightly off-site copy is not yet in operation and will keep at most 30 days. Deleted data drops out of backups within that time | GDPR Art. 32: availability and recovery |
| The record of a deletion request (status and the address the confirmation was sent to) | 7 days after the deletion is confirmed by email; the proof that lasts is the deletion certificate (3 years, no personal data) | GDPR Art. 6(1)(f): showing the customer that the deletion ran |
| Password-reset, email-verification and invitation tokens (hashed; an invitation also holds the invitee email address), and the sign-in links and sessions of affiliate partners (hashed) | 7 days after the token expired or was used | GDPR Art. 6(1)(f): security of sign-in and answering "my link expired" questions |
| Log of the events Stripe sent (event id, type, a payload stripped of personal data), used to ignore duplicates | 90 days after receipt | GDPR Art. 6(1)(f): processing each billing event once and diagnosing failures |
| A referral click on a partner link that no signup followed (partner and time only; no visitor identifier) | 120 days after the click. A click that led to a signup becomes an anonymous count for the partner once the account is deleted | GDPR Art. 6(1)(f) and Art. 5(1)(e): crediting a partner inside the 90-day attribution window |
| Contact details of an affiliate partner (name or label, contact address, payout method) | While the partner agreement runs; erased 12 months after the partner was suspended or, if never activated, after the last change. Payout records follow the invoices row | GDPR Art. 6(1)(b) the partner agreement; Art. 6(1)(f) the fraud-review period afterwards |
| Background jobs that failed for good (tenant and connection ids and the error text), kept for inspection | 30 days after the failure (mail jobs: at most 7 days, see the mail queue row) | GDPR Art. 6(1)(f): diagnosing and replaying a failed job |
| IP address inside a rate-limit counter key (Redis), to slow down abuse of sign-in and the API | 2 minutes after the last request; counters for second-factor attempts 30 minutes | GDPR Art. 6(1)(f): protecting accounts against guessing |
| Application and proxy logs on the server (request path, status, timing; secrets and personal data are scrubbed before logging) | Rotated by size, not by time: at most 250 MB per container and 1 GB of host journal; older lines are overwritten. Error detail beyond that lives in error monitoring (30 days) | GDPR Art. 6(1)(f) and Art. 32: operating and securing the service |
7.3 Deletion confirmation
Klirry sends a deletion confirmation to the Controller's account email address within 5 business days of the purge, stating the date and the tables affected (counts, not content).
7.4 Aborted termination
If the Controller reactivates its subscription within the retrieval period, the deletion is cancelled and nothing has been deleted.
8. Audit rights
8.1 Information
Klirry makes available to the Controller all information necessary to demonstrate compliance with GDPR Art. 28, including this DPA and its annexes, the relevant parts of its security documentation and, when available, summaries of third-party audits or penetration tests.
8.2 Audits and inspections
The Controller (or an auditor it appoints under a confidentiality undertaking) may audit Klirry's compliance with this DPA. Audits are carried out first by documentation and security reports; where that is not enough, by an inspection with reasonable notice (normally 30 days), during business hours, once a year unless there is a breach or a supervisory authority requires more, without unreasonably disturbing the service and without access to other customers' data. Klirry's consent is not required for an audit that the GDPR entitles the Controller to; these practical rules only regulate how it is done. Platform operators (for example Shopify) may also review Klirry as their terms require.
8.3 Liability
Klirry's liability under this DPA follows the limitation in the Terms of Service, §13 ("Liability") — the higher of the fees paid in the 12 months before the claim and SEK 10,000, with the same exceptions for intent, gross negligence and liability that cannot be limited by law — unless mandatory law requires otherwise.
9. Governing law and jurisdiction
This DPA is governed by Swedish law, like the Terms of Service (§20). Disputes are settled by the same court as under the Terms of Service: Växjö tingsrätt as court of first instance.
10. Platform-specific provisions
Google Ads (Google Ads API Terms §7(B)). Where the Controller connects a Google Ads account, this DPA is the written contract with the Google Ads program customer required by §7(B)(i): it describes the processing, and Klirry confirms that it processes personal data in line with the Controller's own obligations under Google's applicable data protection terms (§7(B)(ii)) — only to deliver the Services, with no onward use, sale or use for benchmarks or AI training.
Shopify, Meta and others. Platform data is used only for the Controller who connected it, is kept separate from every other customer's data and is not used across customers.
Execution
This DPA forms part of, and is entered into when the Customer accepts, the Terms of Service (including acceptance during sign-up or when installing from Shopify); no separate signature is required. A Customer that needs a signed copy can request one at privacy@klirry.com.
Annex 1 — Data Subjects and Personal-Data Categories
A1.1 Categories of Data Subjects
| Category | Description | Notes |
|---|---|---|
| Account users | The Customer's staff who access the Klirry dashboard | Work email only (no name field). Controller scope; shown for information (A1.4). |
| End consumers | The Customer's store customers whose orders are imported | No direct contact details (name, email, phone, address) imported. Order records remain pseudonymised personal data that the Controller can re-link. See A1.2. |
A1.2 Personal Data Categories — Order Data
| Field | Category | Purpose | Notes |
|---|---|---|---|
| External order ID | Pseudonymised identifier | Deduplication and upsert | Pseudonymised personal data: the Controller can look it up in its store to reach a named person |
| Order number | Pseudonymised identifier | Reference in the dashboard and the export | Same as above |
| Order date and time | Temporal | Period aggregation | ISO 8601 |
| Destination country | Geographic (country level) | VAT lookup | Country only — nothing below country level |
| Currency, order total, VAT amount, shipping charged, discount | Financial | Profit computation | Integers in minor units |
| Payment method name | Operational | Payment-fee allocation | For example "klarna", "card" — no card numbers |
| Shipping method name; tracked-shipping flag | Operational | Shipping-cost allocation | Free-text name passes a personal-data filter |
| Financial status, fulfilment status, refunded amount | Operational / Financial | Net revenue, refund handling | |
| Line items: SKU, title, quantity, unit price | Operational | Cost-of-goods allocation | Free-text title passes a personal-data filter |
Campaign parameters from the landing URL: utm_source, utm_medium, utm_campaign, utm_content | Marketing | Ad attribution | Free text |
fbclid_present, gclid_present | Marketing | Ad attribution | Present/absent booleans; the click identifier itself is never stored |
tracking_hmac | Pseudonymised identifier | Matching carrier invoices to orders | A keyed per-customer HMAC of the carrier tracking number; the number itself is not stored; cleared 180 days after the order date |
| Payment-provider settlement records (Stripe, Klarna, PayPal) | Financial | Actual payment fees per order | Provider, charge reference, fee amount, currency, capture time; from the provider's API or an uploaded file (for example Klarna settlement) |
| Carrier invoice lines (PostNord, DHL, GLS) | Financial | Actual shipping cost per order | Carrier, invoice reference, cost, currency, matched through tracking_hmac; uploaded by the Controller |
| Advertising data (Meta, Google Ads; TikTok when available) | Marketing | Ad spend and performance | Campaign, ad set and ad identifiers and names, spend, clicks, impressions per day; no data about the people who see the ads |
| Google Analytics 4 summary data (when connected) | Marketing | Directional signal only | Aggregated sessions and conversions; never included in the profit figure |
| Cost settings entered by the Controller | Operational | Profit computation | Not personal data about end consumers |
A1.3 Explicit negative list — data NOT collected
Excluded at the adapter query level (not fetched, not mapped, not dropped after fetch):
- Customer name, email, phone, address (street, zip, city, postal code)
- IP address, user agent, browser details of end consumers
- Raw carrier tracking numbers and raw click identifiers
- Sub-country geographic data
- Swedish personal identity numbers or equivalents
- Payment card numbers or bank details
- Staff or seller names on refunds
- Custom attributes, order notes and other free-text customer-facing fields (except the product
title, which passes the personal-data filter)
These exclusions are enforced in Klirry's data-ingestion code, not by policy alone.
A1.4 Account Data (controller scope, for information)
| Field | Notes |
|---|---|
| Work email address | Login identifier |
| Password (argon2id hash) | Hash only |
| Role (owner / member) | Access control |
| TOTP secret (AES-256-GCM encrypted) | If two-factor authentication is on |
| Audit log entries | Action, acting user, time, scrubbed metadata |
Account Data is processed by Klirry as controller and is outside this DPA's Article 28 scope.
Annex 2 — Technical and Organisational Measures (TOMs)
The following controls are implemented as of the date of this DPA.
| # | Control | Implementation |
|---|---|---|
| 1 | Encryption at rest — credentials | AES-256-GCM with random 12-byte IV; keys stored separately from data |
| 2 | Tenant isolation — Row Level Security | PostgreSQL RLS on all tenant tables; missing context → zero rows; an RLS test suite runs before every release |
| 3 | Authentication | argon2id password hashing; common-password block; optional TOTP |
| 4 | Rate limiting | Sliding-window Redis rate limits on all auth endpoints |
| 5 | PII-free ingestion | Adapters never fetch customer names, emails, addresses or phones; a personal-data filter is a second line of defence |
| 6 | PII-free logging | Central logger scrubs email and token patterns before output |
| 7 | EU data residency | Production database and application run on Hetzner infrastructure in Germany. Error monitoring uses an EU data location of a US provider (Annex 3, with standard contractual clauses); email delivery uses an EU provider |
| 8 | Backups | Encrypted (age) database dumps are taken and restore-verified before every release and pruned after 14 days. A scheduled nightly off-site copy to a Hetzner Storage Box (at most 30 days) is prepared and not yet in operation; this row is updated when it is |
| 9 | Access audit log | Every auth, admin and cost-write action recorded in an append-only audit log; support impersonation is logged |
| 10 | Secret scanning | gitleaks pre-commit hook and in the pre-release test run; custom rules for platform keys |
| 11 | Dependency vulnerability scanning | pnpm audit --audit-level=high in the pre-release test run |
| 12 | Security headers | CSP, HSTS, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy |
| 13 | CSRF protection | Sec-Fetch-Site / Origin check on all mutating endpoints |
| 14 | Input validation | Zod schema validation on all API inputs; body size limit |
| 15 | Offboarding procedure | Checklist for revoking access when a person leaves |
| 16 | Incident response | Written procedure with the 24/48/72-hour clocks and an incident register |
| 17 | Release gate | Every release passes the full test run (lint, types, unit, RLS, integration, end-to-end) and a restore-verified backup before it is deployed |
Klirry may strengthen these measures at any time but will not materially reduce them.
Annex 3 — Sub-processors
| Sub-processor | Purpose | Region | Personal data | Status |
|---|---|---|---|---|
| Hetzner Online GmbH | Cloud hosting: servers, database, storage volumes and encrypted backups | Germany (Falkenstein) | All Order Data and Account Data | Engaged |
| Scaleway SAS | Transactional email only: account, security, trial-reminder and notice mail (never marketing) | France (Paris, fr-par) | Email addresses of the Customer's users and the content of the messages sent to them | Not yet engaged; 30-day notice (3.3) |
| Functional Software, Inc. (Sentry) | Error monitoring and crash reporting | EU data location (de.sentry.io); the provider is a US company | Scrubbed stack traces and tenant or user identifiers (UUIDs); no personal data by configuration (a beforeSend filter removes personal data, including Swedish personal identity numbers) | Not yet engaged; 30-day notice (3.3) |
A provider marked "Not yet engaged" is added only after the notice in Section 3.3, under a written agreement that meets Section 3.2a, and only if it processes data in the EU/EEA or under a valid Chapter V mechanism (Section 2.4).
Annex 4 — Connected platforms (data sources you choose)
The platforms below are the Customer's own: the Customer chooses to connect them and Klirry reads from them (or, for a messaging destination, sends to them) on the Customer's documented instruction under this DPA. They are data sources and destinations chosen by the Customer, not sub-processors of Klirry: Klirry does not engage them to process the Customer's data. Access is read-only wherever the table says so, and the Customer can revoke it at any time in the way the last column describes.
| Platform | Role | What Klirry reads or sends | Access | How you revoke access |
|---|---|---|---|---|
| Shopify | Source platform and payment channel. Shopify Inc. (Canada) and Shopify Commerce Singapore Pte. Ltd. are Klirry's counterparties under the Partner Program Agreement; the merchant contracts with Shopify International Limited (Ireland). Klirry reads orders and products with the scopes read_orders and read_products; Shopify is an independent controller of its own data and not a sub-processor of Klirry. | Orders and products (scopes read_orders and read_products). No customer name, email, address or phone is stored | Read-only | Uninstall the app in your Shopify admin, or disconnect it in Klirry under Settings, Connections (Klirry stops reading at once) |
| Meta | Source platform for ad spend and performance (permission ads_read). Meta is an independent controller; Klirry is not Meta's processor and Meta is not Klirry's sub-processor. | Ad spend and performance per ad account (permission ads_read) | Read-only | Remove Klirry from the connected apps in your Meta business settings, or disconnect it in Klirry under Settings, Connections (Klirry stops reading at once) |
| Source platform for Google Ads spend (planned) and Google Analytics 4 as a directional signal (planned, never in the profit figure). Google is an independent controller. | Google Ads spend and Google Analytics 4 sessions (both planned; never part of the profit figure) | Read-only | Remove Klirry from the third-party access of your Google account, or disconnect it in Klirry under Settings, Connections (Klirry stops reading at once) | |
| TikTok | Planned source platform for ad spend. Not connected today. TikTok is an independent controller. | Ad spend (planned; not connected today) | Read-only | Remove Klirry in your TikTok business settings, or disconnect it in Klirry under Settings, Connections (Klirry stops reading at once) |
| WooCommerce | Prepared, not offered to customers yet. Source platform: your own WooCommerce store, which you host. Klirry calls the store's REST API at the address you enter. The store owner is the controller; Klirry is not the store's processor and the store is not Klirry's sub-processor. | Orders and their line items from the store's REST API. No customer name, email, address or phone is stored | Read-only (a read key you create) | Delete the REST API key in WooCommerce (Settings, Advanced, REST API), or disconnect it in Klirry under Settings, Connections (Klirry stops reading at once) |
| PrestaShop | Prepared, not offered to customers yet. Source platform: your own PrestaShop shop, which you host. Klirry calls the shop's Webservice at the address you enter. The shop owner is the controller; Klirry is not the shop's processor. | Orders and their lines from the shop's Webservice. No customer name, email, address or phone is stored | Read-only (a Webservice key you create) | Delete the key under Advanced Parameters, Webservice in PrestaShop, or disconnect it in Klirry under Settings, Connections (Klirry stops reading at once) |
| Shopware 6 | Prepared, not offered to customers yet. Source platform: your own Shopware 6 shop. Klirry calls the shop's Admin API at the address you enter. The shop owner is the controller; Klirry is not the shop's processor. | Orders and their lines through a search request (a read; no change is ever sent). No customer name, email, address or phone is stored | Read-only (an integration you create) | Delete the integration under Settings, System, Integrations in Shopware, or disconnect it in Klirry under Settings, Connections (Klirry stops reading at once) |
| BigCommerce | Prepared, not offered to customers yet. Source platform. BigCommerce is an independent controller of its own data; Klirry is not its processor and BigCommerce is not Klirry's sub-processor. | Orders (v2 REST API). No customer name, email, address or phone is stored | Read-only (a store-level API account with Orders read-only scope) | Delete the API account in your BigCommerce store, or disconnect it in Klirry under Settings, Connections (Klirry stops reading at once) |
| Wix | Prepared, not offered to customers yet. Source platform. Wix is an independent controller of its own data; Klirry is not its processor and Wix is not Klirry's sub-processor. | Orders (eCommerce Orders search, a read). No customer name, email, address or phone is stored | Read-only (an API key with the Read eCommerce Orders permission) | Delete the API key in your Wix account, or disconnect it in Klirry under Settings, Connections (Klirry stops reading at once) |
| Quickbutik | Prepared, not offered to customers yet. Source platform. Quickbutik is an independent controller of its own data; Klirry is not its processor and Quickbutik is not Klirry's sub-processor. | Orders through the store API (JSON GET only). No customer name, email, address or phone is stored | Read-only (the store API key you create) | Delete or regenerate the API key in your Quickbutik account, or disconnect it in Klirry under Settings, Connections (Klirry stops reading at once) |
| PayPal | Prepared, not offered to customers yet. Source of payment fees. PayPal is an independent controller of its own data; Klirry is not its processor and PayPal is not Klirry's sub-processor. | Transactions and their fees from the Transaction Search report. No payer name or email is stored | Read-only (a REST app you create with Transaction Search) | Delete the REST app in the PayPal developer dashboard, or disconnect it in Klirry under Settings, Connections (Klirry stops reading at once) |
| Stripe (your own Stripe account) | Prepared, not offered to customers yet. Source of payment fees from the Stripe account YOU hold with Stripe. This is a different relationship from Klirry's own use of Stripe to bill its customers (see the vendor list): here Stripe is an independent controller of your account data and Klirry only reads it. | Charges and balance transactions, to learn the real fees. No cardholder or customer detail is stored | Read-only (a restricted key with Charges: Read and Balance Transactions: Read) | Delete the restricted key in your Stripe dashboard (Developers, API keys), or disconnect it in Klirry under Settings, Connections (Klirry stops reading at once) |
| Slack (your own workspace) | A destination YOU choose: if you paste an incoming-webhook URL of your own Slack workspace, Klirry posts alerts there in addition to email. Klirry has no Slack workspace of its own that receives customer data. Slack is an independent controller of the messages in your workspace; it is not a sub-processor of Klirry. | Nothing is read. Klirry sends the decision sentence of an alert email and a link to the decisions page, to the webhook you set up | Send only, to your own webhook | Delete the incoming webhook in Slack, or remove the Slack address in Klirry under Settings |
Changelog
Each entry names the version, the date it was written, and what changed. A change of the major version number is a material change: it is announced to customers by email at least 30 days before it takes effect.
| Version | Date | Change |
|---|---|---|
| 1.0 | 2026-10-10 | First published version. |
| 1.1 | 2026-10-11 | Annex 4 (connected platforms) added; the retention table completed with new classes; Stripe marked as planned until live mode. Minor change: no customer is in live mode yet, no sub-processor is added, and periods only get shorter or are new classes, so there is no 30-day notice. |