Privacy Policy

1. Two very different roles

Publiq processes personal data in two capacities, and almost every question about this policy depends on which one applies. The distinction is not a formality: it decides who you should contact, whose legal basis governs the processing, and who answers to a regulator.

We are the controller of your account data

When you sign up, log in, subscribe to a plan, open a support ticket or connect a channel, we decide why and how that data is processed. We are the controller for it, and this policy governs it in full.

We are only the processor of the data you upload about your contacts

The contacts you import, the leads your forms capture, the people who write to your Instagram, WhatsApp, Messenger, Telegram, TikTok or website chat, and the recipients you email — you decide who they are, why they are contacted and on what legal basis. You are their controller. We process their data only on your documented instructions, as your processor, under the Data Processing Addendum.

If you received an email or a message from a business that uses Publiq and you want your data corrected or deleted, that business is the controller — write to it. Our Data Deletion page explains what to do if that is not possible, and we will pass your request to the customer concerned.

Controller identification: [LEGAL ENTITY NAME], enrolled under [CNPJ], with registered offices at [REGISTERED ADDRESS]. Data Protection Officer / Encarregado: [DPO EMAIL].

2. Data we process as controller

Account and identity

• Your name and email address, and a normalised form of that email used to detect duplicate signups.
• A hash of your password — never the password itself. If you sign in only through SSO, no password is stored at all.
• If you enable two-factor authentication: an encrypted TOTP secret and hashed recovery codes.
• Session records, stored as hashes of the session token, with their expiry and revocation time.
• Email verification, password reset and team invitation tokens, all stored only as hashes.
• For SSO logins: the connection you belong to and the identifier your identity provider assigns you (the OIDC subject or SAML NameID).

Organisation and use of the product

• Your organisation, its plan, its projects, your role in it and the settings you choose.
• API keys, stored only as hashes, with their prefix, scope and last-used time.
• Webhook endpoints you register, their signing secret (encrypted), and the delivery history — including the payload we sent and a truncated snippet of your server's response.
• An audit trail of actions taken in your organisation: who acted, what action, on what resource, and when. It does not record IP addresses or browser user agents.
• AI usage records: which feature was used, which model, the token counts and whether the request succeeded. The content of the prompt is not stored in these records.

Billing

Your plan, subscription status, current period end and the identifiers Stripe assigns to you. Card numbers, expiry dates and security codes are collected by Stripe on its own pages and never reach our servers or our database.

Support

Tickets you open: subject, message bodies, attachments, priority, who is assigned, and any satisfaction score and comment you leave.

Technical data

Your IP address is used transiently to apply rate limits on signup, login, password reset, two-factor verification, SSO, public form submissions and website chat. It is held in a short-lived cache for that purpose and is not written to our database. By default the application ignores forwarded-IP headers entirely and uses the connecting address. Application logs redact authorisation headers, cookies, passwords, tokens and secrets, and expire after 30 days.

3. Data we process as processor, on your behalf

The categories below belong to your contacts and to the people who message your channels. We hold them only to run the service for you.

• Contact records: email address, first and last name, phone number, subscription status, tags, and any custom attributes you define — the attribute fields are yours to design, so their content is whatever you choose to put in them.
• Consent evidence you record: double opt-in confirmation state, WhatsApp opt-in flag with its date and source, and an append-only trail of opt-outs.
• Channel identities: the WhatsApp phone number in international format, the Instagram-scoped user id, the Messenger page-scoped id, the Telegram chat id, the TikTok open id, or the website chat session id — depending on the channel.
• Public profile fields the platform returns for a contact: username, display name and profile picture URL.
• Conversations and the full text of the messages exchanged in them, inbound and outbound.
• Email records: sender and recipient addresses, cc and bcc, subject, template used, delivery status, and the merge variables you supplied for that send. The rendered body of an individual email is not stored in our database.
• Message events — sent, delivered, opened, clicked, bounced, complained, unsubscribed — with their timestamps.
• Send logs for WhatsApp (message id, country code, conversation category and cost) and for Instagram (message text and status).
• The suppression list: addresses that must never be mailed again for your organisation, with the reason.
• Web push subscribers: the push endpoint issued by the browser, its encryption keys, and the browser user agent string.
• Notes your team writes about a contact, bookings, coupons, survey answers, and the click identifier of the ad that started a conversation, where that applies.
• Knowledge files you upload for the AI features: the file name, its extracted text and the vector embeddings computed from it.

Our analytics store keeps message events with the recipient's domain as an indexed field, and retains the raw event payload alongside it — which, for a send event, includes the full recipient address and the subject line. Those events are discarded after 13 months; the email record itself has its subject, recipients and merge variables redacted after 24 months. See "How long we keep data".

Form submissions become contact records. We do not store a separate per-submission row, and we do not record the submitter's IP address.

4. Provenance of consent

The split of roles described above only holds if it is possible to show, for any given contact, where the permission to contact them came from. The platform is built to keep that evidence with the record rather than in a customer's memory.

What the platform records

• A subscription status on every contact — the field that decides whether a marketing send may include them at all.
• Double opt-in state: where a form is configured to require confirmation, the contact is not treated as subscribed until the confirmation link is followed, and the confirmation token and its expiry are held until then.
• For WhatsApp, an explicit opt-in flag together with the date of the opt-in and the source it came from.
• An append-only trail of preference changes: which audience, which action, when it happened and what triggered it. It is append-only by design — an opt-out record that could be edited away would be worthless as evidence.
• Unsubscribes captured from a message are applied through a signed token tied to that specific recipient and message, so the opt-out is attributable.
• Addresses erased on a data subject request are added to the suppression list, which prevents them being re-imported or contacted again.

What the customer declares

When a customer imports a list in bulk or connects an external platform to migrate contacts, the platform cannot observe how that consent was originally obtained. The customer declares its origin, and warrants under the Terms of Service that a valid legal basis exists for every contact imported and that the evidence can be produced on request. That declaration is what the customer relies on if a recipient, a data protection authority or we ourselves ask where an address came from.

We do not verify that declaration for each contact, and we do not become the controller of the data by receiving it. If we have reason to believe a list was purchased, rented, scraped or otherwise collected without a valid basis, we may suspend sending under the Acceptable Use Policy and require the customer to produce the evidence.

5. Purposes and legal bases

The table below covers the processing for which we are the controller. It cites LGPD article 7 and GDPR article 6.

For the data we process as your processor, the legal basis is the one you establish as controller. We do not choose it and we do not process that data for our own purposes.

6. Our legitimate interest assessment, in short

Where we rely on legitimate interests, we have weighed our interest against the rights of the people concerned. The summary:

• Purpose: keeping a sending platform safe. Abuse by one account degrades deliverability and platform standing for every other customer, and unchecked automated signup lets attackers use the service to send phishing.
• Necessity: a rate limit needs an identifier for the requester, and IP is the only one available before authentication. Abuse detection needs sending patterns and complaint rates. An audit trail needs to name the actor. There is no less intrusive way to achieve any of these.
• Impact on the individual: minimal and expected. IP addresses used for rate limiting live in a short-lived cache and are not written to the database; the audit trail records an internal user identifier and an action, not browsing behaviour; we do not profile anyone for advertising and we do not enrich data from brokers.
• Safeguards: strict separation between organisations enforced in the data layer, redaction of secrets in logs, a 30-day expiry on application logs, and encryption of every stored credential.
• Your rights are unaffected: you can object to processing based on legitimate interests at any time, at the address in the Contact section, and we will stop unless we can show compelling grounds that override your interests.

7. Data received from Meta and TikTok

When you connect an Instagram account, a WhatsApp Business number, a Facebook page or Messenger, a Facebook ad account or a TikTok account, those platforms send us data through their APIs. This section describes exactly what we do with it.

What we receive

• The identity of the account, page or number you connected: its platform id, username or display name, and its profile picture URL.
• An access token for that account, limited to the permissions you grant, and encrypted before it is stored.
• The messages people send to your connected account, and the events that come with them — comments, mentions, story replies, reactions and delivery statuses — including the sender's platform-scoped identifier.
• For a connected ad account: aggregated spend, impression and click metrics, and, where a conversation started from a click-to-message ad, the click identifier and the ad's headline and body.

What we do with it

• We use it only to deliver the messaging, automation, inbox and reporting features you configured in your account.
• We keep it inside your organisation. It is never pooled with another customer's data and never used to build a cross-customer profile.

What we never do with it

• We do not sell it, rent it, or share it with data brokers or advertising networks.
• We do not use it to train artificial intelligence or machine learning models — ours or anyone else's.
• We do not use it for advertising targeting of our own, and we do not use it for any purpose unrelated to the feature you enabled.
• We do not transfer it to a third party except the subprocessors listed on our Subprocessors page, and only to run the feature you enabled.

Our use of the Meta and TikTok platforms follows their developer terms and platform policies, including the Meta Platform Terms and Developer Policies and the WhatsApp Business Messaging Policy. You can revoke our access at any time by disconnecting the channel in the application or by removing the app in the platform's own settings; the stored credentials are then deleted. How the underlying data is removed is described on our Data Deletion page.

8. AI features and automated decisions

The product includes AI assistants that draft email templates, landing pages and automation flows, and that can answer questions using the knowledge files you upload.

What the AI does

• It generates a draft from the instruction you write. The draft is a suggestion; nothing is sent to anyone until you review it and choose to send.
• It computes vector embeddings from the knowledge files you upload, so that the assistant can find the relevant passage when answering.
• The prompt you write, and the content it references, are sent to the AI model provider listed on the Subprocessors page. We record which feature ran, which model, how many tokens it used and whether it succeeded — not the content of the prompt.

What the AI does not do

• It does not decide autonomously who receives a message. Recipients are determined by the audiences, segments and automation rules a person configures.
• It does not make any decision that produces legal effects for a person or that significantly affects them in a similar way. There is no automated credit scoring, pricing, eligibility, ranking or profiling of individuals.
• It is not trained on your data. Your messages, your contacts and your content are not used to train our models or the model provider's models.

AI output can be wrong. You are responsible for reviewing anything the assistant drafts before it is sent. If you believe a decision in the product was taken automatically and affected you, you may ask for human review at the address in the Contact section — a right expressly granted by LGPD article 20 and GDPR article 22.

9. Cookies, email tracking and click tracking

In the application

• Session cookies: two strictly necessary cookies hold your access and refresh tokens. They are HTTP-only, so page scripts cannot read them, restricted to same-site requests, and marked secure in production. Without them you cannot stay signed in.
• Local storage: your theme choice and whether the sidebar is collapsed are kept in your own browser. They never reach our servers.
• Signup only: the Cloudflare Turnstile anti-abuse challenge loads on the signup form and sets its own storage under Cloudflare's control, to tell a person from a script.
• We set no advertising cookies, no analytics cookies and no third-party tracking cookies anywhere in the application. There is no consent banner because there is nothing to consent to beyond what is strictly necessary.

In the emails our customers send

Publiq offers open tracking and click tracking to its customers. Whether they are used, and what recipients are told about them, is the customer's decision as controller. This is what the mechanisms actually record:

• Open tracking works through an invisible image loaded from our servers. When it loads, we record the message identifier and the time. We do not record the reader's IP address, browser or location.
• Click tracking rewrites links so that a click passes through a signed redirect on our servers. We record the message identifier, the destination URL and the time. Again, no IP address and no browser identification.
• Unsubscribe links carry a signed token that identifies the recipient for that specific message, so the opt-out can be applied without asking anyone to type their address.
• Short tracked links used in messaging channels record an irreversible visitor fingerprint instead of an IP: a keyed hash of the IP and user agent, salted per organisation so the same visitor cannot be correlated across two customers. The IP and user agent themselves are never written to storage or to a log. Traffic from link-preview bots and crawlers is discarded rather than counted.

On our public website

The marketing site and the documentation carry no third-party analytics, no advertising pixels and no session recording.

10. Who we share data with

We do not sell personal data, and we do not share it for cross-context behavioural advertising. We disclose it only in the following situations:

• Subprocessors: the vendors that run parts of the service for us. Every one of them is named, with its purpose and the data it receives, on our Subprocessors page.
• Platforms you connect: when you connect a channel, messages and identifiers necessarily flow to and from that platform, which is also a controller in its own right.
• Your own destinations: when you configure a webhook, a Google Sheets automation step or an alert channel, we send the data you configured to the address you supplied.
• Professional advisers bound by confidentiality, where necessary for legal or accounting advice.
• Authorities: where a valid legal order requires it. Where the law allows, we notify the affected customer before responding.
• A successor: in a merger, acquisition or sale of assets, with the same obligations carried over and notice to you.

11. International transfers

Several of our subprocessors — the email delivery provider, the payment processor, the messaging platforms and the AI model provider among them — operate outside Brazil, and in some cases outside the European Economic Area. Using them means personal data is transferred internationally.

We rely on the safeguards that Brazilian and European law provide for such transfers: a written contract with each recipient containing standard contractual clauses of the kind approved by the Brazilian data protection authority under LGPD article 33, and, where the transfer is subject to the GDPR, the European Commission's Standard Contractual Clauses under GDPR article 46. Where the destination country benefits from an adequacy decision, we rely on that instead.

You may request a copy of the safeguards applicable to a specific transfer at [DPO EMAIL].

12. How long we keep data

The periods below are the ones the platform actually enforces, by an automated sweep — not intentions. Where a category has no fixed term, we say so, and we say why.

Content with a fixed term

Redacted is not the same as deleted

When a retention term runs out on message content, the personal content goes and the skeleton of the record stays. In a conversation, only the message text is removed: the direction, the channel, the moment it happened and the provider's message identifier remain. In an email record, the subject, the recipient addresses and the interpolated variables are removed: the send line — status, dates, provider — remains.

The reason is deliberate. Keeping the skeleton preserves the service metrics a support team needs and the evidence that a message was in fact sent, which is what answers a later dispute about whether someone was contacted. Neither of those needs the words. So the words go and the fact stays.

The 180 days count from inactivity, not from the age of the message

The clock on conversation content runs from the last activity in the conversation, not from the date each message was written. A new message resets it for the whole conversation.

That has a consequence worth stating plainly rather than leaving for someone to discover: a conversation that never sits idle for 180 days never has its content redacted. That is the intended behaviour, not an oversight — while the relationship is alive, the purpose that justified holding the data is alive too. A conversation that goes quiet loses its content six months later.

What has no fixed term, and why

Per-organisation configurable retention windows are not offered today. The terms above are set globally for the platform. If your compliance programme requires a shorter one for a specific category, talk to us before relying on it.

Note that an organisation is archived rather than erased when it is offboarded, so that billing and audit history remains verifiable. The Data Deletion page explains what is erased, what is retained and why.

13. Security

These are measures the platform implements, not aspirations:

• Passwords are hashed with argon2id. The password itself is never stored and cannot be recovered from the hash.
• Two-factor authentication is available, with the TOTP secret encrypted at rest and recovery codes stored only as hashes.
• Every third-party credential we hold — channel access tokens, SSO client secrets, webhook signing secrets, integration API keys, push keys and 2FA secrets — is encrypted at rest with AES-256-GCM before it is written to the database.
• API keys, session tokens, password reset tokens, email verification tokens and invitation tokens are stored only as SHA-256 hashes. We cannot show you an API key again after it is created, because we do not have it.
• Inbound webhooks are verified before they are trusted: the Meta signature header for Instagram, WhatsApp and Messenger, the TikTok signature, a per-bot secret token for Telegram, an HMAC signature with a five-minute replay window for the email delivery provider, and Stripe's own signature verification. Outbound webhooks we send are HMAC-signed so you can verify them.
• Separation between organisations is enforced in the data access layer, not left to each query: a query that was never scoped to an organisation is refused rather than executed unscoped.
• Webhook URLs you supply are checked to block requests to internal and cloud metadata addresses, and third-party integration hosts are validated against an allow-list.
• Rate limits apply per IP and per identity on signup, login, password reset, two-factor verification, SSO, public form submissions and website chat. Signup is additionally protected by a CAPTCHA and by duplicate-account detection.
• Logs redact authorisation headers, cookies, passwords, tokens, secrets and webhook secrets, and expire after 30 days.
• Staff access to a customer account for support is time-boxed, issues no long-lived credential, and is recorded in a separate platform audit trail.
• Data is encrypted in transit with TLS.

What we do not claim: we hold no ISO 27001 certification, no SOC 2 report and no PCI DSS attestation, and we do not represent otherwise. Card data is handled entirely by Stripe, which does hold those attestations. Our encryption keys are managed by us in the application configuration; we do not currently use a hardware security module or a managed key management service.

No system is perfectly secure. If you find a vulnerability, report it to [SECURITY CONTACT EMAIL] and we will work with you.

If a security incident happens

Where we process data on a customer's behalf, we notify that customer without undue delay and in any event within 48 hours of confirming the incident, with what is known at the time and with updates as the investigation advances. The same 48 hours appear in the Data Processing Addendum and in our internal incident response runbook — the three state one deadline, not three.

Notifying the authority and the affected individuals in that situation falls to the customer, who is the controller, within the deadline the applicable law sets for it; our part is to give it what it needs to meet that deadline.

Where the incident affects data for which we are the controller — the account data of our own customers — we notify the ANPD, and the affected people where the law requires it, within the period set by the regulation in force. We deliberately do not commit to a number of days here: that period is fixed by the authority and has changed by resolution before, and a wrong number in a published policy is worse than a reference to the rule that actually applies.

14. Your rights and how to exercise them

Under LGPD article 18 and GDPR articles 15 to 22, you may ask us to confirm whether we process your data and to give you access to it; correct incomplete, inaccurate or outdated data; anonymise, block or delete data that is unnecessary, excessive or processed unlawfully; port your data to another provider; tell you with whom we have shared it; explain the consequences of refusing consent; withdraw consent where consent is the basis; object to processing based on legitimate interests; and ask for human review of a decision taken by automated means.

If you are a Publiq customer or team member

Write to [DPO EMAIL] from the email address on your account, or open a support ticket in the application. We answer within 15 days for requests under the LGPD, and within one month for requests under the GDPR — extendable by two further months for complex requests, in which case we tell you why within the first month. We may need to verify your identity before acting, and we will ask for no more information than that verification requires.

If you are a contact of one of our customers

Your data is under the control of the business that contacted you, not us. Ask that business directly — it can export or erase your record itself, and the platform gives it a button to do so. If you cannot identify or reach it, write to us at the address above with enough detail for us to find the record, and we will forward your request to the customer concerned and support them in answering it.

Where our customers act on such a request

In the application, a customer opens Audiences, selects the contact and uses the "Privacy (GDPR/LGPD)" panel on the contact page. "Export data" downloads that contact's record. "Request deletion" anonymises it: the name, email, phone, tags and attributes are removed; the recipient address, the subject and the variables interpolated into the message body — a name, an order number, an address — are redacted from the related email records; and the original address is added to the suppression list so it can never be re-imported or contacted again. Campaign statistics survive, but they no longer identify anyone.

Exercising a right is free. If a request is manifestly unfounded or excessive, particularly because it is repetitive, we may charge a reasonable fee or refuse it, and we will explain why.

If you are unhappy with our answer, you may complain to the Brazilian National Data Protection Authority (ANPD) or, in the European Union, to your local supervisory authority.

15. Children

Publiq is a business service and is not directed at children or adolescents. We do not knowingly collect personal data from anyone under 18 as an account holder. If you become aware that a minor has created an account, tell us and we will remove it.

If a customer uploads a contact who is a child or adolescent, that customer is the controller and is responsible for the specific protection LGPD article 14 requires, including consent by a parent or legal guardian where applicable.

16. Changes to this policy

We update this policy when the product changes. The date at the top of this page is always the date of the version you are reading. For a change that materially affects your rights, we give at least 30 days' notice by email to the account address or by a notice inside the application before it takes effect.

17. Contact

Controller: [LEGAL ENTITY NAME], [CNPJ], [REGISTERED ADDRESS].

• Data Protection Officer (Encarregado), privacy questions and data subject requests: [DPO EMAIL]
• Security reports: [SECURITY CONTACT EMAIL]
• Legal and contractual notices: [LEGAL CONTACT EMAIL]

Related documents: the Terms of Service, the Data Processing Addendum, the Subprocessors list and the Data Deletion instructions.