Prepared 6 October 2026. An effective date has not yet been set. Details marked “pending confirmation” are still being finalized. App practices described as proposed remain subject to confirmation before adoption.
This draft distinguishes the public website's confirmed practices from the proposed notice for app accounts. Part A describes the website as reviewed on 6 October 2026. Part B must be verified against the actual beta before account collection or participation begins; it is not a claim that every listed feature or safeguard is already implemented.
1. Organization and contact
MOBEET TECHNOLOGIES PRIVATE LIMITED is responsible for the processing described in this policy. Its registered address is C/o Surja Kanta Sinha, Vidyanagar, Unakoti, Kailashahar, North Tripura, Tripura, 799279, India, and its operating country is India. This policy is to be applied under the Indian privacy and information-technology provisions in force, including the applicable 2011 sensitive-data rules and the Digital Personal Data Protection Act, 2023 as its relevant provisions commence. It does not represent that every provision of that Act is already in force.
Privacy contact: reachout@mobeet.com
General contact: reachout@mobeet.com
India Grievance Officer: Grievance Officer name — pending confirmation
Grievance contact: Grievance Officer contact details — pending confirmation
Statutory submission and appeal route: statutory grievance and appeal route — pending confirmation
Public product website
2. Information collected through the beta request form
When you submit a beta access request, the website sends your email through its server to the same Google Form and linked Google Sheet used for contact enquiries. Your email fills both Name and Your email, the topic is Private beta access, and the message is Requesting private beta request. Google records the submission time, and the website includes a request identifier and privacy-notice version for receipts and retries. An unchanged retry with the same request identifier reuses the response for 24 hours; a separate request can create a separate response.
New beta requests are not added to the website's Cloudflare D1 database. Earlier beta records remain in that database with their email, request timestamp and privacy-notice version. These records are used to manage beta access enquiries.
The request does not create an app account, guarantee an invitation or subscribe you to general marketing. The form does not send an automatic invitation email. We use a beta request to manage the enquiry and communicate about access if appropriate. We must obtain any separate permission required before using the address for another purpose.
Do not provide someone else's email address without authority. You may ask for correction or removal of your request at reachout@mobeet.com.
3. Contact form and email correspondence
The contact form sends the name, email address, selected topic and message you enter through the website server to Google Forms and a linked Google Sheet for Mobeet to answer your enquiry. Google records the submission time; a request identifier and privacy-notice version support confirmed receipts and retry protection. The website uses a server-side signed connection and does not expose its signing credential to visitors. Contact messages are not stored in browser storage or the beta-request database.
The page identifies the submission method before you send anything. When the button says Send message, it accepts an online message. When online submission is not configured and the button says Open email draft, it prepares an email on your device for you to review and send. The form does not send automatic emails or subscribe you to marketing.
If you send the email, your provider and the recipient's provider process the message. Mobeet receives the information included in the email and may use it to answer the enquiry and manage the related correspondence. Do not include passwords, identity documents or unnecessary sensitive information in an initial message.
4. Technical delivery and infrastructure
Delivering the website involves network requests. Hosting and network providers may process IP addresses, requested pages, browser or device information and timestamps for delivery, security and operational purposes. The earlier beta-request table contains email, request timestamp and privacy-notice version; the website does not write IP addresses or device details to that table. Current contact and beta form responses use the Google Form fields described above.
The website is hosted through Sites on Cloudflare infrastructure. Google Forms, Google Sheets and Google Apps Script process online enquiries. Mobeet receives direct email enquiries at reachout@mobeet.com. Specific provider processing locations, email-provider arrangements, access permissions and infrastructure log retention remain to be confirmed before this draft is adopted.
The final provider list, infrastructure logging practices, access arrangements and processing locations must be completed here: provider processing locations and email arrangements — pending confirmation. Data used by providers for their own independent purposes may also be subject to their notices, where applicable.
5. Analytics, cookies and device access
The website application code contains no analytics, advertising pixels, tracking cookies or local-storage collection. It does not request camera, microphone, contacts or location access. This description concerns Mobeet's website code and does not assert that all hosting or email infrastructure processes no information.
If website collection changes, we will update the notice and provide any required choices before introducing the new processing. A beta request is not consent to tracking or unrelated advertising.
6. Website purposes and processing grounds
Website data is used to receive beta requests, manage access enquiries, answer correspondence, deliver the website and address security or legal issues. The lawful grounds applicable to each purpose depend on the operating jurisdiction and must be specified before adoption: website processing grounds — pending confirmation.
Where consent is required, it must be specific to the relevant purpose and capable of withdrawal. Accepting website terms does not supply blanket privacy consent. Refusing general marketing must not invalidate an otherwise valid beta enquiry.
7. Website recipients, retention and transfers
The final access arrangements must limit website records to authorized people and providers who need them for the stated purposes. A legally required disclosure or a necessary rights or security response may also involve the appropriate recipient, subject to applicable safeguards. Those arrangements must be verified before adoption.
The final notice must state the retention periods or clear criteria for beta enquiries, email correspondence and infrastructure logs: website retention schedule — pending confirmation. Requests that are no longer needed should be deleted or anonymized, subject to a necessary and lawful retention exception.
Processing locations and any international-transfer mechanism must be verified for each relevant provider: international transfer arrangements — pending confirmation. This draft does not claim a particular certification, transfer agreement or data-residency guarantee.
Proposed notice for Mobeet app accounts
The following sections provide the proposed notice for account-based services. Before activation, remove inapplicable categories, identify enabled features and providers, and confirm the collection and safeguards described. Product mockups and architecture proposals do not establish actual data practices.
8. Account and profile information
Where account registration is enabled, we process the details required to create and maintain an account, such as an email address, account identifier and authentication information. If phone registration or an external sign-in service is enabled, we process the information needed for that method and explain the relevant provider's involvement.
Where date of birth or other eligibility information is required, it is used for age and feature eligibility and any legally required safeguards. Date of birth must not be shown as a public profile field. Any method for verifying age, parental authorization or identity must be described before it is used: age and identity verification practices — pending confirmation.
Profile information may include a display name, biography, photograph and selected interests. The product must identify which fields are required, optional, public or visible to a restricted audience before publication.
9. Challenges, submissions and interactions
Where enabled, we process the challenge descriptions, images, video, captions and other material you choose to submit. We also process participation state, submission receipts, voting or reaction activity, and the account relationships needed to provide supported social features.
Public content and associated profile information may be visible to other users and people outside Mobeet. Restricted content is shown to its permitted audience, subject to operational access needed to provide and moderate the service. Public content can be captured or copied by others; removing it from Mobeet may not remove those independent copies.
If messages are enabled, their content and associated delivery information are processed for the purposes explained at activation. The final notice must state applicable moderation access and retention and must not imply end-to-end encryption unless that protection is actually provided: message processing and access — pending confirmation.
10. Camera, microphone, location and optional information
Where a recording or photograph feature requires camera or microphone access, the permission request must explain its purpose. Device permission is separate from confirmation to publish. Disabling a permission may prevent the associated feature while leaving unrelated features available.
Location, GPS routes, contact-book access, health data and identity documents are not established collection categories merely because they appear in a design proposal. Any enabled collection must be identified in a feature notice, including whether collection occurs in the background, what is uploaded, what is retained and what becomes visible: optional and sensitive data practices — pending confirmation.
Do not assume that a route or file's embedded location information has been removed. The product must state any actual redaction controls before representing content as location-protected.
11. Device checks and service records
Supported device checks may assess whether selected proof meets a challenge's format or framing requirements. A local check is distinct from uploading media and from server confirmation that an entry has been submitted. The final notice must identify which media and check results stay on the device and which are sent to Mobeet: local checks and upload data flows — pending confirmation.
Where necessary for account services, we process relevant technical records, such as request timestamps, application version, device or browser information, error records and security events. The actual categories, collection tools and retention must be specified. This draft does not establish facial recognition, biometric identification or independent server verification of a performance.
For any lawful paid feature or reward, the notice must identify the payment or reward provider and the information processed to administer the transaction, such as transaction references, amounts, billing details, delivery information and tax or eligibility records. State what Mobeet receives, what the provider collects directly, any identity checks, recipients and retention before collection: payment and reward data and providers — pending confirmation. This draft does not establish a wallet or a need to collect complete card credentials, bank passwords or identity documents.
12. App processing purposes and lawful grounds
The proposed purposes are account administration, feature delivery, challenge participation and results, user-selected personalization, communications about the service, support, safety and moderation, security, and legal compliance. Data must not be collected merely because it might be useful later.
Before adoption, map each actual category and purpose to the lawful ground required in the relevant jurisdiction: app purposes and processing grounds — pending confirmation. For Indian processing, identify the consent or other use authorized by the Indian provisions applicable at the time. Do not assume that a contractual purpose or a generic legitimate-interest claim is an independent basis under Indian law. Additional grounds recognized in another jurisdiction must be identified only where that law applies.
General marketing and any optional sensitive processing require their own applicable notice and choice. A content licence does not replace a lawful privacy basis.
13. App recipients and independent creators
Depending on the features enabled, information may be available to your chosen audience, the creator administering a challenge, and authorized service providers carrying out hosting, media delivery, authentication, support, security or moderation. Creators do not automatically receive your private email address, date of birth or identity documents.
The provider categories, actual recipient arrangements and permitted access must be verified before adoption: app providers and recipients — pending confirmation. We may make disclosures required by law or lawfully necessary to address a rights claim or serious safety issue. A business transfer requires appropriate safeguards and notice where required.
A creator who independently collects information outside Mobeet is responsible for their own collection and notice. Publishing a challenge does not make participant data the creator's property or automatically appoint Mobeet as their data processor.
14. Advertising, automated processing and additional uses
The current public website has no analytics or advertising trackers in its application code. The app's analytics, advertising, sale or sharing practices must be stated expressly before adoption: app analytics, advertising, sale and sharing practices — pending confirmation. Do not infer those practices from the website.
The final notice must identify any automated ranking, personalization or moderation that materially affects users, its purpose and the review or choice provided where applicable: automated processing practices — pending confirmation. A moderation review process does not establish that an automated system is currently in use.
The proposed service-operation content licence does not authorize training a general-purpose AI model on user content. A distinct data use must have an appropriate notice and lawful basis, with separate consent where required.
15. App retention, deletion and security
Retain personal information only for the stated purposes and necessary lawful exceptions. The approved schedule must specify periods or clear criteria for account details, submissions, interactions, messages, support records, moderation evidence, technical logs and backup deletion: app retention and backup schedule — pending confirmation.
Account closure, challenge withdrawal and content deletion are separate actions. Explain what each action removes and any records that remain for a necessary legal, safety or rights purpose. Retained material must not be made public simply because it remains in a backup.
Use proportionate access controls and security measures appropriate to the actual service. Confirm the measures and provider responsibilities before adoption: security measures and incident process — pending confirmation. No service can promise absolute security. Any required incident notice must follow applicable law.
16. Children and age restrictions
Mobeet accounts, publishing, challenge participation and submissions are restricted to people aged 18 or older. People under 18 are not eligible, even with parental or guardian permission. Do not provide a minor's details to create an account or submit a minor's attempt through an adult account. The actual age-assurance process must be disclosed before it is used.
The public website does not create accounts or collect dates of birth. Beta requests are intended for adults, but the form does not itself verify age. If you believe a child has supplied information in circumstances that are not permitted, contact the privacy contact or reachout@mobeet.com. We will assess the request and take the action required by applicable law, including deletion or other protective steps where appropriate, subject to a lawful evidence-preservation requirement.
Restrictions on accounts do not remove protections for children who may appear incidentally in content or be the subject of a report. Such content must meet the safety, consent and privacy rules. Guardian permission for an incidental appearance does not create an exception to the account or participation age limit.
Requests and changes
17. Your choices and rights
Depending on applicable law, you may have rights to access information, correct it, request deletion, obtain a portable copy, restrict or object to processing, withdraw consent, and challenge certain automated decisions. Where applicable, you may also have specific rights concerning advertising, sale or sharing. We will explain any legally applicable exception when responding.
Contact reachout@mobeet.com. Provide enough information to identify the relevant record and request. We may ask for proportionate verification; do not send identity documents unless a secure and justified process has been provided.
Withdrawal of consent does not affect processing that was lawful before withdrawal. Disabling a necessary permission may affect the related feature. The final notice must identify the applicable response periods, authorized-agent procedure and regulator or grievance route: rights request procedure and response periods — pending confirmation. You may complain to a competent authority where the law provides that right.
18. Policy changes
We will publish the date of an adopted policy and provide appropriate notice of material changes. A new collection purpose, device permission or feature must be explained before the relevant information is collected, with renewed consent where required. A later policy version does not retroactively authorize an undisclosed use.