Privacy Policy

This document describes what data GeckoChat ("we", "the platform") processes, why, who it is shared with and how a person can manage it. We describe only what the platform actually does.

1. Two roles of GeckoChat

Platform clients are project owners and the members of their teams. For the data needed so that a client can sign in to the dashboard, use the platform and pay for a plan, GeckoChat itself decides how the data is processed. Sections 2–3 and 5–8 describe this.

People in clients' projects are users of bots and sites, buyers and subscribers. Their data (bot contacts, variables and tags, orders, consents, conversations) reaches the platform because a client built a project on it. Here the client decides why and how the data is processed, and the platform processes it on the client's behalf: it stores it, delivers messages, computes statistics, and runs automation and the project's AI agent. The client is responsible to their own people for the lawfulness of collection and for informing them. If you use someone's bot or site and want to know what is stored about you, or want your data deleted, contact the owner of that project first; we will help them fulfil your request (section 9).

2. What data we receive

Signing in

There are three ways to sign in to the platform; one profile can have several of them.

• Telegram. We receive the Telegram identifier, name, username and profile photo that Telegram passes to our bot. The photo is kept in the platform's avatar cache.
• Google. See section 4.
• Email. We receive the address and send it a one-time sign-in code; the code is valid for 10 minutes.

Sessions and devices

After sign-in a session is issued. It lives in a protected cookie (__Host-gecko_client for the dashboard, __Host-gecko_user for the personal account, __Host-gecko_site for project sites, __Host-gecko_public for a guest of the website). The cookie is readable only by the server (HttpOnly), is sent only over HTTPS and is not used for advertising. A session lasts 30 days from last use. For each session we store the IP address and user-agent so that we can show you a list of devices and let you close someone else's session; the approximate location from the IP address is determined from a local GeoLite2 database on our servers, and the address is not sent anywhere for this.

During a Google sign-in a service cookie __Host-gecko_google_… is set for a short time (10 minutes); it protects that sign-in only.

The interface language is remembered in the NEXT_LOCALE cookie. View settings, drafts and the queue of events of our own analytics are kept in your browser's local storage (localStorage, IndexedDB).

Website analytics

We run our own analytics of the platform's funnel: visits to the website and the dashboard, events (sign-up, bot connection, payment), the referral source and time on page. A visit record does not contain the raw user-agent, city or coordinates; "phone or computer" is derived from the screen width, and the referral source is stored without address parameters. If you are signed in, the visit is linked to your profile. We do not use third-party advertising or analytics services on the website or in the dashboard.

Live view of pages

The platform can show an operator a page the way the visitor sees it: your screen and typed text are replayed to the operator in real time. This covers the website and documentation, the client dashboard and project sites.

• What is visible. The page content, input into fields and actions on the page. Fields with passwords, one-time codes and bank card data, as well as fields the platform itself marks as secret (for example provider keys), are replaced with dots right in your browser: the original never reaches our server. Any other typed text is visible as is. Private messages between users (the /messages section) are not recorded at all.
• Who sees it. A platform administrator sees the platform's dashboards and pages and project sites; together with the recording they can see your IP address, country, city, device, browser and user-agent. A project owner and its administrators see only their own project's sites, and not the IP address: they are shown the country, city, device, browser, system and user-agent.
• When and for how long. Live view is off by default. An operator turns it on for a chosen area (the platform dashboard or a project) for an hour per activation (an operator can turn it on again); the operator's connection dropping or a server restart turns it off. The recording is not saved: there is no archive and no replay of the past, and while it runs the events live only in the server's memory.
• Visitor's choice. Consent is not requested for live view and the visitor has no switch. If you do not want to be seen this way, do not enter data on the page and write to support (section 9).

For project sites the client decides whether to turn live view on for their own site and is responsible to their visitors for informing them; the platform processes the data on the client's behalf (section 1).

Private messages and notifications

• Private messages between users are encrypted on the participants' devices (end-to-end encryption); our server stores encrypted messages and files and cannot read their text. The platform knows who is connected to whom and stores the device data needed for delivery.
• Push notifications are turned on only by you. For them we store your browser's subscription, tied to your session; notifications are delivered by your browser's push service. You can turn them off in your profile; deleting a session deletes the subscription.

Project, payments and logs

• Project data. Bots, sites, flows, broadcasts, the knowledge base, files, and the data of people in the project described in section 1.
• Plan payment. Plans are paid through payment providers (section 5). Payment details are entered on the provider's page, not with us. We receive the payment status, the amount and, when the provider requires it for a receipt, the payer's email address. Secrets of payment providers that a client connects to their project are stored encrypted.
• Logs. Server request and error logs are kept for about 30 days. Secrets and content that belongs to people in a project (message texts, names, phone numbers, email addresses, chat identifiers) are excluded from them. Separately we keep a journal of actions in a project — who performed which action (dashboard, API, AI agent) — so the owner can review what happened.

3. Why we use it

Only to make the platform work: sign-in and account protection, showing the list of devices, running clients' projects, delivering messages and broadcasts, accepting payment for a plan, support, troubleshooting, and measuring how our website performs. We do not use this data for third-party advertising.

4. Google account data (Google user data)

What we request. When you sign in with Google, the platform requests three basic scopes: openid, email and profile. This is identification and basic profile information; we do not request access to Gmail, Drive, Calendar, contacts or any other data in your Google account.

What we receive and store.

• the unique identifier of the Google account, used to recognise you the next time you sign in;
• the email address and a flag that Google has verified it;
• first and last name.

We do not read or store your Google profile photo. We do not store or use an access token for Google APIs: the platform receives only proof of identity (an ID token) from Google and, once it is verified, does not call Google again.

Why. Only so that you can sign in to the platform or to a project's site and so that this sign-in method is linked to your profile. A Google address is not consent to marketing emails: a project's marketing emails are received only by those who subscribed to them separately and can unsubscribe at any time. Service emails (for example a receipt or granting access) are sent by a project's flow to any verified address, including one received from Google, without a subscription and without an unsubscribe link.

Signing in on a project's site. When you yourself choose to sign in with Google on someone's project site, the owner of that project receives your name and verified address as a contact of their project: this is part of the sign-in you chose, and they see it just like the data of any other sign-in method on a site. The project then processes this data itself (section 1). The contact's name and username are available to the project's AI agent when it browses the people of the project, and so may end up in a request to the AI provider (section 5); the email address is not a separate field in those cards.

What we do not do. We do not sell Google data and we do not transfer it to third parties, except where needed for the sign-in to work (section 5), required by law, or happening at your choice to the owner of the project whose site you signed in to. We do not use it for advertising, for profiling for advertising, or to train machine learning models.

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

How to revoke access. You can revoke GeckoChat's access at any time on Google's page of third-party apps with access to your account, and unlink Google from your profile in the profile section of the dashboard (if the profile keeps another sign-in method). A request to delete the Google data we stored can be sent to support (section 9).

5. Who we share data with

The platform uses third-party services; each receives only what its task needs.

We do not control the rules of these services; their terms and policies apply alongside this document. The GeoLite2 (MaxMind) database is downloaded to the server as a file; no personal data is sent to MaxMind.

Data may also be disclosed where the law requires it.

6. How long we keep data

• One-time email sign-in codes — 10 minutes; service records of a started Google sign-in — up to a day after they expire.
• Ended sessions — 30 days, then deleted.
• Server request logs — about 30 days.
• A project site guest who left no trace (no visit, event or account) is deleted after 90 days without visits.
• Visits and events of our analytics are not limited in time.
• Live view of pages is not saved: only the running stream stays in the server's memory, for no longer than the time it is on (up to an hour per activation).
• Profile, project and project people data is kept while the profile or project exists or until it is deleted (section 9). The platform currently sets no separate periods for other data.

7. How we protect data

Sessions travel in protected cookies, one-time tokens are stored as a hash, payment providers' secrets are stored encrypted, and access to a project is determined by the role in it. No protection is absolute, so we do not promise complete invulnerability.

8. Your data and your choices

• In your profile you can see and close your sessions, turn off push notifications, link another sign-in method, or unlink Google, Telegram and email (the last sign-in method cannot be unlinked).
• You can withdraw a subscription to a project's emails at any time.
• A project owner can delete a bot, detach a channel or archive a project.
• In Telegram you can stop and block any bot.

9. Deleting data and requests

The platform does not yet have a self-service button to delete a profile completely. To have your profile, Google data or any other data about you deleted, write to support: @GeckoSupportBot. If your data is in someone's project, contact the project owner first: they decide which data about you to keep, and we will help carry out the request.

10. Changes

We may change this document. The date of the current version is shown at the top of the page; new rules apply from the day they are published.

11. Contacts

The operator of the platform is GeckoChat. For any questions about data write to @GeckoSupportBot.