Privacy Policy

For the data described below, Agentible is the controller: we decide why it is held and what happens to it. Our registered name, address, commercial registry entry and VAT number are published on our Legal Notice page.

We have to be straight with you about one thing. Some of those identity details are not published yet, and the Legal Notice page says which and why rather than inventing them. The contact addresses below are real and monitored in the meantime.

There is a second relationship, and it is worth separating. For the product data we process on your store's behalf, you are the controller and we are your processor. That relationship is governed by our Data Processing Agreement, not by this policy.

For anything about your personal data, email privacy@agentibleapp.com. We have not appointed a data protection officer; that address reaches the people who can act.

We would rather show you the database than summarise it. Below is every table we hold that can contain personal data, what is in it, why, on what lawful basis under Article 6 of the GDPR, and what actually deletes it. A test fails our build if a table is added to the database and does not appear here.

We never request access to your orders or customers, on any plan, so your shoppers' personal data is not in this list and never reaches us.

• stores: Your Shopify store domain and store name, the owner email address Shopify gives us, your encrypted Shopify access token, your plan and billing identifiers, your referral code, and a copy of how the visit that led to the install arrived on our site (campaign, referring URL, and the Google or Meta click identifier if there was one).

  Whose: The merchant who installs the app, and the person who runs the store. Why: Running the app for you: knowing which store you are, reaching you, and charging you. Lawful basis: 6(1)(b) contract; 6(1)(f) legitimate interests. The store, account and billing columns are the contract. The arrival copy is not: it is there so we can tell which of our own adverts produced a customer, which is our interest and not a term of your contract, so it is legitimate interests and you can object to it. How long: Deleted 30 days after you uninstall, by a scheduled sweep, or sooner if you ask.

• store_settings: Your brand tone, the words you asked us to avoid, the facts you asked us to include, your theme choice, and which emails you want.

  Whose: The merchant. Why: Remembering your preferences. Lawful basis: 6(1)(b) contract. Worth saying plainly, because it is our defect and not yours: brand tone, words to avoid and facts to include are stored and read back into the settings screen, and nothing else in the product reads them today. They are not sent to Anthropic and they do not change what Claude writes. We are recording that here rather than letting the collection look purposeful. How long: Deleted with your store.

• products: Your product titles, descriptions, handles, vendor, GTIN, price, images, media and alt text, SEO title, meta description, structured data and attributes, read from Shopify.

  Whose: The merchant, and anyone a merchant has named in their own product text (a founder, a formulator, a photographer). Why: The raw material we audit and improve. Lawful basis: 6(1)(b) contract. Product copy is usually not personal data. It becomes personal data when a merchant writes a person into it, which we cannot prevent and do not filter, so the table is listed rather than excluded. How long: Deleted with your store.

• scans: When a scan ran, what it scored, which checks failed, which agent ran it, whether you or our scheduler started it, and any error text.

  Whose: The merchant. Why: Showing you your results and running the weekly re-scan. Lawful basis: 6(1)(b) contract. How long: Deleted with your store.

• issues: The issues a scan found on your store, their descriptions, and why you dismissed one if you did.

  Whose: The merchant. Why: Showing you what to fix. Lawful basis: 6(1)(b) contract. How long: Deleted with your store.

• fixes: The product copy before our change and after it, who edited it, which agent produced it, and any error.

  Whose: The merchant, and anyone named in the product copy being rewritten. Why: Letting you review a fix before it is published, and reverse it afterwards. Lawful basis: 6(1)(b) contract. How long: Deleted with your store.

• write_log: Every write we made to your Shopify store, with the value before and the value after.

  Whose: The merchant. Why: So a change can be proven and reversed. It is the record behind the promise that every write is undoable. Lawful basis: 6(1)(b) contract; 6(1)(f) legitimate interests. How long: Deleted with your store.

• activity: A short message per event, shown in your activity feed.

  Whose: The merchant. Why: Telling you what happened and when. Lawful basis: 6(1)(b) contract. How long: Deleted with your store.

• alerts: Which alerts you switched on and which channel you want them through.

  Whose: The merchant. Why: Sending only the alerts you asked for. Lawful basis: 6(1)(b) contract. How long: Deleted with your store.

• usage_periods: How many fixes you have generated in the current billing period, and your limit.

  Whose: The merchant. Why: Enforcing your plan's quota. Lawful basis: 6(1)(b) contract. How long: Deleted with your store.

• visibility_samples: Whether an assistant cited your store for a sampled question, and how large the sample was.

  Whose: The merchant. Why: The sampled visibility signal. Lawful basis: 6(1)(b) contract. Listed for completeness rather than because it is active: nothing in the product writes to this table today, which is why the Trust Center no longer advertises the measurement. How long: Deleted with your store.

• questions: The text of a visibility question and, where a merchant suggested it, a link back to the store that did.

  Whose: The merchant, indirectly. Why: Running the same question set across stores in a vertical. Lawful basis: 6(1)(f) legitimate interests. How long: The question is kept, because it is shared across stores. The link to the store that suggested it is removed when that store is deleted.

• invoices: What you were charged, for which plan, on which rail, the charge identifier, the Shopify invoice link, the unit price at the time, and whether it was refunded or charged back.

  Whose: The merchant. Why: Billing you, and being able to account for what we charged. Lawful basis: 6(1)(b) contract; 6(1)(c) legal obligation. JUDGEMENT (2026-08-07): kept under a legal obligation to retain accounting records. Portuguese law requires supporting accounting documents to be kept for ten years (Codigo do IRC art. 123). Whether every column here is part of that record, and whether ten years is the operative period for a service of this kind, has not been confirmed with an accountant. Needs review. How long: Kept after your store is deleted, with the link to your store removed, for as long as tax and accounting law requires. Deleting it would silently restate a closed accounting period.

• mrr_events: That a subscription started, changed or ended, and the revenue movement it caused.

  Whose: The merchant, indirectly. Why: Our own revenue reporting. Lawful basis: 6(1)(f) legitimate interests. How long: Kept after your store is deleted, with the link to your store removed, for the same reason as invoices.

• ai_usage: How many tokens a Claude call used, which model, and which store it was for.

  Whose: The merchant, indirectly. Why: Knowing what the product costs us to run. Lawful basis: 6(1)(f) legitimate interests. How long: The link to your store is removed when your store is deleted. The usage row itself is kept and has no deletion schedule.

• store_events: That a store reached a milestone: installed, first scan, first fix, subscribed, cancelled, uninstalled.

  Whose: The merchant, indirectly. Why: Understanding where people get stuck. Lawful basis: 6(1)(f) legitimate interests. How long: The link to your store is removed when your store is deleted. The milestone row is kept.

• audit_leads: The site address you gave us and its domain, your email address if you gave one, a secret token that opens your report, the issues we found, and how you arrived on our site (campaign, referring URL, and the Google or Meta click identifier if there was one).

  Whose: Anyone who runs the free audit. Why: Running the audit you asked for, showing you the report, and emailing it to you. Lawful basis: 6(1)(b) contract; 6(1)(f) legitimate interests. The audit itself is Art. 6(1)(b): you asked for it, and it is a step taken at your request before any contract. The arrival record is legitimate interests, and you can object to it separately without losing the audit. How long: The report link stops working 30 days after the audit. THE ROW ITSELF IS NOT YET DELETED ON A SCHEDULE, which means your email address and the audit result stay in our database until you ask us to remove them. We are stating this rather than implying an expiry we do not run.

• audit_entitlements: The domain, and the account that claimed it.

  Whose: Anyone who has spent a domain's free audit. Why: Keeping the promise that the free audit is one per store, forever, without letting it be run repeatedly. Lawful basis: 6(1)(f) legitimate interests. JUDGEMENT (2026-08-07): a claim that never expires needs a permanent record, and a permanent record sits awkwardly with storage limitation (Art. 5(1)(e)). We have chosen to keep it and to de-identify it rather than delete it, because deleting it would hand out a second free audit for the same domain. If somebody asks us to erase their account, the account link is removed and the domain claim stays. Needs review. How long: Permanent by design. If you ask us to erase your account, the link to you is removed and the domain claim remains without you attached to it.

• audit_rate_limits: The IP address the request came from, and the domain requested.

  Whose: Anyone who runs the free audit. Why: Stopping one person running thousands of audits. Lawful basis: 6(1)(f) legitimate interests. How long: Deleted after 30 days by a nightly job.

• rate_limit_hits: The IP address of the caller, and, for a sign-in request, a one-way SHA-256 digest of the mailbox rather than the address itself.

  Whose: Anyone who submits a form or asks for a sign-in link. Why: Rate limiting the handful of routes anyone can reach without signing in. Lawful basis: 6(1)(f) legitimate interests. How long: Deleted after 30 days by the same nightly job.

• waitlist: Your email address, which list you joined, your store URL if you gave one, and how you arrived on our site (campaign, referring URL, and the Google or Meta click identifier if there was one).

  Whose: Anyone who joins a waitlist, subscribes to the newsletter, or asks for their audit report by email. Why: Emailing you about the thing you signed up for. Lawful basis: 6(1)(a) consent; 6(1)(f) legitimate interests. The subscription itself is consent, and you can withdraw it at any time through the unsubscribe link, which works without signing in. The arrival record is legitimate interests. How long: NO AUTOMATIC DELETION TODAY. Unsubscribing stops the email and records a suppression, and the row stays until you ask us to remove it. We are saying so rather than writing a window nothing enforces.

• email_log: The address we sent to, which template, when, the provider's message id, whether it was delivered or bounced, and the data the email rendered (your score, your store name, links).

  Whose: Anyone we email: merchants, and people on a list. Why: Sending each email exactly once even if a trigger fires twice, and being able to see what a person was actually sent when they ask. Lawful basis: 6(1)(b) contract; 6(1)(f) legitimate interests. How long: Rows tied to a store are deleted with the store. Rows for a lead are NOT ON A DELETION SCHEDULE. This is the largest store of plain email addresses we hold, and it has no expiry today.

• email_suppressions: A one-way SHA-256 digest of the address. Not the address.

  Whose: Anyone who unsubscribed or hard-bounced. Why: Never emailing you again once you have told us to stop. Lawful basis: 6(1)(c) legal obligation. Art. 21(3) requires us to stop once you object, and the only reliable way to stop is to remember. The digest is unkeyed and one-way, so the list cannot be turned back into a mailing list. How long: Permanent by design. Deleting it would let us email you again, which is the opposite of what you asked for.

• store_deletions: A one-way SHA-256 digest of the store domain, why the deletion happened, whether it succeeded, and how many rows went. The domain in plain text only when the deletion FAILED, so we can retry it.

  Whose: The merchant whose store was deleted. Why: Being able to show that a deletion we promised actually happened. Lawful basis: 6(1)(c) legal obligation. Art. 5(2): we have to be able to demonstrate compliance, and a deletion with no record demonstrates nothing. How long: Permanent by design, and deliberately not linked to the store it records, so it outlives it.

• terms_acceptances: A one-way SHA-256 digest of the shop domain or the account id, which version of the Terms was accepted, the hash of that exact text, when, through which flow, and whether the acceptance was a ticked box or a notice next to the button. Deliberately NO IP address and no user agent.

  Whose: The merchant who installed the app, and the visitor who ran a free audit. Why: Being able to show which version of the contract somebody agreed to, if they later say they did not. Lawful basis: 6(1)(b) contract; 6(1)(f) legitimate interests. 6(1)(b) because the record IS the contract's formation; 6(1)(f) for keeping it after the store has gone, which is Art. 17(3)(e), the establishment or defence of legal claims. JUDGEMENT (2026-08-07): the IP address that a conventional click-wrap bundle would carry is deliberately absent, because an acceptance record has to outlive any dispute while lib/audit/retention.ts caps IP retention at 30 days and that number is printed in the privacy policy. Keeping one here would either break that promise or leave a scrubbed hole in the evidence. How long: Permanent by design. The links to the store and to the account are removed when either is deleted (ON DELETE SET NULL), so what survives an erasure is a digest, a version and a timestamp, with nothing in it that names a person.

• referrals: The code claimed, which store referred which, the status, and the reason a claim was rejected.

  Whose: A merchant who refers another, and the merchant referred. Why: Running the referral programme. Lawful basis: 6(1)(b) contract. How long: The links to both stores are removed when either store is deleted. The row is kept.

• referral_events: Each status change, when it happened, and the reason recorded for it.

  Whose: The merchants involved in a referral. Why: Being able to explain why a reward was granted, refused or clawed back. Lawful basis: 6(1)(b) contract; 6(1)(f) legitimate interests. How long: These rows CANNOT be changed or deleted: the database refuses both. That is deliberate, so a reward decision cannot be quietly rewritten, and it means a referral event survives an erasure request. It carries no email address and no name.

• store_credits: The amount, the currency, what kind of credit it was, and the reason.

  Whose: The merchant credited. Why: Applying a referral reward and clawing it back if the referred store refunds. Lawful basis: 6(1)(b) contract. How long: The link to your store is removed when your store is deleted. The credit row is kept, for the same accounting reason as invoices.

• admin_users: The administrator's email address, their role, and whether access was revoked.

  Whose: Our own administrators. Why: Deciding who may open the support console. Lawful basis: 6(1)(f) legitimate interests. How long: Revoking access sets a timestamp; the row and the address stay, so a past action in the audit trail still names somebody. No deletion schedule.

• admin_audit: Which administrator did what to which store, with the value before and after.

  Whose: Our own administrators, and the merchant whose store was acted on. Why: Being able to see what support did to a merchant's account. Lawful basis: 6(1)(c) legal obligation; 6(1)(f) legitimate interests. How long: Kept after the store is deleted, with the link to the store removed. An audit trail that disappears when the subject does is not an audit trail.

• partners: Your email address, a display name if you set one, your partner code, and once you withdraw money: your legal name, country, tax number, the account holder name and IBAN of your bank account, and the time your bank details last changed.

  Whose: A partner in the referral programme: a merchant, or a person with no store at all. Why: Running the partner programme and paying you: knowing who you are, wiring money to an account in your own name, and issuing the paperwork a payment requires. Lawful basis: 6(1)(b) contract; 6(1)(c) legal obligation. The identity and bank columns exist because tax and invoicing law requires them for a payment, not because we want them: they are collected at first withdrawal rather than at sign-up, and the exact retention the law demands is the accountant's question (increment 26, US-28-13). How long: Kept while your partner account exists. After a payout, the identity behind it is kept for as long as tax law requires, which we will state precisely once the accountant confirms the period. NO AUTOMATIC DELETION runs on this table yet.

• partner_ledger: Every cent the programme earned you, clawed back or paid out, each entry with its stated reason, tied to your partner record and to the referral it came from.

  Whose: The partner the money belongs to. Why: Computing what we owe you, and being able to show the arithmetic afterwards: a payout ledger that can be edited is not evidence of anything. Lawful basis: 6(1)(b) contract; 6(1)(c) legal obligation. How long: Append-only by design and never deleted. If you are erased, the entries stay with the identity detached: the amounts survive so a deletion can never restate what the programme paid, but they no longer name you.

• partner_reviews: That a routine review opened at a referral threshold, when, how it was resolved and by whom, and the stated reason.

  Whose: The partner under review. Why: The human look the programme takes at every multiple of twenty five referrals before more money leaves, and the record that it happened. Lawful basis: 6(1)(f) legitimate interests. Fraud prevention is the textbook recital 47 legitimate interest, and the review holds a payout rather than the partner's data or account. How long: Deleted with the partner record (the table cascades from it).

• partner_payouts: Each withdrawal request: the amount, its outcome, who resolved it, the bank reference of the wire, and the stated reason where one was refused.

  Whose: The partner who asked to be paid. Why: Paying you once per request, and evidencing that the wire happened. Lawful basis: 6(1)(b) contract; 6(1)(c) legal obligation. How long: Kept for as long as payment records must be kept under tax law; the precise period is stated once the accountant confirms it. NO AUTOMATIC DELETION runs on this table yet.

Two further tables exist and hold no personal data: seed_stores, processed_stripe_events. They are listed so that their absence above reads as a decision rather than an oversight.

This is the part the previous version of this policy did not mention at all, so it gets its own section rather than being left in the table above.

When you land on this site, your browser records in its own memory (a sessionStorage key, not a cookie) how you arrived: the campaign parameters in the link, the site that referred you, and, if you clicked one of our adverts, the click identifier that Google or Meta itself attached to the URL. It is discarded when you close the tab. Nothing is sent anywhere while you browse.

If you then give us your email address (a free audit, a waitlist, or the newsletter), that arrival record is stored alongside it, in audit_leads, waitlist or stores. That is how we tell which of our own channels produced a customer without putting an advertising tag on the site.

Google receives some of it. When one of those signups becomes a paying customer, we upload a file to Google Ads containing the click identifier Google itself created and the value of the plan bought. No name, no email address, no product data. Google decides for itself what it does with that, which is why it is listed on our Subprocessors page as a recipient rather than as one of our processors.

The lawful basis for all of this is legitimate interests (Art. 6(1)(f)): knowing which advert worked is what lets a business this small buy traffic at all. You can object. Email privacy@agentibleapp.com and we will delete the arrival record attached to you and stop uploading anything about you. Objecting does not affect your audit, your account or your subscription.

When you ask for a copy fix, we send Anthropic's API the product text we are rewriting, and only that: the product title, the description, the attributes we extracted from it, and, for an SEO fix, the current SEO title and meta description. Claude writes the draft and you approve it before anything is published.

Per Anthropic's commercial API terms, this data is not used to train models. We never send customer personal data, because we never read it, and we never send your name, your email address or your store domain.

A correction, because the earlier version of this page over-claimed. It said "the relevant product data and your settings are sent to Anthropic". Your settings are not sent, and never have been. Your brand tone, your words to avoid and your facts to include are stored, shown back to you on the settings screen, and read by nothing else in the product. That is a defect in the feature, and we are not going to describe it as a privacy practice.

See our Trust Center for detail on what we read and write.

The complete, current list is on our Subprocessors page, and it is generated from the same definition our code uses rather than written by hand. Each row of the table above names the ones that see that particular data.

We require each processor to protect your data and to process it only on our instructions. Google is on that page as a recipient, not a processor, because it decides for itself what it does with an advertising conversion upload, and calling it a subprocessor would describe a control we do not have.

We do not sell your data, and we do not use it for advertising to you.

Our database is in Supabase's European Union region. Several providers we depend on are not in the EU: Vercel, Anthropic, Resend, Stripe and Google are in the United States, and Shopify is in Canada and the United States. So personal data does leave the EEA, and pretending otherwise because the database is in Frankfurt would be misleading.

Each of those providers publishes a data processing agreement incorporating the European Commission's Standard Contractual Clauses, and several of them are certified under the EU-US Data Privacy Framework. What we have not yet done is confirm, in writing and on file, that we have accepted each of those agreements and checked each certification. That work is recorded in our internal transfer impact assessment and is open. We would rather tell you it is open than write a sentence implying it is closed.

Annex I of our Data Processing Agreement sets out the parties and the processing for the transfers we make on your behalf.

If the GDPR or the UK GDPR applies to you, you have the right to access your personal data, to have it corrected, to receive it in a portable form (portability), to have it erased, to restrict our processing of it, and to object to any processing we do on the basis of legitimate interests, which on this site means the advertising attribution described above.

Where we rely on your consent, you can withdraw it at any time, and withdrawing it is as easy as giving it. Every marketing email carries an unsubscribe link that works in one click without signing in. Withdrawing consent does not affect anything we did lawfully before you withdrew it.

To exercise any of these, email privacy@agentibleapp.com. We answer within one month, as Art. 12(3) requires.

There is no automated decision-making that produces a legal or similarly significant effect on you (Art. 22). The scores and issue lists the product generates are advisory and you decide what to do with them.

You also have the right to complain to a supervisory authority. In Portugal that is the Comissão Nacional de Proteção de Dados (CNPD); you may also complain to the authority where you live or work.

When you uninstall, your store data is deleted within 30 days by a scheduled sweep, and the deletion is recorded so we can show it happened. You can request immediate deletion at any time. The per-table detail is in the list above; this section covers the parts that need saying in words.

When you run a free audit we record the IP address the request came from, to stop the same person running thousands of them. We keep that IP address for 30 days and then delete it on a schedule. It is a coarse signal and not the main one: free audits are limited per store and per account, and neither of those needs your IP address.

Three tables have no deletion schedule today, and rather than write "we keep data only as long as necessary" over them, here they are: audit_leads, waitlist, email_log, partners, partner_payouts. They hold email addresses given to us for a waitlist, a newsletter or a free audit, the audit result itself, and the log of emails we sent. Ask us and they go. Building the schedule is open work, and until it exists this paragraph is the honest description.

Some records are kept on purpose after your store is gone: what we charged you (accounting), the fact that a deletion happened (so we can prove it), and a one-way digest of any address that asked never to be emailed again (so we can keep that promise). Those are named in the table above with the reason.

Agentible is sold to businesses running online stores. It is not directed at children, we do not knowingly collect personal data from anyone under 16, and if we learn that we have, we delete it.

When this policy changes, the date at the top changes with it. That is not a promise to be careful: the page content is hashed and checked against the date in our test suite, so an edit that leaves the date stale fails our build. Where a change affects merchants materially, we also notify active merchants by email.