Privacy Policy

Product: Sufflera — web application and Chrome extension Effective date: September 12, 2026 Last updated: September 12, 2026 Version: 1.0

1. Who we are and what this policy covers

The Sufflera Team (“we”, “us”, “Sufflera”) operates Sufflera — a business-to-business assistant for creators and messaging operators who handle high volumes of private correspondence on paid-content platforms.

We are the data controller for the data described in §4 as ours. Sufflera is not operated through a registered company. It is run by the individual or individuals trading as the Sufflera Team, who can be reached at privacy@sufflera.com. If a company is later registered to operate the product, this policy will be updated to name it.

This policy covers:

the web application at app.sufflera.com;
the Sufflera Chrome extension;
the backend API that serves both.

This policy does not cover OnlyFans, Fansly, Fanvue, or any other platform you use our product alongside. Those services are operated by third parties under their own terms and privacy policies. We are not affiliated with, endorsed by, or partnered with any of them.

Who our users are. Our product is sold to businesses and professionals (creators, agencies, and the operators they employ). It is not intended for consumers and not intended for anyone under 18.

2. Summary in plain language

We store the account data you register with, the creator personas you configure, and the CRM records you build — including the conversations you choose to bring into the CRM. Storing that history is the core function of the product: the assistant cannot write a relevant reply without it.
The extension reads the chat page you have open in your own browser to identify the conversation and to place text into the message box. It does not read pages outside the three supported platforms.
When you ask for a draft, the relevant context is sent to an external AI inference provider to generate that one reply. We do not train any model on your data, and we do not permit our provider to train on it.
We never receive or store your card details, bank details, or crypto wallet credentials. Payments settle on public blockchains to a payment node we run ourselves — there is no third-party payment processor. The blockchain transaction itself is public and permanent, and outside our control.
The referral programme records only dates, qualification status, and monetary amounts. A referrer never sees the name, email, or any personal detail of the people who signed up through their link.
We do not sell personal data, do not serve advertising, and do not embed third-party analytics or tracking SDKs in the extension.

The detail behind every one of these statements is below. Where a statement has limits, we state the limits rather than the headline.

3. Our role, and yours: controller and processor

This distinction determines who is responsible for what, and it matters more in this product than in most.

Category of data	Who decides why it is processed	Our role
Your account, users, billing, referrals, product telemetry	We do	Controller
Creator personas, CRM records, conversation history, and everything about the people you message	You do	Processor, acting on your instructions

You are the controller of the conversation data. You decide which conversations to bring into the CRM, what notes to record, and how long to keep them. Accordingly, you are responsible for having a lawful basis for that processing, for informing the people you correspond with where the law requires it, and for honouring their rights. Our Data Processing Addendum (available on request at privacy@sufflera.com) governs that relationship and lists our sub-processors.

We process that data only to provide the service to you, and we do not use it for our own purposes.

4. Information we collect

4.1 Account and identity data (we are controller)

Collected when you register, are invited to a team, or sign in with Google:

email address (required; it is your login identifier);
password, stored only as an Argon2id hash — we never store or can read your plaintext password;
Google account identifier and verified email, if you use Google sign-in;
display name and interface language, if you set them;
your role and permissions inside your account, and which creators you are assigned to;
personal working preferences (draft-translation switch, auto-draft delay and quota floor, notification opt-outs);
optional additional email addresses you nominate to receive notifications. These are not verified by us; only add addresses you are authorised to use.

4.2 Creator configuration (you are controller)

Everything you enter to configure an AI persona: display name, persona description and backstory, tone of voice, allowed and banned topics, example replies, catchphrases, temperament, schedule, goals, timeline events, quick replies, avatar image, and the platform username of the creator account.

Some of these fields describe a real person (for example, a live creator’s age, location, appearance, or routine). Treat them as personal data and enter only what you are entitled to enter.

4.3 Data about the people you message (“Fan Data”) — you are controller

We must be direct about this, because the product cannot work otherwise. When you use the CRM, or when the extension syncs a conversation at your instruction, the following is stored on our servers:

the platform-scoped identifier of the conversation or account (for example, the chat id in the URL, or the handle shown on the page);
the display name or handle exactly as the platform shows it;
the content of messages in that conversation, inbound and outbound, together with the direction, the clock time printed by the platform, and a sort order;
notes, tags and instructions you write about that person;
an AI-maintained summary of durable facts drawn from the conversation, so that context is not lost when older messages fall outside the model’s window;
monetary records you record — tips, pay-per-view purchases, subscriptions, and the lifetime total derived from them;
follow-up reminders you schedule;
images you choose to upload to that person’s album;
derived signals: conversation stage, warmth, closeness, detected language, and per-conversation automation settings.

What we do not do:

We do not ask for, and the product has no field for, a fan’s legal name, postal address, telephone number, email address, government identifier, payment card, or crypto wallet.
We do not attempt to resolve a platform handle to a real-world identity, and we do not enrich, cross-reference, or link fan records against any external data source.
We do not build profiles of these people for our own purposes, do not share their data with advertisers or data brokers, and never sell it.
We do not access conversations you have not opened or synced. The extension has no capability to enumerate an account’s messages on its own.

Nevertheless, a handle plus the content of a private conversation is personal data under GDPR and similar laws. We do not pretend otherwise, and §12 sets out the rights available and how to exercise them.

4.4 Generated drafts and quality records (you are controller)

For each draft the assistant produces we store: the input it was given, the draft it returned, your final edited version if you record it, an optional 👍/👎 rating, the media item suggested (if any), and technical metadata — model identifier, latency, token counts, quota cost, prompt version and a hash of the assembled prompt, plus the automated safety and review outcome as stable codes only.

Two diagnostic fields — the raw model response and the fully assembled prompt — can contain the conversation text and persona details verbatim. They are written only when the DRAFT_DEBUG_RAW debugging switch is enabled, which is off in production, and they are erased by the retention job described in §11 regardless of whether the switch was on when the record was written.

Safety and integrity events are recorded without the offending text: only issue codes, severity, stage, attempt count and outcome.

4.5 Billing data (we are controller)

We store: your balance, the two numbers your subscription is made of (creators allowed and drafts per month), your draft counters (how many are left and how many have been used in total), your billing status and renewal date, any change you have scheduled, any individually agreed rate card, and a ledger of transactions containing the amount, type, status, timestamp and the payment provider’s invoice identifier. We also keep a daily record of the two draft counters so we can show you your own usage over time.

We never receive, process, or store card numbers, bank details, private keys, seed phrases, or any other payment credential.

Payments are made in cryptocurrency to an invoice address generated by a BTCPay Server instance we operate ourselves. There is no third-party payment processor between you and us: our server records only the invoice identifier, the amount, and the status that invoice reached.

Two consequences follow, and we state them plainly rather than in a footnote:

Because these payments settle on public blockchains, the transaction itself — sending address, amount and time — is publicly visible and permanently recorded on a ledger we do not control. We cannot erase, amend or reverse a blockchain record, and a deletion request cannot reach it.
To notice that an invoice has been paid, our payment node reads the chain through a blockchain RPC provider. That provider sees the invoice addresses we watch and the transactions to them. It receives no account, identity, or conversation data, and cannot connect an address to you.

4.6 Referral programme data (we are controller)

Each user may be issued one permanent 8-character invite code. When someone registers through it we record a referral row containing: the referrer’s account and user identifier, the code used, the internal account identifier of the new account, the status (pending, qualified, void), the percentages frozen at registration, the creation and qualification timestamps, and — once a qualifying payment occurs — a text description of the subscription bought (its two numbers, e.g. “5 creators / 3000 drafts”), the currency, the full monthly subscription price, the discount applied, the amount charged, and the reward credited.

No name, email address, or any other personal detail of a referred customer is stored on the referral record or returned by the referral API at any access level. A referrer sees only counts, dates, statuses and monetary totals. This is enforced on the server, in the database query itself, so the data is not present in the network response at all — not hidden in the interface.

Users with billing permissions additionally see aggregated, per-referrer totals for their own account. They still never see who was referred.

Consent records: document type, version, timestamp, and the IP address and user agent of the acceptance — evidence that terms, the AI disclaimer, and high-autonomy sending consent were accepted. Append-only.
Audit log: account, acting user (or “system”), action, resource type and identifier, timestamp, IP address, user agent, and limited structured context such as an amount or a reason code. We log changes, not views.
Server logs and error monitoring: request metadata, timing, error stack traces and request identifiers, used to keep the service running and to diagnose faults. Error reports may be sent to Sentry (see §9).
Session records: refresh-token identifiers held in Redis so that sessions can be revoked.

4.8 What the extension stores in your browser

Stored locally through the Chrome storage API, on your machine:

your access and refresh tokens, and the API address;
the creator you are currently acting as, and the interface language and theme;
per-tab working state: the identified conversation, the pending draft, your edits and one-off instructions;
the autopilot state and its activity journal (up to 300 entries, containing the conversation name and the text that was sent), the auto-send journal, and the retry queue;
history-collection progress markers, and a cache of your quick replies.

This data stays in your browser. It is removed when you sign out of the extension, clear the extension’s storage, or uninstall it. Uninstalling the extension does not delete data already stored on our servers — use the deletion routes in §12 for that.

4.9 What we never collect

Browsing history, page content, or activity on any site other than the three supported platforms and our own API. The extension’s content script is restricted at the manifest level to onlyfans.com, fansly.com and fanvue.com.
Keystrokes, screenshots, clipboard contents, microphone or camera input, precise geolocation, or contact lists.
Your platform account password. The extension never reads platform credentials and never authenticates to a platform on your behalf; it works inside the session you have already opened yourself.
Advertising or cross-site tracking identifiers. The extension contains no analytics, advertising or tracking SDK of any kind, and makes no network request to any host other than our own API.

5. How the Chrome extension works

Single purpose. The extension exists to help an authorised operator draft and send replies in a conversation they already have open on a supported platform, using context from their own CRM.

Local execution. All page interaction happens locally, inside your browser. A content script running on the open tab reads the visible conversation using CSS selectors to determine who the conversation is with, which messages are inbound and outbound, and where the message box and send button are. It writes the finished text into that message box. Page content is parsed in the browser; no page is uploaded wholesale, no screenshot is taken, and no remote code is fetched or executed.

What leaves your browser, and when. Content is transmitted to our backend only for these actions, all of which follow from your use of the product:

Action	What is sent
Generate a draft	the pending inbound messages, the identified conversation, your optional instruction
Sync conversation history	the messages read from the page, with direction and printed clock time
Record a sent reply	the text that was sent
Identify a conversation	the platform-scoped identifier and displayed name

Permissions and why each is needed:

Permission	Why
`activeTab`	act on the tab you are currently working in
`storage`	keep your session, current creator and per-tab draft state locally
`sidePanel`	render the workspace beside the page instead of covering it
`alarms`	retry a failed draft in the background after a delay
Host access to `onlyfans.com`, `fansly.com`, `fanvue.com`	read the open conversation and insert the reply
Host access to our API	send drafts and CRM data to your account

Automation and human oversight. Automatic sending is off by default. Every account starts at the manual level, and automatic sending additionally requires a separate, explicit activation in the side panel that applies to one browser tab and stops when that tab is closed, the page is reloaded, or the browser restarts. You are responsible for ensuring your use complies with the terms of the platform you use it on.

Chrome Web Store Limited Use disclosure. Our use of data received through the extension adheres to the Chrome Web Store User Data Policy, including the Limited Use requirements. Specifically, we use the data only to provide and improve the single purpose stated above; we do not transfer it to third parties except to the sub-processors listed in §9 (and where legally required); we do not use or transfer it for advertising, ad personalisation, or credit or lending assessment; and we do not allow humans to read it except with your explicit consent, for security or legal purposes, or where the data is aggregated and de-identified.

6. How we use information, and our legal bases

Purpose	Data used	Legal basis (GDPR Art. 6)
Provide the service — accounts, CRM, drafting, sending	§4.1–4.4	Performance of a contract
Generate a reply on request	conversation context, persona, CRM record	Contract; for fan data, processed on your documented instructions as processor
Enforce the limits of your subscription and bill it	§4.5, draft counters	Contract
Operate the referral programme	§4.6	Contract; legitimate interests in running a referral scheme
Keep the service secure; prevent abuse and fraud	§4.7	Legitimate interests; legal obligation
Evidence of consent for terms and high-autonomy sending	consent records	Legal obligation; legitimate interests
Service and security notifications	email, preferences	Contract; legitimate interests
Diagnose faults and improve reliability	technical metadata, error reports, safety codes	Legitimate interests
Comply with tax, accounting and legal duties	billing records	Legal obligation

We do not use your data, your CRM records, or the content of your conversations to train, fine-tune, or evaluate any machine-learning model of our own. Our internal quality-testing harness runs against a separate database seeded with fictional test fixtures, never against customer data.

We do not carry out advertising profiling, and we do not sell personal data.

7. AI processing: what is sent, what is kept

When a draft is requested, our backend assembles a prompt from the persona configuration, the recent conversation history, and the CRM context, and sends it to an external, OpenAI-compatible inference provider over an encrypted connection. The provider returns generated text, which is validated and returned to you.

Three points, precisely:

The prompt itself is transit data. In production configuration we do not retain the assembled prompt or the raw provider response: only the input text, the returned draft, a hash of the prompt, and technical metadata are stored on the draft record (§4.4). The debugging switch that would store them verbatim is disabled in production and its output is retention-wiped.
The underlying conversation is not transit data — it is stored. The message history, notes and AI summary that the prompt is built from live in your CRM and persist until you delete them or the retention rules in §11 apply. It would be inaccurate to describe the product as not storing conversations; storing them is what makes the assistant useful.
No training, by us or by our provider. We do not train models on your data. We contract with our inference provider on terms that exclude the use of submitted content for model training, and we configure the routing options available to us to exclude providers that reserve training rights. Because model routing can change, the current provider and its terms are stated in §9 and in the Data Processing Addendum, and material changes are notified under §14.

Self-hosted option. For customers with stricter requirements, the platform supports pointing inference at a self-hosted model server, in which case no conversation content reaches any third-party AI provider. Contact us to arrange this.

AI output is not reliable by default. Generated text may be inaccurate or inappropriate. Review before sending; where you enable automatic sending, you accept responsibility for what is sent under your account.

8. Automated decision-making

The assistant classifies conversations (stage, warmth, risk signals) and can, at levels you enable, send a message without a person approving that specific message. These processes affect the content of messaging, not legal or similarly significant matters concerning you. They are configured and switched on by you, can be disabled at any time, and every automated send is recorded in a journal available in the extension. We do not carry out automated decision-making with legal or similarly significant effects within the meaning of GDPR Art. 22.

We do not sell personal data. We disclose it only to:

Recipient	Purpose	Data
AI inference provider — currently OpenRouter (routing to upstream model providers) or a self-hosted server	generate the requested draft, translation, mood and summary calls	prompt content: persona, conversation excerpt, CRM context
Blockchain RPC provider — read-only node access for the payment networks we accept	let our own payment node see that an invoice was paid	invoice addresses and their on-chain transactions; no account, identity or conversation data
Hetzner Online GmbH — servers in Germany (EU)	run the application and database	all stored data, at rest
Sentry	server error monitoring	error traces, request metadata; may incidentally include identifiers
Transactional email provider — servers in the European Union	verification, password reset, invitations, notifications	recipient address and message content
Professional advisers, auditors, or an acquirer in a corporate transaction	legal and corporate necessity	as strictly required
Law enforcement or regulators	where legally compelled	as required by a valid legal request

A current, itemised sub-processor list with locations is available at privacy@sufflera.com and forms part of the Data Processing Addendum. We give notice of new sub-processors as provided there.

10. International transfers

Our infrastructure is hosted in Germany, within the European Union. Our sub-processors may process data outside your country, including outside the European Economic Area. Where that happens, we rely on the European Commission’s Standard Contractual Clauses (and the UK Addendum where applicable), together with supplementary technical measures such as encryption in transit and at rest. A copy of the relevant transfer mechanism is available on request.

11. Data retention

Data	Retained
Account, users, roles	while the account exists
Creator configuration	until you delete it, or the account is deleted
CRM records and conversation history	until you delete them — there is no automatic expiry, because history is the assistant’s working memory
Messages no longer visible on the platform	flagged as disappeared and excluded from prompts, but kept in the record unless deleted
Draft text and AI diagnostics	180 days. After that the input text, draft text, translation, raw response and assembled prompt are erased in place by a daily job, leaving only non-personal metrics (model, latency, token counts, your rating). The record of that a draft happened survives; the words do not
Safety and integrity events	retained as codes only; contain no message text
Billing ledger and consent records	as long as required by tax, accounting and limitation law, typically 7 years
Audit log	while the account exists, as evidence of account changes
Referral records	while the account exists
Server and error logs	short-term, typically up to 90 days
Extension local storage	until sign-out, storage clearance, or uninstall

Deletion is real for your operational data. When you delete your account, all CRM records, fan data, personas, and generated drafts are permanently purged. However, to comply with tax and accounting laws, strictly financial records (invoices, crypto payment receipts, and billing history) will be retained securely for up to 7 years.

Deleting a single fan record removes that person’s messages, purchases, reminders, media and drafts by database cascade, without affecting the rest of your account. Backups are overwritten on their normal cycle, typically within fourteen (14) days.

Draft text expires on its own. You do not have to ask for this and you cannot be relying on it not happening: the words of every generated draft, and the message that prompted it, are erased after 180 days whether or not you have deleted anything. Only the measurements stay — which model wrote it, how long it took, how many tokens it used and how you rated it. If you need the text of an old draft for a dispute, export it before then.

Retained financial records are kept for that legal purpose only: they are not used to provide the Service, are not profiled, and are accessible to a restricted set of personnel. They record amounts, dates, transaction type and the payment invoice identifier — not the content of your account.

Consent records are retained on the same basis: evidence of which document, at which version, was accepted and when, for as long as a related claim could be brought (GDPR Art. 17(3)(e), establishment and defence of legal claims). When an account is deleted we keep only the document type, its version and the date of acceptance — the IP address and browser user agent captured at the time are discarded, because once the account is gone there is nobody left to attribute them to.

12. Your rights

Depending on where you live, you have some or all of the following rights: access, rectification, erasure, restriction, objection, portability, and the right to withdraw consent without affecting processing already carried out. Under the CCPA/CPRA, California residents also have the right to know, to delete, to correct, to opt out of sale or sharing — we do neither — and to be free from discrimination for exercising these rights.

We do not sell or share personal information as those terms are defined by the CCPA/CPRA, and we have not done so in the preceding twelve months.

Several rights are exercisable directly in the product:

Right	How
Access and portability (your account)	Settings → Account → Export, returns your account data as JSON
Access and portability (one CRM record)	Export on the fan record, returning that person’s messages, purchases, reminders, media and drafts
Rectification	edit any field in the web application
Erasure (one record)	delete the fan record — the deletion cascades
Erasure (everything)	Settings → Account → Delete account
Restriction of automation	set the autonomy level to manual, or leave autopilot off
Withdraw notification consent	Settings → Notifications

For anything not covered above, contact privacy@sufflera.com. We respond within 30 days (extendable by a further 60 days for complex requests, with notice). We may need to verify your identity first.

If you are one of the people our customers correspond with: the customer is the controller of that data and decides its purposes; we hold it on their behalf. Direct your request to them where you can identify them. If you contact us instead at privacy@sufflera.com with enough detail to locate the record, we will pass the request to the relevant customer without delay and assist them in fulfilling it, as our Data Processing Addendum requires.

Complaints. You may lodge a complaint with your local supervisory authority. If you are in the EU, that is the authority in your country of residence, workplace, or the place of the alleged infringement; in the UK, the Information Commissioner’s Office.

13. Security

Measures in place include:

passwords hashed with Argon2id; plaintext passwords are never stored;
short-lived access tokens with rotating refresh tokens, server-side session revocation, and signing-key rotation support;
strict tenant isolation — every query is scoped to the account, and a request for another tenant’s record returns “not found” rather than revealing that the record exists;
role-based access control enforced on the server, with per-creator assignment for restricted roles; hiding a control in the interface is never the only protection;
AES-256-GCM encryption for sensitive stored secrets;
TLS in transit; security headers, request rate limits, request size limits and strict schema validation of all input;
append-only audit and consent journals;
financial operations executed under serializable transactions to prevent double-charging;
safety and integrity checks that record issue codes without storing the offending text.

No system is perfectly secure. Where a personal data breach is likely to result in a risk to individuals, we notify the competent supervisory authority within 72 hours of becoming aware of it and inform affected customers without undue delay.

14. Changes to this policy

We may update this policy as the product changes. The version number and “last updated” date at the top always reflect the current text. For material changes — in particular a new category of collected data, a new sub-processor with access to conversation content, or a new purpose — we notify account owners by email at least 30 days before the change takes effect and, where required, seek consent. Continued use after the effective date constitutes acceptance of the revised policy. Previous versions are available on request.

15. Contact


Service	Sufflera
Privacy enquiries and data-subject requests	`privacy@sufflera.com`
Data Processing Addendum and full entity details	available on request

This document describes the data practices of the Sufflera platform and Chrome extension as implemented at the effective date above. It is not legal advice; have it reviewed by qualified counsel in your jurisdiction before publication.