1. Overview and Purpose
This Privacy Policy explains how Administrator collects, uses, stores, protects, and discloses information when visitors access our public website, when resellers or administrators sign in to the control panel, and when end users install or activate the Android application that connects to our device management platform. The goal of this document is to make our operating model understandable to customers, resellers, sub resellers, administrators, and support staff who rely on the panel for day-to-day business activity. Because the platform includes device registration, activation codes, DNS assignment, expiry management, and reseller account controls, privacy expectations have to be described in a practical and transparent way rather than with vague legal language.
Our service is designed around a panel-first workflow. A customer installs the app, the device appears in the panel, a code is generated or assigned, the device is activated, and the panel then routes the device to the correct assigned service path. The panel may also push supported app preferences such as STB model, media player, overlay behavior, and reload profile commands. That means the platform has to process account details, device identifiers, configuration preferences, billing-related information, and operational logs. We do not believe trust is created by hiding these mechanics. Instead, this policy lays out what information is involved, why we use it, which users can see or manage it, and how long it remains part of the platform. If you use the service as an administrator, reseller, sub reseller, support contact, or customer, this policy is meant to help you understand the exact privacy boundaries of the system.
2. Information We Collect
The information collected through the platform depends on the role of the person using it. Public site visitors may only provide voluntary contact actions such as clicking a Telegram or WhatsApp support link, downloading the Android app, or submitting login credentials. Panel users such as admin, reseller, or sub reseller accounts provide more structured information, including username, password, display name, support contact details, role permissions, DNS slot configuration, pricing settings, credit balances, package settings, session data, and two-factor authentication settings where enabled. These records are needed to operate the reseller business model that the panel was built to support.
When the Android application is installed or launched, the platform may process device-related information needed to activate and route the installation correctly. That can include the generated device ID, the app-generated MAC-style identifier, activation code status, activation date, expiry date, assigned DNS slot, default portal assignment, current or assigned STB model, media player choice, overlay setting, reload command token, and device status such as pending, enabled, suspended, or expired. We may also store timestamps related to app registration, login events, session activity, renewals, plan changes, code generation, support actions, and API requests. If a panel user enters customer notes, support comments, reseller notes, or billing remarks, those user-provided records may also be stored within the system as part of regular operations.
3. Why We Use This Information
We use information because the platform is operational by design. Device identifiers are used to detect new installations, prevent duplicate confusion, enforce activation status, route the right DNS or service destination, and associate the device with the correct admin, reseller, or sub reseller workflow. Account information is used to authenticate access, protect role boundaries, show the right management controls, and preserve business ownership over the devices and customers under each user. Billing and credit information is used so that administrators can allocate resources, resellers can manage stock or growth responsibly, and plan-based renewals can be tracked over time.
We also use collected information for platform maintenance, security monitoring, fraud prevention, and service quality improvement. For example, login attempt history helps detect abuse. Session records help administrators review active access. Audit logs help trace device changes, DNS changes, password actions, profile updates, remote command pushes, reload profile requests, and other sensitive events. DNS health checks help panel operators monitor whether configured endpoints are responsive. Support contacts entered by the owner account are used to present the correct support path on the public site and other customer-facing flows. None of this information is gathered just for curiosity; it is tied directly to onboarding, support, business operations, or security integrity.
4. Device Registration and Activation Data
One of the most important privacy areas in this platform is device registration. When the application starts, it may generate or display a device ID and an app-level MAC-style identifier so that the installation can be recognized in the panel. That registration process is what allows the device to appear for approval, code generation, activation, renewal, or suspension. Without that step, the panel could not reliably distinguish one installation from another, and the reseller workflow would become error-prone. The platform therefore keeps records of pending devices even before activation is completed, because the entire business process depends on being able to match a physical installation to a panel-side record.
Activation data is treated as operationally sensitive. A generated activation code, a pending status, an assigned DNS slot, assigned app preferences, and the transition from pending to enabled all matter because they determine whether the app is permitted to proceed and how it behaves after activation. We store that state so the panel can enforce device access properly, prevent accidental cross-routing, keep portal URLs out of customer-facing fields, and show administrators or resellers exactly which customer devices are live, pending, expired, or disabled. We may also store renewal-related data such as activation date and expiry date so the same record can be used for reminder popups, billing workflows, and support intervention. These fields are visible only to the roles that are authorized to manage the device within the reseller hierarchy.
5. Account Roles and Visibility Rules
The platform is intentionally role-based. The admin account has the broadest visibility and can manage global settings, reseller accounts, sub reseller access, device controls, pricing strategy, credits, security settings, and site branding. Resellers are restricted to the accounts, devices, DNS profiles, and credits that belong to their own business slice. Sub resellers are further limited to the users and devices they are allowed to manage. These role boundaries are not just convenience features. They are part of our privacy design, because they reduce unnecessary access to information and help ensure that panel users only see the operational data required to perform their own responsibilities.
We also use role logic to hide sensitive routing information or management controls where appropriate. For example, direct portal URL fields can be hidden from customer-facing app settings, and certain route or gateway visibility may be limited to admin-only contexts. Username change privileges can be restricted by role. Credit pullback, full account reset, global password actions, or high-level export access may be reserved for admin. These rules exist to keep the platform manageable, but they also reduce overexposure of system data. In other words, privacy on this platform is not only about storage; it is also about making sure that one user’s ability to view, edit, or export information is aligned with legitimate business responsibility.
6. Security, Authentication, and Logs
We use account passwords, session handling, optional two-factor authentication, IP allowlisting, login attempt tracking, and audit logs to help secure panel access. Login records may include timestamps, attempted usernames, success or failure outcomes, and session status. Audit records may capture important administrative events such as password updates, profile changes, credit actions, DNS modifications, device assignment changes, plan configuration changes, and account status changes. These records are not public-facing. They exist to help platform owners review who did what, when it happened, and whether corrective action is needed if there is a support issue or suspected misuse.
No system can honestly promise perfect security, but our goal is to apply proportionate controls to the kind of data the platform handles. Role permissions, login protections, encoded app route values, hidden customer portal fields, and structured audit trails are meant to reduce the risk of accidental misuse or silent tampering. Device activation state is controlled by the panel instead of relying only on customer-side behavior. Sensitive management routes can be hidden from non-admin roles. Operators can also use support contact settings, logout flows, session review, and account status controls to respond quickly if credentials are lost or a reseller relationship changes. Security is therefore part of privacy because visibility, access, and accountability are closely connected in a reseller platform.
7. Credits, Plans, and Billing Records
The panel supports commercial workflows such as customer plans, reseller credit balances, credit transfers, renewals, package pricing, and billing notes. To operate those features, the system may store plan names, duration, pricing, active or inactive status, credit movements, package allocations, renewal timing, expiry dates, and records of administrative actions related to commercial activity. This information is necessary for running the service as a reseller platform rather than as a simple single-user dashboard. It helps platform owners track stock, identify which account initiated a transaction, and understand how credits or plan benefits were applied over time.
Although credit and package data is business information rather than highly personal consumer data in the traditional sense, we still treat it as sensitive because it affects revenue, reseller trust, and dispute handling. Only roles with legitimate access should be able to see or change the relevant records. Administrators may have broader visibility so they can audit the ecosystem, while resellers and sub resellers are limited to their own scope. If the platform ever presents billing notes, plan descriptions, or export files, those are generated to support legitimate account management or business administration. They are not intended to be used for unrelated profiling or sold as third-party marketing intelligence.
8. Communications, Support, and Public Contact Paths
The public site may display support contact information such as WhatsApp or Telegram links configured by the owner account. When visitors or customers click those links, they leave the panel-controlled page and enter a third-party communication platform. Once that happens, the privacy and security practices of the messaging provider also matter. We do not control how Telegram or WhatsApp stores or processes messages outside our own site. Panel owners should therefore configure those links thoughtfully and understand that customer communication through external chat tools may be subject to the policies of those external services.
Within the panel itself, support notes, messages, broadcast records, or popup messages may be stored to help manage customer communication. For example, administrators may configure welcome notices, renewal reminders, operational notices, or targeted messages for certain groups. Those messages can include business information such as expiry guidance, support instructions, or service reminders. We recommend that panel users avoid putting unnecessary personal details into these fields. The platform is built for operational communication, not for storing sensitive personal histories or unrelated private data. Support records should stay focused on activation, device management, subscription service, and account administration.
9. Data Sharing and Disclosure
We do not position the platform as a data brokerage service, and we do not run it on the assumption that user records should be freely shared outside the system. Information may be disclosed only where needed to operate the service, comply with law, respond to legitimate security concerns, protect the rights of the platform owner, or support authorized role-based access inside the reseller hierarchy. For example, an administrator may need to review a reseller-managed device if there is a dispute or security problem. A reseller may need access to the devices and customer accounts that belong to that reseller. A sub reseller may need access to devices under that sub reseller’s own control. Those role-based disclosures are built into the function of the service.
If hosting providers, messaging tools, analytics tools, backup systems, or infrastructure partners are used in the future, the platform owner should evaluate those services carefully because they can affect how data is stored or transferred. We aim to keep the application logic transparent, but actual deployment choices matter. A locally hosted environment, a self-managed server, and a third-party cloud deployment each create slightly different operational risks. Panel owners are responsible for choosing a hosting approach that fits their own legal and commercial obligations. Where disclosure is required by law or lawful order, information may also need to be preserved or disclosed accordingly.
10. Retention and Deletion
We retain information for as long as it is needed to operate the platform, maintain account continuity, support audits, enforce activation state, handle renewal and expiry workflows, respond to disputes, or satisfy reasonable business and legal obligations. For example, device records may need to remain in the panel even after a customer stops using a service so that duplicate device confusion, renewal history, and operational changes can still be understood. Login and audit logs may need to persist for security review. Credit and plan actions may need to persist for accounting clarity and reseller trust.
That said, retention should not mean indefinite accumulation without purpose. Administrators can remove devices, disable accounts, change statuses, and manage the operational lifecycle of data. If a deployment needs stronger deletion standards, the panel owner should adopt a documented retention schedule and follow it consistently. Because the platform supports role-based business operations, deletion decisions may affect not only privacy but also billing integrity, customer support continuity, and dispute resolution. For that reason, deletion is best handled deliberately rather than casually. We recommend that owners review retention practices periodically and limit stored information to what remains useful for service operation or compliance.
11. User Choices and Responsibilities
Panel users have an important role in privacy. Administrators, resellers, and sub resellers should use strong passwords, enable two-factor authentication where available, review role permissions carefully, avoid unnecessary sharing of support links or credentials, and use the platform only for legitimate operational activity. They should also avoid storing excessive customer details in notes or message fields. The panel works best when it contains the data needed to activate, route, renew, support, and secure devices, but not unrelated personal data that adds legal risk without adding operational value.
Customers and app users should understand that the activation workflow is not anonymous. The app needs to register enough information for the panel to recognize the installation and decide whether it should be activated. If a customer does not want that operational registration to occur, the service cannot function as intended. Panel owners should therefore explain the activation model clearly to their own customers. Transparency at the point of installation often prevents confusion later. By continuing to use the service, the relevant parties acknowledge that the platform must process the account, device, and workflow information described here in order to provide the activation-first experience promised by the product.
12. International Access, Changes, and Contact
Because IPTV and reseller operations may involve users from multiple countries or regions, the platform may be accessed internationally depending on where it is hosted and who is invited to use it. That means data may be viewed or managed from different jurisdictions. We recommend that platform owners evaluate whether their local laws require additional notices, consent practices, or data handling procedures based on their customer base. This Privacy Policy is intended to provide a strong operational foundation, but no single generic document can replace region-specific legal advice for every deployment environment.
We may update this policy from time to time as the platform evolves, as features are added, or as the business model becomes more refined. Changes may include updates for new security controls, new public-site contact options, expanded export features, new plan logic, improved device registration handling, or changes in how role permissions are described. When a significant update is made, the latest version published on this site should be treated as the current policy. If you have questions about this Privacy Policy, about the information shown in the panel, or about support contact details associated with your deployment, the best first step is to use the support route listed on the site footer or the public support contact configured by the owner account.