NetAdmit
Effective date: 25 September 2026 · Last updated: 25 September 2026
This Privacy Policy explains how NetAdmit (“we,” “us,” or “our”)
collects, uses, stores, and shares information when you use our captive-portal Wi‑Fi Service:
the guest portal, Customer (venue/ISP) dashboard and APIs, and related integrations
(the “Service”).
NetAdmit is a captive-portal provider for businesses (venues, hospitality, small ISPs, and similar).
Customers use NetAdmit so guests can get online after a portal step. Depending on how a Customer configures
their site, guests may only need to continue/acknowledge terms, or may need to verify identity or contact
details — including but not limited to phone number, email, name, or other fields the venue enables —
before the venue’s network equipment is instructed to authorize the device for a limited session.
Where a Customer enables messaging-based verification (for example via WhatsApp on
Meta’s WhatsApp Business Platform / Cloud API, one-time codes, or similar channels), this policy also
covers personal data processed in those flows.
1. Who is responsible
For the NetAdmit platform, the data controller is the NetAdmit service provider
(contact: [email protected]).
When a venue or ISP customer (“Customer”) configures NetAdmit for
their site, that Customer typically acts as an independent controller for guest data they collect
through their portal (for example contact details used for Wi‑Fi access and any marketing they run).
NetAdmit processes that data on their behalf to operate the Service. Guests should also review any
notices shown on the venue’s portal screen.
“Customer operators” who log into the NetAdmit dashboard are staff of the Customer, not the NetAdmit
service provider. Wi‑Fi controller accounts on venue hardware are separate from NetAdmit platform accounts.
2. Scope
This policy covers:
Guests who connect to Wi‑Fi and use a NetAdmit captive portal
People who use the NetAdmit dashboard or APIs on behalf of a Customer
Data received through messaging or identity providers a Customer enables for guest verification
(including Meta WhatsApp Business webhooks when WhatsApp-based auth is turned on)
When WhatsApp is used, Meta provides Cloud API as a processor/service provider to the business that uses it.
Meta’s own terms and policies also apply to WhatsApp traffic.
3. Information we collect
3.1 Guest / end-user (captive portal)
Device network identifiers supplied by the Wi‑Fi controller or portal URL,
especially client MAC address, and related captive-portal context (for example
AP MAC, SSID name, radio id, external site reference). MAC is used as a routing hint
to authorize the correct device on the LAN — it is spoofable and is not treated as strong identity proof.
Session and access records: session identifiers, site/org association, verification
method configured for the site, status, timestamps, access window, and authorize/deauth outcomes.
Verification and contact details the Customer requires, which may include
phone number, email address, name, and similar fields — only when that site’s portal flow asks for
or receives them (typed in the portal, confirmed via one-time code, or obtained through a messaging
channel the venue enables). Business Customers often keep these as guest leads subject to on-portal consent.
Messaging metadata when a messaging channel is used for verification
(for example provider message ids needed for delivery, matching, and idempotency). We do not operate
a full chat-history product for guests.
Consent / acknowledgment when the portal asks the guest to continue or accept
venue terms (click-through or equivalent).
Technical request data: IP address, user agent, and basic request logs/errors
from our hosting edge, used for security, rate limiting, and debugging.
3.2 Shared venue password (when enabled)
Guests may submit an on-site Wi‑Fi / venue password. We verify with a salted hash
stored for the site. The plaintext password is not returned by the API and is not intended to be logged.
3.3 Customer staff (dashboard / SaaS accounts)
Account identifiers such as email/login, authentication credentials (hashed secrets / tokens as applicable),
org and site membership, and administrative actions (for example ending a guest session or replaying a job).
Configuration data: sites, network bindings, policy, secrets references, billing-related records when enabled.
3.4 Vouchers and billing (when enabled)
Voucher serials and salted code hashes (full scratch secrets are meant
for print once; not stored in plaintext).
Commercial records when those product surfaces are live (amounts in minor currency units, statuses,
payment-provider event ids).
3.5 What we do not intentionally collect
No advertising tracking pixels on the guest portal.
We do not sell or rent personal information.
We do not require government ID for standard Wi‑Fi auth flows described above.
Complete the verification method the Customer configured (including matching one-time codes or messaging
confirmations) and associate verified contact details with the guest session / lead for that Customer’s site when applicable.
Operate the multi-tenant Service for Customers (orgs, sites, staff accounts, audit trail).
Improve reliability (retries, background cleanup, error classification)
without using guest personal data for third-party advertising networks.
Comply with law and respond to lawful requests.
Where portal consent text says so, allow the Customer to use guest contact details
for Wi‑Fi access and that Customer’s own communications — subject to the venue’s notices and applicable law.
5. Legal bases (where applicable)
Depending on jurisdiction, we rely on one or more of:
Contract / steps prior to contract — delivering the Wi‑Fi session the guest requested
Consent — where the portal or Customer obtains consent (including marketing uses described on-screen)
Legal obligation — when we must retain or disclose information
In Indonesia, processing may also be assessed under applicable personal data protection rules
(including UU No. 27 Tahun 2022 where it applies). Customers remain responsible for their own
guest-facing notices and lawful basis for marketing.
6. How we share information
Customers (venues / ISPs): Customer staff see guest and session data for their
org/sites only (site-scoped access). Guest contact details collected through verification are available
to that Customer as part of the Service.
Infrastructure processors acting on our instructions, which may include
cloud edge/hosting, managed databases, email/ops tooling we configure, and similar vendors required to run the Service.
Messaging and identity providers the Customer enables (for example Meta / WhatsApp when
WhatsApp-based verification is on): delivery and webhooks under that provider’s terms so we can complete verification.
Network equipment / controllers at the venue: we send authorize/deauth instructions
(device routing identifiers + duration and related portal context) so the LAN can admit the device.
Controller credentials are stored as site secrets.
Legal and safety: if required by law, regulation, or to protect rights, safety, and integrity of the Service.
We do not sell or rent personal information.
7. International transfers
Infrastructure may process data in regions where our processors operate (including outside the guest’s or
Customer’s country). We use reputable cloud providers and HTTPS in transit. Customers should choose NetAdmit
only if this processing model is acceptable for their compliance needs.
8. Retention
Guest sessions, leads, grants, jobs, audit events: retained while needed to operate the
Service and for the Customer’s history, until a deletion request is completed or a future retention schedule
is introduced. Long retention is the current default; purge/TTL may be added later without reducing this
policy’s commitment to honor deletion requests for data we control.
Messaging verification receipts / message ids: kept as needed for idempotency, security, and audit.
Customer staff accounts: while the account/org remains active, and afterward as needed for
security, dispute, and legal retention.
Backups: may lag primary deletion until rotated (backup lag is not a separate purpose of use).
9. Security
TLS for public HTTP endpoints
Secrets (controller credentials, app/webhook secrets, signing keys) kept out of the guest portal and source control
Webhook authenticity checks when configured (for example signed webhook headers with an app secret)
Rate limits and attempt limits on portal verify paths
Tenant scoping in application queries (org/site filters)
Sensitive secrets hashed at rest where designed (for example venue password hashes, voucher code hashes;
short-lived display copies of one-time codes only while a challenge is pending)
No method of transmission or storage is perfectly secure. Report suspected incidents to the contact below.
10. Your choices and rights
Subject to law and the Customer’s role as controller of guest leads, you may request to:
Withdraw consent where processing is consent-based (this may end Wi‑Fi auth methods that depend on that data)
Guests: start with the venue that operates the Wi‑Fi (they often control the lead).
You may also email us; we will route or act on platform-held data as appropriate.
Customer staff: contact us with the email on your account. We may need to verify control of the account/org.
11. Data deletion
To request deletion of personal data associated with NetAdmit (including data obtained through messaging
or other verification integrations used for Wi‑Fi access):
Email [email protected]
with subject line NetAdmit data deletion request.
Include: (a) phone, email, or other identifier used for portal verification if any,
(b) approximate venue/site or SSID if known,
(c) Customer staff account email if applicable,
(d) whether you want guest lead deletion, staff account deletion, or both.
We will verify the request (we may ask for a confirming message or other proof) and delete or anonymize
platform-held personal data we control within 30 days, except data we must keep for
security, fraud prevention, or legal compliance. Copies in encrypted backups may
remain until routine backup rotation completes; backup lag is not a separate use of your data.
If the data is controlled solely by a Customer venue, we will inform you and/or forward the request to that Customer when feasible.
A shorter standalone version of these steps is published at data-deletion.html for app-store / platform settings.
12. Children
The Service is aimed at venue guests and business Customers. It is not directed at children under 16
(or higher age required in your country). If you believe we stored a child’s data, contact us for deletion.
13. Cookies and similar technologies
The guest portal is a static page that talks to our API; we do not place third-party advertising cookies or pixels on it.
Essential technical storage (for example transient UI state) may be used by the browser.
Customer dashboards may use local storage or cookies as needed for session/auth when that UI is enabled.
14. Third-party services and links
Messaging platforms (including WhatsApp/Meta when enabled), cloud hosts, databases, and Wi‑Fi controller vendors
have their own privacy policies. NetAdmit is not responsible for third-party practices outside data they process
for us as described above.
15. Changes
We may update this policy as the product evolves. The “Last updated” date at the top will change.
Material changes for Customers may also be communicated through the dashboard or account email when appropriate.
Continued use of the Service after an update means the updated policy applies to subsequent processing.
This page is a publicly reachable Privacy Policy for platform reviews (including Meta Developer app settings).
It is not legal advice. Customers should obtain counsel for their jurisdiction and guest marketing practices.