Privacy Policy

Effective date: 2026-11-14 · Last updated: 2026-11-11

This policy covers the PinSay feedback widget (<pinsay-feedback>), the PinSay dashboard, the PinSay browser extension, and the PinSay CLI (pinsay, used to install the widget and apply comments). PinSay can be run as a hosted service or self-hosted by an organization on its own server. When you use a self-hosted instance, that organization — not the operator of the hosted service — controls your data; this policy describes how the software handles data in either case. For the engineering-level view of what is captured, see Data & self-hosting.

1.Data controller

The hosted service at pinsay.dev (including the dashboard at app.pinsay.dev) is operated by PinSay, LLC, a Delaware limited liability company in the United States ("PinSay", "we", "us"). PinSay, LLC is the data controller for hosted-service accounts, for every hosted user wherever they are located. If your organization self-hosts PinSay, your organization is the data controller for your installation, not PinSay, LLC.

The address above is the registered office of our registered agent in Delaware. It is not where PinSay's servers are or where your data is stored (see Data residency), and it is not an office for visits: please write to support@pinsay.dev.

2.Legal basis (PDPL)

Hosted data is stored in Saudi Arabia (see Data residency), so we apply the Saudi Personal Data Protection Law (PDPL) where it applies to your data. Under the PDPL, we process account information and feedback content on the basis of legitimate interest — operating the feedback and annotation service you or your organization signed up for. Where a project enables the optional bug reports, we rely on your consent, given per comment, to collect that additional data.

3.Legal basis (GDPR section)

For users located in the European Economic Area, we additionally note the equivalent GDPR basis: legitimate interest (Art. 6(1)(f)) for operating the service, and consent (Art. 6(1)(a)) for optional bug reports. PinSay does not make an EU-residency promise — all data is stored in the Oracle Cloud Riyadh region regardless of where you are located (see Data residency below); this section exists so EEA-based users know which rights apply to them, not to promise EU storage.

4.What we collect

• Account information — email address, a hashed password, display name, and role, used to sign in and identify who left a comment.
• Feedback content — the comment text you write, the page route, the environment (local/staging/production), and metadata about the element you clicked: its selector, the CSS rules that apply to it, a text snapshot of nearby content, and (optionally) a screenshot. For the engineering view of what is captured, see Data & self-hosting.
• Bug reports (opt-in, per comment) — only if a project turns on bug capture and you mark your comment as a bug: the network calls your browser made in the seconds before the comment (method, address, status, timing and a short list of harmless headers such as content type), console errors and warnings (plus uncaught errors, unhandled promise rejections, and pages or files that failed to load), and your recent steps on the page (what you clicked, which field you typed in and how many characters — never what you typed; masked and password fields are recorded only as "a masked field was used"). The request and response content of those calls is included only if the project's admin turns that on separately; secret-looking values (passwords, tokens, cookies, API keys, card numbers and similar) in addresses and request and response content are replaced with [REDACTED], secret headers are never kept, and anything that looks like a session token (a JWT or a bearer/basic credential) in kept headers, console messages and step labels is replaced with [REDACTED] in your browser before anything is sent, and again on the server. Addresses a project excludes are recorded without any content. Your browser's user-agent string is also attached.
• Bug recordings, annotations and voice messages (when the project offers them) — if you record a bug: the same kinds of steps, network calls and console entries as a bug report, collected from when you press Record until you stop (up to the workspace's limits), plus a screenshot after each click or page change (not while typing); if you annotate: the screenshot with the marks you drew, kept next to the clean screenshot; if you leave a voice message: the audio file and the text it was turned into, which you can edit before sending. Replies can carry an annotation and voice messages the same way.
• Preferences — your interface language, theme, and (if set) a custom keyboard shortcut, stored against your account so they follow you across devices.
• Browser extension data — your session sign-in token, stored only in the extension's isolated session storage and never exposed to the pages you visit; and, per browser, which project/environment you last picked for each domain you activated the extension on.
• Browser extension usage — each time you activate the extension on a tab: the time, the project, your browser (Chrome, Edge, Firefox or another Chromium browser), which store the extension came from, and its version; and, once per workspace and site, the site's origin (scheme, host and port — never the page path or content). From these the service keeps, per person and workspace, when you first and last used the extension, how many times you activated it, which browsers you used, and the store and version of your latest activation. Used only to understand and improve how the extension is used.
• How you came to PinSay — for each account: how it was created (the extension, the dashboard, an embedded widget, an invitation, or by an administrator) and where it was first used (the extension, the dashboard, the CLI, or an embedded widget); and for each comment, whether it was made through the extension, a site's own embedded widget, or another client.
• Visitor feedback (no PinSay account needed) — when you leave feedback as a visitor, on a site whose owner turned it on or, with the PinSay browser extension, on any site: the comment text, whether it is a bug or a suggestion, the page address, details of the element you clicked (its selector, tag, classes, position and size, a few of its visible styles, and a short text snapshot of the nearby page), your screen size, a screenshot of the page where your browser allows it, and — only if you type them — your email address and a name. Email and name are optional: without them the feedback is stored as coming from an anonymous visitor. Before sending, your browser solves a spam check (a short proof-of-work, or Cloudflare Turnstile when the operator turns it on); your IP address is used, in memory only, to limit how often feedback can be sent. Feedback on a site whose owner uses PinSay goes to that owner's workspace. Feedback left through the extension on a site that is not yet in PinSay is kept apart, as described below.

If you sign in with Google or LinkedIn, we receive your name, email address, whether the provider verified that address, your account identifier at that provider and your profile photo URL. We do not receive your contacts, posts or any other data, and we never post on your behalf.

Profile details you choose to add

You may add a profile photo, upload your own or import it from the Google or LinkedIn account you sign in with. We remove the photo's embedded metadata (such as camera and location data) and store the copy on our servers; we never link to the provider's copy. Your photo is shown to the members of your workspaces next to your name.

You may also tell us how to address you (masculine, feminine, or "prefer not to say", the default). We use it only so that texts and emails in languages with grammatical gender, such as Arabic, address you correctly. It is never shown to anyone else.

To decide which languages to support next, we record the language codes your browser reports (for example "ar" or "en", nothing else) and the languages you choose in PinSay. We only look at them as totals per language.

We never sell profile data and never use it for advertising, profiling or tracking across sites.

Feedback on sites not yet in PinSay

Feedback you leave with the extension on a site that no PinSay workspace has claimed is stored separately from every workspace, in the same region as the rest of the service. No workspace can read it. PinSay's platform administrators can, to understand which sites receive feedback and to contact a site's owner about it by hand; PinSay never sends automated messages to those owners and never publishes the feedback.

Nobody else — the site's owner included — sees the feedback, your email or your name until the owner proves they control the site's domain (with a DNS record, a tag on the site's home page, or a file on the site) and claims it. Claimed feedback moves into that workspace's visitor inbox, with your email and name if you gave them, and from then on that workspace controls it like any other visitor feedback. You are emailed about it only if you gave your address and confirm it.

Feedback that no workspace claims is deleted, with its screenshot, after the period PinSay's operator sets (90 days by default, between 30 and 365 days). To have feedback you left removed sooner, or to report feedback about your own site, write to support@pinsay.dev with the site's address.

5.Browser storage — what the widget stores on your device

The <pinsay-feedback> widget stores the following in your browser. No cookie is set — the widget uses only localStorage, sessionStorage and (while you record a bug) IndexedDB, scoped to the site that embeds it.

6.Screenshots

A screenshot is captured alongside each comment where the browser allows it; a bug recording adds one screenshot per step, and an annotation adds the marked-up copy. It is stored server-side in the same region as the database, attached to that comment, and is deleted when the workspace it belongs to is deleted. Deleting a single comment hides it and its screenshot from every screen; the file itself is removed by a scheduled clean-up of deleted comments (see the retention table) rather than immediately. These images depict the customer's application UI at the moment of the comment, not the commenter's personal data. On a data-subject access/erasure request, the operator can delete individual screenshots on a targeted basis.

7.Data retention

Comments and user accounts are retained until deleted by you or an administrator of your workspace; deleting a comment or project hides it everywhere immediately. Separately, the following operational data classes are retained on a fixed schedule and then purged automatically (one row below is instead kept for the life of the account, as it says):

A full account deletion tombstones your account: your comments and replies are kept but re-attributed to the tombstone rather than your name. A full, unrecoverable hard-delete of a workspace's comment rows happens only when the whole workspace is deleted — including when a workspace admin requests it themselves (Settings → Danger zone), after the cancellable grace period above.

8.Data residency

All PinSay data — accounts, comments, screenshots, and bug reports — is stored in the Oracle Cloud Riyadh region (Middle East). It leaves the region only for transactional email delivery via Brevo, and the website analytics described under Subprocessors (Cloudflare Web Analytics and PostHog) receive visit and usage data directly from your browser. If you buy a paid plan, your billing details (name, e-mail, billing address and payment card) are handled by Stripe, our payment processor, in the United States; PinSay keeps only the subscription record (plan, status, amounts, dates and links to Stripe's invoices), never card numbers. While you record a voice message, your browser's own speech-to-text may send the audio to the browser's maker (see below).

9.Subprocessors

Website analytics. Cloudflare Web Analytics runs on pinsay.dev and on the dashboard. It counts page views and measures how fast pages load, and sets no cookies. PostHog runs only on our production domains (pinsay.dev and the hosted dashboard at app.pinsay.dev), never in the widget on your site, on self-hosted or on-premise installations, or on local copies. It records page views and clicks (autocapture) with the text and attributes of the clicked elements masked, so it does not see what is written on the page or in form fields. It stores an anonymous visitor id in your browser on those domains. If your browser sends Do Not Track, PostHog records nothing. On pinsay.dev, visits stay anonymous. In the dashboard, when you sign in, PostHog links your usage to your account: your user id, e-mail, name, role, workspace id and name, and whether you are an admin; signing out ends that link on the device. PostHog stores this data in the US.

AI features. Translation suggestions and the assistants run only when someone uses them; opening a page never sends anything. The provider receives the request and returns an answer; PinSay does not store questions or answers, only usage counts and an audit record without their text. A workspace that adds its own provider key chooses that provider, which then processes these requests under its own terms and is not a PinSay subprocessor.

Spam check for visitor feedback. By default the widget proves a visitor is not a bot with a short proof-of-work solved in the browser, and nothing is sent to Cloudflare. When PinSay's operator turns on Cloudflare Turnstile instead, the widget loads it from Cloudflare in the visitor's browser before feedback is sent; Cloudflare then receives the visitor's IP address and browser signals to tell people from bots, under its own privacy terms, and PinSay receives only a pass or fail token.

Voice messages and your browser's speech-to-text. While you record a voice message, the widget uses the speech-to-text built into your browser to turn your voice into text you can edit. In Chrome this sends the audio to Google, and in Edge to Microsoft, under the browser maker's terms. The browser maker is not a PinSay subprocessor, and the widget says so the first time you use the microphone. The audio file you send is stored by PinSay like a screenshot.

Integrations you connect. When a workspace admin connects Slack, Discord, Microsoft Teams, Telegram, GitHub or a webhook, PinSay sends that service a short notification for the comment events the admin chose: who acted, the project, the comment number and status, a link back to PinSay, and the first 280 characters of the comment text (none when the admin picks "Metadata only"). Private comments are never sent. The service you connect is chosen by you, not a PinSay subprocessor, and handles the message under its own terms. With "Add to Slack", PinSay asks Slack only for permission to post to the one channel you pick (no access to your messages, channels or people) and stores only that channel's posting address, encrypted. Disconnecting removes it from PinSay; you can also remove the app in Slack at any time.

Linked chat accounts. A workspace member may link their own Telegram account to receive personal notifications (mentions, replies to their comments, status changes on their comments) from the workspace's bot. PinSay then stores only that account's Telegram user id, its public username if it has one, and which bot it was linked through. It never reads your chats, contacts or phone number, and the bot only writes to you when one of those events happens. Each notification contains the same fields as the channel message above. You can disconnect at any time in your profile, which deletes the link at once; leaving the workspace or deleting your account deletes it too. To stop the bot entirely, you can also block it in Telegram.

10.Widget consent posture — for your own privacy policy

If you embed the PinSay widget in your own product, you are the data controller for the people who use it. The paragraph below is written so you can paste it into your own privacy policy as a starting point:

11.Internal access & operator visibility

By default, PinSay staff access to the hosted service is metadata only — counts, statuses, tenants, billing, and health — not the content of your comments or replies. Current status (as of this policy's effective date): the underlying database access used by operator/support tooling can, today, read any workspace's comment content when an operator uses it, and that access is not yet logged to a customer-visible security log. An audited, time-boxed impersonation flow — visible to your workspace admin through an in-product audit log — is designed and is being built, but has not shipped yet. Until it ships, treat operator access to comment content as "staff access on an as-needed basis," not as "audited and time-boxed." This section will be updated, with a changed effective date, once that audited access log ships. The extension usage figures and the "how you came to PinSay" fields in section 4 are visible only to PinSay's platform administrators (shown with your name, e-mail and workspace role), never to other workspaces, and are never published. Visitor feedback left on sites not yet in PinSay is visible to PinSay's platform administrators as described in section 4.

12.Your rights (PDPL)

Where the PDPL applies to your data, you may request: access to your personal data, correction of inaccurate data, deletion of your data, portability of your data to another provider, and to object to certain processing. Contact us using the details below to exercise any of these.

13.Your rights (GDPR)

If you are located in the EEA, you additionally have the standard GDPR rights: access, rectification, erasure, restriction of processing, data portability, and objection, plus the right to lodge a complaint with your local supervisory authority. These rights apply only to the extent GDPR applies to you as an EEA-based data subject; PinSay does not claim EU establishment.

14.Children's privacy

PinSay is a developer tool and is not directed at children. We do not knowingly collect data from children.

15.Changes to this policy

If this policy changes, the updated version will be published at this same URL with a new effective date.

16.The PinSay CLI

The PinSay CLI (@pinsay/cli) connects your local repository to PinSay and runs your AI agent workflows. Its data collection is designed to be minimal, transparent, and under your direct control:

• Source code stays local: The CLI never reads or uploads your application source code. Any design tokens detected in your repository stay in .pinsay/stack.json on your local machine and are never transmitted to PinSay servers.
• Comment files on your machine: When you run get, apply or the MCP tools, the CLI downloads the comment's screenshot, annotation, recording screenshots and voice messages (and those of its replies) from PinSay into .pinsay/media/ in your repository, hidden from git, so your AI agent can open them. They are deleted when you mark the comment applied, and any folder older than 7 days is removed on the next run. Nothing is uploaded from this folder.
• Always sent: Essential functional requests without which PinSay cannot work — signing in, project lists and project creation, comment actions you trigger (list, get, apply/mark, reply, status), skill file downloads, and CLI version checks.
• Sent only when you agree to share: When setting up a repo, the CLI asks if you wish to share framework names (e.g. react, vite, dotnet), the detected AI tool name, and usage events (installed, doctor_run, apply_started, first_apply). The default answer is Yes (in interactive prompts as well as in non-interactive environments like CI, AI agents, or when passing --yes).
• If you answer No (or pass --no-share-stack): None of your framework names, AI tool names, or usage events are sent. The CLI only sends one bare "setup done" signal with no project details so the dashboard's setup guide can confirm connection.
• API key storage: Your API key is stored locally in .pinsay/credentials.env (mode 0600, hidden from git).
• Changing your consent or removing data: You can flip your sharing choice at any time by running npx @pinsay/cli init --no-share-stack (or --share-stack). To completely remove every file and configuration PinSay added to a repository, run npx @pinsay/cli remove.

17.Contact

Questions about this policy, or to exercise your rights above: support@pinsay.dev. To remove visitor feedback you left on a site, or feedback left about your site, write to the same address with the site's address.

This is not legal advice. A Data Processing Agreement (DPA) is not yet offered — it is deferred to the first paying customer (founder decision F6).