Set up a destination
1
Open Integrations
Sign in as an admin and click Integrations in the app that should send the events. The apps keep separate destinations and secrets.
2
Choose the receiver
Select New integration, give it a name, and choose JSON event, Plain text, or Discord message. Enter the complete HTTPS destination URL. If authentication is needed, enter headers as a JSON object, for example
{"Authorization":"Bearer YOUR_TOKEN"}.3
Choose events and filters
Select the events you want. Filled Scout ID, instance ID, job name, and source address filters must all match exactly. Source address applies to Station only; leave it empty on Scout. Leave Include error and unusual-backup details off unless the receiver should get those details.
4
Save and test
Click Save, then Test saved destination. A test uses the saved URL and headers, even when the destination is disabled. It sends an
event: "test" sample and bypasses event filters. Unsaved form edits don’t affect the test.Service guides
- Discord: send messages to a channel webhook.
- n8n: trigger a workflow and route events to other services.
- ntfy: publish plain text to a topic.
- Generic HTTP POST: receive the event schema in your own service.
- Secrets and recovery: encryption, external keys, and custom-script secrets.
Events
Station receives forced uploads too. A retry of an already finalized upload doesn’t repeat its events. Station cannot report a Scout that stops sending backups; use a separate uptime or dead-man monitor for that.
Selecting both
job-finished and upload-finished sends two events for a successful Scout job. Selecting the same upload on both apps also produces separate notifications. Choose the event that matches what you want to monitor.
Payloads and templates
JSON event sends the event schema, including a renderedmessage. Plain text sends only that message. Discord message sends a JSON content field with mentions disabled and message length capped at 2,000 characters.
An empty template uses:
app, event, scout_id, scout_instance_id, job_name, status, stored_as, error_category, detail, and time. Surround each with {{ }}. Unknown placeholders become empty. Inserted values are encoded safely in JSON and aren’t interpreted as more template tokens.
detail is empty unless you enable Include error and unusual-backup details. Job names, IDs, archive filenames, and error categories are sent normally. Credentials, file contents, local paths, advertised URLs, settings, and source addresses are not automatically included. Source addresses can still be used for matching. Treat names and templates as public metadata and keep secrets out of them.
For plain text and Discord messages, add {{ detail }} to the template to display those opted-in details. JSON events include the separate detail field when enabled and nonempty.
Delivery behavior
Delivery is best effort. A bounded, in-memory queue holds up to 128 events; a full queue logs a warning and drops new events. Events aren’t replayed after a restart, and failed deliveries aren’t retried automatically. A destination has a five-second timeout by default, configurable from one to thirty seconds. HTTP2xx means accepted. Redirects and all other statuses fail; credentials aren’t forwarded to a redirect destination. Logs identify the integration by ID and report a safe failure description or HTTP status. They don’t include URLs, headers, request payloads, or response bodies. Use the receiver’s own execution history to investigate downstream processing.