Add native webhook action for automations

[tomerh2001]

Description

qui automations already support Execute External Program, and the docs even mention notifying external systems as a valid use case. That works as a workaround for webhooks today, but it still means setting up a shell script / curl wrapper, allowlisting executables, and handling request formatting outside qui.

For users who just want to call an HTTP endpoint when a workflow matches, a first-class webhook action would be much simpler and more portable.

Requested feature

Add a native Webhook automation action that can make an outbound HTTP request directly when an automation rule matches.

Proposed behavior

A webhook action could support:

• URL
• HTTP method (GET, POST, PUT, PATCH)
• Optional headers
• Optional request body / payload template
• Timeout
• Success/failure based on HTTP status
• Activity log entries with request outcome

If templating is supported, exposing the same kind of torrent/rule context already available to other automation features would make this especially useful.

Why this would help

This would reduce friction for common integrations such as:

• Home Assistant
• n8n
• custom media workflows
• lightweight notification/automation endpoints

Current workaround

The current workaround is to use Execute External Program and call a script that performs the HTTP request.

That is functional, but it adds extra setup for a use case that feels like a natural built-in automation action.

Related but different

This is different from the new webhook:// notification target work in #1623.

That PR is about notification delivery targets, while this request is about a per-workflow automation action that can be combined with automation conditions and other actions.

[tomerh2001]

Additional context after filing this:

• Prior related discussion: [FR] Add Notification / Webhook Support (Notifiarr, etc.) #1093 ([FR] Add Notification / Webhook Support (Notifiarr, etc.))
• That discussion was closed by: feat(notifications): add shoutrrr and notifiarr #1371 (feat(notifications): add shoutrrr and notifiarr)
• There is also now open webhook-target work in: feat(notifications): add webhook:// notification target #1623 (feat(notifications): add webhook:// notification target)

I think this issue is still a distinct request because it asks for a first-class per-workflow automation action that performs an HTTP request directly, rather than notification delivery or the current External Program workaround.

If maintainers feel this should be folded into the notifications/webhook work instead, happy to treat this as duplicate/adjacent context.

[nitrobass24]

I've put together an implementation for this in #1733. Here's a summary of what it supports and the design decisions we made:

What's included:

• Native Webhook automation action — configure a URL and optional headers, and qui will POST a structured JSON payload whenever the rule matches
• The payload automatically includes full torrent context: name, hash, category, tags, tracker, save/content paths, size, ratio, state, progress, seeds/leeches, added time, seeding time, uploaded/downloaded bytes, plus rule ID/name, instance ID/name, and timestamp
• Optional custom headers for auth tokens (e.g. Authorization: Bearer ..., X-API-Key: ...)
• Activity log entries with success/failure outcome and HTTP status
• Works with per-action conditions just like every other action type
• Fire-and-forget async execution so it doesn't block the automation run

Simplifications I made (can revisit later) to keep the UI Simple:

• POST only — no HTTP method selector. Covers the vast majority of webhook use cases (Home Assistant, n8n, custom endpoints)
• Standard JSON payload — no user-editable body template. The auto-built payload should be rich enough for most integrations, and avoids template syntax errors and JSON escaping footguns
• 30s timeout, not configurable — sensible default, keeps the UI simple

All three of these can be added later as optional fields on the existing action without a migration, if there's demand.

This is distinct from the webhook:// notification target work in #1623 — that PR is about notification delivery, while this is a per-workflow automation action that respects conditions and works alongside other actions.

[nitrobass24]

@tomerh2001 can you test this? I dont really have a use-case for sending a web hook in my environment so other than seeing it fire it's hard for me to tell if this will do what you are looking for.
Docker pull ghcr.io/autobrr/qui:pr-1733