Skip to content

Repository navigation

App Examples

Jump to bottom
Digitalcheffe edited this page Apr 19, 2026 · 1 revision

App Examples

Per-app source-side configuration — how to set up each app itself so the events it sends actually match what the NORA profile expects to receive.

The authoritative copies of these files live in the N.O.R.A repo at docs/examples/. If you clone or pull the repo, they're under docs/examples/ locally. This page summarizes each and links to the source.

For profile-side details (field mappings, display templates, severity rules) see Custom App Profiles. For the ingest endpoint contract see Webhooks.

Every example targets the same ingest URL shape: POST http(s)://your-nora/ingest/{token}. Get the token from the app's Settings slide-panel in NORA.

Webhook examples

DIUN — Docker image-update notifier

Configured entirely via environment variables in docker-compose.yml. DIUN watches your containers on a cron schedule (default every 6 hours) and POSTs to NORA when a newer image digest is found.

  • Set DIUN_NOTIF_WEBHOOK_ENDPOINT to your NORA ingest URL
  • DIUN_PROVIDERS_DOCKER_WATCHBYDEFAULT=true watches every running container
  • Opt individual containers out with the diun.enable=false label

📄 Full compose snippet and tips: diun-webhook-config.md

Duplicati — Backup success / failure

Duplicati sends HTTP notifications via advanced options. Three ways to wire it up — globally (every job), per-job, or via the CLI.

Key flags:

--send-http-json-urls=http(s)://your-nora/ingest/{token}
--send-http-message={"action":"backup.%PARSEDRESULT%","backup_name":"%backup-name%","result":"%PARSEDRESULT%","operation":"%OPERATIONNAME%","source_path":"%LOCALPATH%"}
--send-http-level=Success,Warning,Error,Fatal

%PARSEDRESULT% expands to Success, Warning, Error, or Fatal — the Duplicati profile maps these to NORA severities.

📄 Full setup (global, per-job, CLI): duplicati-webhook-config.md

Home Assistant — Any automation as an event

HA fires events into NORA via a rest_command entry in configuration.yaml. You call the command from any automation and pass your own subject, message, and severity.

Use cases in the reference doc:

  • Battery-low warnings (numeric_state trigger)
  • HA startup notifications
  • Door-left-open alerts (state trigger with for: duration)

📄 Full config + three worked automations: home-assistant-webhook-config.md

n8n — Workflow success + failure

Two pieces:

  1. A global Error Workflow set under Settings → Error Workflow — this catches every workflow failure without editing the failing flows. One HTTP Request node POSTing action: workflow.error.
  2. An HTTP Request node at the end of each workflow you want a success signal from — action: workflow.success.

Both nodes share the same body shape — unavailable fields send as empty strings.

📄 Full payload and node setup: n8n-webhook-config.md

Overseerr / Jellyseerr — Requests, issues, availability

Single webhook endpoint, one JSON payload covers every notification type. Enable all types in Settings → Notifications → Webhook and let the profile route by notification_type.

Covered notification types:

  • Request pending / approved / declined / available / processing failed
  • Issue reported / commented / resolved / reopened

📄 JSON payload and full type list: seerr-webhook-config.md

Tautulli — Plex activity + server events

Unlike Seerr, Tautulli needs a separate Notification Agent per trigger — one per event type. Each agent posts its own JSON body with trigger-specific Tautulli variables ({user}, {title}, {media_type}, etc.).

Triggers with pre-built payloads in the example:

  • Playback Start / Watched / Recently Added / User New Device
  • Plex Server Down / Up, Plex Remote Access Down / Up, Plex Update Available
  • Tautulli Update Available, Tautulli Database Corruption, Tautulli Plex Token Expired

📄 Per-trigger JSON bodies: tautulli-webhook-config.md

What's Up Docker (WUD) — Container image updates

HTTP trigger configured via environment variables, same pattern as DIUN. WUD watches running containers, checks registries on a schedule, and POSTs once per container when a newer image is found.

  • Set WUD_TRIGGER_HTTP_NORA_URL to your NORA ingest URL
  • ONCE=true stops WUD from re-notifying every watch cycle
  • THRESHOLD filters by version bump type (all / major / minor / patch)

📄 Full compose snippet + threshold reference: whatsupdocker-webhook-config.md

NZBGet — Post-processing webhook extension

NZBGet doesn't ship with a native webhook trigger, so the repo provides a small Python post-processing extension. It runs after every download and POSTs a structured payload describing the result.

Installation:

  1. In your NZBGet ScriptDir, create a folder WebhookNotifier/
  2. Drop main.py and manifest.json in it
  3. Reload NZBGet settings — WebhookNotifier appears under Extension Manager
  4. Set WebhookUrl to your NORA ingest URL
  5. Add WebhookNotifier to the post-processing list
  6. Use the Send Test Notification button to verify connectivity

The script maps NZBGet TOTALSTATUS values to actions (download.success / download.warning / download.failure) and adds a human-readable failure_reason from the PAR/UNPACK/HEALTH/etc. detail code. A failed webhook never blocks or fails the download.

📄 Python source: nzbget-webhook-main.py 📄 Extension manifest: nzbget-webhook-manifest.json

Using these as a starting point

  • Same app, different payload fields — customize the JSON body and then adjust the profile's field_mappings to match. See Custom App Profiles.
  • Different app, similar shape — steal the pattern (e.g. Duplicati's --send-http-message, HA's rest_command, WUD's env-var triggers) and write a new profile.
  • Testing — every example includes either a test/connection button or a manual way to fire a sample event. Watch the Events page while you test.

See also

Clone this wiki locally