Privacy Policy

Last updated: 5th of November 2026

This Privacy Policy explains what AGP LLC ("AGP," "we," "us") collects, why, and what happens to it, across tg.page and the dashboard at app.tg.page (together, the "Service").

0. Three Different People, Three Different Sections

This is the most important thing to understand before reading further, because almost nothing below applies equally to everyone. The Service involves three distinct people, and we hold very different amounts of data about each.

The Account Holder creates a project and connects a Telegram channel to it. They have an account with us, and Sections 1 through 8 describe what we collect about them. The Site Visitor reads a published site — which is only ever served at the Account Holder's own domain — and has no account with us; Section 3 describes the limited, largely non-identifying data we collect about them. The Channel Author and their Telegram subscribers are the source of the published content; they have no account with us and have not agreed to anything with us simply because their public channel was published by someone else. Section 5 covers what happens around verifying a channel, and Section 4 covers what we retrieve from Telegram in the first place.

If you are a Site Visitor or a Channel Author and you have concerns about content published about you, see Sections 5 and 9, and Section 4 of our Terms of Service — together they explain that the Account Holder who published the content, not AGP, is responsible for it. You can reach us about content directly at legal@tg.page.

1. Data We Collect When You Create an Account

When you sign in with Telegram, we receive and store your Telegram ID, your username if you have set one, your first and last name as Telegram sends them, and the address of your profile photo. If you sign in by email instead, your email address becomes your sole identifier for the account. Beyond that, the Service itself generates and stores: your chosen interface language, your account role and status, your plan, when your trial started, when you first held our paid plan (a date that, once set, is never cleared), any add-on slots you've purchased, the identifiers Polar gives your customer record and subscription if you subscribe (Section 6), when you accepted our Terms of Service and this Policy, lifetime counts of how many times you've used AI autofill or triggered a manual refresh (these counters are not reset by deleting a project), and your account creation date.

No password. You sign in with Telegram or a one-time emailed link — we never ask for or store a password.

Signing in never merges a Telegram account with an email account. If the same person signs in once with Telegram and once by email, our systems treat these as two separate accounts. Verifying a channel does not change that: the Telegram ID that verifies a channel is kept with that channel (Section 5), never added to your account.

You can link your own Telegram account to an account you sign in to by email. While signed in by email, you can link it from the Account page of the dashboard. Linking needs a Telegram login completed during that same session, and it is refused if that Telegram account already signs in to another account with us. When you link it, we store what we store for a Telegram sign-in: your Telegram ID, your username, your first and last name, and the address of your profile photo, which becomes your account's photo. The username, name and photo address are refreshed each time you sign in with Telegram. From then on, signing in with that Telegram account opens your email account. You can unlink it from the same page at any time. We then remove the Telegram ID, username, name and photo address from your account, sessions already open stay open, and you keep signing in by email. An account that can only be signed in to with Telegram cannot unlink it.

Your profile photo itself is not copied to our servers. We store the web address of your Telegram-hosted photo, and your browser loads the image directly from Telegram when you view the dashboard.

2. Cookies, Sessions, and Login Records

The dashboard at app.tg.page sets six cookies of its own, whatever you answer about Google's tools, all marked httpOnly (meaning page scripts cannot read them), all limited to app.tg.page, and none used for advertising. A session cookie lasts 30 days; it holds a random token, and we store only a one-way hash of that token, never the token itself. A language-preference cookie lasts 365 days and simply records your chosen interface language. A sign-in return cookie is set when you are asked to sign in, lasts at most 30 minutes, records which dashboard page to take you back to, and is deleted once you have signed in. A checkout cookie is set when you come back from Polar's checkout, lasts at most five minutes, records whether your payment has reached us yet and which account it belongs to so the page can tell you, and is deleted once the page has read it. Two sign-in cookies, tg_signin and tg_signin_pending, last at most 15 minutes: the first marks that a sign-in was started in this browser, and the second holds a sign-in that is waiting for you to confirm it with "Sign in as …?"; signing in does not work without them. The consent cookie that tg.page and the dashboard share, the one cookie of ours the dashboard sets only if you accept, and the cookies Google sets only if you accept them, are described at the end of this section.

Your session cookie is scoped only to app.tg.page and is never sent to a published site — including your own custom domain. Published pages are assembled from someone else's Telegram content, and we do not want your dashboard session anywhere near that boundary.

What we store about a session: while your session is active, we hold the IP address and browser user-agent you signed in with, in plain, unhashed form, tied to that session. The session stops working after 30 days. Its record is deleted when you log out, when the cookie of an expired session next reaches us, or when the account is suspended or deleted. We do not yet remove expired session records on a schedule, so the record of an expired session whose cookie never comes back stays until one of those happens. There is no separate long-term archive of it.

Login history: separately, we keep a 90-day record of login attempts against your account — the login method used, whether it succeeded, and the IP address and user-agent used. We record exactly two outcomes: a successful login, or a login refused because the account is suspended. We do not log anonymous failed login attempts. This history is deleted automatically after 90 days, and immediately if you delete your account.

Browser storage: our own code does not write to localStorage, sessionStorage, cookies outside the six above and the two described below, the consent cookie and tg_ga_once, or IndexedDB. One exception: a third-party theming library we use on the dashboard stores your light/dark mode preference under the key theme in your browser's local storage. This happens only on the dashboard, never on a published site.

Published sites set no cookies and write nothing to your browser's storage, full stop — not even the theming preference above.

Google's tools, only if you accept. The first time you visit our website at tg.page — including the pages these documents are published on — or the dashboard at app.tg.page, we ask whether you accept analytics and advertising cookies, with "Accept" and "Decline" offered side by side. Until you choose, and for as long as you decline, Google Tag Manager is not loaded, nothing is sent to Google, and Google sets no cookies. If you accept, both sites load Google Tag Manager, and through it we run analytics and advertising tools to understand how visitors use these two sites, measure the effectiveness of our marketing, and, where enabled, show relevant advertising, including by building audiences based on activity on them. Those tools set Google's own cookies in your browser, and your browser sends Google your IP address, its user-agent string and the pages you visit. You can change your answer at any time: on tg.page, with "Cookie settings" at the foot of every page; in the dashboard, with "Cookie settings" in the account menu or under the language tabs on the sign-in page, or in the "Analytics cookies" section of the Account page, which shows your current choice. A choice made on either site applies to both. If you decline after having accepted, Google's tools stop, Google Tag Manager is not loaded again, and we delete the Google cookies our two sites can reach (those named _ga, _ga_…, _gid, _gat…, _gac_… and _gcl_…). Google Tag Manager never loads on a published site, so none of this reaches a Site Visitor on an Account Holder's domain.

The consent cookie. Your answer is stored in a single cookie, tgp_consent, which holds only v1.granted or v1.denied and no identifier. It is set for tg.page and its subdomains, so that a choice made on our website or in the dashboard holds on both, and it never reaches a published site on an Account Holder's own domain. It lasts 180 days, after which we ask again; deleting it also makes us ask again. Page scripts can read it, because the page needs it to decide whether to load Google's tools.

What reaches Google Analytics from your account, only if you accept. In the dashboard, once you have accepted and signed in, we give Google Analytics our internal identifier for your account: a random code, never your email address, your Telegram ID or username, your name or your domain. It lets Google count your visits from different devices as one person. We also store with your account whether you accepted and the identifier Google Analytics gave your browser (read from its _ga cookie), so that our server can tell Google Analytics when you start a subscription and when a payment succeeds: the plan, the billing period, the amount and currency, and Polar's number for the order. For an account that has not accepted, our server sends none of this. It stops when you decline in the dashboard. A Decline on tg.page takes effect the next time you open the dashboard, and in any case our server stops 180 days after our dashboard last recorded your acceptance.

The sign-in cookie for Google Analytics. If you have already accepted, signing up or signing in to the dashboard sets one more cookie of ours, tg_ga_once, on app.tg.page only. It holds only whether you signed up or signed in and how, with Telegram or by email, and no identifier. It lasts at most 10 minutes, and it lets the page tell Google Analytics about that sign-up or sign-in once. Page scripts can read it, because the page reads it to tell Google Analytics. If you have not accepted, it is never set.

The campaign you arrived from. If the address you arrived at on tg.page names an advertising campaign, through the utm_source, utm_medium, utm_campaign, utm_content and utm_term parameters or Google Ads' gclid, gbraid and wbraid, our links to the dashboard carry those values on with you, whether or not you accepted, and nothing else from the address. tg.page itself stores none of them. Until you answer the dashboard's own prompt, it keeps them only in the memory of the open page and writes none of them to your browser. It passes them to Google Analytics only once you have accepted, and forgets them if you decline, or if you close or reload the page first.

3. What We Collect About Site Visitors

This section covers anyone reading a published site — which is only ever served at an Account Holder's own domain — who does not have an account with us.

We built this deliberately to collect as little as possible. Each page view is logged as a single row containing: which site it relates to and, on a post's own page, which post; whether it was a page or a post view; the page path (cut off after 300 characters); the host name of the referring site — only if it is outside the site, never the full address of the referring page, and cut off after 120 characters; and a timestamp. We do not store, next to this record: any cookie, any visitor or device identifier, any browser fingerprint, the visitor's IP address, or their user-agent string.

A few details worth being precise about. We do briefly look at your IP address, but only to compute a short-lived rate-limiting key that prevents abuse of the analytics endpoint. That key is combined with a random value generated fresh each time our service restarts, expires after 60 seconds, and is never written down next to, or linked with, any analytics event — restarting the service changes the key derived from the same IP, so it cannot be used to track you over time. We record no country: the record has room for a two-letter country code supplied in a header by a network provider, but none of ours supplies one, so for an ordinary visit it stays empty, and we keep no IP-lookup database of our own. We filter out known automated and bot traffic using pattern-matching on the user-agent string. Only visits to a published site at its own domain are counted. The tracking beacon does not run inside an iframe, and only reports a referring page on a page's first load. The Account Holder who owns a site can see aggregate statistics derived from this data — view totals for the last 7 days, the last 30 days and all time, daily views, top-performing posts and top referring sites over the last 30 days — but they cannot see individual visitor records, because none exist.

Retention. Each visitor analytics event is deleted automatically 400 days after it was recorded. The all-time view count the Account Holder sees is kept as a single number for each site, so it outlives the events it was counted from; it identifies no one. Events and the count are also deleted when the project or the account is deleted.

Responsibility for your data as a Site Visitor. If you're reading a published site on the Account Holder's own custom domain, that Account Holder chose the domain, the branding, and the channel content you're seeing. As between AGP and the Account Holder, the Account Holder is responsible for their own site's compliance with the law that applies to their audience, including any disclosures they owe you. AGP acts as the infrastructure and analytics provider behind the scenes. If you have a request about your data as a visitor, you can still contact us directly at support@tg.page and we will address it.

4. Content Retrieved From Telegram

We read a channel's content only at the request of an Account Holder who names that specific channel. When you type a channel's name in the dashboard, our server reads its public web preview once to show you the channel's card — its name, description, photo, subscriber count and whether it has posts — and stores none of it. When you then create a project for that channel, we import its most recent posts, about the last hundred, into a draft that only you and our administrators can see. A channel is published only after you have subscribed to our paid plan and verified control of it (Section 5), and it is public only once you have connected your own domain. We do not operate a search tool, directory, or catalog of Telegram channels, and we do not read channels nobody has asked us to.

All of a channel's content comes from Telegram's own public web preview of the channel (the same page format publicly reachable at t.me/s/<channel>) — the same page anyone can view in a browser. Our background service reads it identifying itself to Telegram with a standard browser-style identifier rather than a custom one; the single read that shows you a channel's card identifies itself as tg.page. While a site is published, we re-read the newest part of its channel's page on a schedule (currently every 15 minutes), and re-read older parts from time to time to keep images and deletions current. A draft is re-read only when its owner asks, and older history is imported only when an owner on our paid plan asks for it. We do not receive a channel's posts through Telegram's Bot API: our bot is told who started it and who added it to or removed it from which channel, and nothing about what a channel publishes. We use the bot only to verify who controls a channel, to reply to the person verifying it, and to send administrative notifications (see Section 5).

For each post, we store the message ID and date, cleaned HTML of its content, hashtags, links to any media, the full content of any poll (the question, every option, and the current vote percentages), the view count shown on Telegram, what the post was forwarded from and what it's a reply to where applicable, and a copy of the original message markup in Telegram's own raw format. For the channel itself, we store its name, avatar, and description.

We keep our own copies of images, but not of video. The first time a photo, a video's cover image or the channel's avatar is opened on one of a site's pages — by a visitor, by the site's owner, or by our own screenshot service (below) — our servers fetch it from Telegram once, convert it to a reduced copy in WebP format (no more than 1,600 pixels on its longer side — we never keep the original file) and store that copy with our storage provider, Cloudflare R2 (see Section 6). From then on the page serves the image from the site's own address, and the visitor's browser does not contact Telegram for it. Video is not copied: a video's address on a published page redirects to Telegram's own media servers, so a visitor's browser connects directly to Telegram to load video, and Telegram can see that visitor's IP address as a result. The same redirect is used, as a fallback, for an image we could not copy — for example, one larger than 20 MB, or one Telegram did not deliver when it was first requested.

If a post is deleted on Telegram, it is removed from the site when a later read of the channel's public page shows it gone — marked removed internally, with its stored text kept until the project is deleted, and automatically reinstated if the same post reappears on Telegram. We can notice a deletion only on a part of the page we re-read: the newest posts are re-read on every scheduled read and older ones only from time to time, so an old post deleted on Telegram can stay on the site. We also keep one screenshot of each project's site, drafts included, which our own service takes by opening the site in a browser and refreshes as the site changes. It is stored as an image in our database, shown to the Account Holder and to our administrators, and kept until the project is deleted — meaning a visual copy of the channel's content, as it appears on the site, is retained by us independent of the live page.

Our copies follow the post. When a post is deleted on Telegram, or a photo is removed from it, our copy is deleted at the sync that notices the change. Copies are also deleted when we block a post, and every copy belonging to a project is deleted when the project or the account is deleted (see Sections 8 and 9); if that deletion fails, the project is deleted anyway and the failure is recorded for us to deal with. Because an image is copied only when it is first opened, images nobody — no visitor, owner or screenshot — has opened are never stored. If an Account Holder replaces the picture inside an album without deleting the post, the copy of the earlier picture may remain until the post itself is deleted.

5. Verifying Who Controls a Channel

Before a channel is published, the Account Holder proves control of it by adding a bot we operate as an administrator of that channel. Proving control is part of our paid plan; a free account cannot start it. The process works like this: the person clicks a unique start link in Telegram, which must be opened within 30 minutes and tells us their Telegram ID; they then add the bot as a channel administrator, and Telegram separately confirms that to us, matching the same ID. For each attempt we store a hashed version of the verification token, its expiry, when the link was opened, the Telegram ID of the person who opened it, when the attempt ended, and, if it failed, why. An attempt that ended is cleared 14 days after it was started. An attempt that never ended — one replaced by a newer attempt, or one whose link was opened but whose bot was never added — is kept until the project is deleted.

Verifying control is not what lets us read a channel. Its most recent posts were already imported into your draft when you created the project (Section 4). Verification is what lets you publish them, and it applies only to the channel you verified, not to any other channel.

A verified project retains, for as long as it exists, when it was verified, the Telegram ID of the person who completed verification, the channel's internal chat ID, and, if applicable, when the bot was later removed. An administrator who revokes a verification clears the first three.

Verifying a channel never attaches a Telegram identity to your account. The Telegram ID of the person who opens the start link is stored with the verification attempt and, once the channel is verified, with the project, as described above — never with your account. If you sign in by email and want to sign in with Telegram too, you link it yourself from the Account page (Section 1).

If our bot is later removed from a channel, we message the Account Holder on Telegram to let them know — at their own Telegram ID or, if we have none, at the one that verified the channel — and our regular syncing of that channel stops immediately, as do manual refreshes. An hourly pass may still re-read parts of the channel's page around posts we already hold, to keep their images working. The site stays online, but after the period that message names (14 days unless we change it) it is withdrawn from search engines. We may require the channel to be verified again before syncing resumes. A given channel can only be verified by one account; if two people attempt to verify the same channel, the first to complete the process controls it.

6. Who We Share Data With

Reading a channel's public web preview, as described in Section 4, means requesting it directly from Telegram (t.me) — this exposes the channel name and our own server's IP address to Telegram, but not any data about you or your visitors. Images on a published page are served from our own copies, so a visitor's browser does not contact Telegram for them. Video — and, as a fallback, an image we could not copy — is still fetched by the visitor's browser straight from Telegram's media servers, which means in those cases the visitor's IP address goes directly to Telegram (see Section 4). Making a copy means our own server fetches the image from Telegram once, which exposes our server's IP address to Telegram, but not any data about you or your visitors. If you sign in with Telegram, the sign-in page itself runs on Telegram's own domain (oauth.telegram.org), in a popup or in your browser window. Beyond that, our contact with Telegram's Bot API (api.telegram.org) covers confirming the bot's own identity, sending messages — to the person verifying a channel, to an Account Holder whose channel has removed our bot, and to our own administrators — and, through our registered webhook, being told when someone starts our bot or adds it to or removes it from a channel. It never carries a channel's posts.

We use Resend to send the one-time login link emails — the only email the Service sends — which means your email address and that link pass through their systems.

AI autofill runs only when you press its button in a project's SEO settings, once per press; nothing is sent in the background, and there is no setting that turns it on. Each press sends the channel's name and username, its description (cut to 600 characters), the site's language, and up to 30 of its posts sampled across the history we hold, each turned into plain text and cut to 300 characters, to OpenRouter, which runs the request against Google's gemini-2.5-flash-lite model. An account on the free plan can do this once. We use this only to generate suggestions for your own site — its SEO title, description and keywords — and not to train, fine-tune, benchmark, or otherwise develop any AI or machine-learning model of ours, and not to build any dataset from Telegram content. The model doesn't act on its own: it returns suggested text, which fills the form for you to review, and nothing is saved until you save it, through the same content-cleaning as anything you type by hand. We don't control, and this Policy doesn't describe, what OpenRouter or the underlying model provider do with a request on their own systems beyond fulfilling it — consult their own privacy terms if that matters to you.

While your site is published on a live custom domain and not withdrawn from search, the addresses of its home page and of new or removed posts are pushed to IndexNow (api.indexnow.org), a shared protocol that forwards new or updated URLs toward participating search engines. We deliberately do not publish which search engines participate, because the list changes over time — please don't assume it means any specific search engine. Once a URL is submitted this way, it cannot be recalled — this is a one-way push, and neither removing the page nor changing robots.txt afterward undoes the submission. Separately, if you choose to enter a Google Search Console ownership-verification code in your SEO settings, we place that code in a tag on every page of your published site, where Google reads it; we send Google nothing ourselves — this is entirely optional and at your discretion.

If you subscribe, Polar.sh acts as our payment processor and merchant of record (see Section 6 of our Terms of Service). We send Polar our internal identifier for your account and, if your account has one, your email address; you give your payment details to Polar directly, and we never see your card. From Polar we read your subscription's status, product, billing period and dates, the amount and currency charged, and Polar's customer record, including its email address, which we use to match a payment to your account and do not store. We keep Polar's customer and subscription identifiers and a history of your plan changes, with the amount and currency of each.

Infrastructure we run on, as processors rather than independent recipients: Railway hosts our application servers, background jobs, and our database and cache — including Postgres and Redis — on Railway's servers in the United States and the Netherlands. A DigitalOcean server we operate in Frankfurt, Germany (fra1) receives every request to a custom domain and passes it on to our application servers together with the visitor's IP address, and Let's Encrypt or, if that fails, ZeroSSL issues TLS certificates for those domains (see Section 7). Cloudflare R2 stores our reduced copies of the images on sites (see Section 4) in a private bucket we asked Cloudflare to place in Western Europe — a location hint, not a guarantee; visitors are served those copies through our own servers and never connect to Cloudflare for them. Cloudflare also hosts our website at tg.page, where these documents are published, and so receives the IP address and browser details of everyone who visits it; that website sets one cookie of its own, the consent cookie, and loads Google Tag Manager only if you accept, as Section 2 describes.

We do not sell your data, and we do not share it with data brokers. The one advertising company that receives data about visitors is Google, through the tools described in Section 2, on our own website and dashboard and only if you accept them — never on a published site.

7. Custom Domains — What This Means If You Connect One

If you're an Account Holder connecting your own domain on a paid plan, your domain, its DNS zone, and any email service tied to it remain entirely yours. We ask you to create DNS records pointing at our infrastructure — two for a whole domain, one for a subdomain; we never ask for or take delegation of your domain.

TLS termination for your domain happens on infrastructure we operate, meaning the private key for your domain's certificate is generated and held on our server, not yours. This is standard for a hosting provider, but you should know it rather than assume otherwise. Certificates themselves are issued by Let's Encrypt or, if that fails, ZeroSSL — both public certificate authorities — and as with any certificate from any public authority, your domain name is recorded in public Certificate Transparency logs — a feature of how web certificates work generally, not something specific to us, but one that means your domain becomes publicly discoverable through CT-log tooling once you connect it.

We are still finalizing exactly what our edge server logs about requests to custom domains and for how long; we will update this section once that is settled rather than assert a retention period we have not yet implemented. One domain can be connected to exactly one project, and vice versa.

8. How Long We Keep Things

Most of what we hold about you has a defined lifespan. A session, including the raw sign-in IP recorded with it, stops working after 30 days or when you log out, and its record is deleted as Section 2 describes. Login history — IP address and device — lasts 90 days. A channel-verification attempt that ended is cleared 14 days after it began; one that never ended stays until its project is deleted (Section 5). Background job failure logs last 30 days. A magic-link email record, including the email address it was sent to, is deleted 24 hours after it was created, whether or not the link was ever opened. A visitor analytics event is deleted 400 days after it was recorded, and each site's all-time view count is kept as a number for as long as the project exists (Section 3).

One thing is different, and we're calling it out rather than letting it blend into the rest of the list: trial records of closed accounts are kept indefinitely — see Section 9. A magic-link email record is not tied to any account, so deleting your account does not reach it, but it is gone within a day of being created in any case.

Everything else tied to an active project — posts, stored image copies, page screenshots, SEO settings — is kept for as long as the project exists. On the free plan, the trial runs for 7 days from when you create your first project; the project is then frozen — paused, and visible only to you — and if the account has never held our paid plan, its projects are deleted 30 days after that. An account that has ever paid us is never cleared this way: when its subscription ends, its oldest project stays published and the others are paused until it subscribes again.

9. Deleting Your Account

You can delete your account yourself from the dashboard once Polar is no longer billing you for a subscription (cancel it first), or we may delete it as described in our Terms of Service. Doing so removes all of your sessions and login history, every project and its posts, the stored copies of their images, SEO settings, sync state, all analytics collected on your sites, page screenshots, verification attempts, connected-domain records, and related routing data.

Some records survive account deletion, on purpose, and we want to be direct about exactly what and why, rather than imply deletion erases every trace of you. An account-closure log retains your username or email address, who closed the account, how many projects and sites you had, when your account was created, your plan, and the closure date. An administrative-action log retains labels identifying who performed an admin action and who it affected, which may include a name, email, or domain name depending on the action. A plan-change history retains your account identifier and label, what plan you moved from and to, who changed it, the amount and currency of any payment behind it, and any note attached. Background job failure logs may still reference a site you owned, for up to 30 days after the failure, independent of account deletion. A record of each domain we stopped serving for you — its hostnames, the IP address we had asked you to point it to, the project's title, why we stopped, whether we told you, and your account's internal identifier — is kept for 90 days after your account is deleted, so that a notice we sent or a question about that domain can still be answered, and is then removed. A trial record keeps the closed account's email address and Telegram ID — including a Telegram ID linked from the Account page (Section 1), where the account had one — not in clear but as keyed one-way hashes (HMAC-SHA256 under a secret key used for nothing else), together with the date the account's free trial started, if it had started, and the date the account closed. When a new account signs in with a matching email address or Telegram ID, we compute the same hash, and a match means the new account continues the closed account's trial rather than starting a fresh one: a trial already used stays used, a running one keeps only its remaining days, and one never started is still available in full. These hashes are not anonymous — we hold the key, so we can check whether a given address or ID is on record. And, as described in Section 8, magic-link email records are structurally separate from your account — keyed by email address, not by account ID — so account deletion does not reach them; they are deleted 24 hours after they were created in any case.

We keep these because closed-account and administrative records need to remain attributable — including, in the closure log, to the specific person who requested a closure — for our own accountability and dispute-resolution purposes. We do not keep them to continue using your data for any other purpose. The trial record is kept for a different reason: only to decide whether a new account is entitled to a free trial, and for nothing else.

We do not currently offer a self-service "download everything you have about me" tool. If you would like a copy of the data we hold about you, contact support@tg.page and we will provide it manually.

10. Security

Session tokens, magic-link login tokens, and channel-verification tokens are all generated the same way and stored as one-way hashes, never in plain text — the raw token itself never sits in our database, only a hash of it. Beyond that, we do not currently apply field-level encryption to database contents, and we do not currently offer two-factor authentication — sign-in security rests on the security of your Telegram account or your email inbox. We do not currently maintain automated backups of our production database. We are describing our security posture as it stands, not as we might wish it to be, and we will update this section as it changes.

A practical note about login links: the emailed link that signs you in contains the raw access token as part of its address. It is single-use and expires after 15 minutes, but until it does, or until it is used, anyone who has that link can sign in as you — including someone who intercepts the email, finds it in your sent or forwarded mail, or reads it from a mail server's own logs. Treat a tg.page login email the way you would treat a temporary password: don't forward it.

11. Administrative Access

A small number of authorized administrators can, where necessary to operate or moderate the Service, see projects and posts belonging to any account — including drafts, page screenshots and posts that have been hidden from public view — connected domains, active sessions and login history including IP addresses and devices used, email addresses and Telegram IDs, and plan and usage information. This access is granted only by setting it directly in our database, not through any in-product control, and the administrative panel refuses to act on an administrator's own account. Administrative actions — including removing a domain — are generally not announced to the affected Account Holder individually, though they will usually be visible as a change in what the account can do.

12. Your Rights

Depending on where you live, you may have rights over the personal data we hold about you — for example, to access it, correct it, delete it, restrict or object to its processing, or receive a copy of it in a portable format. We aim to honor these rights for every user regardless of location, as a matter of policy, not only where a specific law requires it.

How to exercise them: write to support@tg.page. Where a request can be handled through the dashboard — for example, deleting your account, Section 9 — we'll point you there; otherwise we will process it manually within a reasonable time. We do not currently have an automated self-service tool for access or export requests — see Section 9.

Our basis for processing your data is, depending on the data: performing our contract with you (account, hosting, and publishing functionality, and AI autofill when you ask for it); our legitimate interest in operating, securing, and improving the Service (for example, login-attempt records and rate-limiting); your consent, for Google's analytics and advertising tools on our website and dashboard (Section 2), which you can withdraw at any time through "Cookie settings" on tg.page or in the dashboard, as Section 2 describes, and where a feature is opt-in (for example, entering a Google Search Console verification code); and legal compliance, where applicable.

Age. The Service is intended for users 18 years of age or older, matching the eligibility requirement in our Terms of Service. We rely on the representation you make when creating an account and do not independently verify age.

13. International Data Transfers

Because our infrastructure, our team, and the third parties listed in Section 6 are not all located in one country, using the Service typically involves your data being processed outside the country you're in — including, for many users, transfer to or processing within the United States, the Netherlands and Germany. Where applicable law requires a specific safeguard for such transfers, we intend to rely on the mechanism appropriate to that transfer, such as the relevant third party's own standard contractual clauses; this section will be made more specific once our data-transfer arrangements with each processor are finalized.

14. Changes to This Policy

We may update this Privacy Policy from time to time. If a change is material, we will provide notice before it takes effect, in the same way described in our Terms of Service. The "Last updated" date at the top of this page always reflects the current version.

15. Language

This Privacy Policy is written and published in English, and the English version is the authoritative one. Where we make a translation available, it is provided for convenience; if it differs from the English version, the English version is the one that describes what we actually do.

16. Contact

Questions about this policy, or to exercise a privacy right described in Section 12: support@tg.page.

AGP LLC
1712 Pioneer Ave Ste 500
Cheyenne, WY 82001
USA