Thank you for the detailed response.

I'll dive into the properties set and retention create commands to see if the current implementations already cover our automation usecase.

Fair point about the API, then I'll continue to default to using PGUtil so that you at least have one less user depending on the API in case you want to supercede/deprecate it in the future :)

Best Regards
Nils Nilsson

To create feeds with different settings, you'll can use multiple pgutil commands like this:

$ pgutil feeds create --name=myNugetFeed --type=NuGet
$ pgutil feeds properties set --feed=myNugetFeed --property=dropPath --value=c:\bulk-import
$ pgutil feeds retention create --feed=myNugetFeed --deleteCached=true --keepVersionsCount=5 --keepUsedWithinDays= --rule=1

This was intentional and the "list/set" approach is by design.

As for why it differs from the API so much.... to be totally honest, we all hate the Feed Management API. Not just the endpoints themselves, but the code that implements it.

We planned to rewrite it, and perhaps the "list/set properties" was a part of that idea... but we eventually realized the only thing worse than the current Feed Management API would be having to maintain it along with a whole new version. So, we're stuck with it.

Anyway, we'd be open to expanding the options in pgutil, but it's not on our roadmap of priorities right now. We would very much welcome a pull request if there are properties you'd like to add:
https://github.com/Inedo/pgutil/tree/thousand/pgutil/Feeds/Properties

-- Dean