Restrict and restore Comments

The Project Backend owns the decision to show a resource and its Comments. Use moderation:write only for state changes and moderation:read for direct state inspection. Every command must bind the credential, Comment, resource_type, and resource_id to one Project Client resource.

Shell example

: "${MINICENTER_URL:?set the Sandbox URL}"
: "${MINICENTER_PROJECT_CREDENTIAL:?set a Project Credential}"
: "${MINICENTER_COMMENT_ID:?set a Comment ID}"

curl --fail-with-body -X PUT "${MINICENTER_URL}/api/v1/community/comments/${MINICENTER_COMMENT_ID}/moderation" \
  -H "Authorization: Bearer ${MINICENTER_PROJECT_CREDENTIAL}" \
  -H 'Content-Type: application/json' \
  --data '{"resource_type":"article","resource_id":"article-42","state":"restricted","reason":"spam"}'

restricted requires one of spam, harassment, hate, violence, or sexual_content. Repeating the same PUT is idempotent. A restriction changes only moderation state: it does not delete or rewrite Comment content.

Restore visibility with {"resource_type":"article","resource_id":"article-42","state":"visible","reason":null}. visible requires a null reason.

Shell example

curl --get --fail-with-body "${MINICENTER_URL}/api/v1/community/comments/${MINICENTER_COMMENT_ID}/moderation" \
  -H "Authorization: Bearer ${MINICENTER_PROJECT_CREDENTIAL}" \
  --data-urlencode 'resource_type=article' \
  --data-urlencode 'resource_id=article-42'

Create, list, and reply responses also include moderation_state and moderation_reason. The Project Backend must omit or clearly replace restricted content according to its own display policy. If MiniCenter is unavailable, default to the Backend's last successfully observed state; this API does not provide a moderation queue, account restriction, or notification.