@MrBurrBurr This is likely due to the fact that ASF API now prefers to return string representation of enum when possible. ASF-ui should be aware that enum values can be returned as underlying type or a string, where string should be interpreted as the name of the enum value.

Example:

      "BotConfig": {
        "AutoSteamSaleEvent": true,
        "BotBehaviour": "DismissInventoryNotifications, MarkBotMessagesAsRead",
        "Enabled": true,
        "HoursUntilCardDrops": 0,
        "OnlineStatus": "Offline",
        "PasswordFormat": "AES",
        "RedeemingPreferences": "KeepMissingGames",
        "TradingPreferences": "AcceptDonations, SteamTradeMatcher, MatchActively",
        "UseLoginKeys": false
      },
      "KeepRunning": true,
      "Nickname": "Archi",
      "SteamID": 76561198006963710,
      "WalletBalance": 4661,
      "WalletCurrency": "PLN"

The right thing to do is to start ditching the current /Api/Type and /Api/Structure in favour of /swagger/ASF/swagger.json, which follows OpenAPI specification and guarantees to display the correct types and structures for all the API objects that ASF sends to you and receives from you.

For example:

      "EOptimizationMode": {
        "enum": [
          "MaxPerformance",
          "MinMemoryUsage"
        ],
        "type": "string"
      },
      "EUpdateChannel": {
        "enum": [
          "None",
          "Stable",
          "Experimental"
        ],
        "type": "string"
      },

Or:

          "SteamUserPermissions": {
            "type": "object",
            "additionalProperties": {
              "$ref": "#/components/schemas/EPermission"
            }
          },

I looked into that spec and in fact the only problematic thing is detecting when enum is flags enum or not, but that can easily be solved by checking if the last value of the enum is All. It should work for all the cases of configs where we handle the enums, and even if it doesn't, it's still better to ask for type of a single enum instead of basing everything on it.

We've used our own API for describing configs because back then we didn't have swagger spec, now is a good time to consider rewriting it into something far more robust.

And of course, the fact that it follows OpenAPI spec means that it's almost guaranteed that there is some OpenAPI parser for javascript that you can use, I know that deluxghost used one for his python ASF_IPC library, entirely solving the issue of requests/responses interpretation.

This might need more time than I thought and I am in the middle of moving to a different country. Right now I can't say when I will have time for it, so I removed my assignment.

I've added a workaround for this in JustArchiNET/ArchiSteamFarm@18a9821 until it's resolved, so users won't need to suffer from this lack of compatibility.

Still, it'd be a good idea to move to swagger as I'd also want to remove no-longer-needed /Api/WWW/Structure and /Api/WWW/Type