Privacy notice.

Effective 27 October 2026. Ntfyx is operated by 湖南巴格智能科技有限公司 (Hunan Bage Intelligent Technology Co., Ltd.). Registered address: No. 20020-98, Building 5, Runhe International Plaza, Liuyanghe Street, Kaifu District, Changsha, HUNAN 410003, China mainland. Contact x@bagex.online for privacy, support, or security requests.

iPhone and Android are publicly available in their respective stores. This notice applies to the Ntfyx service, website and browser receivers; publication states and device-specific verification remain separate.

Ntfyx does not insert advertisements or unrelated promotional content into your Inbox, including on the Free plan. Ordinary messages come from sources you authorize: agents, tools, scripts and services, or a message you send yourself. You control these connections from your primary phone. Necessary pairing, connection and security status supports those connections.

Protected Topic CLI and agent message titles, bodies, options and replies are end-to-end encrypted on your devices. Public Topic names and messages are readable by the service and anyone with the Topic ID or link. The explicit fixed monitor-access and webhook-management questions and their signed phone answers are disclosed to the service for verification.

HTTPS push and webhook requests are readable by the service before encrypted delivery. Optional provider verification secrets are encrypted and stored by the service, then used in plaintext to verify the raw webhook body; they are hosted secrets, not hidden from the service. My Monitor reads the monitored address, rule and response; a public publisher knows the content it publishes.

The relay routes ciphertext and processes operational metadata such as identifiers, time, size and push tokens. Do not put secrets in monitored URLs or request examples. Independent security review is not complete. The service processes opaque Inbox, Topic, Source and receiver IDs, timestamps, sizes, request states and delivery metadata for authorization, routing, deduplication and deletion.

No Ntfyx account registration is required; personal data is still processed.

The service needs APNs device tokens, push environment, and relevant app/device versions to deliver notifications. Apple transaction identifiers and anonymous entitlement associations support purchase restoration, refunds, and abuse prevention. Network IP information is available during connections and abuse checks.

The Ntfyx application does not log message bodies, credentials, or raw IP addresses. Hosting providers may process network and security metadata under their own policies; application-level logging limits do not disable those provider records. Android uses FCM registration tokens and Firebase installation IDs for push delivery.

Firebase also processes app version and technical device/SDK user-agent metadata to provide, maintain and improve its service. Google Play purchase tokens, order/product/state information and opaque owner associations support verified rights, acknowledgment, restoration and refund reconciliation. Play Integrity processes request digests, app signing/version/licensing and device attestation signals for security.

No Advertising ID, Analytics SDK or Crashlytics SDK is integrated.

Cloudflare provides the globally distributed website, API, encrypted relay storage, and delivery queues. A RackNerd server runs the Apple gateway; Apple provides APNs and in-app purchases. These providers may process data outside your country. Cloudflare routing and recovery features do not constitute a promise of single-country residency.

Device and browser vendors independently process data under their own terms. Google provides Firebase/FCM, Play Billing, Developer API purchase verification and Play Integrity for Android; the isolated RackNerd Google gateway processes the necessary verification and delivery metadata.

Public messages and ordinary service ciphertext are retained at most 24 hours and within the Inbox capacity limit. Pending requests remain until their deadline; terminal request and answer data remain 24 more hours. Public-send idempotency receipts retain only IDs and hashes for seven days. Minimal idempotency and consumption tombstones last thirty days.

The Web cache keeps at most thirty days or 5,000 records, with active requests protected; iPhone history defaults to ninety days or 10,000 records. Revoked or invalid push tokens stop being used. Aggregate metrics contain no content or secrets. Cloudflare recovery copies may retain deleted records for up to 30 days.

No separate application-level message backup is exported. Recovery must preserve deletion and revocation records before reopening access.

Delete service data from the primary phone. Device copies and exported recovery packages are under your control and must be removed separately. Minimal deletion, revocation, and entitlement-generation records remain while the service operates to prevent old credentials or restored databases from reviving access.

Purchase identifiers and entitlement history remain to support purchase restoration and refund reconciliation; they do not have an automatic expiry in the current implementation. Contact us about these retained records. A recovery package restores keys only when valid; a purchase restore alone cannot decrypt old content.

Support cannot recover lost private keys.

• Request deletion without installing the app

Support reports are opt-in. Preview and redact the report locally before sending; never send private keys, pairing links, recovery codes, or message content. Support correspondence is used to resolve the request and is deleted within 90 days after closure unless a continuing dispute or legal obligation requires retention.

Depending on your market you may have access, correction, deletion, objection, restriction, portability, or complaint rights. Send requests to x@bagex.online. To protect an Inbox, we may need a signed ownership proof; do not send encryption secrets.

An invitation is a voluntary company gift for your own anonymous Inbox, independent of store purchases. The service receives the invitation during your confirmed, signed claim and stores its keyed hash, Inbox binding, grant times and revocation state. It does not obtain your encryption private keys. A gift does not cancel store renewal or restore another Inbox.

Inbox deletion removes associated gift bindings; invitation-level issuance/capacity audit records remain until administratively removed. Local saved codes are protected by device encryption and can be cleared in Settings.

The Chrome extension stores independent non-extractable receiver keys and an encrypted message cache in its own local database, separate from the Web Inbox. Local settings include language, appearance, notification delivery, preview choice and muted Topics; drafts and exact signed pending replies are kept to preserve their request binding.

It sends authorization credentials, routing identifiers and encrypted messages or replies to the Ntfyx API to provide its disclosed features. It does not read browsing history, unrelated pages or cookies, and does not use advertising or analytics SDKs. Message previews are off by default; enabling them allows decrypted titles and text in the operating system’s notification history, which the operating system controls.

Chrome must be running for background checks and notifications.

• Chrome extension: setup and publication status

The first Chrome receiver retains its local cache until the user removes it. Its storage is separate from the hosted Web Inbox. Disconnect clears the extension’s connection, keys, cached messages, drafts and pending replies, and attempts to revoke its receiver. If it is offline, also revoke the receiver on the primary phone.

Revocation cannot remotely erase already-delivered local copies. Ntfyx uses extension data only to provide and secure encrypted notification and reply features. It does not sell that data or use it for advertising. Its use of extension data adheres to the Chrome Web Store User Data Policy, including the Limited Use requirements.

• User Data Policy

In app versions that support notification sources, an explicit phone authorization creates a private subscription Topic. The service processes the selected plugin, subscription status, time zone, digest time and necessary routing metadata to deliver the requested content. A hosted publisher knows the public content it publishes.

It does not use your private agent messages or local search terms to generate digests. Reports contain the selected public event identifier and reason, without automatically attaching private message bodies. Mute, pause, unsubscribe and publisher blocking have distinct effects. These free content subscriptions are separate from auto-renewing store purchases.

• Notification source details and controls

When you enable HTTPS push, the hosted service processes the title, body and optional Session fields that you submit over TLS, then encrypts the notification for authorized receivers. This entry point is not sender-to-phone end-to-end encryption. The phone creates an independent send-only key; the service stores a verifier rather than disclosing the raw key.

Never submit your phone management token as the push key. Disable or rotate push access from the phone. The service does not log message bodies or raw push keys.

• HTTPS request and credential scope

When you create My Monitor checks, the service processes the configured public URL, name, expected rule, enabled and notification preferences, scheduling, status and recent bounded check results. A protected probe reads a bounded response to evaluate your rule; raw response bodies are not included in stored result history.

On an explicit setup request, up to 4,096 UTF-8 bytes of response text are returned to the editor temporarily without storing that sample. The service retains individual scheduled check outcomes for at most seven days; the existing app detail view shows up to twenty recent results. Numeric weekly aggregates for the current and previous reporting week, and their summary snapshots, expire no later than seven days after that week ends.

They contain no monitored URL, name, response body or credentials. URLs and rule text can reveal information about your service: do not include secrets. Disabling or deleting a monitor stops its future checks and per-monitor alerts. A weekly summary may still report checks that already ran before pausing or deletion.

Encrypted Inbox copies on the service follow a 24-hour retention period; device copies follow local history settings. Hosted alerts are encrypted after the service creates them, not before the service can read their inputs.

• Monitor controls and public URL limits

When you explicitly approve CLI monitor management, the service verifies that authorization question and primary-phone answer using a secret scoped to each signed recipient ciphertext. This reveals that authorization exchange, not the phone/root private keys or unrelated messages. The service stores its Source/Topic/root bindings, canonical requested scope, signed exchange, answer digest, expiry and revocation state.

Authorization records are removed seven days after the grant expiry; minimal security and replay controls follow the existing security metadata policy. A grant permits reading all monitor URLs, rules and recent results and managing monitors until revoked or expired.

• Monitor authorization and controls

Webhook management needs a separate phone-approved Source grant bound to its HTTPS sender and Topic. The fixed authorization question and primary-phone answer are explicitly disclosed for service verification. Raw child keys are created on the client and explicitly exported to a private file; the management API stores only key digests and cannot return a lost raw key.

The incoming webhook URL itself carries its bearer over TLS for validation. Metadata includes owner/phone/root/Topic bindings, key generation, expiry, signature mode and revocation state. A configured provider verification secret is instead held encrypted by the service and used in plaintext for raw-body verification.

Generic webhook input is processed before encrypted delivery. Revoking the management grant does not itself disable previously created sending keys; disable/delete or owner revocation provides that control.

• Webhook setup, controls and limits
• 中文 Webhook 接入

管理 Webhook 必须由主手机另行批准当前 Source、HTTPS 发送端和固定 Topic；仅本次固定授权问答明确披露给服务核验，不传手机或 Root 私钥。子 key 在客户端生成，完整发送 URL 只显式写入私有文件，管理 API 保存 digest、不能回读丢失的原始 key；真正的发送 URL 会经 TLS 携带 bearer 供服务内存校验。配置供应商验签时，独立验证 secret 由服务加密存储、解密后按原始 body 验签，因此是托管 secret，并非服务端不可见。Webhook 正文由服务处理后加密投递。撤销管理 grant 不会停用已经创建的发送 key；停止发送须停用/删除 key 或撤销 owner Source。普通 Agent 消息保留现有加密。

• 接入方法、权限与限额

We process routing identifiers, encrypted payloads and delivery state to provide the notification and reply features you request; purchase records to verify and restore paid access; and limited security records to prevent abuse and revoked access from returning. Where the GDPR or UK GDPR applies, the grounds are performance of our service contract, legitimate interests in securing and maintaining the service, and compliance with applicable legal obligations.

Optional device permissions and feature authorizations have their own controls. Where processing requires consent under applicable law, that consent must be specific and can be withdrawn; this notice is not blanket consent. Disabling a feature stops its future use but does not erase records needed for an existing request, security or a legal obligation.

The website and Web Inbox use system fonts, without requests to a third-party font service. Ntfyx does not integrate advertising analytics or session replay: it does not record your screen, keystrokes or decrypted conversations for behavioral analysis. The website does not set advertising or analytics cookies.

The Web Inbox and Chrome extension use local storage for selected language and appearance, public directory caches, connection keys, encrypted messages and pending replies needed for their features. These are not advertising profiles. You can remove local data in browser settings; disconnect the receiver first where possible, and keep any recovery material you need.

Hosting providers still process network and security metadata as described above.

Ntfyx is a general-purpose notification tool. It does not ask for a birth date, identity document or age estimate, and does not use age-based advertising or profiling. A store content rating describes content suitability; it is not proof of age or parental consent. A parent or guardian concerned about a child’s data can contact x@bagex.online to request review, access or deletion as applicable.

Do not send identity documents, private keys or message contents in the initial request. We will assess the applicable child-data rules and use proportionate verification; this notice does not replace any legally required parental consent.

Ntfyx does not require an email address to create an Inbox and has no in-app marketing-email signup. Contacting support does not subscribe you to marketing. User-authorized agent notifications, requested public-source digests and store purchase receipts are separate from operator marketing email. If we introduce marketing email, it must have a valid sending basis under the recipient’s applicable rules, identify the sender and postal address, and provide a clear, free way to stop all such email.

Promotional tracking or session recording is not enabled by accepting these service terms.

Contact x@bagex.online for access, correction, deletion, restriction, portability, objection or withdrawal of consent where applicable. You can also complain to the competent data-protection authority, including in your place of residence where that right applies. Requests do not require a paid plan or reinstalling the app.

We may ask for limited proof that you control the affected Inbox, but never your private key or recovery code. Encryption limits which content we can retrieve; it does not remove rights concerning the metadata we process. Ntfyx does not sell personal data, share it for cross-context behavioral advertising, or use it to make solely automated decisions with legal or similarly significant effects.

• x@bagex.online
• Delete data without installing the app

Starting with iOS 1.8.3, Ntfyx automatically saves an encrypted recovery file to your own iCloud Drive when available. Its encryption key uses iCloud Keychain. The file contains Inbox identity keys, Topic membership, pending identity operations and HTTPS credentials; it excludes message history and pending replies.

Ntfyx servers do not receive this file or its decryption key. Apple manages availability, upload and synchronization under your Apple Account settings. Settings shows backup status and provides manual encrypted export and import. Reinstalling on the same phone first checks retained Keychain data; a different device uses signed identity recovery.

Availability of iCloud Drive, iCloud Keychain and a completed backup affects restoration. Deleting an Inbox records its deletion so an older backup cannot reactivate it. You can remove cloud files through iCloud Drive; doing so can remove your recovery option.

Public Topic names and messages are plaintext to the service and anyone with the Topic ID or link. The service derives a Topic-specific, keyed one-way source label from the network address to support reporting and blocking; it does not expose the address in messages or use the label for advertising. The label identifies a network source, not a verified person: people sharing a network can share it, and changing networks can change it.

Public sends record acceptance of the current public-content terms. Reporting sends the selected public Topic, message or source identifiers and a reason; it does not attach private encrypted messages. Reports and selected public-content evidence are accessible only to authorized operators and retained for up to 30 days for review, even if the public feed has expired or the Topic or Inbox has been deleted.

The same report record supports idempotent retries during its retention period. Content removals and source or Topic restrictions remain as needed to enforce moderation. Local source and Topic blocks remain on the device until removed or local data is deleted. Contact x@bagex.online about a report, restriction or data request.

• Public content rules

Rich content can contain formatted text, metrics, tables and chart values. Protected Topic rich messages sent with ntfyx send / ntfyx_send are encrypted before leaving the sender, including the summary. Public CLI/MCP content and summaries are plaintext at the service and readable by anyone with the link.

Hosted HTTPS processes submitted rich content before encryption, under the existing HTTPS boundary. Rich rendering does not load remote images, execute HTML or add a third-party chart service.