I’m working on an integration that publishes and syncs companion topics into Discourse via the API. For setup diagnostics, I’d like to read the forum’s current authoring limits so the integration can preflight content before attempting to create or update topics. The settings I’m trying to confirm access for include: min_topic_title_length max_topic_title_length min_first_post_length min_post_length max_post_length max_tags_per_topic max_tag_length tagging_enabled create_tag_allowed_groups tag_topic_allowed_groups I first checked /site.json, which is accessible and useful for public capability hints, but it does not appear to expose these concrete authoring-limit settings. With an API key for a non-admin bot user, these returned 404: /site_settings.json /admin/site_settings.json /admin/site_settings After making the bot user an admin, these worked: /admin/site_settings.json /admin/site_settings Using headers: Accept: application/json Api-Key: ... Api-Username: discussbridge-bot X-Requested-With: XMLHttpRequest /site_settings.json still returned 404. My questions: Is /admin/site_settings.json the expected API path for reading current site settings? Is admin user permission required, or is there a supported read-only/granular API scope for this? Is /site_settings.json deprecated, plugin-dependent, or not expected to exist? For integrations, is the recommended pattern to use an admin-capable diagnostics/setup key for reading settings, while using a less-privileged publishing key for normal topic/post sync work? The goal is not to change settings via API, only to read them during setup diagnostics so the integration

It’s /admin/site_settings.json You need to be an admin, except for settings that have client: true, those can be found in /site/settings.json All settings you need, except for the last two, can be found in /site/settings.json. But for allowed groups, the mechanism works differently: if you request /site.json as a specific user, you can inspect can_tag_topics and can_create_tags. AFAIK /site_settings.json never existed. I think that, for your specific use case, you can get away with a regular user and using the pattern under #2.

Thanks @RGJ , this was exactly the missing distinction. I tested the paths against my forum and can confirm: /site/settings.json /site.json work with my current global/admin bot key. /site/settings.json exposes the numeric authoring limits I need, including: min_topic_title_length max_topic_title_length min_first_post_length min_post_length max_post_length max_tags_per_topic max_tag_length tagging_enabled And /site.json, when requested as the bot user, exposes: can_tag_topics can_create_tag That seems like the right pattern for setup diagnostics. One follow-up: I also tested a granular API key scoped for topic/post/category/tag publishing work: categories:list categories:show posts:edit posts:list search:show tags:list topics:write topics:update topics:read topics:status With that granular key: /t/{topic_id}.json works /tags.json works /categories.json works but: /site/settings.json 403 /site.json 403 I don’t see an obvious granular scope in the admin UI that allows access to those two site-level endpoints. Am I missing a granular scope or allowed URL configuration for /site/settings.json and /site.json? Because the keys are for an admin bot user, each key is admin-capable at the user level. The granular key only restricts which API endpoints it may call. If not, my practical setup during testing appears to be: a current global publishing key a global diagnostics key for setup checks that read site settings a granular publishing key candidate for normal topic/post/tag sync If the granular publishing key proves sufficient for normal sync, the original global publishing key could be retired, leaving: granular publishing key for runtime sync global/admin-capable diagnostics key for setup checks But that depends on whether the granular key can cover all normal publishing operations, and whether /site/settings.json / /site.json need to remain on the diagnostics side.

[image] philh: I don’t see an obvious granular scope in the admin UI that allows access to those two site-level endpoints. Am I missing a granular scope or allowed URL configuration for /site/settings.json and /site.json? As I understand it this is expected Discourse behavior. I would prefer it if a non-admin user was able to view/use /site/settings.json and /site.json Looks like this is headed to Feature - Discourse Meta FYI: the Astro Discourse integration is coming along, nearing Alpha release.

[image] Feature request: Allow safe API access to site settings without an admin-level key Feature As I understand it, requiring admin access for /site/settings.json and some information in /site.json is expected Discourse behavior. Discussion Bridge and similar integrations need a limited set of site configuration information for routine diagnostics, planning, and synchronization. Today this may require using an API key associated with an administrator. A read-only admin key prevents writes, but it can still expose everything the administrator can read. A global admin key carries an unneces…

Confirming API Access to Authoring Limit Site Settings

Development

philh July 25, 2026, 11:07pm 5

Topic		Replies	Views
Feature request: Allow safe API access to site settings without an admin-level key Feature rest-api	9	350	July 27, 2026
API to get composer settings? Development composer , rest-api	2	595	May 17, 2023
API user with granular access cannot read about.json \| Discourse MCP Product Support mcp	5	332	April 21, 2026
Hidden Site Settings Reference Guide Self-Hosting rails-console , advanced-setup , reference	0	1578	May 20, 2024
API rate limits Development rest-api	7	4495	November 8, 2021

Confirming API Access to Authoring Limit Site Settings

Related topics