What's Changed

• Add anlageimmobilie REAL_ESTATE_TYPE for immoscout by @JannisStraus in #408
• feat: opt into ImmoScout tenant-network pool via &tenantNetwork=true by @sidneypiper in #410

New Contributors

• @JannisStraus made their first contribution in #408
• @sidneypiper made their first contribution in #410

Main Changes for v 26.0.0

Notification channels

Until now every job carried its own copy of your notification settings. Ten jobs meant ten copies of the same Telegram token, and rotating that token meant editing all ten.

A saved configuration is now a notification channel and lives in one place: Settings → Notification channels. Set one up there, pick it in as many jobs as you like, and edit it once when something changes. Every job that uses it follows.

What you can do now that you could not before

• Two channels of the same kind on one job. "Telegram → family chat" and "Telegram → work chat" can both be on the same search. The old form allowed one configuration per adapter type, full stop.
• Duplicate a channel instead of filling the whole form again. Useful when two channels differ only in a chat id.
• See where a channel leads. Every list shows the destination (the chat id, the Slack channel, the recipient address) so you can tell two Telegram channels apart at a glance.
• Delete is blocked while a job still uses a channel. The message names the jobs. A search can never quietly stop notifying you because somebody tidied up.

Sharing, for multi user instances

An administrator can make a channel available to everyone on the instance, or to other administrators only. Sharing lets other people send through a channel. It never shows them its credentials.

Anyone who wants their own variant can duplicate a shared channel: the copy is theirs, starts private, and asks them for their own credentials.

Credentials

Tokens, passwords, API keys and webhook URLs are now marked as secrets throughout. They are never sent to the browser of anyone who may not edit the channel, they are masked in the form, and they never appear in a destination column. Previously a job's full configuration, credentials included, was served to everyone who could see that job.

Upgrading

Your existing configurations are migrated automatically on first start. Identical configurations belonging to the same user are merged into one channel; anything that differs stays separate. Nothing is shared with other users by the migration, whoever owned a job owns its channels.

BREAKING!!! ->Downgrading to 25.x is not supported.<- Jobs store channel references after the migration, which older versions cannot resolve, and they would send nothing without reporting an error.

For anyone scripting against the API

POST /api/jobs now takes notificationAdapter as a list of channel references rather than inline configurations:

{ "notificationAdapter": [{ "configuredAdapterId": "V1StGXR8_Z5j" }] }

A bare array of ids works too. The old inline shape is ignored rather than migrated on the fly, so a script that still sends it will save a job with no channels attached.

Channels have their own endpoints under /api/notificationChannels (list, read, create or update, delete, and test). The list never includes field values; reading a single channel returns its secrets only to its owner or an administrator.

Full Changelog: 25.2.1...26.0.0