Documentation

HTTPS notifications, agent replies and hourly service checks

Phone notifications for Claude Code, Codex and scripts. Send to public Topics without pairing, or pair a protected Topic for encrypted CLI messages and verified phone answers.

Updated 28 October 2026

Choose notifications or verified answers

An existing public Topic needs no pairing or key. A private HTTPS push link is send-only and the service reads its input. Verified phone answers require a paired protected Topic; CLI and agent content on that path is end-to-end encrypted.

Send lightweight rich messages

Choose bounded native content, from ordinary text to Markdown, tables and charts. The CLI works without MCP.

Rich-message formats and complete example

Choose the notification workflow you need

Start with the outcome: a completed agent task, a question that needs your answer, an HTTP event, an optional call-style alert, or an hourly service check. Each guide covers one workflow, setup and its limits.

Start with an HTTPS notification

Yes. Open HTTPS Push on the phone to prepare MyNotify. The app generates a short sk_ send-only key and prepares your HTTPS sending link. Tap Send to receive hello, or copy the link. Open it with GET to send a notification using the final URL-encoded path segment, or keep the whole copied URL fixed and POST dynamic text, JSON or form content to it.

No app update or CLI is required for that URL. CLI 0.3.0 and local MCP can create independent wh_ sending keys after separate phone-approved webhook management authorization; monitor permission does not grant it. Revoking management does not itself disable existing sending URLs. The HTTPS service processes this plaintext request, then encrypts the message for authorized receivers.

Keep the whole sending link private because it includes your key. Rotate the key in the app to invalidate old links. It cannot read messages, manage the Inbox or receive agent replies.

MyNotify HTTPS request guide

Keep an eye on a public service

Open Discover → My Monitor and add a public HTTP or HTTPS address. Checks run every hour and require a final HTTP 2xx status; optionally require the response to contain specified text or a simple JSON object field equal to a chosen primitive value. Every check result is grouped into one Session per service in the system My Monitor Topic.

In app 1.5.3, preview text or JSON before entering your expectation. Only notify on failure is on by default: healthy results stay in the conversation silently; turn it off to receive an alert for every check. It does not consume your custom Topic allowance. The paired CLI and local MCP tools can manage these same items after explicit, revocable phone approval valid for up to 24 hours; the grant covers all My Monitor items.

The monitoring service reads the address, rule and response. Individual scheduled outcomes are kept for seven days. For weeks with check activity, a non-silent English summary with emoji is scheduled for Monday at 00:00 UTC, reporting counts, completed-check success rate and response time, subject to mute and delivery settings.

This is hourly monitoring, not real-time incident response or an SLA.

My Monitor and hourly checks

What Ntfyx does

Ntfyx sends task notifications and questions from AI agents, CLI tools and scripts to your iPhone, Android phone or authorized Web Inbox. Read progress, confirm a request, choose an option or write a reply beneath the original message. A Session ID keeps one task’s messages together. No Ntfyx account is required.

Just your agents and tools

Protected Topic messages from paired agents and tools are encrypted for your authorized devices. Public Topic content is visible to the service and anyone with its identifier or link. Send a message yourself or connect a source you want to hear from. Ntfyx does not insert ads or unrelated content. Your phone authorizes sources and can revoke them; Topics and quiet hours help you control alerts.

Who can send messages? See the FAQ

The CLI and agent conversation

First authorize a source on your phone. After that, messages and answers travel as encrypted, signed envelopes. The relay routes them; your devices interpret their content.

CONTENT PATH · Every receiver gets its own encrypted copy

CLI / AgentEncrypts & signs

Ntfyx relayCiphertext + APNs wake

iPhone / WebVerifies & decrypts

A signed, encrypted answer returns to the original source

The private QR authorizes the source after you name or choose a Topic on your phone. The iPhone authorizes each source and browser. The relay sees routing metadata, timing, sizes and request states, not the plaintext content. The Web receives only messages addressed to it after authorization.

Install the CLI. Run ntfyx connect and scan its fresh, one-time QR code in the phone app. Name or choose the Topic on your phone, then authorize the source. Keep the QR private.
Connect an agent through local MCP or a supported Claude Code / Codex hook, or use ntfyx send and ntfyx ask directly.
The source encrypts the title, body and context for each authorized receiver and signs the complete envelope. The relay validates and stores ciphertext. APNs or FCM can alert or wake the phone; foreground sync retrieves events. Push-provider acceptance alone does not prove delivery.
The phone or authorized browser verifies the sender, decrypts the content and presents the question. Allow, Deny, choice and text are all explicit answers.
Your receiver signs and encrypts the answer. The relay accepts the first valid answer for the pending request; another answer cannot replace it.
The original source verifies that the answer matches this request. An executor acquires a one-time claim and records consumption before continuing its own operation.

The pieces you control

An Inbox belongs to the primary phone identity. Topics separate work streams; public Topics allow anyone knowing the ID to read and send, while protected Topics require authorized sources and receivers. The phone manages both modes. A Session groups one task inside a protected Topic.

Piece	Purpose	Authority
Primary phone	Reads, replies and manages the Inbox.	Holds the management root and authorizes sources and browsers.
Topic	Groups a stream of work, such as one project.	The phone manages its signed membership list.
Source	A CLI, script or agent that sends messages.	Own sending and reply keys; no phone management key.
Web Inbox	An optional second screen for new messages.	Own receiver keys; only phone-approved access.

Start with the quickstart

Why the content stays private

For protected Topics, content is encrypted on the sending endpoint for the intended receivers. Content private keys stay on authorized endpoints; the relay does not receive those private keys. Each envelope also carries a signature, so a client checks who sent it and which request an answer belongs to.

Pairing binds the one-time secret to the service origin, device role and keys.

Protected content	What the service still sees
Protected message titles, bodies, options, answers, links and local display labels are encrypted. Topic API names are service metadata; protected clients use a fixed wire label.	Opaque routing IDs, timing, size, event kind, request state and delivery information.
A new browser receives independent keys and only newly addressed messages.	Its authorization, connection and revocation state.
Browser private keys are non-extractable WebCrypto keys; the local cache is encrypted.	A compromised endpoint or malicious served app code can still read content after decryption.

When something changes

A phone can revoke a source or browser. Old browser history is not shared with a newly authorized browser, and removing access cannot erase content that was already delivered. Pending requests expire at their deadlines; an old draft, late answer or lost connection must never turn into a fresh Allow.

When the agent needs your input

Completion alerts, tool permission requests and missing information need different integrations. Use the guide below to choose a supported permission hook or explicitly ask for a choice or text reply through the CLI or local MCP. Existing terminal prompts are not automatically forwarded.

Session conversations

CLI 0.1.3 and current clients group related messages into Sessions within a Topic. Confirm or choose on the original message; select Reply for a quoted text answer. CLI 0.1.3 includes --session-id and --session-name; run ntfyx upgrade to update. Read the guide for examples, standalone-message defaults and availability.

Sessions and message replies

Chrome notifications and replies

Chrome extension 0.2.4 is publicly listed on the Chrome Web Store. The current protected-message protocol requires Chrome 0.4.0, submitted and still under review as of 28 October 2026. The public 0.2.4 listing does not establish compatibility with that protocol. Use the phone-authorized Web Inbox while waiting for the compatible extension.

The extension provides desktop notifications, a phone-authorized Inbox and original-message replies. Each Topic needs its own phone authorization; Chrome must stay running for background checks. The current Web Inbox remains available.

Chrome extension: setup and publication status

Notification sources

Current public phone releases are iPhone 1.8.3 and Android 1.8.2. Open Discover in the iPhone or Android app, review a public notification source and confirm its subscription. No computer, CLI, pairing scan or Ntfyx account is needed. Receive future editions in its Topic; pause or unsubscribe from the phone.

Each source lists its coverage and schedule. Private agent messages are not used to generate these updates. Free includes 100 messages per UTC day, including up to 10 Call reminders and 10 answer requests, one monitor and one subscription. Notification-source subscriptions and public follows share the subscription allowance.

Topic count is not a paid entitlement. Public Topics support ordinary and rich messages; protected Topics also support verified answers and Call reminders.

All sources, schedules and phone availability

How Ntfyx compares with notification tools

Ntfyx combines task messages, answers attached to the original question, and Topic/Session history with an opt-in notification marketplace. A workflow can wait for a verified confirmation, choice or text answer. Push services and bots have different reply, encryption and integration features; compare their current official documentation and the setup your workflow needs.

Follow a complete workflow

Two reproducible walkthroughs show the steps, what was actually verified, and how to recognize failures or timeouts.

Develop a notification source

Run your own collector, submit its metadata and sample, and wait for phone review before publishing to subscribers. This is separate from a local agent plugin.

Official notification plugin development

More agent notification and reply workflows

Choose a guide by task completion, waiting for input and agent host.

Public Topics: send your first notification without pairing

Anyone with an existing public Topic ID or link can read and send without an account, pairing or key. The name and messages are readable by the service and anyone with the link; keep passwords, private logs and approval requests out of it. Public messages support text, Markdown and lightweight rich content, without answers, approvals or Call reminders.

Use a protected Topic for private messages, authenticated senders or signed answers.

Public Topics: send your first notification without pairing

Complete your own automation task

Start with a complete, copyable example and check the job result, send receipt and phone message separately.