Documentation for the pre-configured/saved destinations page?

Is there any documentation for the “Destinations” page in the ngclient? I couldn’t find any.

I assume it can be used to create destinations that can be re-used, but hopefully that can be confirmed before I start to rely on it!

Also to confirm: When I select a pre-configured destination for a backup job, are the values copied into the new backup or is there a reference back to the pre-configured destination placed into the backup config? (eg: If I setup a backup job and select a pre-configured/saved destination for it, do any changes to the pre-configured destination at a later date get reflected back to that backup job or vice versa if I edit the path, etc in the backup job itself?). Note: I know I could test this myself, but I didn’t want to accidentally rely on a feature that might not be working as intended that is later changed and messes up all my backups.

Mainly asking because It would be nice to setup a re-useable destination (for cloud so I don’t have to type credentials everywhere), but I was thrown off by it asking for a Path in the bucket (eg for B2). So I guess you are supposed to set that to some random value in the saved destination, then in each backup job change it to what it really should be? And then If I ever need to change the Application keys, etc, I’d have to manually change those for each job too (the saved destination mostly acts like a template for new jobs then)?

Thanks! And sorry for the maybe long-winded question, I tried my best to condense it.

There is currently no documentation for it.

Yes, the idea is that you can add a “template destination”, and then re-use that destination when you are setting up backups.

When you use a stored destination, the values are copied from the store destination configuration into the destination that you are configuring. You can then edit to adapt to your setup.

You can leave the path empty in the stored configuration, and then type in the desired path when creating a backup.

We do track which backups are using the stored destinations, so we could add a “push updates” later. The main use for this would be rotating credentials, and then you could update just the stored configuration and push it to the backup configurations. We have not yet implemented this feature because it quickly becomes hard to manage in all variations.

For now, you can mentally consider that all values are copied into the backup.
If we decide to implement the push feature, it will be opt-in or manually activated somehow.

Yes, for now that is how it works.

Is destination known by the name shown on Destinations page?
The name seems easy to drift. This might interfere with tracking.

I’ve seen two formats so far. One has a timestamp. Another a #,
for example, FTP #1 in Canary, but FTP timestamp in the Beta.

Save as connection string was unclear when I first saw that,
especially since the new UI also uses “target URL” on its screen.
Are these the same or is there a name change partway finished?

The message has no help on what the toggle does or why to use.

The toggle itself has an unusual behavior, as it seems a one-shot,
turning itself off, and sending in on “Continue” but not top-bar nav.
Fortunately there seems to be a final check on last screen Submit.

I sometimes think of template as partly filled, which gets into validation.
Maybe these are supposed to be well-filled, then maybe tweaked later.

One particular fill issue I just hit is the password. FTP seems to store it.
OneDrive gets an Alert saying “An error occurred”. Profiling logs shows:

2026-08-31 10:07:12 -04 - [Error-Duplicati.WebserverCore.DuplicatiWebserver-UnhandledException]: Unhandled exception in webserver request to /api/v2/connection-strings
System.ArgumentException: Connection string base URL contains password placeholder
   at Duplicati.Server.Database.Connection.AddConnectionString(ConnectionString cs)
   at Duplicati.WebserverCore.Endpoints.V2.ConnectionStrings.AddConnectionString(Connection connection, CreateConnectionStringDto input)
   at lambda_method399(Closure, EndpointFilterInvocationContext)
   at Duplicati.WebserverCore.Middlewares.HostnameFilter.InvokeAsync(EndpointFilterInvocationContext context, EndpointFilterDelegate next)
   at Duplicati.WebserverCore.Middlewares.LanguageFilter.InvokeAsync(EndpointFilterInvocationContext context, EndpointFilterDelegate next)
   at Microsoft.AspNetCore.Http.RequestDelegateFactory.<ExecuteValueTaskOfObject>g__ExecuteAwaited|130_0(ValueTask`1 valueTask, HttpContext httpContext, JsonTypeInfo`1 jsonTypeInfo)
   at Microsoft.AspNetCore.Http.RequestDelegateFactory.<>c__DisplayClass102_2.<<HandleRequestBodyAndCompileRequestDelegateForJson>b__2>d.MoveNext()

No, there is an ID for each stored configuration that is carried around.

Could be the # version was an older implementation, I have only seen the timestamp version.

You can avoid using it and the create/edit stored configurations from the “Destinations” page.

The idea with including it on the backend page was something like “Oh, I just typed in everything and know that it works, let’s save it for later”. But maybe that should be an actual button, so the action is explicit.

You can do either. You can store partially filled connection strings, or you can store fully filled ones.

That indicates that the password that is stored in the destination is somehow not being recognized. If you can explain how to reproduce it, we can fix it. It is most likely a case where the ID of the stored configuration is dropped so we can no longer retrieve the actual password.

Testing latest Canary 2.3.0.110_canary_2026-08-25, it might be what it does when creation is by the Destinations screen. Creation in job seems to use the timestamp.

Here the Destination screen shows both:

A press-when-desired button (if possible) with good text and bubble help might be less confusing than a self-clearing toggle. I usually expect what I set to stay set…

The GUI just sends it that way on some destinations. Examples on latest Canary:

ftp://127.0.0.1/test%201?auth-username=username&auth-password=password

aftp://127.0.0.1/test%201?auth-username=username&auth-password=***************

onedrivev2://<path>?authid=***************

This is done from job. Sometimes it sends the placeholder, and that gets rejected.
Based on timestamps, I think this is the profiling log rejection of the aftp asterisks:

System.ArgumentException: Connection string base URL contains password placeholder

EDIT 1:

The send is the BaseUrl value on the POST as viewed in Edge developer tools.

EDIT 2:

The new UI seems to have more implicit early actions in general compared to old.
Settings screen has some. I guess the tradeoff is that delaying until save request
risks someone forgetting to save. The risk of early implicit actions is surprise save
which is especially surprising in this one. Depending on navigation, sometimes the
early save is done by advancing to next screen, but that depends on how you do it.

Nothing earth-shattering, just hard to reverse-engineer, with lack of documentation.