# Authoring Limit 사이트 설정에 대한 API 액세스 확인
**URL:** https://meta.discourse.org/t/confirming-api-access-to-authoring-limit-site-settings/407937
**Category:** Development
**Tags:** rest-api
**Created:** [7월 18, 2026, 8:21오전 UTC](https://meta.discourse.org/t/confirming-api-access-to-authoring-limit-site-settings/407937 "2026-07-18T08:21:13Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@philh](https://meta.discourse.org/u/philh)
#### Post date: [7월 18, 2026, 8:21오전 UTC](https://meta.discourse.org/t/confirming-api-access-to-authoring-limit-site-settings/407937/1 "2026-07-18T08:21:13Z")
API를 통해 동반 주제(companion topics)를 게시하고 Discourse에 동기화하는 통합 기능을 개발 중입니다. 설정 진단을 위해 포럼의 현재 작성 제한(authoring limits)을 읽어서, 주제 생성 또는 업데이트를 시도하기 전에 통합 기능이 콘텐츠를 사전 검사(preflight)할 수 있도록 하려고 합니다.
접근을 확인하려는 설정은 다음과 같습니다:
```plaintext
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
```
먼저 `/site.json`을 확인했는데, 이는 공개된 기능 힌트에 유용하게 접근할 수 있지만, 이러한 구체적인 작성 제한 설정은 노출하지 않는 것으로 보입니다.
비관리자 봇 사용자의 API 키를 사용할 때, 다음 요청은 `404`를 반환했습니다:
```plaintext
/site_settings.json
/admin/site_settings.json
/admin/site_settings
```
봇 사용자를 관리자로 만든 후, 다음 요청이 성공했습니다:
```plaintext
/admin/site_settings.json
/admin/site_settings
```
사용된 헤더:
```plaintext
Accept: application/json
Api-Key: ...
Api-Username: discussbridge-bot
X-Requested-With: XMLHttpRequest
```
`/site_settings.json`은 여전히 `404`를 반환했습니다.
질문 사항:
1. `/admin/site_settings.json`이 현재 사이트 설정을 읽기 위한 예상된 API 경로인가요?
2. 관리자 사용자 권한이 필요한가요, 아니면 이를 위한 지원되는 읽기 전용/세분화된 API 스코프가 있나요?
3. `/site_settings.json`은 비활성화(deprecated)되었거나, 플러그인에 의존하거나, 존재하지 않는 것이 정상인가요?
4. 통합 기능의 경우, 설정을 읽기 위해 관리자 권한이 있는 진단/설정용 키를 사용하고, 일반적인 주제/게시물 동기화 작업에는 권한이 적은 게시용 키를 사용하는 것이 권장되는 패턴인가요?
목표는 API를 통해 설정을 변경하는 것이 아니라, 설정 진단 중에 설정을 읽는 것입니다. 이를 통해 통합 기능은…
---
### Author:  [@RGJ](https://meta.discourse.org/u/RGJ)
#### Post date: [7월 18, 2026, 9:29오전 UTC](https://meta.discourse.org/t/confirming-api-access-to-authoring-limit-site-settings/407937/2 "2026-07-18T09:29:32Z")
1. `/admin/site_settings.json`입니다.
2. `client: true`가 설정된 항목을 제외하고는 관리자가 되어야 합니다. 해당 항목은 `/site/settings.json`에서 찾을 수 있습니다.
마지막 두 항목을 제외한 필요한 모든 설정은 `/site/settings.json`에서 찾을 수 있습니다.
하지만 허용된 그룹의 경우 메커니즘이 다릅니다. 특정 사용자로 `/site.json`을 요청하면 `can_tag_topics`와 `can_create_tags`를 확인할 수 있습니다.
1. AFAIK(본인의 지식 범위 내에서) `/site_settings.json`은 존재한 적이 없습니다.
2. 특정 사용 사례의 경우, 일반 사용자 계정과 #2의 패턴을 사용하면 충분할 것이라고 생각합니다.
---
### Author:  [@philh](https://meta.discourse.org/u/philh)
#### Post date: [7월 18, 2026, 4:37오후 UTC](https://meta.discourse.org/t/confirming-api-access-to-authoring-limit-site-settings/407937/3 "2026-07-18T16:37:43Z")
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:
```plaintext
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:
```plaintext
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:
```plaintext
categories:list
categories:show
posts:edit
posts:list
search:show
tags:list
topics:write
topics:update
topics:read
topics:status
```
With that granular key:
```plaintext
/t/{topic_id}.json works
/tags.json works
/categories.json works
```
but:
```plaintext
/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.
---
### Author:  [@philh](https://meta.discourse.org/u/philh)
#### Post date: [7월 24, 2026, 5:56오전 UTC](https://meta.discourse.org/t/confirming-api-access-to-authoring-limit-site-settings/407937/4 "2026-07-24T05:56:51Z")
> [@philh](#):
>
> 관리자 UI에서 해당 사이트 레벨 엔드포인트에 대한 액세스를 허용하는 명확한 세부 범위를 찾지 못하겠습니다.
>
> `/site/settings.json`과 `/site.json`에 대한 세부 범위 또는 허용된 URL 구성을 놓치고 있는 건가요?
제 이해로는 이것이 Discourse의 예상된 동작입니다. 관리자가 아닌 사용자가 /site/settings.json과 /site.json을 볼 수 있고 사용할 수 있기를 더 선호합니다.
이 사안이 [https://meta.discourse.org/c/contribute/feature/2로](https://meta.discourse.org/c/contribute/feature/2%EB%A1%9C) 넘어가는 것 같습니다.
참고로, Astro Discourse 통합은 순조롭게 진행되고 있으며 알파 릴리스를 앞두고 있습니다.
---
### Author:  [@philh](https://meta.discourse.org/u/philh)
#### Post date: [7월 25, 2026, 11:07오후 UTC](https://meta.discourse.org/t/confirming-api-access-to-authoring-limit-site-settings/407937/5 "2026-07-25T23:07:34Z")
> [@기능 요청: 관리자 권한 키 없이 사이트 설정에 대한 안전한 API 접근 허용](https://meta.discourse.org/t/feature-request-allow-safe-api-access-to-site-settings-without-an-admin-level-key/408523):
>
> 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…