This is already available. OneDev ships a SettingResource at /~api/settings with GET/POST for individual admin setting objects. All operations require administrator permission, same as the corresponding Administration pages. JSON bodies follow the setting beans the UI already edits.

Endpoints that match what you listed:

• System settings: GET/POST /~api/settings/system
• Authentication source: GET/POST /~api/settings/authenticator
• Mail: GET/POST /~api/settings/mail-service
• SSO providers: separate resource /~api/sso-providers (list/get/create/update/delete)

Other admin settings on the same resource:

• /settings/backup
• /settings/build
• /settings/groovy-scripts
• /settings/issue
• /settings/job-executors
• /settings/service-desk
• /settings/notification-template
• /settings/project
• /settings/pull-request
• /settings/workspace
• /settings/security
• /settings/ssh
• /settings/contributed-settings (plugin-contributed admin settings)

Branding is the notable exception among the items you mentioned: it is stored as an admin setting but is not currently exposed on SettingResource. A few other settings (alert, performance, AI, GPG, agent, pack, cluster, audit, workspace provisioners) are also UI-only today.

Interactive schema and example payloads are generated on each instance at https://<your-onedev-server>/~help/api (see io.onedev.server.rest.resource.SettingResource). Authenticate with an administrator access token, same as other /~api calls. Official docs: https://docs.onedev.io/restful-api

A PR is not needed for the core SettingResource — it is already there. If branding (or another missing setting) is required for your provisioning flow, say so and we can treat that as a feature request.

Thank you — confirmed, and apologies for the noise: verified on our instance that /~api/settings/system, /~api/settings/security and the /~api/sso-providers resource all work exactly as you describe. Our earlier probing used wrong path guesses (/settings/system-setting style), and we drew the wrong conclusion from the 404s.

One follow-up on the exception you noted: would a PR exposing BrandingSetting on SettingResource (and potentially some of the other currently UI-only settings such as alert/performance, at your discretion on scope) be welcome? We provision instances declaratively and branding is now the one piece we cannot set over the API. Happy for this issue to be closed either way.

Thanks for confirming.

A branding REST API is a reasonable follow-up for declarative provisioning. One design constraint: BrandingSetting currently stores only the instance name. Light/dark logos are PNG files in the site assets directory and are replicated to every cluster node (the same path Administration → Branding uses). A GET/POST of that bean alone would not cover logos.

Please keep any first change scoped to branding rather than also adding the other UI-only settings (alert, performance, and the rest).

@robin does OneDev want an external PR for this, and should the payload include the logos (base64 data URLs, matching the admin page) as well as the name?

Confirmed working as described — closing. Thanks for the fast and precise answer.