What personal data Onflow Ads collects across the website, the Telegram bot and the Mini App, why we collect it, who else sees it, how long we keep it, and what you can make us do about it. Written from what the platform actually does.
Your channel, your creative and your public trust signals. Never your email address, your wallet balance, your ledger or your other campaigns.
Read the section § 16Not for money, not for "valuable consideration", and not to a data broker. Section 16 says exactly what we do instead, and where the line is.
Read the section § 22Access, correction, erasure, a portable copy, withdrawal of consent — and the one address that gets all of it done.
Read the sectionThis Privacy Policy explains how Onflow Ads ("Onflow Ads", "we", "us" or "our") handles personal data across our website at onflowads.com, our Telegram bot and Mini App, and every service we provide through them (together, the "Services").
It forms part of our Terms and Conditions and should be read with them and with our Refunds & Cancellations Policy. Where the Terms describe what you and we have agreed, this document describes what we actually do with data — and it is written from the platform's own behaviour, product by product, rather than from a template.
Four sections change what a reader expects more often than the rest, so please read them in particular: section 8 on people who are not our users, section 13 on what a counterparty can see, section 20 on what survives closing your account, and section 22 on the rights you can exercise and how.
Onflow Ads is an advertising and growth platform for Telegram channels. We operate the website at onflowads.com, the Telegram bot @OnflowAdsBot and the Mini App it opens. Through them we run Boost Metrics, Paid Promotions, Cross-Promotion, the Subscriber Exchange, a set of AI features, and a wallet that funds all of it.
For the personal data described here, Onflow Ads is the Data Fiduciary under India's Digital Personal Data Protection Act, 2023 (the "DPDP Act") and the controller under the EU/UK General Data Protection Regulation, except where section 3 says otherwise.
Everything we do as Onflow Ads: the website (signed in or not), the bot, the Mini App, the emails and notifications we send, and the back-office systems that run orders, payments and support. It covers you whether you are a channel owner, an advertiser, a buyer of a growth service, someone who only ever filled in the contact form, or someone who merely clicked a link in a promotion we delivered (section 8).
It does not cover what Telegram does with your data, what a payment provider does with data you give it directly, or what another user does with data you choose to hand them. Those are governed by their own policies, and section 3.3 explains where our responsibility stops.
Each section is numbered so it can be cited, and every heading has a link anchor —
hover a heading to copy a deep link straight to that clause. Sub-clauses are numbered
N.1, N.2 and so on. Where a section states a limit on what we
do, that limit is a commitment, not a description of current practice we may quietly
drop; changing one requires the notice period in
section 26.
Plain English, on purpose. Where a legal term is unavoidable it is defined in section 2. Where the law gives you a right we have written what to actually do to use it, not just that it exists.
These terms carry the same meaning throughout. Terms defined in the Terms and Conditions — "Channel", "Placement", "Order", "Wallet", "Bot" and the rest — keep the meaning given there.
Data protection law puts duties on whoever decides what happens to personal data. On a marketplace that decision is not always ours, and pretending otherwise would leave you with no idea who to ask. So this section splits it three ways.
For your account, your orders, your payments, your Wallet, your support tickets, the security logs we keep, and the analytics we compute about how the Services are used, we decide the purpose and the means. We are the Data Fiduciary and controller, and every obligation in this Policy is ours.
When you use the Services to reach other people, the personal data of those people is yours to answer for, not ours. That includes:
For that data you are the controller and we act on your instructions. You must have a lawful basis for processing it, must honour the rights of the people it belongs to, and must not use the Services to process data you are not entitled to process. This mirrors section 23.6 of the Terms.
Two features put you squarely in that seat, and they deserve naming rather than leaving to the general words above:
If someone asks us to delete personal data you put into the platform, we will usually route them to you — because you are the only one who knows what basis you had for it. Where the law makes us act anyway, we will, and we will tell you. If a request reveals that you had no basis at all, that is a breach of the Terms and we may suspend the Account under section 24.
Telegram is not our platform. What Telegram collects about you as a Telegram user, what it shows in a channel, and how it handles your account are governed by Telegram's Privacy Policy, not by this one. The same is true of a payment provider's own checkout page, an app store, and any site you follow a link to. We can only tell you what we send them and what they send back — which we do, in section 14.
The DPDP Act asks for an itemised description rather than a summary, so this section and the next two list categories rather than gesturing at them. Nothing below is collected for its own sake; each row exists because a feature stops working without it.
We also mint two identifiers of our own at sign-up: a random public id, and your OFA ID — the short reference you quote to support. Neither is derived from anything about you.
When you connect a Channel we store what the marketplace needs to list, match and price it: its Telegram id and username or invite link, its title and public description, its category and language, its subscriber count and engagement figures, and the pricing and availability you set. Section 6 explains where the figures come from and what we deliberately do not read.
Creative is not private. Anything you put into an ad is written to be published. Do not put personal data into creative unless you are entitled to publish it — see section 3.2. Delivery-proof and certificate pages are reachable by anyone holding the link and are not listed publicly; sharing one reveals the target and the delivery figures.
Top-ups, plan purchases and payouts generate a transaction record: the amount, the currency, the method, the provider's reference, the status, the fee, and the resulting Wallet movement. For payouts we also hold the destination you gave us — a UPI handle, bank details or a crypto address, depending on the method.
We never see or store your full card number, CVV or UPI PIN. Card and UPI details are entered on the payment provider's own page and stay with them. What comes back to us is a reference, a status, an amount and, depending on the provider, the payment method's type and last four digits.
Sellers who cross a lifetime-payout threshold are asked to verify. The first level collects your legal name and country, and is approved automatically. Higher levels are reviewed by a person, and if we need anything further at that point we will ask you for it specifically and tell you why before you send it.
We do not ask for a government ID document, a selfie or a biometric through the platform's verification flow. If a payment provider or the law ever requires one for a particular payout, we will tell you what is needed, who it goes to and why, before you provide it — never as a silent upload.
A contact-form enquiry stores your name, email address, subject and message. A support ticket stores the same plus a phone number if you give one, and the technical context that makes a problem diagnosable — the page you raised it from, your IP address and your browser. You can open a ticket without an account, and if you do, that ticket is all we hold about you.
Dispute submissions, reliability appeals and anything you send the Bot are kept with the account they relate to, including the evidence you attach. If you tell us something sensitive in a ticket, it lives in that ticket — so please send only what the question needs. Where an AI feature drafts or triages a reply, the ticket goes to a model provider; section 12.2 says so plainly and tells you how to opt that out.
When you use the Services we record your IP address and your browser's User-Agent string against security-relevant events — signing in, failing to sign in, verifying an email, changing a password, enabling or disabling two-factor authentication, requesting admin access. From the User-Agent we derive a readable label ("Chrome on Windows") that our staff see when investigating an account.
We use the IP address to work out an approximate location — country level, for fraud signals and currency — and as a key for rate limiting and lockouts. We also record the page you came from when you arrive from elsewhere. Lockout counters are keyed on a hash of the email address or IP rather than the value itself; short-lived rate-limit counters use the address directly and expire within minutes.
Meaningful requests across the Services are written to an activity record — who acted, what they did, when, from which IP address and browser, the country inferred from that address, the referring page, and the outcome. It is how a support agent reconstructs what actually happened to an order, and how we notice an account being worked over by someone who is not its owner. The same entries are mirrored to an operations channel described in section 14.5.
Where a request carried an email address or a name, the activity record keeps a copy of it — a sign-in attempt records the address used, whether or not it belonged to an account. That copy is deliberate: it is what makes the record useful after an account is gone. It also means the record is not erased when the account is — see section 20.3.
Security event logs are the one record that outlives your account. When an account is deleted the link to it is severed, but the event rows — including the email address used and the IP and User-Agent at the time — remain, because their entire purpose is to answer "who tried what, from where" after the fact. Section 20.4 sets out how long, and section 20.6 what you can ask us to do about it.
We record which pages and screens you open, which features you use, which buttons you press in the Bot, and the outcome — an order placed, a slot booked, a Wallet top-up started and abandoned. This is what produces your analytics, our funnel reporting, and the evidence for a dispute about whether something was actually delivered.
Some of the most consequential data we hold is data you never gave us — we worked it out. It is still personal data and you still have rights over it.
Section 11 explains which of these make decisions on their own, and what you can do when one goes against you.
You can link a Telegram account to sign in and to receive Bot notifications. The handshake passes us exactly two identity fields: your numeric Telegram user id and the display name shown on your Telegram profile. The short-lived codes that bind the browser to the chat are stored only as hashes and expire within minutes.
Telegram sign-in does not give us your phone number, your profile photo, your contact list or your message history. Telegram does not offer them to a bot, and we do not ask for them by another route.
When you message the Bot, Telegram passes it your user id, your display name and username, your language setting and the content of the message you sent it. We keep what the conversation needs — your account link, your preferences, your place in a flow, and the commands you ran. The Mini App authenticates using the signed data Telegram gives it, which we verify before trusting.
The Bot and the website are one platform sharing one database, so an action in one shows up in the other. They are covered by this single Policy for exactly that reason.
Using the Bot can create an account record for you even if you never signed up on the website. The platform is one system, and a Telegram user who transacts through the Bot needs somewhere for their orders, balance and standing to live. That record is yours: everything in section 22 applies to it, and you can ask us to close it exactly as you would one you created yourself.
Where an analytics tool is configured, the Bot also reports in-chat activity to it server-side, using your Telegram user id as the identifier. This is a persistent identifier reaching an analytics provider, so we name it rather than let it sit under "usage data" — see section 18.3.
Connecting a Channel means giving the Bot administrator rights on it. What it does with them is deliberately narrow, and the limits are contractual as well as descriptive — the same three appear in section 4.2 of the Terms.
The Bot never messages your subscribers privately, never posts anything outside the campaigns and slots you accept or book, and is never given your subscriber list — Telegram does not hand one to a bot. It publishes what you agreed to publish, removes only its own posts, and otherwise reads public details and counts.
You can remove the Bot's access at any time by removing it as an administrator of the Channel, or by disconnecting the Channel from your account. Access ends immediately. What we have already recorded about completed orders stays under section 20, because a deal that happened is a record we are required to keep — but nothing further is read from that Channel.
To price and verify a Channel we read the figures Telegram exposes about it: its subscriber count, the view and reaction counts on recent posts, posting frequency and the timing pattern those imply. We use the Telegram Bot API and, for public channels, an operator-held Telegram reader account which can see what any member of that channel can see. It is used to count, and to confirm that a post we were paid to place is still there.
We read counts, not people. We do not collect, request or store your Channel's member list, the identity of anyone who viewed or reacted to a post, or the content of any private conversation. What we take from a post is a number.
There is one identity read, and it is the one that proves you own the Channel: to verify a Channel we ask Telegram for its administrator list and check that our Bot — and, where your Telegram account is linked, you — appear in it. Only an administrator can appoint another, so that list is the proof, and it is why we do not ask you for screenshots. Where a co-administrator is not an Onflow Ads user, their Telegram identifier reaches us as part of that check; it is used to answer the ownership question and for nothing else. Section 4.3 of the Terms describes the same check.
Where enabled, you may sign in with Google or Apple. We request the minimum scope each offers for identification — from Google, your basic profile and email address; from Apple, your name and email address, which you may choose to relay through Apple's private address. We receive no password, and no access to anything else in that account.
Support for further platforms — Instagram, YouTube, X, TikTok and Discord among them — is on our roadmap. When one goes live, the data we take from it, the permissions we ask for and the reason will be published here before you can connect an account, either in an update to this section or as an Additional Privacy Term. We will not quietly widen collection under a general sentence about "supported platforms".
Not everything we hold came from you or from your device. These are the other routes, and what arrives by each.
Where a third party sends us something we did not ask for and do not need, we discard it rather than file it.
An advertising platform inevitably touches people who never signed up for anything — the audience of a Channel where a Placement runs. Most policies pass over this in a sentence. It is the part of our processing that deserves the most explanation, so it gets a section.
When an advertiser buys a Placement, the links in their creative are rewritten to pass through a redirect of ours before continuing to the destination. That is what lets us report clicks and click-through rate honestly, rather than asking both sides to take the other's word for it.
When someone clicks such a link, we record the click, the link it was for, a one-way salted hash of the visitor's IP address and User-Agent, and the country, referring page and device type — and then send them on their way. The hash exists to tell a repeat click from a new one. It is salted with a server-side secret, so it cannot be reversed into an address and cannot be correlated with anything outside our own click table.
The click record itself contains no IP address, no cookie is set on the visitor's device through the redirect, no profile is built, and they are not followed to the destination site. Click data is never sold, shared or otherwise made available to anyone for advertising to that person. The advertiser gets a number, not an audience list.
The click redirect is deliberately excluded from our general activity record too — the log in section 5.2 that records the IP address of ordinary requests. It would otherwise have undone the whole design by recording, at the outer layer, the identifier the redirect itself refuses to keep. So the answer to "what do you hold about me because I clicked an ad" is: a salted hash that cannot be reversed, and nothing else.
Click and conversion records live with the campaign they belong to, and are covered by the order retention row in section 20.1. Because they carry no address and no account link, there is nothing in them we could return to an individual visitor who asked — which is the point of storing them that way.
The Subscriber Exchange is the exception, and it is a real one. When a Telegram user taps an exchange ad inside the Bot, Telegram tells us who tapped it, and we record that Telegram user id against the delivery. We do it for one reason: the exchange pays a channel owner for genuine taps, and without knowing that two taps came from two different people rather than one person twice, the product is a fraud machine.
What we store is the numeric id and the moment of the tap — no name, no username, no phone number, no profile. It is not shown to the advertiser, who sees counts. It is not combined with anything else about that person, because we hold nothing else about them. And it is deleted with the delivery record it belongs to.
Cross-Promotion taps inside the Bot work the same way for the same reason, except that the identifier is held only briefly — in a cache that expires within days — because there deduplication is all it is for.
We do not collect member lists, viewer identities or reaction identities from any Channel — see section 6.4. What an advertiser learns about a Channel's audience from us is aggregate: how many, how engaged, when they are active.
If you name someone in a support ticket, a dispute, an abuse report or a piece of creative, we process that data to deal with the matter you raised. We keep it with the matter and no longer than section 20 allows. If that person asks us what we hold about them, we will tell them — and, where you supplied it, generally point them to you under section 3.2.
Everything in section 22 is available to you even if you have never had an account. Write to privacy@onflowads.com with enough detail to find the record — the link you clicked, the promotion, the approximate date — and we will search and respond. Be aware that for click data the honest answer is often that we hold nothing we can tie to you, precisely because it was never stored in an identifiable form.
A notice that only lists what a platform takes tells you half of what you need. These are commitments, and changing one needs the notice in section 26 — not a quiet edit.
We do not collect, and do not want:
We also do not buy personal data from data brokers, do not enrich your record from third-party datasets, and do not scrape personal data from Telegram or anywhere else to build lists.
We use personal data only for the purposes below. Each is paired with the basis we rely on: under the DPDP Act, either your consent or a legitimate use the Act allows; under the GDPR, one of contract, legitimate interests, legal obligation or consent. Where two bases are shown, the first is primary.
Data collected for one of these purposes is not quietly reused for another. If we want to use something you gave us for a materially different reason, we will say so first — in an update to this Policy, or as an Additional Privacy Term — and where the new purpose needs consent, we will ask for it rather than assume it.
Where we rely on legitimate interests, the interest is: running a marketplace where delivery can be verified, fraud can be caught, and a dispute can be decided on evidence. We have weighed that against your interests and consider it proportionate because the data involved is transactional rather than intimate, it is used to protect the other side of a deal as much as our own position, and you can object at any time under section 22. Tell us why, and we will stop unless we can show compelling grounds that override your objection.
Some things on this platform are decided by code before a person ever looks. You are entitled to know which, and to get a human involved.
No automated decision permanently closes your account, confiscates your Wallet balance or cancels a payout on its own. Those outcomes require a person. An automated decision can suspend, hold or block pending that review — because the alternative is letting a suspected fraud complete while we deliberate — but it is a hold, not a verdict.
Where a decision about you was made automatically and has a significant effect, you may ask for it to be reviewed by a person, put your side of it, and have the decision reconsidered. Use the in-product appeal where one exists, or write to privacy@onflowads.com.
On request we will explain, in ordinary language, what categories of behaviour feed a decision about you, roughly how they are weighted, and what would change the outcome. We will not publish the exact thresholds and detection rules, because doing so hands the playbook to the people the system exists to catch — and a fraud-detection system that explains precisely how to evade it protects nobody. Your right to a human review does not depend on our disclosing them.
The Services include AI assistance: drafting and rewriting ad copy, suggesting targeting and pricing, describing a Channel, summarising analytics, checking creative for prohibited content, and spotting near-duplicate submissions. The same AI layer serves the website and the Bot.
More than the sentence "we use AI to help you write ads" implies, so here it is in full. Depending on which feature runs, the following is sent to the model provider we have configured at the time:
Support tickets, dispute records and your commercial figures do reach a model provider when an AI feature runs over them. We would rather say so than write the usual line about AI only touching ad copy. If you would prefer your ticket not to be processed this way, say so in the ticket and we will handle it manually.
What never goes to a model provider: your password or any credential, your two-factor secret, your Wallet balance as a payment instrument, your payment or payout details, and the contents of another user's account except where they are a party to the dispute being assessed.
The engine behind those features is one of a small set of established commercial model providers. Which one is active is an operational choice that can change without a code release, so rather than print a list here that goes stale, we will tell you the provider in use, and the terms it operates under, if you ask — privacy@onflowads.com.
One of the options is a router rather than a model. A routing service passes the request on to a downstream provider of its own, so where one is the configured engine, a further company processes the content — and the answer to "who exactly" is part of what you get by asking. If we ever route AI processing somewhere on materially different terms, we will publish it under section 27.
We log that an AI call happened — which feature, which account, when, and how much quota it used — for billing and abuse control. We do not store the prompt or the model's response in that log. AI output that becomes part of your work — a saved draft, a generated description, a campaign email — is stored as your content, like anything else you saved.
One exception is deliberate: where a safety check blocks a submission, the blocked text is kept as the evidence for that decision, so an appeal under section 11.2 can be judged on what was actually written rather than on a summary of it.
We do not train AI models on your personal data, and we do not licence your content to anyone for training. We use these providers through their business interfaces on terms that do not permit customer content to be used to train their general models. We cannot bind a provider beyond that contract — so if this matters to you, ask us who is in use and we will tell you, and you can read their terms yourself.
AI output is a draft. It can be wrong, generic or unsuitable, and you remain responsible for what you publish — see section 10 of the Terms. AI does not decide anything about you on its own beyond the checks listed in section 11.1, all of which carry the human-review right in section 11.2.
The AI layer is optional infrastructure. When no engine is configured, every AI feature degrades to templates and nothing leaves for a model provider at all. Nothing else about the Services depends on it.
A marketplace only works if each side can judge the other. This is the exact line between what a counterparty is shown and what they are not.
They do not see your email address, your Wallet balance, your transaction ledger, your payout destination, your legal name from verification, your IP address, your other Channels, or your other campaigns. None of it is exposed by any marketplace screen, and none of it is included in a deal record shared with them.
One precision, so the sentence above is exact: where a channel owner needs to tell two
advertisers apart, they are shown a masked form of the advertiser's
address — al****@g***.com. It is a label, not an address: it cannot be
written to, and the address itself is never rendered.
Channels listed in the public directory, and the pages you choose to make public, are visible to anyone — that is the point of listing. Delivery-proof and certificate pages are unlisted but reachable by anyone holding the link: they are not indexed and not discoverable, but they are not access-controlled either, so treat the link as the secret.
Our support and operations staff can see your account record — email, name, standing, balances, orders, tickets and the security events in section 5.1 — because they cannot resolve a dispute or a locked account without it. Access is restricted to the roles that need it, the most sensitive actions are limited to the platform owner, and administrative actions are logged. We do not read your data for curiosity, and we do not sign in as you to look around.
Running the Services means other companies touch some of the data. These are the categories, what each receives, and why. A provider here is bound to use the data only to deliver its service to us.
Payment providers are independent controllers of what you give them directly. Their handling of your card, bank or wallet details is governed by their own policies, and we could not access those details even if asked.
As described in section 12.2 — a commercial model provider, named to you on request. It receives the content an AI feature operates on and nothing else.
A Boost order is fulfilled through a third-party supply panel. We send it three things: the service identifier, the target link you gave us, and the quantity (plus a drip schedule where you chose one).
A supplier is never told who you are — no name, email, account id or payment data crosses that boundary. But the target link is by definition your Channel or your post, it is a link you have chosen to promote publicly, and it goes to a company we do not control, often outside India. If a link is one you would not hand to a stranger, do not place a Boost order against it. Suppliers are also independent controllers of what they do with a link once they hold it.
The activity record in section 5.2 is mirrored, as it happens, into a private operations channel that only our operators can read. It is how we notice a failed payout or a suspicious sign-in within seconds rather than at the next report. An entry can contain the acting account's name and email address, its account id, the IP address, the country and the browser, the referring page, the action and its outcome, and the operative details of the event — for money operations, the amounts and references involved. Credentials and secrets are stripped before anything is written.
Practically, this means a messaging provider carries a copy of those operational records as the transport for that channel, on the same footing as any other provider in this section. We disclose it rather than describe it as "internal logging", because that is what it is.
What does not go into that channel: your payout destination, the legal name you gave for verification, and any phone number you have given us. A payout destination appears only as its last four characters — enough for an operator to notice that a member's destination has changed, which is how a hijacked account is caught before the money leaves, and not enough to pay anyone or identify anyone. A verification name is dropped entirely. Credentials and secrets never appear at all.
The Services can be configured with third-party analytics, session-replay, support-chat and review widgets. None of them are essential, all of them ship off, and where one is enabled it loads only after you have accepted analytics cookies — see section 18, which lists them individually and tells you how to see which are live on your visit.
Two of these can receive your identity, not just your behaviour. A support-chat widget is given your email address, display name, plan tier, role and your current credit balance so an agent knows who they are talking to, and a product-analytics tool can key your record on your email address. A conversion event for a completed top-up can also carry the amount and the payment reference to an analytics provider. All of it is gated behind your analytics consent, and declining costs you nothing but the chat widget.
The tables above describe every provider by what it does and what it receives, which is what actually affects you, rather than by brand name. Two reasons, and neither is evasion.
You can have the names. Write to privacy@onflowads.com and we will tell you which providers are in use, what each holds and where they are — for the whole list, or for one category you care about. We answer this on the timetable in section 22.2, we do not require a reason, and a regulator, auditor or enterprise customer asking gets the same answer without having to ask twice.
Anything you can already see for yourself is still named in full: every cookie we set (section 18.1) and every third-party tag that runs in your browser (section 18.3). Those load on your own device, so withholding a name there would hide nothing from an attacker and would stop you giving informed consent.
We may change or add a provider — a payment rail, an AI engine, a host. When we do, the categories in this section still describe what is shared, and where a change materially affects who holds your data or where, we will publish it under section 27 and, for a significant change, give the notice in section 26.
We disclose personal data where we are required to by law, or where it is necessary to comply with an order of a court of competent jurisdiction or a lawful demand from a government agency authorised to make one. Our practice is to require the request in writing, to satisfy ourselves that the requester has authority and that the request is lawful and proportionate, to disclose only what is actually asked for, and to record what we handed over.
Where we are lawfully permitted to tell you that a request has been made about you, we will. Sometimes we are prohibited from doing so, and in that case we will not.
We disclose what is necessary to investigate suspected fraud, abuse, security incidents or breaches of the Terms, to protect the rights, property or safety of Onflow Ads, our users or the public, and to establish, exercise or defend a legal claim — including in a dispute between you and another user, where the evidence for one side is often the record of the other.
Our lawyers, accountants, auditors and insurers may see personal data where they need it to advise us. They are bound by professional duties of confidence and, where applicable, a written data-processing agreement.
If Onflow Ads is involved in a merger, acquisition, restructuring, financing or sale of assets, personal data may be transferred as part of it.
Data does not lose this Policy by changing hands. Any acquirer takes it subject to this Policy and may only use it for the purposes described here until you are given notice of any different practice and, where the law requires it, a fresh basis is obtained. Where the law requires us to notify you of such a transfer, we will.
We have never sold personal data, and we do not sell it now. Not for money, not for other "valuable consideration", not to a data broker, not to an advertising network, and not as a dataset in any form. We have no business model that requires it: we are paid by the users who buy the Services.
California and several other US states treat some disclosures as a "sale" or a "share" even when no money changes hands — in particular, passing personal information to an advertising technology provider for cross-context behavioural advertising. We treat that definition as the standard, not the narrow one:
To be explicit for the avoidance of doubt: we do not sell or share the personal data of anyone under 16, and we do not knowingly hold any (see section 23).
What we do is disclose the minimum a counterparty needs to do a deal with you (section 13), and the minimum a provider needs to run part of the platform for us (section 14). Neither is a sale. If either ever became one, this section would say so before it happened, and you would get the opt-out the law requires.
Onflow Ads is operated from India and serves users worldwide. The infrastructure and the providers in section 14 are located in several countries, including the United States and the European Union. Using the Services therefore involves your personal data being processed outside the country you are in.
The DPDP Act permits transfer of personal data outside India except to a territory the Central Government restricts by notification. We do not transfer personal data to any territory currently restricted in that way, and if a restriction is notified that affects a provider we use, we will move or stop that processing.
Where we move personal data out of your region we rely on an appropriate safeguard — normally the European Commission's Standard Contractual Clauses (with the UK Addendum or IDTA where the UK is involved), together with a transfer risk assessment and technical measures such as encryption in transit. Where a provider is in a country with an adequacy decision, we rely on that instead. You may ask us for a copy of the safeguard relied on for a particular transfer by writing to privacy@onflowads.com.
Data in another country is subject to that country's laws, including the powers of its authorities. Contractual safeguards bind the company we send data to; they do not bind a foreign government. We tell you this plainly because a policy that promises otherwise is promising something no company can deliver. What we can and do control is how little crosses a border: a supplier gets a link, a crypto gateway gets an amount, and an AI provider gets the text you are editing.
Some messages are part of the Services rather than marketing: verification and security codes, receipts and invoices, order and Placement updates, payment and payout notices, dispute notices, plan expiry reminders and incident announcements. You can choose which channel some of them arrive on, but you cannot switch them off entirely while you hold an account — they are how the platform tells you about your own money and your own commitments. This mirrors section 23.1 of the Terms.
Campaign and product-update emails go only to accounts that have consented. Every one carries a one-click unsubscribe that works without signing in, and consent is re-checked at the moment a campaign is sent — so unsubscribing after a campaign is prepared still takes you out of it. Unsubscribing affects marketing only; account, order and payment mail still reaches you. You can resubscribe from the same link.
Audience segments for a campaign are built from your plan tier, your role and how recently you joined. They are not built from the content of your messages, your creative or your support tickets.
If you have linked a Telegram account, the Bot can message you directly. Stop it by turning the category off in your notification preferences or by blocking the Bot in Telegram. Delivery is best-effort and depends on Telegram — see section 11.3 of the Terms.
Web push requires your browser's own permission. If you grant it we store the push endpoint your browser issues, the keys needed to encrypt a message to it, and the User-Agent — enough to send a notification and nothing more. Revoke the permission in your browser and the endpoint stops working; tell us and we will delete the record.
Where we offer it, you may choose to receive one-time verification codes by WhatsApp instead of email. It is entirely opt-in, requires you to give your own number, and carries only the same six-digit code the email would have — never marketing, never links or media. The number is used for that, and to check it is reachable on WhatsApp before sending. It stays on your account record until you remove it: turn the option off and we fall back to email, ask us and we delete the number.
We keep personal data for as long as it is needed for the purpose it was collected for, and then for any period the law requires us to hold it. "As long as needed" is not a number, so this section says what the periods actually are, and — more usefully — what happens when you close your account.
Ask us to close your account and we delete or anonymise your account record, your profile, your channels and your listings. What we keep, we keep for a stated reason, and nothing kept is used to market to you or to build a profile of you.
Closing your account is not a full erase, and you should know exactly what remains:
We do not currently run an automatic expiry over security and administrative event records. They are retained while they remain useful for security, fraud investigation and the defence of claims, and are reviewed periodically for deletion or de-identification. We would rather write that than quote a period we do not yet enforce — a retention promise a system cannot keep is worse than an honest one it can.
If you want these records dealt with sooner, say so under section 22 and we will assess it. Where the purpose has been served and no legal obligation or live matter requires them, we will erase or de-identify them.
We take encrypted backups of the database on a regular cycle and keep them off-site for a limited period, so a hardware failure or a bad deployment costs hours rather than everything. They are encrypted at rest and access is limited to the platform owner.
This means deleted data can persist inside a backup for a short period after deletion — a backup is a point-in-time copy and cannot be edited in place. Backups are never used to restore an individual record that was deliberately deleted, and when a backup is restored for a genuine failure, deletions are re-applied.
We do not publish the schedule, the retention window or where backups are held. That is deliberate — it is the one detail whose disclosure would help someone attacking us while telling you nothing useful about your own data. A regulator or an auditor asking will be told.
We do not delete accounts merely for being idle, and an idle Wallet balance stays yours subject to the Terms. If we ever introduce automatic deletion after a period of inactivity, we will email you first and give you a clear window to keep the account alive — never a silent removal.
No system is perfectly secure, and a policy that says otherwise is selling something. We do not claim your data cannot be compromised. We claim that we take the measures above, that we review them, that we will tell you when something goes wrong (section 25), and that we will not quietly weaken a protection this document describes.
Use a password you use nowhere else, turn on two-factor authentication, keep your Telegram account secure — it can sign you in — and treat proof and certificate links as private, since anyone holding one can open it. Tell us immediately at support@onflowads.com if you think your account has been accessed by someone else.
We will never ask you for your password, a verification code, a card number, a UPI PIN or your Telegram login code — by email, by chat, on Telegram, or anywhere else. Anyone who does is not us.
If you find a security flaw, report it to security@onflowads.com (or support@onflowads.com) with enough detail to reproduce it, and give us a reasonable chance to fix it before disclosing it publicly. We will not pursue a researcher who acts in good faith, stays within their own test data and does not degrade the service or access other people's data.
Which rights you have depends on where you are, but our practice does not: we extend all of the following to every user, wherever you live, except where the law forbids it or a right makes no sense for the data in question.
Write to privacy@onflowads.com from the email address on the account, or use our contact form. Tell us which right you are exercising and include enough to find the record — your account email or OFA ID, and for anything order-related, the reference and dates.
We will acknowledge within 72 hours and respond substantively within 30 days. If a request is genuinely complex we may extend that once, and we will tell you why before the first 30 days are up. It is free; we will only charge for a request that is manifestly unfounded or repetitive, and we will tell you before we do rather than after.
We must be sure a request comes from the person the data is about — handing an account's data to an impostor is itself a breach. Normally, sending the request from the account's email address is enough. Where the data is sensitive or the request comes from another address, we may ask you to confirm from the account email, complete a verification step or sign in. We will not use anything you give us for verification for any other purpose, and we will not demand an identity document for an ordinary request.
An authorised agent may act for you if you confirm the authority directly.
Sometimes we must decline, and you are entitled to know the reasons in advance rather than discovering them in a rejection:
Where we decline we will say which of these applies, comply with the part of the request we can, and tell you how to challenge it under section 24.
Indian law places duties on you as well as on us. You must not impersonate anyone else, must not suppress material information when giving personal data for a verification the law or we require, must not raise a false or frivolous grievance, and must furnish only verifiably authentic information when asking us to correct or erase data. Breaching these can carry a penalty under the DPDP Act, and may lead us to hold a request or an account while we verify.
The Services are for adults. You must be at least 18 years old, or the age of majority where you live if that is higher, to hold an account — see section 3 of the Terms. This is not only a contractual rule: under Indian law a person below the age of majority cannot enter into a binding contract, and the Services involve money.
We do not knowingly collect personal data from anyone under 18, we do not advertise to children, and we do not track or profile a child or serve behavioural advertising directed at one. No part of the platform is designed for, marketed to, or made appealing to children.
If we learn that an account belongs to someone under 18, we will close it and delete the personal data, keeping only what we must to record that we did so and to settle any money already moved. If you are a parent or guardian and believe a child has given us personal data, write to privacy@onflowads.com and we will deal with it promptly.
Where the DPDP Act requires verifiable consent from a parent or lawful guardian before processing a child's data, we meet that requirement by not processing children's data at all. The same reasoning covers persons with disability who have a lawful guardian: if a guardian tells us they act for an account holder, we will deal with the guardian.
Separately, an audience member who sees a promotion is a member of someone else's Telegram channel, and Telegram sets its own minimum age. We do not know who is in an audience and do not receive their identities (section 8). If your Channel's audience includes children, you must not use the Services to advertise to them anything you could not lawfully advertise to a child.
If you are unhappy with how we have handled your personal data or answered a request, tell us. Write to privacy@onflowads.com with the word "Grievance" in the subject line, and include your account email or OFA ID, what happened, when, and what you want done.
We will acknowledge your grievance within 24 hours of receiving it and dispose of it within 15 days. If we cannot resolve it in that time we will tell you why and give you a date.
Questions about how personal data is processed, and grievances under this Policy, are handled by our Grievance Officer / Data Protection Contact, reachable at privacy@onflowads.com. That address is monitored by a person with the authority to act, not an autoresponder. Should we be designated a Significant Data Fiduciary under the DPDP Act, or otherwise be required to appoint a named Data Protection Officer, we will publish their name and contact details in this section.
You do not have to be satisfied with our answer, and you never lose a statutory route by trying us first.
We do not require you to arbitrate or to waive a statutory complaint route as a condition of using the Services, and nothing in the Terms is intended to take away a right you have under data-protection law.
A personal data breach is any security failure that leads to personal data being lost, destroyed, altered, disclosed or accessed without authorisation — whether by an attacker, a provider, or our own mistake.
Where a breach affects your personal data, we will notify you without undue delay, in plain language, and tell you: what happened and when, the categories of data involved and roughly how much, the likely consequences, what we have done to contain it, and what you should do — change a password, watch for a particular kind of message. We will notify you directly rather than only posting a notice, wherever we have a working way to reach you.
We report breaches to the authorities that require it, within the deadlines they set — including the Data Protection Board of India and, where the GDPR applies, the relevant supervisory authority within 72 hours of becoming aware.
We will not delay a notification to protect our reputation, and we will not describe a breach as something else. If we get it wrong we will say what we got wrong. What we will not do is speculate before we know: an early notice may say less than a later one, and we would rather tell you three true things quickly and the rest as we confirm it.
We update this Policy when what we do changes, when we add a service or a provider, or when the law moves. The date at the top of the page is always the date of the current version.
For a change that materially affects how we handle your personal data — a new purpose, a new category of data, a new category of recipient, a materially different retention period, or a narrowing of a commitment in section 9 — we will give you at least 30 days' notice by email or through the Services before it takes effect, and it will apply prospectively only.
If you do not want to continue under the new version, you may close your account before it takes effect and withdraw any consent you have given. Where the new processing needs your consent, we will ask for it rather than treat continued use as agreement.
Corrections, clarifications, a renamed provider in the same category, or a change that reduces what we collect take effect when published. The date at the top changes; nothing about your rights does.
If you need to know what this Policy said on a particular date — because that is the version you relied on — ask privacy@onflowads.com and we will provide it. Clauses published under section 27 each carry the date they were added, and a clause we retire keeps its text and its date in our records for exactly this reason.
From time to time we publish further disclosures under this section — when we engage a new processor, when a provider changes what it returns to us, when a new feature processes something the sections above do not cover, or when a regulator asks for a specific statement. They appear below, each showing the date it was added.
Anything published here forms part of this Policy and describes our actual practice exactly as the numbered sections above do. An Additional Privacy Term supplements those sections; where one conflicts with a section above, the Additional Privacy Term controls for the subject it covers, because it is the later and more specific statement. Where such a term widens what we collect or who receives it, the notice period in section 26.1 applies to it too.
A term that is later retired stops applying from the date it comes off this page. Retiring it does not erase the fact that it applied while it was in force, and we keep its text and its date so that the version of this Policy you relied on can always be reconstructed.
There are no Additional Privacy Terms in force at the moment. When there are, they will appear here.
One address handles everything in this Policy — rights requests, questions, grievances and complaints. You will get a person.
For anything about your personal data — access, correction, erasure, a copy, withdrawing consent, a human review, or a grievance.