Feature Request: Webhooks

[Gabgobie]

This discussion is a continuation of the recently closed #4745

For reference I will try to paste the most relevant parts of the discussion below:

OP @expxx

Describe the feature you would like to see.

A webhook system, for client and admin activity updates. Like GitHub Webhook log. When someone does something, if the webhook is told to report it, it sends a POST req to the specified Webhook URL.

Could be useful for, example, action logging in discord, or updating things on a remote API for an addon, idk.

Describe the solution you'd like.

A new tab in the Admin Panel called Webhooks, you can edit or add webhooks here. In the screen that pops up, it'd show a list of everything that a person could do on the admin side, and on the client side as checkboxes. All the way from just navigating around the tabs / pages, up to changing a setting in a nest. Along with a text box at the top for the URL input.

(Not required, just my imagination)

@devnote-dev:

This is similar to the conversation in #4671, I think we can close those that one in favor of this issue.

Me:

[...] My usecase would be to have it create and destroy port forwards on my firewall according to allocations of active servers so my firewall doesn't unnecessarily look like swiss cheese even though most or all of my servers are shut down.

@LaserKaspar

[...]I currently. have a system that pulls new Backups from each node over night. Would be awesome if Backups could be pulled on creation.

@colonelpopcorn

+1 on this issue. I could see port forwards, notifications, and automation tooling as good use cases for this feature. Doesn't have to be everything, but I think a good start would be booting and shutting down servers.

[cydactyl]

+1 would be nice to be able to use ntfy.sh for server status notifications and what not.

[DaneEveritt]

Are there particular webhooks that would be most useful to have implemented up-front? There is quite a surface area to Pterodactyl so adding a webhook for everything would take an eternity to get implemented. If there are a select few that would be most helpful we could start with those, especially as a beta feature.

[electricsteve]

On top of server startup, stop, etc. events, I would like it to seperate between normal stop/restart and a detected crash (when the process exits unexpectedly), so I know something's wrong.

[Gabgobie]

On top of server startup, stop, etc. events, I would like it to seperate between normal stop/restart and a detected crash (when the process exits unexpectedly), so I know something's wrong.

This seems to be out of scope to me. The hooks are there to act on events that are manually initiated. You are suggesting something along the lines of monitoring/observability endpoints. I didn't check if there's already a FR for an OpenTelemetry integration but that's probably what you're looking for.

---

As for some of the other answers, I encourage you to use reactions (👍/⬆️) instead of +1 or agreement responses to avoid pinging everybody. Thanks

Best,
Gab

[electricsteve]

This seems to be out of scope to me. The hooks are there to act on events that are manually initiated. You are suggesting something along the lines of monitoring/observability endpoints. I didn't check if there's already a FR for an OpenTelemetry integration but that's probably what you're looking for.

What do you mean this is out of scope? And why would I want to get webhooks only for manually triggered actions? In my case I would want the opposite, I would want to get notified if my server crashed! Webhooks don't just serve one purpose you know?

[Gabgobie]

What do you mean this is out of scope?

The original feature request, although admittedly being written as more of an idea without a concrete need, focused on Ptero events triggering web requests where Ptero events are defined as direct user interactions with the panel. Including scheduled events like backups seems reasonable because they may very well just be a cron-alike trigger for a simulated user interaction. That means they share the request trigger with their manual counterpart.

You are asking for an alert mechanism. For that, the panel needs to observe the state of your game containers and trigger the request on its own in case one of them becomes unhealthy. Observability tools like Grafana already implement the necessary functionality for alerts, hence why I prompted you to look for or open a feature request centered around that. OTel seems to be the way to go here but is another huge chunk of work to implement.

Webhooks don't just serve one purpose you know?

To put it plainly, I can use my phone to hammer nails into the wall. That doesn't make it the best nor cheapest option to do so.

Implementing this has a cost to it and if this feature is to ever see the light of day, we should avoid getting sidetracked or expand the scope beyond what is reasonable though I obviously yield the final say on this to the maintainers of the project.

[devnote-dev]

To clarify: this is something already feasible via server websockets but those come with their own costs, but it's not unreasonable or out of scope for this feature request. There are also other use cases for this beyond alerts or telemetry where implementations using the current server websockets system are operationally heavy and, in some cases, difficult to manage.