[GH-ISSUE #1076] Triggering Webhook upon Receiving Notifications

BreizhHardware commented

2026-05-07 00:27:11 +02:00

Owner

Originally created by @afunworm on GitHub (Mar 29, 2024).
Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/1076

💡 Idea

💻 Target components

I understand that NTFY is intended to be a simple notification server. However, given that it has email forwarding feature, it would be extremely useful to implement webhook action upon receiving notifications.

It's as simple as this: When a notification is received, perform an outgoing Webhook.

This would greatly expand the capability of NTFY. For example, I can use NTFY as a central location to take in all notifications, then probably distribute the notifications somewhere else, like a Discord/Slack channel, or send them off to other applications to collect data, performing searches, etc. The possibility is endless.

If this sounds like it will deter NTFY from what it is doing, I'd love to learn to contribute to make this happen.

Thank you.

Originally created by @afunworm on GitHub (Mar 29, 2024). Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/1076  :bulb: **Idea**  :computer: **Target components**   I understand that NTFY is intended to be a simple notification server. However, given that it has [email forwarding feature](https://docs.ntfy.sh/config/#e-mail-notifications), it would be extremely useful to implement webhook action upon receiving notifications. It's as simple as this: When a notification is received, perform an outgoing Webhook. This would greatly expand the capability of NTFY. For example, I can use NTFY as a central location to take in all notifications, then probably distribute the notifications somewhere else, like a Discord/Slack channel, or send them off to other applications to collect data, performing searches, etc. The possibility is endless. If this sounds like it will deter NTFY from what it is doing, I'd love to learn to contribute to make this happen. Thank you.

BreizhHardware

2026-05-07 00:27:11 +02:00

closed this issue
added the
enhancement
label

BreizhHardware commented

2026-05-07 00:27:12 +02:00

Author

Owner

@binwiederhier commented on GitHub (Mar 29, 2024):

Performing outgoing HTTP requests to untrusted servers is a security issue. Here are just a few dangerous things, but I'm sure there are more:

Webhook URL is "http://127.0.0.1:1000", "http://127.0.0.2:1001", ... -- This allows port scanning localhost
Webhook URL is "http://ntfy.sh/mytopic/publish?webhook=http://ntfy.sh/mytopic/publish..." -- This makes ntfy call itself and could potentially be used for recursion
Webhook URL is "http://victim-site.com/abc" -- This can let ntfy participate in illegal scanning/probing/attacking of other sites using ntfy's IP

As a result of this, ntfy will never support calling outgoing HTTP requests for untrusted URLs.

I hope you understand

@binwiederhier commented on GitHub (Mar 29, 2024): Performing outgoing HTTP requests to untrusted servers is a security issue. Here are just a few dangerous things, but I'm sure there are more: - Webhook URL is "http://127.0.0.1:1000", "http://127.0.0.2:1001", ... -- This allows port scanning localhost - Webhook URL is "http://ntfy.sh/mytopic/publish?webhook=http://ntfy.sh/mytopic/publish..." -- This makes ntfy call itself and could potentially be used for recursion - Webhook URL is "http://victim-site.com/abc" -- This can let ntfy participate in illegal scanning/probing/attacking of other sites using ntfy's IP As a result of this, ntfy will never support calling outgoing HTTP requests for untrusted URLs. I hope you understand

BreizhHardware commented

2026-05-07 00:27:12 +02:00

Author

Owner

@afunworm commented on GitHub (Mar 29, 2024):

Performing outgoing HTTP requests to untrusted servers is a security issue. Here are just a few dangerous things, but I'm sure there are more:

Webhook URL is "http://127.0.0.1:1000", "http://127.0.0.2:1001", ... -- This allows port scanning localhost

Webhook URL is "http://ntfy.sh/mytopic/publish?webhook=http://ntfy.sh/mytopic/publish..." -- This makes ntfy call itself and could potentially be used for recursion

Webhook URL is "http://victim-site.com/abc" -- This can let ntfy participate in illegal scanning/probing/attacking of other sites using ntfy's IP

As a result of this, ntfy will never support calling outgoing HTTP requests for untrusted URLs.

I hope you understand

Hello.

Thank you so much for the explanation. I overlooked the fact that I was using the self hosted version, which was also the publicly available versions hosted by ntfy and other contributors. This would, in fact, raise a lot of security concerns, to perform unwanted outgoing webhooks, since there are public users that can access the platform.

Is it possible for you to let me know where in the script you started to send out the notifications to the client? I am thinking of digging deeper and maybe forking it just for my own use. I understand it shouldn't be done publicly, but the possibilities of NTFY being able to do these things are so appealing to me.

I apologize in advance for asking this, but are you available for hire if I'd like to make this work just for me? I only need a simple script to be activated every time a notification is received.

Either way, this is an extremely great project and I can't think of a single day I didn't use it since I discovered it.

Thank you so much.

@afunworm commented on GitHub (Mar 29, 2024): > Performing outgoing HTTP requests to untrusted servers is a security issue. Here are just a few dangerous things, but I'm sure there are more: > > * Webhook URL is "http://127.0.0.1:1000", "http://127.0.0.2:1001", ... -- This allows port scanning localhost > * Webhook URL is "http://ntfy.sh/mytopic/publish?webhook=http://ntfy.sh/mytopic/publish..." -- This makes ntfy call itself and could potentially be used for recursion > * Webhook URL is "http://victim-site.com/abc" -- This can let ntfy participate in illegal scanning/probing/attacking of other sites using ntfy's IP > > As a result of this, ntfy will never support calling outgoing HTTP requests for untrusted URLs. > > I hope you understand Hello. Thank you so much for the explanation. I overlooked the fact that I was using the self hosted version, which was also the publicly available versions hosted by ntfy and other contributors. This would, in fact, raise a lot of security concerns, to perform unwanted outgoing webhooks, since there are public users that can access the platform. Is it possible for you to let me know where in the script you started to send out the notifications to the client? I am thinking of digging deeper and maybe forking it just for my own use. I understand it shouldn't be done publicly, but the possibilities of NTFY being able to do these things are so appealing to me. I apologize in advance for asking this, but are you available for hire if I'd like to make this work just for me? I only need a simple script to be activated every time a notification is received. Either way, this is an extremely great project and I can't think of a single day I didn't use it since I discovered it. Thank you so much.

BreizhHardware commented

2026-05-07 00:27:12 +02:00

Author

Owner

@wunter8 commented on GitHub (Mar 29, 2024):

You can use this to activate a script every time a notification is received on a specific topic: https://docs.ntfy.sh/subscribe/cli/#subscribe-to-multiple-topics

@wunter8 commented on GitHub (Mar 29, 2024): You can use this to activate a script every time a notification is received on a specific topic: https://docs.ntfy.sh/subscribe/cli/#subscribe-to-multiple-topics

BreizhHardware commented

2026-05-07 00:27:12 +02:00

Author

Owner

@afunworm commented on GitHub (Mar 30, 2024):

You can use this to activate a script every time a notification is received on a specific topic: https://docs.ntfy.sh/subscribe/cli/#subscribe-to-multiple-topics

This looks very promising! One last question, how do I pass the data to the script though? NTFY will have the body and the title, and optionally the tags, priority, etc. Is it possible to access these variables within the script?

EDIT: Never mind, there's a section for the variables. I'll play with it.

Thank you again, so, so much!

@afunworm commented on GitHub (Mar 30, 2024): > You can use this to activate a script every time a notification is received on a specific topic: https://docs.ntfy.sh/subscribe/cli/#subscribe-to-multiple-topics This looks very promising! One last question, how do I pass the data to the script though? NTFY will have the body and the title, and optionally the tags, priority, etc. Is it possible to access these variables within the script? EDIT: Never mind, there's a section for the variables. I'll play with it. Thank you again, so, so much!

BreizhHardware commented

2026-05-07 00:27:13 +02:00

Author

Owner

@afunworm commented on GitHub (Mar 30, 2024):

You can use this to activate a script every time a notification is received on a specific topic: https://docs.ntfy.sh/subscribe/cli/#subscribe-to-multiple-topics

Hello.

I played with it for a bit and realized the 'run a command for every notification only' works when you subscribe to a topic using CLI, then publish a message via CLI. In other words, a topic test in CLI is different than a topic test subscribed via other methods, such as web UI or mobile apps. When a message is published through methods such as HTTP, email, etc., to the topic test that was subscribed to from the Web UI, for example, it won't trigger the command set for the test topic from the CLI.

Is there any way to use the 'run a command for every notification' function from the CLI while still utilizing the ease of publishing a message from the other method, such as HTTP, email, etc.?

Thank you.

@afunworm commented on GitHub (Mar 30, 2024): > You can use this to activate a script every time a notification is received on a specific topic: https://docs.ntfy.sh/subscribe/cli/#subscribe-to-multiple-topics Hello. I played with it for a bit and realized the 'run a command for every notification only' works when you subscribe to a topic using CLI, then publish a message via CLI. In other words, a topic `test` in CLI is different than a topic `test` subscribed via other methods, such as web UI or mobile apps. When a message is published through methods such as HTTP, email, etc., to the topic `test` that was subscribed to from the Web UI, for example, it won't trigger the command set for the `test` topic from the CLI. Is there any way to use the 'run a command for every notification' function from the CLI while still utilizing the ease of publishing a message from the other method, such as HTTP, email, etc.? Thank you.

BreizhHardware commented

2026-05-07 00:27:13 +02:00

Author

Owner

@wunter8 commented on GitHub (Mar 30, 2024):

The ntfy sub command can react to messages sent from any client (Android, web, CLI, curl, etc.).

I'm guessing you sent messages to your self hosted server and that the ntfy sub command was misconfigured and was subscribing to the test topic on ntfy.sh instead of the test topic on your server

@wunter8 commented on GitHub (Mar 30, 2024): The `ntfy sub` command can react to messages sent from any client (Android, web, CLI, curl, etc.). I'm guessing you sent messages to your self hosted server and that the `ntfy sub` command was misconfigured and was subscribing to the `test` topic on ntfy.sh instead of the `test` topic on your server

BreizhHardware commented

2026-05-07 00:27:13 +02:00

Author

Owner

@afunworm commented on GitHub (Mar 30, 2024):

The ntfy sub command can react to messages sent from any client (Android, web, CLI, curl, etc.).

I'm guessing you sent messages to your self hosted server and that the ntfy sub command was misconfigured and was subscribing to the test topic on ntfy.sh instead of the test topic on your server

Hello.

I am using the Docker self hosted version. The command should be written inside the docker container at /root/.config/ntfy/client.yml, am I correct?

@afunworm commented on GitHub (Mar 30, 2024): > The `ntfy sub` command can react to messages sent from any client (Android, web, CLI, curl, etc.). > > I'm guessing you sent messages to your self hosted server and that the `ntfy sub` command was misconfigured and was subscribing to the `test` topic on ntfy.sh instead of the `test` topic on your server Hello. I am using the Docker self hosted version. The command should be written inside the docker container at `/root/.config/ntfy/client.yml`, am I correct?

BreizhHardware commented

2026-05-07 00:27:13 +02:00

Author

Owner

@wunter8 commented on GitHub (Mar 30, 2024):

No, for the root user, it should be at /etc/ntfy/client.yml

@wunter8 commented on GitHub (Mar 30, 2024): No, for the root user, it should be at `/etc/ntfy/client.yml`

BreizhHardware commented

2026-05-07 00:27:13 +02:00

Author

Owner

@afunworm commented on GitHub (Mar 30, 2024):

No, for the root user, it should be at /etc/ntfy/client.yml

Hello.

Is there a way to check if the server and the client are using the same host? I've made sure that inside the Docker Container, /etc/ntfy/client.yml has the default-host: https://myserver.com and /etc/ntfy/server.yml has base-url: https://myserver.com.

I am able to receive the notifications coming to the topic test (on PWA app) when I do ntfy pub test Hello!:

And it shows up everywhere:

But the nothing happens in the CLI subscription:

The /etc/ntfy/client.yml is pretty straight forward too:

default-host: https://myserver.com

# This token works
default-token: tk_my_super_secret_token
subscribe:
  - topic: test
    command: 'echo "Command run: $m" >> /etc/ntfy/logs.txt'

It feels like I'm getting really close as soon as I can figure this out somehow.

EDIT: I removed the default-host from /etc/ntfy/client.yml to use ntfy.sh to test, it worked. I subscribe to the topic from ntfy.sh/randomTopicName and the notification will go through the ntfy CLI. It's just when I switched it back to https://myserver.com, the CLI stopped receiving notifications.

Thank you for all your help so far. I truly appreciate it.

@afunworm commented on GitHub (Mar 30, 2024): > No, for the root user, it should be at `/etc/ntfy/client.yml` Hello. Is there a way to check if the server and the client are using the same host? I've made sure that inside the Docker Container, `/etc/ntfy/client.yml` has the `default-host: https://myserver.com` and `/etc/ntfy/server.yml` has `base-url: https://myserver.com`. I am able to receive the notifications coming to the topic `test` (on PWA app) when I do `ntfy pub test Hello!`: ![image](https://github.com/binwiederhier/ntfy/assets/5475479/ef9d0be4-3300-416d-a0f1-7562ff196e76) And it shows up everywhere: ![image](https://github.com/binwiederhier/ntfy/assets/5475479/2627a9f3-283f-4807-9d5a-3e3bae843e77) But the nothing happens in the CLI subscription: ![image](https://github.com/binwiederhier/ntfy/assets/5475479/ce577eda-bfdb-4e41-9599-926467fcaea0) The `/etc/ntfy/client.yml` is pretty straight forward too: ``` default-host: https://myserver.com # This token works default-token: tk_my_super_secret_token subscribe: - topic: test command: 'echo "Command run: $m" >> /etc/ntfy/logs.txt' ``` It feels like I'm getting really close as soon as I can figure this out somehow. EDIT: I removed the `default-host` from `/etc/ntfy/client.yml` to use ntfy.sh to test, it worked. I subscribe to the topic from `ntfy.sh/randomTopicName` and the notification will go through the ntfy CLI. It's just when I switched it back to `https://myserver.com`, the CLI stopped receiving notifications. Thank you for all your help so far. I truly appreciate it.

BreizhHardware commented

2026-05-07 00:27:13 +02:00

Author

Owner

@wunter8 commented on GitHub (Mar 31, 2024):

You need to do ntfy subscribe --from-config without including any topics in the command (since they are already listed in the config file)

And since ntfy pub test sends to your self-hosted server but ntfy sub test does not subscribe to your self-hosted server, that might be a bug in the code. I'd have to test something's myself.

@wunter8 commented on GitHub (Mar 31, 2024): You need to do `ntfy subscribe --from-config` without including any topics in the command (since they are already listed in the config file) And since `ntfy pub test` sends to your self-hosted server but `ntfy sub test` does not subscribe to your self-hosted server, that might be a bug in the code. I'd have to test something's myself.

BreizhHardware commented

2026-05-07 00:27:14 +02:00

Author

Owner

@afunworm commented on GitHub (Mar 31, 2024):

You need to do ntfy subscribe --from-config without including any topics in the command (since they are already listed in the config file)

And since ntfy pub test sends to your self-hosted server but ntfy sub test does not subscribe to your self-hosted server, that might be a bug in the code. I'd have to test something's myself.

I've spun up a new VPS and kept all the files docker-compose.yml & /etc/ntfy/server.yml the same, and the server works. I can subscribe to from another computer using NTFY ntfy sub and everything worked fine. As soon as I switched back to the other VPS, it stopped working.

Is there any particular port (besides the one ntfy server is on, in this case, 80) that needs to be opened for the polling? Besides the cache.db, user.db, webpush.db, /etc/ntfy/server.yml, /etc/ntfy/client.yml and docker-compose.yml, is there any other files that need to be preserved to replicate an instance at its 100%?

I tried using ntfy server with debug and there was no error shown up when subscribing or publishing at all. I'm not sure what the next step might be. If there is a hidden bug somewhere, how would you propose I diagnose it?

Thank you.

@afunworm commented on GitHub (Mar 31, 2024): > You need to do `ntfy subscribe --from-config` without including any topics in the command (since they are already listed in the config file) > > And since `ntfy pub test` sends to your self-hosted server but `ntfy sub test` does not subscribe to your self-hosted server, that might be a bug in the code. I'd have to test something's myself. I've spun up a new VPS and kept all the files `docker-compose.yml` & `/etc/ntfy/server.yml` the same, and the server works. I can subscribe to from another computer using NTFY `ntfy sub` and everything worked fine. As soon as I switched back to the other VPS, it stopped working. Is there any particular port (besides the one ntfy server is on, in this case, 80) that needs to be opened for the polling? Besides the `cache.db`, `user.db`, `webpush.db`, `/etc/ntfy/server.yml`, `/etc/ntfy/client.yml` and `docker-compose.yml`, is there any other files that need to be preserved to replicate an instance at its 100%? I tried using `ntfy server` with debug and there was no error shown up when subscribing or publishing at all. I'm not sure what the next step might be. If there is a hidden bug somewhere, how would you propose I diagnose it? Thank you.

Rows
Columns

[GH-ISSUE #1076] Triggering Webhook upon Receiving Notifications #756