Confirming API Access to Authoring Limit Site Settings

Development
1

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:

  1. Is /admin/site_settings.json the expected API path for reading current site settings?
  2. Is admin user permission required, or is there a supported read-only/granular API scope for this?
  3. Is /site_settings.json deprecated, plugin-dependent, or not expected to exist?
  4. 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

2

  1. It’s /admin/site_settings.json

  2. 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.

  1. AFAIK /site_settings.json never existed.

  2. I think that, for your specific use case, you can get away with a regular user and using the pattern under #2.

3

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:

  1. a current global publishing key
  2. a global diagnostics key for setup checks that read site settings
  3. 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:

  1. granular publishing key for runtime sync
  2. 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.