I’m hitting the same wall. The Style & Guidelines say not to use menu items for preferences and to use the manifest instead - but the Manifest Reference doesn’t mention anything about a preferences field.
I’ve been throwing things like `preferences`, `settings`, `config`, `options` as both arrays and objects, different field types like `text`, `integer`, `boolean`. The manifest dose not throw any errors but nothing ever shows up on the Preferences page.
Would love to know if anyone’s got this working, or if there’s a different approach I should be taking for per-account addon settings?
You’re not missing anything obvious here: our Add-on Style & Guidelines doc says to use preferences within the add-on manifest to add preferences to the account’s Preferences page, but the current Manifest Reference doesn’t document any preferences (or similar) manifest parameter.
Based on the public Manifest Reference, the only documented manifest capabilities are things like actions, menuItems, and webhooks, so adding keys like preferences / settings / config isn’t something we can point to as a supported, documented feature that will render a Preferences UI.
For per-account add-on settings, one documented approach is to store your configuration in your own system keyed by the account identifier provided in events (auth.accountUUID).
If you need an in-product configuration screen, the documented UI extension points are Actions and Menu Items, with Menu Items intended for larger UI that isn’t tied to a specific Job/Client (and they show under the Add-ons menu on web and the More… menu in the app).
If you’re building a Web Service Hosted add-on, the activation flow can also be used to collect initial configuration because users are redirected to your Activation URL when they click Connect.
Can you confirm whether you’re building a Simple Function add-on (NodeJS) or a Web Service Hosted add-on?