Privacy policy

Last updated: 2026-10-21.

Who we are. colding.app is operated by OpenWings Automação Comercial Ltda., CNPJ 63.852.648/0001-06 ("colding", "we"). Our data protection contact, encarregado under the LGPD and data protection officer under the GDPR, is Gustavo Salomé Silva, at [email protected].

1. What colding does

colding connects to email mailboxes its customers own, exchanges warmup mail between them, sends campaigns, single messages and the customer's own app email through them, and reads their inbox into one console. It runs no mail servers of its own and sends nothing from its own addresses except mail about your account.

2. Four kinds of people

Customers: the people who have an account, call the API or use the console.
Contacts: the people in a customer's lists, to whom campaigns are sent, and the people a customer's app emails through the service (a receipt, a sign-in link).
Correspondents: anyone who writes to a connected mailbox, whose mail is read into the inbox.
Warmup partners: other customers' mailboxes that exchange warmup mail with yours, and the people they belong to.

For customers we are the controller. For contacts and correspondents we are the customer's processor: the customer decides who is in a list and what is sent, and we act on their instructions. The data processing agreement is the contract for that relationship.

3. What we collect about customers

Account data: email address, display name, the UI locale and time zone you choose, which workspaces you belong to and with which role. If you continue with Google, also what Google shares for that: your Google account's id, name, email address and the link to its profile photo.
Mailbox data: the address, provider and settings of each connected mailbox; its credentials (an app password or the mailbox's own SMTP and IMAP password, or, for a mailbox connected by signing in with Microsoft or Google, the token that company issues), sealed with a key the service that answers the links in sent mail never holds; sync cursors, error history and warmup standing. A warmup hold (a quarantine or block, or one our team sets) belongs to the mailbox address, so it goes with the address when it is connected in another workspace.
Usage data: every send in the ledger (recipient, subject, the rendered message, the Message-ID, the outcome), every API request's kind, request id and timestamp, the hashed API keys you mint, webhook endpoints and delivery logs, and an audit log of who changed what in the workspace.
Plan data: the workspace's plan and what it has used of it. For a paid plan, also the ids Stripe gives the customer, the subscription and the checkout. Card numbers never touch our systems, because Stripe holds them.
Technical data: the IP address and user agent of each request, kept in request logs, and of each sign-in, kept by the sign-in service to protect your account.

We use it to run the service, hold each workspace to its plan's limits, secure it (abuse detection and rate limits), support you and show you alerts. We do not sell it and we do not use it to train models.

4. Your account, and connecting a mailbox

Your account uses an email address and a password. For now we open each account by hand: ask for access at [email protected] and we answer by email.

You can also continue with Google instead of typing your password. Google then asks you to let colding see your name, email address and profile photo (openid, email and profile), and you go into the colding account that has the same email address. While we open accounts by hand, a Google account whose email has no colding account is refused. Continuing with Google reads none of your mail and connects no mailbox. To stop it, remove colding from your Google account at https://myaccount.google.com/permissions; your password keeps working.

Connecting a mailbox is a separate step, and you choose which mailboxes. A Gmail or Google Workspace mailbox can connect with an app password, and a mailbox at another host, such as Zoho, with its SMTP and IMAP login. We use that login to send, read and file that mailbox's mail, and for nothing else: warmup mail goes into a folder of its own, and what you read or move in our inbox is done in the mailbox too.

A Microsoft 365 mailbox connects by signing in with Microsoft, which asks you to accept these permissions:

openid, email and profile: the sign-in itself, which tells us your name and email address.
User.Read: your name and the mailbox's address, so we connect the right mailbox.
offline_access: to stay connected after you close the tab, until you disconnect.
Mail.Send: to send mail from that mailbox.
Mail.ReadWrite: to read its mail and to file warmup mail in its folders.

With that access we send the mail you compose or schedule, read new mail into your inbox, and file warmup mail. We never read other mailboxes in your organisation, your calendar, your contacts or your files. In some organisations an admin has to approve colding before anyone can accept these permissions. You can remove colding from a Microsoft 365 account at https://myapps.microsoft.com. If an admin approved colding for your whole organisation, only an admin can remove it for everyone, under Enterprise applications in the Microsoft Entra admin center.

A Google Workspace mailbox can also connect by signing in with Google, which asks for permission to read and send mail in that mailbox (gmail.modify). With that access we send the mail you compose or schedule, read new mail into your inbox, and make the same change in the mailbox when you read or move a message in our inbox. Section 13 applies to it. Warmup never uses the Gmail API: a Google mailbox takes part in warmup only when connected with an app password. You can remove colding from a Google account at https://myaccount.google.com/permissions.

To disconnect, remove the mailbox in the console. Its credentials are deleted at once, and its messages at the next hourly clean-up. For a mailbox connected by signing in with Google, we also ask Google to remove our access. You can also revoke the app password at your provider.

What we may and may not do with data we receive from Google is in section 13.

5. What we hold about contacts, correspondents and warmup partners

Contacts: whatever the customer imported: email address, name, company, custom fields; plus what we learn by sending: which steps were sent, whether they replied, bounced, complained or unsubscribed, and the suppression record when they opt out. When a campaign tracks opens, also when one of its emails was opened (at most once an hour for the same email, IP address and kind of program): when, the kind of program that loaded the image (read from its request headers), and the IP address it came from as a keyed hash (for IPv6, only the network part of the address). The address itself appears only in our request logs. When a campaign tracks clicks, also when a link in one of its emails was clicked (at most once an hour for the same link, IP address and kind of program): when, which link, the kind of program that followed it, and the IP address in the same keyed form; and, so each link can take its reader on, the address of the page it leads to. From those facts we judge whether a person opened or clicked, or a program did (a spam filter checking the email, an image proxy), and keep on the email when a person first opened it and first clicked a link in it, and how many times, and when a program first opened it.
Transactional email: for each email a customer's app sends to one person, the address, the message, when it may still go out, and what became of it. It is never tracked, and a bounce, a spam report or a reply asking to stop leaves a suppression record.
Addresses checked: when an address is checked before mail goes to it, each check: the address, whether it can receive mail (valid, risky, invalid or couldn't tell), why, who answered and when. A contact keeps the latest result.
Correspondents: the messages received by a connected mailbox: headers, the text and HTML body up to 512 KB per part, never attachments, and the thread they belong to. When you download an attachment, we fetch it from the mailbox and pass it to you without keeping it.
Warmup partners: the warmup messages exchanged, and the health signals derived from them (where they landed, whether they were replied to).

Legal basis. For customers, the contract with you (LGPD art. 7, V; GDPR art. 6(1)(b)). For contacts and correspondents, the customer's basis, usually legitimate interest in business correspondence (LGPD art. 7, IX; GDPR art. 6(1)(f)), with these safeguards on our side: an opt-out line on by default in campaign messages and an unsubscribe header on every one, each opt-out honoured at once, suppression before every send, and an Acceptable use policy, part of our Terms, which requires a way to opt out in every campaign email. Email a customer's app sends to one person rests on the customer's relationship with that person, usually the contract between them; it carries no opt-out line, and an opt-out from the customer's campaigns doesn't stop it, but a bounce, a spam report or a reply asking to stop does.

6. How long we keep things

Sends: kept while the workspace exists, with no age limit yet, except warmup's (below). Each mailbox's count of what it sent each day, warmup or not, goes after 120 days.
Messages: kept while their mailbox is connected. Disconnecting a mailbox hides its messages at once, and the next hourly clean-up deletes them.
Warmup: each warmup email as it was sent, where it landed and what the other mailbox did with it: 120 days, then pruned. A few stay longer. One that landed in spam stays until the sender's warmup is stopped, because it still slows that mailbox's warmup. One the other mailbox still has to move to its warmup folder stays until it does, while that mailbox keeps checking for mail at least once every 7 days. One we may still find in a mailbox that stopped checking for mail, the other mailbox's copy or the sender's own copy in its Sent folder, stays until that mailbox checks again or is disconnected. Every copy stored in a connected mailbox, the sender's Sent copy and the partner's, is that mailbox's mail, kept as messages are.
Contacts: until the customer deletes them or the workspace. A suppression record outlives the contact, because it is the only way to keep honouring an opt-out. It holds the address, how and when it was added, any note and end date the customer gave it, and which campaign, email or reply it came from, nothing else. When the workspace is erased, a recipient's own opt-out stays as a hash, as the Workspaces and accounts item says.
Opens: 90 days after the open, then pruned. The first open and first click a person made, their counts, and when a program first opened it are part of the send and go with it.
Clicks: 90 days after the click, then pruned. Tracked links: 365 days after the email was sent, then pruned with any clicks still on them; after that the link no longer leads to its page.
Address checks: 30 days after the check finishes, then pruned, with the batches that ran them. A contact keeps its latest result while the contact exists. How many checks a workspace used each month, a count with no addresses in it, is kept 13 months.
Audit log: 90 days. Event stream: 24 hours.
Webhook delivery logs: 30 days.
What our mail servers' log says about an email: when an email leaves through a mail server of ours, the log of that server says what the receiving server answered, with the recipient's address. We keep that 40 days in our database and 14 days on the mail server, then it is pruned.
A campaign's history (what happened to it, such as a pause or a lead left out): 90 days. Alerts, read or not: 90 days.
Alerts to our staff: the daily list of people who started using colding, with each one's email address, is kept 2 days. Other staff alerts keep only the latest one about each thing.
Repeated API requests: when a request carries an Idempotency-Key, we keep its answer 24 hours, so a retry gets the same answer.
Contact imports: the file and its cells are deleted once its contacts are added, or 24 hours after the upload if they never are. The counts of what it did are kept 7 days.
Contact exports: the file is made while it downloads and never stored. Its link works 10 minutes and is deleted within the hour after.
Files of mailboxes: each row's passwords are deleted once that mailbox is connected or fails. The rest of the file is deleted 7 days after it was sent.
Mailbox confirmation codes: a code works 30 minutes, then is deleted. The request without its code is kept 7 days, to look into mail that never arrived.
Unsubscribe links: a link works 365 days after the latest email that carried it, and is deleted 30 days after that.
Stripe's messages about subscriptions. For each one we keep its id and kind, the subscription it is about, when Stripe sent it and what we did with it. We keep them 90 days. Some stay longer: the ones from about a day before a workspace's latest checkout opened, and every one after. They stay until that workspace's subscription starts or it opens another checkout.
Bounce and complaint reports from a sending service, for a send-only mailbox whose owner turned them on. For each one we keep what kind it was, what we did with it, the email it matched and when it came in, never the service's words or an address. We keep them 30 days.
Workspaces and accounts: kept while you use them. A workspace's owner can ask to delete it in Settings, under Delete workspace. After 30 days we erase it on our own; until that date the owner can cancel the request. From the moment they ask, the workspace sends nothing: its campaigns pause, its scheduled emails don't go out, warmup pauses, and its API keys and pending invitations are revoked. Incoming mail keeps arriving, and the owner can still download the workspace's data. Once the date passes, a worker erases it in steps, which take from a few minutes to some hours for a big workspace, and goes over it again until a pass finds nothing left, 3 passes at most, to catch anything that arrived while it ran. Erased: its mailboxes and their logins, contacts, campaigns, messages and their bodies, sends, drafts, address checks, webhooks, API keys, members, invitations, download links and audit log. Nothing of it can be downloaded once the erasing starts. What stays, and only as a keyed hash, a code we cannot turn back into the address, with no workspace attached: a recipient's own opt-out (they unsubscribed, replied to stop, or reported spam) for 3 years, so the next workspace of the same owner cannot write to someone who asked to stop; a hold on a mailbox address's warmup (a health term, a rest, a probation, a block by our team and the appeals decided about it) until it ends, and a block or rest, which have no end, for 1 year; and the limit we put on the workspace, if it had one, for 2 years, so deleting a limited workspace and starting again does not shed it. These are applied when the same address, or the same owner, comes back. The workspace's row stays with no name and no readable address: its id, dates, plan, the Stripe customer and subscription ids our payment records need, and the version of the acceptable use policy it accepted. Warmup evidence that our mailboxes gathered about other workspaces' mailboxes (where their warmup mail landed) stays, with nothing that points at the erased workspace; the evidence about our own mailboxes is deleted. The account of the person who asked stays. The person who asked gets an email when it is done.
Your account: kept while you use it. You can delete it yourself in Settings, under Delete your account, by typing your sign-in email. First give each workspace you own to another member, or ask to delete it. While a workspace you asked to delete waits for its date, your request waits too, and runs once the last one is erased. You can cancel until the deletion starts. It starts within a few minutes once you own no workspace. Then a worker takes you out of every workspace you are a member of, revokes the API keys you made and the invitations you sent, and deletes your sign-in, your name, your email address, your alert settings and your alerts. What you did in someone else's workspace stays there with your name taken off: the emails you sent and the record of who changed what. If our team banned your address, the ban stays only as a keyed hash, with no account attached, for 2 years, so signing up again with the same address meets the same ban. We send one email to your address when it is done, and then keep the address nowhere. The request itself, with your account's id and no address, is deleted 30 days after it is done or canceled.
Request logs, which hold each request's IP address and user agent: 180 days.
Sign-ins: to protect accounts from stolen passwords, the sign-in service keeps the IP address and user agent of each sign-in with its session, until you sign out or the account is deleted. It also keeps the IP address of each sign-in in its sign-in history, and of each request made to it in its own log. Neither has a time limit yet.
Backups: a copy of the database every night, kept 7 days on our server and 30 days in a private Cloudflare R2 bucket. Before a copy leaves our server we encrypt it with a key that is kept offline, never on the server, and Cloudflare also encrypts the bucket at rest. We also keep a second kind of copy in the same bucket, encrypted the same way: a full copy of the database each night, plus every change made since, which reaches the bucket within minutes. These are kept for up to 8 days. Data deleted from the service leaves the backups when the last copy that holds it expires.

Whether you are a customer, a contact or a correspondent, you can: confirm whether we process data about you; access it; correct it; ask for its deletion or anonymization; ask for it in a portable form; object to processing based on legitimate interest; withdraw consent where consent was the basis; and complain to your supervisory authority (in Brazil, the ANPD).

Customers: a workspace's owner can download a copy of the workspace's data from Settings, under Your data. It is one file with the contacts, labels and segments, the campaigns, every email sent with what it said, the inbox with each message, drafts, the suppression list, saved replies, the settings of the mailboxes, API keys and webhook, the members' names, email addresses and roles, and the record of who changed what. It leaves out logins and passwords, mailbox sign-in tokens, API key hashes, the webhook's signing secret and the addresses of warmup partners: of warmup, it holds the counts per day and the owner's appeals about a hold. Each email is in the file as it was sent, links included, so an unsubscribe link in one still works for whoever holds the file. The webhook's address is in it too. Keep the file as safe as the mailbox. The owner can make up to 1 of these files a day, and a new day starts at 00:00 UTC. Each file's link works for 60 minutes and for up to 3 downloads. You can also export just your contacts, as a spreadsheet, from the Contacts page. The owner can also ask to delete the workspace in Settings; section 6 says what happens then. You can delete your own account in Settings too, and section 6 says what happens then as well. To get a copy of your own account's data, write to [email protected].

If you received mail from a colding customer, the unsubscribe link or a reply saying so stops it at once and needs no account; for anything else write to [email protected] and we will route the request to the customer, who is the controller, and help them answer. We answer within 15 days.

8. Who else touches the data

For each company below that works for us, we say what its agreement states about moving data to another country. Where an agreement names no mechanism, we say that and name none. We read these agreements on 4 October 2026. On 7 October 2026 we read them again for what they say about the ANPD's clauses, and read Stripe's for the first time. On 21 October 2026 we read AWS's. The sub-processors page lists the same companies with what each receives and where it works, and the data processing agreement is our own with you.

Your mail providers (Google, Microsoft, Zoho or the SMTP host you chose): every message is sent and received through them, under their terms. They are your providers, not our processors.
Stripe: takes payment for the paid plans. We send it only the workspace's id. You give it your email, your card and your billing details on its own payment page, so they never reach us. Its data processing agreement, last updated 28 September 2026, sends the data to Stripe, LLC in the United States, and to Stripe's affiliates and sub-processors in other countries, under its data transfers addendum, last updated 18 November 2025. The addendum names the Data Privacy Framework, the EU's standard contractual clauses, the UK's international data transfer addendum and a Swiss version of them. Its section 11 applies the ANPD's standard contractual clauses to data that goes from Brazil to a country with no adequacy decision from the ANPD: the exporter is the party to the agreement with Stripe, and the importer is Stripe, LLC. For part of its work Stripe decides the purposes on its own, and there it is a controller, not our processor.
Our own checking server: to check an address, a server of ours asks the mail server that receives mail for it whether the address exists, and hangs up before any message is sent. It never sends mail. It receives the address and the names of that domain's mail servers. It keeps no copy of the address and never writes it in its logs. Its logs name the mail server it asked and what that server answered, with any address taken out. The address's own mail server sees the question. For now we rent this server from netcup (netcup GmbH, Germany), and it sits in netcup's data center in the United States.
MillionVerifier (GBD Software as a Service Private Limited Company, Hungary): checks whether an email address can receive mail, for the addresses our own checking server can't answer. It receives the address only. Under its data processing agreement it keeps the address in its cache up to 7 days, and in its backups until they are replaced. We keep each check 30 days after it finishes. That agreement names no transfer mechanism. It says that where a transfer is subject to Chapter V of the GDPR, MillionVerifier will use a lawful transfer mechanism required for it, and that it signs no country-specific transfer agreement unless the law also requires one for its own processing. It does not mention the ANPD's clauses or the LGPD.
Amazon SES (Amazon Web Services, Inc., United States): delivers mail about your account (sign-in links, password resets, alerts, notices and the codes that confirm a mailbox's address) and receives your address, your name and the message itself. Campaign mail never goes through it. It works in AWS's us-east-1 region, in the United States. AWS's service terms let AWS, or companies it uses, store and scan each message to block spam, phishing and viruses. If our email to you bounces for good, or you mark it as spam, Amazon SES keeps your address on our account's list of addresses it sends nothing to, until we take it off. AWS's data processing addendum applies the EU's standard contractual clauses to data the GDPR covers that goes to a country outside the EEA with no adequacy decision from the European Commission, unless AWS has adopted binding corporate rules or another recognised standard for those transfers. AWS's service terms add a UK addendum and a Swiss one. None of these texts mentions the ANPD's clauses or the LGPD, and AWS's page on Brazil's law names no mechanism for data that leaves Brazil, so this policy names none for it.
Supabase (self-hosted on our own server): authentication and the database. Nothing leaves our server for this.
Cloudflare: DNS, the hosting of our web front-ends, and storage for the nightly backup copies (section 6). A security check on the pages where you sign in, create an account or ask for a new password (Cloudflare Turnstile) is built but not switched on yet. When it is switched on, your browser will load the check from Cloudflare, which will receive your IP address, your browser's user agent and the fingerprint of its encrypted connection, to tell a person from a program and to improve the check. Our sign-in service will then ask Cloudflare whether the check passed, sending your IP address with the question. Cloudflare receives nothing for this today. Its data processing addendum applies the EU's standard contractual clauses to a transfer from the EEA that needs them (Module Two, or Module Three when the customer is a processor), with the UK addendum and a Swiss version of them. It also says Cloudflare complies with the EU-U.S. Data Privacy Framework and holds Global CBPR and Global PRP certifications. It does not mention the ANPD's clauses or the LGPD.
netcup (netcup GmbH, Germany): the server that runs the service and holds its database, in the United States. Its data processing agreement names no transfer mechanism. It says the customer decides where the data is processed.

The ANPD's clauses and the EU's are annexes to our own data processing agreement, for the data of our customers' contacts. Of the companies above, only Stripe's addendum adopts the ANPD's clauses, and none of the others has signed them with us.

Our servers are in the United States, so what we hold about you is stored there, wherever you are.

Data we receive from Google follows the extra rules in section 13.

9. Security

Mailbox credentials are encrypted at rest with a key the service that answers the links in sent mail never holds; API keys are stored hashed; sessions are short-lived tokens; traffic to and from our servers uses TLS wherever the other side supports it (a few mail servers that our checking server asks about an address don't, and that question then goes unencrypted); the database asks for its password on every login from outside our server; access is limited to the operator. Mail from strangers renders in the console in a sandbox without scripts. No system is perfect; if a breach affects you we will tell you and the authority as the law requires.

10. Children

colding is not for people under 18, and we do not knowingly hold accounts for them.

11. Emails we send

About your account. We open each account by hand and answer your request from a person's address. Account email is part of the service and keeps coming while the account exists. It carries sign-in links and password resets, and the codes that confirm a mailbox's address go to that address. It also tells a workspace's owner and admins when the owner asks to delete it, 7 days and 24 hours before it is deleted, and if the owner cancels the request. When you delete your account, we send you one last email once that is done.

Alerts. Alerts show in the console's bell and on its Alerts page. You choose in the console which kinds also reach your inbox by email: "Mailbox trouble", "Campaign trouble", "A new reply" and "Requests for you". Alerts that come close together share one email: after an alert email, the next one waits 30 minutes and lists everything that came in the meantime. You get at most 25 alert emails in any 24 hours, from all your workspaces together; past that, the alerts wait in the console.

News and tips. We send none today. If we ever start, only people who say yes to them will get them, and every email will carry an unsubscribe link.

We don't sell your email address.

12. Data processing agreement

For contacts and correspondents, the processing agreement between the customer (controller) and us (processor), as the LGPD and GDPR art. 28 require, is the data processing agreement. It applies to every workspace without a signature. The sub-processors page is part of it, and so are its two annexes: the standard contractual clauses of the ANPD and of the EU.

13. Google user data

This section covers information we receive from Google APIs: your Google account's name, email address and profile photo when you continue with Google, and the mail of a Google Workspace mailbox you connect by signing in with Google (both in section 4). A mailbox connected with an app password goes through Google's mail servers, not its APIs.

colding's use and transfer to any other app of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements. In practice:

We use it only to provide and improve the features you see in the console.
We pass it to another party only to provide those features, for security, or to comply with the law. In a merger or sale of the business, we pass it on only after you agree.
We never use it for advertising, never sell it, never use it to decide on credit or lending, and never use it to train AI models.
No person reads it unless you agree to it for specific messages, it is needed for security, the law requires it, or it has been combined and anonymized for our internal operations.

14. Changes

We will announce material changes by email to customers and by a dated note at the top of this page.