Limitations

All interpreters share constraints on which ntfy features are available and how input is processed.

Unsupported ntfy Headers

The proxy builds outgoing headers from the interpreter's notification object. Only 8 headers are supported:

ntfy supports additional headers that the proxy does not forward: X-Click, X-Delay, X-Email, X-Call, and X-Template. Incoming request headers are not passed through — the proxy constructs all outgoing headers from the interpreter output.

The ntfy-json interpreter provides the most control, but is still limited to the 8 fields above. For the full list of ntfy-supported headers, see the ntfy publishing docs.

HTML Stripping

All interpreter output bodies have HTML tags removed and common entities decoded before delivery:

• & → &
• < → <
• > → >
• " → "
• ' → '
•   →

This applies after interpretation and before formatting, so interpreters can work with raw HTML internally.

Notification Suppression

Interpreters can return null to intentionally suppress a notification.

• HTTP contexts — Returns {"status": "ignored"} with HTTP 200.
• Email contexts — Silently drops the message. No response is sent to the sender.

Currently, the Statuspage interpreter uses suppression:

• statuspage — Component-only updates (whether or not a KV namespace is bound) and incident updates already sent (detected via KV).

Malformed JSON is an interpretation failure, not suppression. Both statuspage and ntfy-json return HTTP 422 for it, and a configured error topic can receive the diagnostic attachment.

Interpreter Availability by Context Type