Skip to main content

Transmission VPN

Turn the alerts Transmission VPN sends, such as a dropped VPN or a finished torrent, into ntfy notifications with the app's name before each title.

Input Handling

The interpreter reads the JSON alert that Transmission VPN posts to a destination whose service is ntfy-reverse-proxy. Every field below is required, and fields that aren't listed are ignored.

FieldTypeDescription
version1Payload format. Any other version fails.
appstringThe app that sent the alert, which must be transmission-vpn.
eventstringThe event's key, such as vpn-dropped, or test for Send test.
titlestringThe alert's title, such as VPN dropped.
messagestringThe alert's text.
priority1-5Priority level (1 = min, 3 = default, 5 = max).
tagsstring[]ntfy tags, such as the emoji shortcode warning.
occurredAtstringWhen the alert happened.
detailsobjectExtra data about the alert.

The notification uses title, message, priority, and tags. The event, occurredAt, and details fields must be present, but they don't appear in it.

Supported Events

Transmission VPN sends these alerts, each with a fixed priority and tags:

TitleEvent KeyPriorityTags
Saved secrets were removedsecrets-removed4 (high)key, warning
Sign-in lockedsign-in-locked4 (high)lock
VPN droppedvpn-dropped4 (high)warning
VPN back upvpn-restored3 (default)white_check_mark
Torrent finishedtorrent-finished3 (default)white_check_mark
Torrent errortorrent-error4 (high)x
Test notificationtest3 (default)bell

Test notification is what Send test sends, so a destination can't choose it as an event.

Context Setup

  1. Add an HTTP context — Run nrp, choose Manage Contexts > Add, pick HTTP, and choose Transmission VPN as the Interpreter.
  2. Deploy — Choose Deploy, then copy the context's URL and token from the Context reference list it prints.
  3. Add a destination — On Transmission VPN's Notifications page, select Add notification, choose ntfy-reverse-proxy as the Service, and paste the URL into Context URL. Paste the token into Context token if the context has one, enter a Name, and select Add notification to save it.
  4. Send a test — Select Send test on the destination, and check that [Transmission VPN] Test notification arrives on the context's topic.

Under Context URL, the dialog reminds you with Set the context's interpreter to transmission-vpn.

json
{
  "id": "transmission-vpn-example",
  "name": "Transmission VPN",
  "type": "http",
  "interpreter": "transmission-vpn",
  "topic": "downloads",
  "mode": "send-once",
  "show_visitor_info": false,
  "primary_server": "primary",
  "servers": ["primary"],
  "token": "replace_with_auth_token"
}

With this context, Transmission VPN posts its alerts to https://transmission-vpn-example.ntfy.example.com.

Notification Output

  • Title: [Transmission VPN] and the alert's title (e.g., [Transmission VPN] VPN dropped).
  • Body: The alert's message, with HTML tags removed as for every interpreter (see HTML Stripping).
  • Priority: The alert's priority, unchanged. Transmission VPN sends 4 for high-priority events and 3 for the rest.
  • Tags: transmission-vpn first, then the alert's tags (e.g., transmission-vpn, warning).

The interpreter sets no icon, actions, or Markdown.

Example

Transmission VPN posts this alert when the VPN has been down for a minute:

json
{
  "app": "transmission-vpn",
  "details": {
    "downSince": "2026-10-26T12:00:10Z",
    "lastError": ""
  },
  "event": "vpn-dropped",
  "message": "The VPN went down and hasn't come back after a minute. Transmission's traffic is blocked until it does.",
  "occurredAt": "2026-10-26T12:01:10.000Z",
  "priority": 4,
  "tags": ["warning"],
  "title": "VPN dropped",
  "version": 1
}

The proxy publishes it to ntfy with these ntfy headers and body:

text
X-Title: [Transmission VPN] VPN dropped
X-Priority: 4
X-Tags: transmission-vpn,warning

The VPN went down and hasn't come back after a minute. Transmission's traffic is blocked until it does.

ntfy shows the warning tag as an emoji and lists transmission-vpn below the notification.

Wrong App Error

A context reads alerts from one app, so a payload whose app names a different app fails instead of arriving under the wrong name. When that app has a built-in interpreter, the proxy answers with HTTP 422 and names the interpreter to use:

json
{
  "status": "error",
  "message": "This context reads Transmission VPN alerts, but the payload came from outpost. Set the context's interpreter to outpost."
}

If app contains an unknown producer key, the error instead says the app is unsupported and lists the supported interpreter keys. It never recommends configuring the unknown value.

  • Fix — Set the context's interpreter to the key the message names, or point that app at a context that uses its own interpreter.
  • Send test — The sending app reports that the test couldn't be sent, with HTTP 422 and up to 120 characters of this message as the reason.
  • Error topic — If the context has an error_topic and error_events includes interpretation (or is omitted), the proxy also sends an Interpretation Error with error-debug.json to that topic.
  • Other payloads — A non-empty body that isn't JSON, or JSON that isn't an alert (such as one without title, or with a version other than 1), also fails with HTTP 422 before the app is checked.

tip

For when each alert is sent, how to manage destinations, and every field in details, see Notifications in the Transmission VPN docs.